Classifications

• • G—PHYSICS
  • G07—CHECKING-DEVICES
  • G07F—COIN-FREED OR LIKE APPARATUS
  • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
  • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
  • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
  • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
  • G06Q20/326—Payment applications installed on the mobile devices
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
  • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
  • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
  • G06Q20/327—Short range or proximity payments by means of M-devices
  • G06Q20/3278—RFID or NFC payments by means of M-devices
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
  • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
  • G06Q20/351—Virtual cards
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
  • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
  • G06Q20/353—Payments by cards read by M-devices
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/38—Payment protocols; Details thereof
  • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
  • G06Q20/409—Device specific authentication in transaction processing
  • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q30/00—Commerce
  • G06Q30/02—Marketing; Price estimation or determination; Fundraising
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
  • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
  • H04L63/0492—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload by using a location-limited connection, e.g. near-field communication or limited proximity of entities
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
  • H04L63/00—Network architectures or network communication protocols for network security
  • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities

Definitions

• the present invention relates generally to the field of telecommunications, and more specifically to the field of electronic tag reading applications using so-called “non-contact” technologies for short-distance radio reading.
• NFC Near Field Communication
• ISO International Standard Organization
• the applications of the second type are card emulation applications: a mobile terminal is used to secure electronic transactions between an application emulating for example a payment card on this terminal, and an external reading terminal which emits radio waves. short distance to read the data from this virtualized card on the handheld.
• the mobile terminal is then associated with a security element in which the card emulation application is stored.
• the mobile terminal is a GSM compatible mobile phone (according to the English "Global System for Mobile Communications") or UMTS (according to the English "Universal Mobile Telecommunications System")
• the UICC card from the English "Universal Integrated Circuit Card" is used as a security element. This element is typically used by the external read terminal to authenticate the map emulation application.
• components implementing these contactless technologies in the terminals limit the applications offered to users. Indeed these components operate either in a reading mode, allowing applications of the first type to operate, or in a card emulation mode, allowing applications of the second type to operate. They do not make it possible to operate both in a reading mode and in a card emulation mode, limiting the development of applications of the first type or the second type, without service logic making these two types of applications interact. .
• Discounted coupons stored in electronic tags currently only applications of the first type are available.
• a user approaches his mobile terminal of one of these tags, which triggers the reading of the corresponding discount coupon by a reading application on the mobile terminal, which then sends the data read to a remote server managing a user's loyalty account, for example.
• the data contained in the electronic tag are intended only for a predetermined application of a service provider.
• the electronic tag therefore transmits this data only to this predetermined application.
• This predetermined application to use the reading mode of the mobile terminal it is an application of the first type, which means that coupons using a contactless technology are not directly transmissible to a virtualized loyalty card in the UICC card of a user's terminal.
• the present invention aims to overcome the disadvantages of the prior art by providing a method and devices for reading an electronic tag, allowing a card emulation application in a terminal to read data contained in this electronic tag and which are intended for him.
• the invention proposes a method for reading an electronic tag storing data comprising an identifier, a terminal equipped with a short-distance radio reading module and a card emulation application, associated with said identifier and located in a secure element of said terminal, said method being characterized in that it comprises the steps of:
• an electronic tag is made capable of communicating directly with a card emulation application located in the terminal of a user, the authentication of this card emulation application being carried out beforehand by the module terminal, or by the electronic tag itself.
• a user whose terminal implements the invention is thus offered the possibility of updating a virtualized loyalty card on its terminal using a contactless technology, provided that the service provider associated with this loyalty card has an agreement with the issuer of the secure element.
• the invention enables card emulation applications to interact with electronic tag reading applications in a terminal to render services to users in a secure manner.
• the invention enables an electronic tag to securely transmit, via a reader application in a terminal, service tokens to a card emulation application in the same terminal.
• service tokens are for example telephone tokens, identification tokens or rights of use of a content.
• said reading module is an NFC reader and said electronic tag is a passive RFID tag.
• said NFC reader and said electronic tag is a passive RFID tag.
• This choice of implementation of the invention has the advantage of using a mature contactless technology, NFC technology being widely used.
• passive RFID tags is economically advantageous. Indeed these labels are very cheap and do not require power supply or network connection as opposed to active electronic tags.
• the step of establishing said communication session comprises a substep of mutual authentication between said card emulation application and said electronic tag.
• This characteristic corresponds to an alternative embodiment of the invention in which the authentication of the application is performed by the electronic tag.
• This variant has the advantage of minimizing the impact of the implementation of the invention on the terminal used.
• Securing exchanges between the electronic tag and the card emulation application is further reinforced by this substep.
• the card emulation application authenticates the electronic tag, which protects the card emulation application against unauthorized updating by a fraudulent electronic tag.
• said communication session uses a secure tunnel between said card emulation application and said electronic tag.
• This additional feature ensures the integrity of data exchanged end-to-end between the electronic tag and the map emulation application.
• the step of reading by said read module of said identifier is followed by a step of authentication of said card emulation application by said read module.
• This characteristic corresponds to another variant embodiment of the invention in which the authentication of the application is performed by the reader module.
• This variant has the advantage of not requiring complex electronic tags including authentication capabilities to implement the invention, at the cost of a slightly more complex implementation in the terminal than in the previous variant.
• the emulation application card is then authenticated both by the terminal itself and by the electronic tag during a sub-step of mutual authentication during the establishment of the communication session between the map emulation application and the electronic tag.
• said step of authentication of said card emulation application by said read module is preceded or followed by a step of authentication of said read module by an entity of said secure element.
• Authentication of the reader module allows the service provider related to the card emulation application to limit the use of the invention to certain terminals.
• these terminals are those for which the implementation of the invention conforms to a particular security standard, or to a signed charter with the service provider.
• said secure element when said secure element is a smart card inserted in said terminal, during said step of authentication of said card emulation application by said read module, the authentication data of said application of card emulation are provided by an authentication gateway contained in the operating system of said smart card.
• the authentication step of the card emulation application is then provided by an authentication gateway on the secure element of the terminal, forming part of a pre-existing application framework on the secure element of the terminal, or having been downloaded by the issuer of this secure element. For example, if this secure element is a smart card, the issuer is the telecommunications operator linked to this smart card.
• the invention also relates to a mobile terminal provided with a short-distance radio reading module, said mobile terminal being characterized in that said reading module comprises: means for reading an identifier stored in an electronic tag,
• the invention also relates to a smart card hosting a card emulation application associated with an identifier, characterized in that it comprises: an authentication gateway comprising means for authenticating said card emulation application with an electronic tag or a short-distance radio reading module of a mobile terminal,
• the invention finally relates to a computer program comprising instructions for implementing the method according to the invention, when it is executed on an integrated circuit, a microprocessor, a processor or a computer.
• the mobile terminal, the smart card and the computer program have advantages similar to those of the reading method according to the invention.
• FIG. 1 represents a mobile terminal according to the invention, connected to a communication network, and implementing the reading method according to the invention for reading an electronic tag
• FIG. 2 represents steps of the reading method according to the invention in a first variant embodiment of the reading method according to the invention
• FIG. 3 represents a flow diagram between the electronic tag read by the mobile terminal according to the invention and entities of the mobile terminal, in this first variant embodiment;
• FIG. 4 represents steps of the reading method according to FIG. invention in a second variant embodiment of the reading method according to the invention,
• FIG. 5 represents a flow diagram between the electronic tag read by the mobile terminal according to the invention and entities of the mobile terminal, in this second variant embodiment.
• the reading method according to the invention is used by the user of a mobile terminal T, shown in Figure 1, to read an electronic tag TAG.
• the electronic tag TAG is, in this embodiment of the invention, a passive RFID tag, such as micro-controller or Mifare® type, that is to say that it uses the energy provided by the short-distance radio waves emitted by a short-distance MR radio module in the mobile terminal T, to function.
• This operation corresponds to the activation and progress of a program stored in the tag TAG, in particular to transmit to the terminal T information also stored or calculated in this tag TAG.
• the radio module MR of the terminal T is, in this embodiment of the invention, a conventional NFC component, compliant with the ISO 14443 or ISO 15693 standard.
• the invention is not limited to reading passive RFID tags by NFC components, other non-contact technologies being also usable.
• the electronic tag TAG is an active electronic tag, that is to say that it has its own power supply, or includes an NFC reader operating in "peer-to-peer” mode.
• the electronic tag TAG and the radio module MR use infrared or optical non-contact technologies, or technologies such as ZigBee® or UWB (according to the English "Ultra-Wideband") to operate.
• the tag TAG contains so-called "public” DP data, which it transmits to any entity reading it without prior authentication, and so-called “private” DS data, intended for a card emulation CA application located in a data element.
• the public data DP contain in particular a service provider identifier ID associated with the AC card emulation application. In a variant, this identifier ID is more specifically associated with a predetermined service, or with a predetermined card emulation application. This is for example an "AID" identifier as standardized by the ISO 7816-5 standard and coded on 16 bytes.
• the security element ES hosting the application AC is a UICC card inserted in the mobile terminal T, the latter being a mobile phone compatible GSM or UMTS.
• the telecommunications operator of the user of the mobile terminal T has a TSM server for downloading card emulation applications in the terminals of his clients, located in the communication RES network to which the terminal T is connected.
• the AC card emulation application has thus been downloaded by the TSM server into the UICC card of the terminal T, thanks to an agreement between the telecommunications operator of the user and the service provider associated with the application of the AC card emulation.
• Downloading or updating applications in the UICC card of the T terminal by the TSM server is done by the OTA mechanism (according to the English “Over The Air"), standardized by ETSI (according to the English “European Telecommunications Standards Institute") and 3GPP (according to the English “Third Generation Partnership Project”) .
• the TSM server is managed by the service provider associated with the AC card emulation application, the download of the card emulation application AC in the UICC card of the terminal T by OTA mechanism being done after authorization of the telecommunications operator of the user.
• the invention is of course implementable in other types of terminals comprising various types of security elements.
• the terminal T is a fixed computer, a personal digital assistant PDA (or the “Personal Digital Assistant") or any other type of laptop
• the security element ES is a "Secure Multimedia Card” type memory card inserted in the terminal T, or in a secure controller connected to the radio module MR.
• the radio module MR of the terminal T communicates with a reader module ML in the terminal T, via an interface 12 in the Java programming language, in accordance with the specification "Java Requesf Specification (JSR) 257 standardized by the JCP community ("Java Community Process”)
• This reading module conventionally implements applications for reading electronic tags of the prior art in the terminal T.
• the applications contained in the security element ES are commonly called “cardlets”, and that the applications contained in the rest of the terminal T, such as those implemented by the ML reader module, are commonly referred to as “midlets”.
• the invention is not limited to card emulation applications developed as “midlets” and to reading modules developed as “cardlets”.
• the map emulation application AC is for example a native application of the security element ES
• the reader module ML is an Internet browser integrating a reading function. electronic tags.
• the operating system of the security element ES integrates a CG authentication gateway, application making the interface between the "cardlets” and the “midlets” for all that concerns the authentications of a "cardlet” by a “midlet” or a “midlet” by a “cardlet”.
• the authentication gateway CG uses the interface 11 to communicate with the read module ML.
• Step E1 is the reading of the service provider identifier ID on the electronic tag TAG by the read module ML.
• the ML reading module uses for that the request or "method" Java
• MR is represented by the message m1 in FIG.
• TAG then sends in response to the radio module MR, in a new frame
• the read module ML then decodes the received byte stream into a service provider identifier ID associated with the tag TAG. Thanks to a correspondence table stored in the read module ML, it deduces a corresponding application identifier, here an identifier of the card emulation application AC. It should be noted that this identifier is commonly called "AID" according to the ISO standard.
• Step E2 is the authentication of the card emulation application AC by the reader module ML.
• the reader module ML uses the method JSR177 "Connector.open” and sends an "exchangeAPDU" message on the interface 11, represented by the message m3 in FIG. 3, to the authentication gateway CG.
• This message includes an "authenticate” application message with in its arguments the identifier of the application AC determined in step E1, and a string of characters to be signed.
• the authentication gateway CG managing the authentication of the "cardlets” contained in the security element ES, has access to the private keys of these cardlets, stored in a register of the security element ES.
• the read module ML further checks, upon receipt of the signed string of characters, that this signature is correct. For this purpose, it uses the public key of the card emulation application AC, stored in a register accessible to the reader module ML on the terminal T. This public key has for example been downloaded by the user of the terminal T since.
• the TSM server via a GPRS connection (according to the English "Global Packet Radio Service") to the Internet, for example to time of his subscription to the service provided by the map emulation AC application.
• a GPRS connection according to the English "Global Packet Radio Service”
• the signature provided by the map emulation application AC is correct.
• the reader module ML sends a request JSR177 "Connector.open" represented by the message m5 in FIG. 3, to the authentication gateway CG. This request is based on the identifier of the map emulation application AC determined in step E1.
• the authentication gateway CG does not have access to the private keys of the "cardlets" contained in the security element ES.
• the authentication of the card emulation application AC is then carried out by the provision by the authentication gateway CG to the read module ML, of a proof that the issuer of the security element ES, by example the telecommunications operator of the user, has approved the AC card emulation application.
• the authentication gateway CG maintains for example a list of "cardlets” approved by the issuer of the security element ES, and signs the string of characters received in the message m3 with a secret key common to the transmitter of the security element ES and the reader module ML.
• Step E3 is the authentication of the read module ML by the authentication gateway CG.
• the authentication gateway sends on the interface 11 an "authenticate” request, represented by the message m6 in FIG. 3, to the read module ML.
• This request is proprietary, that is, it is not specified by JSR177. It is constructed similarly to the "authenticate” request of step E2, in particular it includes in its arguments a string of characters to be signed, but does not include an application identifier.
• the reading module signs the string of characters contained in this request with a private key associated with the terminal T and contained in a register accessible to the read module ML, according to the RSA mechanism. Then the reader module ML sends the string of characters thus signed to the authentication gateway CG, in a response to the request "authenticate” corresponding to the message m7.
• the authentication gateway CG further checks, upon receipt of the signed string of characters, that this signature is correct. For this it uses the public key associated with the terminal T, stored in a register of the security element ES. This public key will for example have been previously downloaded into this register using the OTA mechanism, by the telecommunications operator of the user. For the sake of clarity and simplification, it is assumed in this example of use of the invention that the signature provided by the read module ML is correct.
• the latter accepts, in this step E3, the connection request of the read module ML to the card emulation application AC, corresponding to the message m5.
• the authentication gateway CG requests the card emulation application AC to create a new connection interface dedicated to the reader module ML, and sends an identifier of this interface in a "exchangeAPDU" message, represented by the message m8 in FIG. 3, to the reading module ML.
• Other authentication mechanisms are of course usable in these steps E2 and E3, for example by using a shared secret code between the reader module ML and the card emulation application AC.
• the authentication data of the map emulation application CA are moreover not necessarily specific to this application AC, they are for example associated with an application security domain dedicated to the service provider identified by the identifier ID.
• an authentication gateway is optional: alternatively, the card emulation AC application directly receives the "exchangeAPDU" message containing the "authenticate” application message and authenticates itself with the read module ML in step E2. Similarly, alternatively, the card emulation AC application directly authenticates the read module ML in step E3, or does not require such authentication, that is to say that step E3 is limited to then at the connection of the reading module ML to the card emulation application AC.
• Step E4 is the establishment of a communication session between the card emulation application AC and the electronic tag TAG, the card emulation application AC using the reader module ML as a proxy server ( commonly called "proxy").
• proxy a proxy server
• the read module ML having received a connection interface identifier to the AC card emulation application at the end of step E3, it is able to send or receive application messages or "APDU" (according to the English “Application Protocol Data Unit") using the ISO 7816-4 application protocol, to or from the AC card emulation application.
• APDU Application Protocol Data Unit
• this step E4 it sends a message JSR177 "exchangeAPDU" containing such an application message and represented by the message m9 in FIG. 3, to the application AC card emulation.
• the application message contained in this message m9 indicates to the card emulation application AC that the reader module ML is ready to operate in proxy mode with an electronic tag external to the terminal T, here the electronic tag TAG.
• the card emulation AC application then sends the reader module ML, in response to the message m9, a first APDU application message represented by the message m10 in FIG. 3, in accordance with the standard JSR177.
• the content of this message is not intended for the reader module ML, but the electronic tag TAG, since the reader module ML now operates in proxy mode.
• the read module ML On receipt of the message m10, the read module ML transmits it as a message JSR257 "exchangeData" on the interface 12 to the radio module MR, this message "exchangeData" containing the first "APDU” application message.
• the radio module MR Upon receipt of the "exchangeData” message, the radio module MR sends a "Block” frame conforming to the ISO 14443 standard to the electronic tag TAG, this "Block” frame also containing the first "APDU” application message.
• This sending of information between the read module ML and the electronic tag TAG via the radio module MR is represented by the message m11 in FIG.
• this first application message "APDU" between the map emulation application AC and the electronic tag TAG in this step E4 makes it possible to establish a communication session with the electronic tag TAG, insofar as the following information exchanges between the card emulation application AC and the electronic tag TAG will be linked to this first application message.
• the electronic tag TAG responds to each application message "APDU” sent by the map emulation application AC, by an application message "APDU” response. For this, the electronic tag TAG sends this application message "APDU” response to the radio module MR in a frame
• the radio module MR then inserts the response "APDU” application message in the response to the "exchangeData” method received previously from the read module ML and corresponding to the "APDU” application message sent by AC map emulation application.
• the read module ML When the read module ML receives this response to the "exchangeData” method containing the response "APDU” application message, it inserts it into a new JSR177 "exchangeAPDU” message that it sends to the emulation application AC. Map.
• the sending of an "APDU” application message of response between the electronic tag TAG and the module of reading ML via the radio module MR is represented by the message m12 in FIG. 3, and the transmission by the read module ML of this application message "APDU" of response to the card emulation application AC is represented by the message m13.
• the card emulation AC application After receiving a reply from the TAG electronic tag, the card emulation AC application sends, if necessary, a new "APDU" application message to the electronic tag
• the content of the "APDU" application messages exchanged between the card emulation application AC and the electronic tag TAG depends on the implementation of the service provided by these two entities. For example, if this service requires high security of the exchanged data, the TAG electronic label and the card emulation AC application mutually authenticate each other before the TAG electronic tag authorizes the AC application to emulate the card. read the DS data contained in the TAG electronic tag. Moreover, the sending of the DS data to the card emulation application AC is possibly encrypted. This option is detailed later in the second embodiment of the invention.
• Step E5 is the reading of the DS data stored in the electronic tag TAG by the card emulation application AC.
• the map emulation application AC sends an application message "APDU" to the electronic tag TAG, possibly encrypted, indicating to the electronic tag TAG that it is ready to receive the data DS.
• this application message "APDU” is the first application message "APDU” sent by the user.
• AC card emulation application to the TAG electronic tag.
• the electronic tag TAG sends the card emulation application AC an "APDU” application message, possibly encrypted, containing the DS data.
• the reading method according to the invention is now described in a second variant embodiment in the form of an algorithm comprising steps F1 to F4.
• This second embodiment of the reading method according to the invention is much less detailed than the first embodiment, because these two variants have many steps and messages used in common.
• the differences between this second embodiment variant and the first embodiment essentially reside in the way of authenticating the AC map emulation application.
• Step F1 is the reading of the service provider identifier ID on the electronic tag TAG by the read module ML.
• This step is carried out in the same way as step E1 in the first variant embodiment of the reading method according to the invention: it uses an exchange of two messages between the read module ML and the electronic tag TAG, these messages passing through the radio module MR. This exchange is represented by the messages m'1 and m'2 in FIG.
• step F1 the read module ML deduced from the stream of bytes received in the message m'2, the identifier ID of the service provider associated with the tag TAG, and determines an identifier of the corresponding map emulation AC application.
• Step F2 is a connection request from the read module ML to the card emulation application AC.
• the reader module ML uses the method JSR177 "Connector.open” and sends an "exchangeAPDU" message represented by the message m'3 in FIG. 5, to the authentication gateway CG.
• This message is based on the identifier of the card emulation application AC determined in step F1. Unlike the first embodiment of the reading method according to the invention, this message does not contain an "authenticate” application message and does not cause the authentication of the reader module ML by the authentication gateway CG.
• the authentication gateway CG Upon receipt of the "exchangeAPDU” message, the authentication gateway CG requests the card emulation AC application to create a new connection interface dedicated to the reader module ML, and sends an identifier of this interface in a response.
• the "exchangeAPDU” message represented by the message m'4 in FIG. 5, to the reading module ML.
• Step F3 is the establishment of a communication session between the card emulation application AC and the electronic tag TAG, the card emulation application AC using the reader module ML as a proxy server ( commonly called "proxy").
• proxy a proxy server
• the reader module ML sends a message JSR177 "exchangeAPDU" containing an application message and represented by the message m'5 in FIG. 5, to the application AC card emulation.
• the application message contained in this message tells me to the card emulation AC application that the read module ML is ready to operate in proxy mode with an electronic tag external to the terminal T, here the electronic tag TAG.
• the card emulation AC application then sends the reader module ML, in response to the message m'5, an APDU application response represented by the message m'6 in FIG. 5, in accordance with the standard JSR177.
• the content of this message is not intended for the read module ML, but the electronic tag TAG, since the read module ML operates in proxy mode, and aims to authenticate the electronic tag TAG.
• the read module ML On receipt of the message m'6, the read module ML transmits it as a message JSR257 "exchangeData" on the interface 12 to the radio module MR, this message "exchangeData" containing the application response "APDU".
• the radio module MR Upon receipt of the "exchangeData" message, the radio module MR sends a "Block” frame conforming to the ISO 14443 standard to the electronic tag TAG, this "Block” frame also containing the application response "APDU".
• This sending of information between the read module ML and the electronic tag TAG via the radio module MR is represented by the message m'7 in FIG.
• the card emulation application AC and the electronic tag TAG share a secret key, stored on the one hand in the electronic tag TAG, and on the other hand downloaded for example previously in the map emulation application AC by the OTA mechanism.
• This secret key is used by the card emulation application CA to authenticate in this step F3, in the form of mutual authentication between the electronic tag TAG and the card emulation application AC.
• Mutual authentication by public key is however also usable.
• the APDU application response received by the electronic tag TAG in the message m'7 thus comprises a string of characters to be decrypted by the electronic tag TAG, this string of characters having been previously encrypted by the card emulation application AC. using the key secret shared between the map emulation AC application and the TAG electronic tag.
• the electronic tag TAG On receipt of the message m'7, the electronic tag TAG decrypts the string of characters included in this message using the secret key, and sends another application message to the card emulation application AC. , with the decrypted string of characters and another string of characters to decipher.
• This application message is carried by the messages m'8 and me 9 shown in Figure 5.
• the map emulation AC application Upon receipt of this application message, the map emulation AC application checks that the electronic tag TAG has correctly decrypted the chain previously sent to it. If this decryption is incorrect, the card emulation AC application interrupts the communication session with the electronic tag TAG.
• the card emulation application AC decrypts the string of characters to be decrypted sent by the electronic tag TAG and sends the string of characters thus deciphered in a new application response, transported via lower-level messages m'10 and m'11, to the TAG electronic tag.
• the electronic tag TAG verifies that the map emulation application AC has deciphered this chain of characters. If this decryption is incorrect, the electronic tag TAG interrupts the communication session with the map emulation application AC. On the contrary, if this decryption is correct, the electronic tag TAG then authorizes the card emulation application AC to read the DS data contained in the electronic tag TAG.
• step F4 is the reading of the DS data stored in the electronic tag TAG, by the card emulation application AC.
• the electronic tag TAG sends the card emulation application AC an application "APDU" response message, encrypted using the secret key shared between the card emulation application AC and the electronic tag TAG. , containing the DS data.
• the electronic tag TAG sends the DS data to the card emulation application CA only after receipt by the latter of an optionally encrypted application message "APDU", indicating to the TAG electronic tag that the card emulation AC application is ready to receive DS data.
• APDU optionally encrypted application message
• the encryption of the data DS sent by the electronic tag TAG is not necessary for the implementation of the invention, it is for example activated according to the degree of security desired by the associated service provider to the TAG electronic tag.

Landscapes

• Engineering & Computer Science (AREA)
• Business, Economics & Management (AREA)
• Accounting & Taxation (AREA)
• Strategic Management (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Computer Networks & Wireless Communication (AREA)
• General Business, Economics & Management (AREA)
• Theoretical Computer Science (AREA)
• Computer Security & Cryptography (AREA)
• Finance (AREA)
• Microelectronics & Electronic Packaging (AREA)
• Computer Hardware Design (AREA)
• Computing Systems (AREA)
• General Engineering & Computer Science (AREA)
• Signal Processing (AREA)
• Development Economics (AREA)
• Entrepreneurship & Innovation (AREA)
• Game Theory and Decision Science (AREA)
• Economics (AREA)
• Marketing (AREA)
• Telephonic Communication Services (AREA)
• Credit Cards Or The Like (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=39645310

Family Applications (1)

Country Status (2)

Families Citing this family (9)

Family Cites Families (6)

• 2008
  • 2008-12-11 WO PCT/FR2008/052275 patent/WO2009083679A2/fr not_active Ceased
  • 2008-12-11 EP EP08866018A patent/EP2243106A2/de not_active Withdrawn

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events