+

WO2002039369A1 - Protocole de communication entre une carte a puce de type pro-active et son terminal d'accueil - Google Patents

Protocole de communication entre une carte a puce de type pro-active et son terminal d'accueil Download PDF

Info

Publication number
WO2002039369A1
WO2002039369A1 PCT/FR2001/003505 FR0103505W WO0239369A1 WO 2002039369 A1 WO2002039369 A1 WO 2002039369A1 FR 0103505 W FR0103505 W FR 0103505W WO 0239369 A1 WO0239369 A1 WO 0239369A1
Authority
WO
WIPO (PCT)
Prior art keywords
card
proactive
protocol
data
network
Prior art date
Application number
PCT/FR2001/003505
Other languages
English (en)
Inventor
Renaud Mariana
Original Assignee
Cp8 Technologies
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cp8 Technologies filed Critical Cp8 Technologies
Publication of WO2002039369A1 publication Critical patent/WO2002039369A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06K—GRAPHICAL DATA READING; PRESENTATION OF DATA; RECORD CARRIERS; HANDLING RECORD CARRIERS
    • G06K7/00—Methods or arrangements for sensing record carriers, e.g. for reading patterns
    • G06K7/0008—General problems related to the reading of electronic memory record carriers, independent of its reading method, e.g. power transfer

Definitions

  • the present invention relates to a communication protocol between a smart card of the pro-active type and its reception terminal, the protocol being intended inter alia to manage data transfers either locally between the smart card and equipment associated with the terminal reception, or remotely between the smart card and equipment associated with a remote terminal connected to an external network.
  • data is taken in its broadest sense and covers, in addition to the actual data files, coded instructions, programs and other software, communication protocols, various messages, etc. .
  • proactive type smart cards that can be used in the context of the invention comply with ISO 7816-3 and 7816-4 standards (hereinafter ISO 7816-3 / 4) of the International Organization of Standardization.
  • These commands have a specific APDU (Application Protocol Data Unit) format and allow, among other things, data transfer.
  • the ISO 7816-3 / 4 card is qualified as proactive when it is capable of initiating actions on the terminal by appropriate commands called proactive.
  • SIM Subscriber Identity Module
  • GSM Global System for Mobile Communications
  • ETSI European Telecommunications Standards Institute
  • the GSM version 11.14 / class a integrates proactive commands allowing the SIM_Toolkit card to communicate with an additional card reader physically present in the GSM terminal and / or with the card residing in this reader, in particular a bank card or an electronic wallet.
  • SIM_Toolkit containing exchanges of data with a network entity must be able to have a communication channel ensuring all guarantees of routing in a reasonable time.
  • the GSM 11.14 specification indeed defines a mechanism for sending and receiving short SMS (Short Message Service) messages. These mini messages are short with a maximum of 140 bytes. Despite a low speed, the use of these mini messages allows an application to send data to a device (server, smart cards, etc.) by sending one or more mini messages. The exchange in the opposite direction is also carried out by sending mini messages to the recipient, the SIM_Toolkit application using an ENVELOPE command defined by the GSM specification 11.14.
  • SIM_Toolkit programming via mini SMS messages requires global processing at the application and kernel level both from the memory point of view (allocation of buffers or buffers) and CPU (processor) time for assembly, disassembly and not provide the possibility of establishing a connection from the network to the card.
  • the object of the invention is to propose a communication protocol between a card of the ISO 7816-3 / 4 proactive type and its reception terminal which eliminates or substantially reduces the drawbacks presented above and in particular which gives the card the ability to communicate with a remote network infrastructure under good conditions of reliability and speed while presenting easier programming conditions.
  • the invention proposes a communication protocol intended inter alia to manage data transfers between a proactive smart card conforming or compatible with ISO 7816-3 / 4 or capable, possibly using a proxy machine.
  • the communication protocol according to the invention is based on the use of communication sessions between the card and its reception terminal with bidirectional opening (and closing) of the sessions while benefiting from the achievements of the original pro-active commands.
  • card or card readers to obtain very homogeneous proactive active orders.
  • the protocol according to the invention is used in one or more locally separate proactive card communication sessions for card-to-card data transfers through a chain of communication sessions. ensuring the direct and permanent connection between the two cards for the duration of the sessions.
  • This card-to-card connection is important in the field of smart cards because it allows real and secure authentication, which is much sought after for transactions in the context of electronic commerce. Note that the BIP protocol does not provide for such a card-to-card connection.
  • the protocol according to the invention is used for the transfer of data through the reception terminal between the initiating card and at least one local card connected to said terminal by a real or virtual local card reader or at least one network card connected to an external or remote data network by a real or virtual network reader.
  • the invention provides, alongside real readers (physical readers), virtual readers defined by software applications which, by appropriate emulation, very considerably enlarge the field of action of the invention.
  • the protocol according to the invention is not limited to the initiator card and is also used on at least one of said local cards or at least one of said network cards, which accelerates, standardizes and facilitates dialog between cards accordingly. , whether initiating, local or distant.
  • the data transfers between the initiating card, the local cards and / or the network cards are carried out in whole or in part on one or more interfaces through dynamically allocated communication channels. More particularly, a command to open a communication session on a proactive card generates the local allocation between the card and the terminal of a session number and the allocation of a communication channel number. Thus opening a proactive card communication session exclusively reserves the communication channel corresponding to the session as long as it is not closed. It will also be noted among the advantages of the protocol according to the invention that this protocol is capable at the card level of managing several sessions simultaneously and that, moreover, synchronous or asynchronous reading is possible. 8
  • the protocol according to the invention is used bidirectionally at the two ends of a connection between two remote proactive cards, each card being locally connected to its corresponding terminal by a communication session on a proactive card. , the two terminals being connected to each other by at least one network session and adapted to manage the conversions of protocols between the sessions on proactive cards and the network session and the data flows in the corresponding communication channels.
  • This connection scheme between a card and an external network is particularly effective, particularly in terms of the reliability of data transfers.
  • the address used for the readers consists of a telephone number, in particular for networks of the X25, ATM, ISDN or similar type, an IP (Internet Protocol) address with a predefined implicit port number, a IP address with TCP / IP port number or a logical name, permanent or temporary, consisting of a machine name, for example its network address, and a software application name, for example its AID (Application Identifier Discriminator ).
  • IP Internet Protocol
  • the temporary logical addressing mode facilitates direct control of the card-to-end connection from end to end, it being noted that the addressing of a reader is often replaced by means of temporary logical addressing by direct addressing. of the card temporarily inserted in this reader.
  • the protocol according to the invention using a logical name with network addressing is characterized in that: at the opening of a session, a first connection is first established between two network applications, said first connection or network connection being followed by an application type connection with exchange of messages on the network connection, and
  • the closure of said application type connection is carried out first then followed by the closure of the network connection.
  • connection levels including virtual software connections, greatly facilitates programming with the use of a high-level application language.
  • the initiator card is connected:
  • Ilb with a remote card reader associated with an external data network and supporting a protocol supporting session opening, the initiator card accessing network servers ensuring the management of the initiator card session and the remote network session; or Ile) a virtual smart card defined by a local or remote computer application and managing sessions of the TCP or X25 type.
  • the protocol of the invention is characterized in that said initiator card is connected to an electronic SAM-type safe or to an RMI (Remote Method Invocation of the Java environment) card using a protocol based on the ISO 7816-3 / 4 protocol, the initiator card accessing the network by network servers, for example by a local proxy machine at the initiating card and a local proxy machine at the remote card reader.
  • said initiator card is connected to an electronic SAM-type safe or to an RMI (Remote Method Invocation of the Java environment) card using a protocol based on the ISO 7816-3 / 4 protocol, the initiator card accessing the network by network servers, for example by a local proxy machine at the initiating card and a local proxy machine at the remote card reader.
  • RMI Remote Method Invocation of the Java environment
  • the protocol of the invention according to which the initiator card is connected, in binary mode on session with data transfer in binary format, with a card reader locally associated with the reader of the initiator card and supporting a protocol supporting the communication session opening on a proactive card, characterized in that said initiating card is connected to a dual-slot GSM mobile with initiating SIM card and a proactive card supporting the protocol of the invention defined above 11
  • the protocol of the invention according to which the initiator card is connected, in binary mode on session with data transfer in binary format, with a virtual smart card defined by a local or remote computer application and managing sessions of the type TCP or X25, characterized in that said initiator card is connected to remote Web servers, database servers or a browser residing on a PC to which the reader of the initiator card is connected.
  • the protocol according to the invention can be used for the routing of APDU type data between the initiating card and terminals indifferently supporting the APDU mode or the binary mode to enable the card level to use programming interfaces for application, also called API (Application Programming Interfaces), homogeneous and high level.
  • API Application Programming Interfaces
  • the protocol according to the invention is used with an initiating card of the proactive SIM type and a GSM compatible reception terminal, the protocol comprising an extension of proactive commands for GSM specification local card reader 11.14 / class a so as to use uniform extended proactive commands to manage data transfers between the SIM card and either a local reader or an external network reader.
  • the card reader commands of the GSM 11.14 / class a specification which are the subject of an extension are the following:
  • the four card reader commands of the GSM specification 11.14 / class a are after extension on the one hand used in communication session for a local reader, and on the other part used to manage a communication session with a remote drive, in this case a network drive, in particular the primitive PERFORM CARD APDU command is used for synchronous sending of data in the form of APDU.
  • the protocol according to the invention has the capacity for dynamic insertion of network readers and for carrying out communication sessions on a proactive card from remote cards and / or local cards, with the possibility of opening. and logoff from remote 13
  • protocol according to the invention can also be used for the asynchronous sending of data to an application in open session state or the asynchronous extraction of data from an application in open session state.
  • the extended commands are optimized to combine in a single command a data transfer operation command with a logoff command.
  • This characteristic facilitates programming and provides an appreciable time saving for the execution of transactions and makes it possible to optimize the manipulation of the data flow.
  • the extended PERFORM CARD ADPU command for reading from the pro-active SIM card is optimized to allow when reading a string of bytes with sequential access, hereinafter data stream, to perform at least one of the operations: - sliding the read pointer of the data stream by integrating an additional command SKIP_DATA / GLISSER_DONNEES, 14
  • This characteristic makes it possible to optimize the manipulation of a data flow and makes it easier for the SIM card to promote access to large databases (Internet network).
  • the host terminal of the initiator card supports GSM / GPRS compatibility allowing the execution of GPRS communication sessions.
  • FIG. 1 shows a communication diagram illustrating the implementation of the communication protocol according to the invention between the proactive card and its reception terminal
  • FIG. 2 shows a communication diagram illustrating the implementation of the communication protocol associated with FIG. 1 in a local structure
  • FIG. 3 shows a communication diagram illustrating the implementation of the communication protocol associated with FIG. 1 in an external network structure.
  • the communication protocol according to the invention is implemented in a telematic system linking telecommunications and information technology (hardware and software), most of the elements of which, some of them quickly presented below, are known and will not be described. in detail.
  • the protocol according to the invention comprises a certain number of logical mechanisms and rules, often translated in the form of software, intended for the global and unitary implementation of the physical elements of the system, including the management of the interfaces. between these various physical elements.
  • the protocol according to the invention relates to communication and data exchange between a pro-active SIM chip card first with its reception terminal and then with a local or remote data network, for example the Internet network.
  • the link 51 between the card 10 and the reader 11 schematizes the interface by contacts between these two pieces of equipment
  • the link 52 between the reader 11 and the terminal 12 in this case a PC compatible computer, schematizes a serial cable (RS232 or USB)
  • the link 53 between the terminal 12 and the external network shows diagrammatically a network cable.
  • the CPA 10 card is represented in a simplified way with four software layers concerned by the invention going from the lowest level to the highest:
  • the protocol layer of the proactive PCPA commands including the Notification procedure for Event cards on card readers (for example in GSM environment, the protocol according to GSM specification 11.14 / class a)
  • the application card layer APPLI (CPA), for example the display of data on the terminal screen.
  • the LEC reader 11 is represented in a simplified manner with two software layers concerned with the invention, going from the lowest level to the highest:
  • the TAC 12 terminal is represented in a simplified manner with five software layers concerned by the invention going from the lowest level to the highest: - a stack of 4 layers composed of the RS232 layer, USB or the like, the PC / SC layer, the PCPA layer and PCINV layer,
  • FIG. 2 shows a communication diagram illustrating the implementation of the communication protocol according to the invention in a local structure.
  • the local TLOC terminal 21 is equipped with two card readers 22 and 23 for which the terminal protocol layers for accessing these readers are not shown.
  • the terminal 21, through its reader 22 having the ISO 7816-3 / 4 layers, PCPA and PCINV (communication protocol according to the invention), dialogues with the proactive card 20 called initiator by definition and having the same ISO 7816 layers -3/4, PCPA and PCINV via link 61 (supporting in this case a communication session according to the invention).
  • terminal 21 through its reader 23 having ISO 7816-3 / 4 layers, PCPA and PCINV dialogues with the pro-active card CPA-2 24 having the same ISO 7816-3 / 4 layers, PCPA and PCINV by intermediary of the link 62 (supporting in this case another communication session according to the invention distinct from the session supported by the link 61).
  • the terminal 21 also includes the protocols and procedures (represented by the double arrows 223 and 225) adapted to manage and carry out the resolution of the addresses, the establishment of the connections, the transfers and the conversions of protocols between the reader 22 of the initiator card.
  • APPLI terminal application 220 APPLI
  • the terminal 21 has the APPLI application (TLOC) 220, for example a web server using on the link 61 a communication session of the proactive card CPA 20 to display data on the terminal 21 or for manage the user interface of this terminal.
  • TOC APPLI application
  • link 62 is used for dialogue between the two proactive cards CPA 20 and CPA-2 24, for example between the APPLI (CPA) 200 and APPLI (CPA-2) 240 applications, links 61 and 62 supporting each a communication session according to the invention, these sessions being distinct from each other.
  • the terminal 21 after reconfiguration of the reader 23 can also route data to the application 250 of the CISO card 25 only compliant or compatible with ISO 7816-3 / 4 by a session established on the link 61 between the proactive card CPA 20 and the TLOC terminal 21.
  • APDU type data on session 61 will flow on link and strict APDU type data link 63, the latter link only supporting data in strict APDU mode (without session) .
  • FIG. 3 shows a communication diagram illustrating the implementation of the communication protocol according to the invention in an external network structure.
  • the local TLOC terminal 31 is equipped with a card reader 32 and a network interface 33 for which the terminal protocol layers for accessing this reader or this network interface are not represented. .
  • the local terminal 31 through its reader 32 having the ISO 7816-3 / 4, PCPA and PCINV layers (communication protocol according to the invention) dialogues with the proactive card CPA 30 called initiator 20
  • the terminal 31 through its network interface 33 having the TCP / X25 network stack dialogues through the TCP / X25 network stack of the network interface 35 with a remote TDIS terminal 34 via the link 72 (supporting in this case a network communication session).
  • the remote terminal 34 through its card reader 36 having the ISO 7816-3 / 4, PCPA and PCINV (communication protocol according to the invention) layers, dialogues with the pro-active network card CPA-3 37 having the same layers ISO 7816-3 / 4, PCPA and PCINV via link 73 (supporting in this case one or more communication sessions according to the invention).
  • the pro-active network card CPA-3 37 having the same layers ISO 7816-3 / 4, PCPA and PCINV via link 73 (supporting in this case one or more communication sessions according to the invention).
  • the local terminal 31 and the remote terminal 34 each include the protocols and procedures (represented by the double arrows 310 and 320) adapted to manage and carry out address resolution, establishment of connections, transfers and conversions of protocols between each proactive card reader 32, 36 and the corresponding TCP / X25 network stack of network interfaces 33, 35.
  • the terminals 31, 34 each have a device or a software application acting as a proxy
  • the two proactive cards 30, 37 [or the two card applications APPLI (CPA) 300 and APPLI (CPA-3) 340] can connect and interact directly with each other, links 71 and 73 each supporting a session 21
  • the remote terminal includes remote proxy equipment for converting between network protocol and the APDU protocol, thus allowing a session connection from the local proactive card to the conventional card via two separate sessions (a session according to the invention between the proactive card and the local terminal and a network session between the two terminals) followed by a data transfer in APDU mode between the remote terminal and the conventional card.
  • each terminal having at least two card readers of which at least one is equipped with the layer of the protocol according to the invention PCINV and at least one network card allowing dialogue between all the smart cards on reader associated locally or remotely.
  • local or remote physical card readers capable of interacting with each other or with the initiating card can be replaced by virtual readers as long as these readers support ISO 7816-3 / 4 compatibility or are able to emulate or support ISO 7816-3 / 4 protocol as presented above in the preamble to this presentation.
  • the protocol according to the invention at the level of the extension of proactive card or card reader commands of a PCPA type protocol.
  • a preferred mode of implementation according to the invention will be described below in the GSM environment, the proactive CPA cards (capable of initiating actions from the card to the terminal) being chosen.
  • the pro-active SIM type with the proactive PCPA command protocol the protocol according to the GSM 11.14 / class a specification and for the reception terminal a GSM compatible terminal.
  • SIM Subscriber Identity Module
  • GSM Global System for Mobile communications
  • IMSI International Mobile Subscriber Identity
  • SIM card used for the present invention is of the proactive type (also called SIM_Toolkit type) and compatible with the GSM 11.14 specification. / class a.
  • a proactive SIM card will be unless specifically mentioned simply called SIM card.
  • the communication protocol according to the invention which complies with ISO 7816-3 / 4 standards or is compatible with them, therefore uses APDU software commands from the 23
  • CLA application class byte 2
  • PI and P2 instruction byte 3 and 4
  • P3 command length or response length.
  • This header is optionally followed by a data field present in the order.
  • the response of the SIM card to an APDU command includes an epilogue of two bytes SW1 and SW2 (Status Word) possibly preceded by a data field.
  • SW1 code is included in hexadecimal (hex) coding between 90 (positive acknowledgment) and 9F or between 60 and 6F in the event of a problem independent of the application.
  • the code SW2 is used to explain the cause of the refusal to execute the command.
  • the ME terminal then issues an APDU FETCH command to the SIM card, the response of which back to the terminal will contain the pending proactive command.
  • the proactive command is executed by the terminal ME which then sends a response called TERMINAL RESPONSE to report the result of the execution of the proactive command or its non-execution.
  • GSM 11.14 / class specification conceptualized the concept of card reader by: i) the four card commands: POWER ON CARD, PERFORM
  • the 4 card commands and the card notification Event of the card reader are used to manage a communication session to a remote or local card reader: opening of the session, data transfer on the 25
  • the pro-active SIM card will therefore use the same commands to address a card reader located on the network, for example an SAM electronic safe, as a local reader comprising an electronic purse.
  • the 4 card reader commands include a discriminant “Device identities” which specifies the sending and receiving equipment.
  • the discriminant Device identities is positioned for the 4 card reader commands with:
  • a POWER ON CARD command (not yet extended according to the invention) could be written according to the GSM 11.14 specification / class a:
  • - 02 02 81 11 is a data field comprising in epilogue the identities of the transmitter 81 (the SIM card) and the recipient 11 (the resident reader 11), and
  • the TERMINAL RESPONSE response to card reader commands of the PERFORM CARD APDU type contains the discriminant Device Identities positioned with
  • the correspondence between the card reader commands and the operations for managing a communication session begins with the opening of a session by the pro-active SIM card with establishment of the 27
  • the extended POWER ON CARD command comprises two complementary fields, each consisting of a character string in “machine_l: application_2” format (non-limiting format).
  • each chain defines a TLV (Tag / Length / Value) type field indicating the Address identity of the sender equipment or of the recipient equipment.
  • the extended POWER ON CARD command can be written (hex) [after the fields added or modified in their interpretations are bolded]: D0090103013100020281110606FF00000000010606FF00000001039000
  • Address-Recipient must always be an AID application address or, failing that, a machine address for example: www.bull.net: 8070 (where 8070 is the 28
  • the extended POWER ON CARD command can be written (hex) [after the fields added or modified in their bold characters have been changed:
  • the number of the card reader remains the number of the readers of the mobile for the values (hex) 10 to 17 and becomes equal to (hex) 20 to 2F for the remote readers, which guarantees compatibility with the GSM specification 11.14 / existing class a.
  • the Recipient Identity number is given by convention and for convenience as the communication session number. So the presence of the binary pattern 0010 xxxx which corresponds to the range (hex) 29
  • 20 to 2F allows the mobile i) to interpret the command as a session management command with a network reader as opposed to the binary pattern 0001 Oxxx which identifies the logical numbers (0 to 7) of the local card readers resident in the mobile and ii) read the name of the recipient Identity network drive, which will be an additional field in the Device identities structure.
  • the session number defined by the POWER ON CARD command will be used by the other commands of the PERFORM CARD APDU, POWER OFF CARD and GET READER STATUS sequence during the sequential or synchronous sequence of the session.
  • the mobile uses this session number for:
  • the validity of the session number expires at the end of the session by the POWER OFF CARD command on the remote reader, a reset of the SIM card, or a connection problem in the connection.
  • the extended PERFORM CARD APDU command is completed by:
  • CQ (hex) 02 (or 04)
  • the PERFORM CARD DATA command is written: D00F010301300202028121220441414141
  • the extended PERFORM CARD APDU command is completed according to the invention by:
  • the asynchronous mode is characterized by the coming one by one Notifications to the proactive SIM card of the Card reader status event by means of the ENVELOPE terminal command, it being noted that the content of the card reader event status is modified according to the type of “reader” event to be taken into consideration by the SIM card (logon, data transfer, logoff).
  • a very interesting characteristic of the protocol according to the invention lies in the possibility of notifying the SIM card of the opening of a session by the network or by a local reader. We are thus in the presence of a Server request (remote opening) as opposed to a Client request (local opening where the SIM card takes the initiative to open the session as presented above).
  • the reception of the GSM 11.14 card reader status event by the SIM card using the ENVELOPE terminal command allows the SIM_Toolkit application to be notified of a change in the status of the reader (for example 'card inserted' / 'card removed').
  • the SIM_Toolkit application can then run a procedure corresponding to a connection request or to an end of connection.
  • a connection request can correspond to a Server request, the SIM_Toolkit application being configured in this case as a Server for example as a TCP / IP or HTTP Server if the appropriate software stack is present above the four commands 33
  • GSM API card reader 11.14 / class a The details of the mobile-level notification of a network connection request must be the subject of a specific GPRS or other data exchange protocol (IP, X25, etc.).
  • the management of the status of the local reader residing in the mobile or of the network reader can be done while maintaining reciprocal compatibility using a Device identities field of the structure.
  • the status request by the pro-active SIM card by the GET READER STATUS command can be made using the session number (hex) 20 to 2F, the presence of the binary pattern 0010 xxxx allows the mobile to interpret the command as a request for the status of current sessions as opposed to the binary pattern 0001 lxxx which identifies the logical numbers (0 to 7) of the card readers residing in the mobile.
  • the mobile then sends to the SIM card the concatenation of the statuses of all the network card readers, ie n times a structure of 3 bytes TLV (Tag / Length / Status).
  • This asynchronous reading operation by the SIM card is also carried out via the ENVELOPE terminal command (EVENT DOWNLOAD - card reader status).
  • the EVENT DOWNLOAD - card reader status structure is extended by adding at the end of the structure: 35
  • the EVENT DOWNLOAD - card reader status structure can be written:
  • the remote closing of a session is carried out via the ENVELOPE terminal command encapsulating the EVENT DOWNLOAD structure - card reader status.
  • the EVENT DOWNLOAD - card reader status structure can be written:
  • the protocol according to the invention allows simplified programming since the orders (commands) are submitted sequentially to the reader without the need to leave the application for each order.
  • the reader remains "blocked” and unavailable for another session until receipt of the result of the proactive order (this does not prevent the sending of Card Notifications by the ENVELOPE command), any error encountered can thus be treated at once.
  • the transfer rate is improved by the protocol according to the invention compared to the use of mini SMS messages, the mobile being capable of using an external GPRS circuit in the current state of the art of a bit rate of at least 9600 bits / s.
  • the data is exchanged by a uniform API whatever the location of the reader (local reader residing in the mobile or remote network reader) and compatibility with the basic mechanism of the 37
  • GSM specification 11.14 / class a for the dialogue with a reader is respected.
  • the availability of the data communication channel is known from the opening of the session by the POWER ON CARD command which will return an error if the mobile is unable to open this channel, for example if all the sessions are active, if the radio coverage is poor or if the remote machine does not respond after a certain time (ti e out), for example several seconds.
  • the communication protocol according to the invention also comprises in a first optional variant a set of commands optimized for combining in a single command a data transfer operation command with a session closure command. . 38
  • the PERFORM CARD DATA command is written from the SIM card without change from the corresponding extended command: D00D010301300102028121220200009000
  • protocol according to the invention also comprises, in a second optional variant, a set of commands optimized for reading a chain of bytes with sequential access, hereinafter “data stream” (stream), and in particular for carrying out at least one of the operations:
  • CQ ⁇ 03 (SKIP_DATA) with sliding of the read pointer of the data stream coming from the Mobile by N bytes, N being specified in the TLV object (C_APDU)
  • TLV (R_APDU) 2303414243 contains the data (hex) to be transferred to the card, in this case 414243.
  • This last optimized PERFORM CARD APDU read command is particularly efficient for reading in large databases often encountered in data networks, especially in the Internet.
  • the communication protocol according to the invention is not limited to its implementation and its implementation in the GSM environment described above but is capable of being implemented in the context of the invention defined by the claims below in any application using a ISO 7816-3 / 4 compliant or compatible proactive card or capable of emulating or supporting the ISO 7816-3 / 4 protocol and comprising a set of Proactive card or card reader commands that can be extended to manage a communication session between the card and its reception terminal.

Landscapes

  • Engineering & Computer Science (AREA)
  • Artificial Intelligence (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Le protocole de communication PCINV gère la communication et les échanges de données entre une carte à puce pro-active CPA 10 compatible ISO 7816-3/4 et son terminal d'accueil TAC 12 au travers d'un lecteur de carte LEC 11, le terminal TAC 12 de type PC étant relié à un réseau externe de type Internet ou X25 par un câble réseau 53. Le terminal TAC 12 peut être également en liaison avec un lecteur local auxiliaire. Le protocole de communication représenté par la couche PCINV intègre et étend les commandes pro-actives APDU de lecteur de carte de la couche PCPA et la procédure de Notification de carte de type Evénement sur lecteur de carte, en particulier pour une carte SIM pro-active les commandes et procédure de la spécification GSM 11.14/classe a. Les transferts de données sont gérés par sessions de communication sur canaux de données alloués dynamiquement.

Description

PROTOCOLE DE COMMUNICATION ENTRE UNE CARTE A PUCE DE TYPE PRO-ACTIVE ET SON TERMINAL D'ACCUEIL
La présente invention concerne un protocole de communication entre une carte à puce de type pro-active et son terminal d'accueil, le protocole étant destiné entre autres à gérer des transferts de données soit localement entre la carte à puce et un équipement associé au terminal d'accueil, soit à distance entre la carte à puce et un équipement associé à un terminal distant connecté à un réseau externe. On notera que dans le cadre de l'invention le terme « données » est pris dans son sens le plus large et couvre, outre des fichiers de données proprement dits, des instructions codées, des programmes et autres logiciels, des protocoles de communication, des messages divers, etc. .
D'une façon générale les cartes à puce de type pro-active utilisables dans le cadre de l'invention sont conformes aux normes ISO 7816-3 et 7816-4 (ci-après ISO 7816-3/4) de l'Organisation Internationale de Normalisation. Une telle carte communique et échange des données avec son terminal d'accueil, par exemple un mobile téléphonique, suivant le protocole T=0 défini par la norme ISO 7816-3 et selon lequel les dialogues sont toujours réalisés a l'initiative du terminal, celui-ci envoyant des commandes entraînant des réponses par la carte. Ces commandes présentent un format spécifique APDU (Application Protocol Data Unit) et permettent entre autre le transfert de données. Dans certains cas la carte ISO 7816-3/4 est qualifiée de pro-active lorsqu'elle est capable par des commandes appropriées dites pro-actives d'initier des actions sur le terminal.
Parmi les exemples de cartes à puce ou à microprocesseur ISO 7816-3/4 utilisables dans le cadre de la présente invention on peut citer de façon non limitative les cartes à microprocesseur SIM (Subscriber Identity Module) permettant l'identification d'un abonné. Ces cartes SIM sont largement utilisées aujourd'hui notamment dans la téléphonie mobile, dans les décodeurs de télévision à péage et dans les systèmes de contrôle d'accès.
A titre d'exemple non limitatif, les spécifications GSM (Global System for Mobile Communications) de l'ETSI (European Télécommunications Standards Institute) , couramment utilisées dans la téléphonie mobile, définissent un certain nombre de commandes pro-actives, notamment dans la spécification GSM 11.14 compatible ISO 7816-3/4. Ces commandes pro-actives GSM 11.14 sont regroupées sous le vocable « SIM Application Toolkit » ou « SIM_Toolkit ». De plus à côté de la version de base de la spécification GSM 11.14 ont été définies cinq versions étendues à commandes additionnelles à la version de base et ci-après nommées de « GSM 11.14 /classe a » à « GSM 11.14/classe e ». Par exemple la version GSM 11.14/classe a intègre des commandes pro-actives permettant à la carte SIM_Toolkit de dialoguer avec un lecteur de carte additionnel physiquement présent dans le terminal GSM et/ou avec la carte résidant dans ce lecteur en particulier une carte bancaire ou un portefeuille électronique .
Avec le développement des réseaux de données, notamment du réseau Internet, il apparaît intéressant pour une carte à puce d'être en mesure de dialoguer avec une infrastructure de réseau telle qu'un serveur ou une autre carte à puce dans de bonnes conditions de fiabilité et de rapidité .
En particulier le développeur-programmeur d'applications SIM, notamment SIM_Toolkit, contenant des échanges de données avec une entité du réseau doit pouvoir disposer d'un canal de communication assurant toutes les garanties d'acheminement dans un temps raisonnable.
Cependant les capacités en mémoire et les temps de traitement des données sont trop limités sur une carte à puce pour généraliser la technique connue des mini messages SMS actuellement utilisée pour faire communiquer la carte SIM_Toolkit avec le monde extérieur. Il est de fait impossible de faire coexister sur une même carte SIM_Toolkit plusieurs applications logicielles utilisant des mini messages. De plus le temps d'une transaction quelque peu complexe dépasse la minute.
La spécification GSM 11.14 définit en effet un mécanisme d'envoi et de réception de mini messages SMS (Short Message Service) . Ces mini messages sont courts avec 140 octets au maximum. Malgré un faible débit, l'utilisation de ces mini messages permet à une application d'envoyer des données à un équipement (serveur, cartes à puce, etc.. ) par l'envoi d'un ou plusieurs mini messages. L'échange en sens inverse s'effectue également par l'envoi de mini messages du destinataire, l'application SIM_Toolkit utilisant une commande ENVELOPE définie par la spécification GSM 11.14.
Toutefois cette technique SMS a l'inconvénient d'être peu pratique à programmer, l'application logicielle en effet sortant à chaque envoi d'un mini message (avec perte des paramètres de la connexion) d'où la nécessité de garder un contexte pour interpréter l'ensemble des mini messages reçus. La programmation SIM_Toolkit par mini messages SMS exige un traitement global au niveau de l'application et du noyau tant du point de vue mémoire (allocation des mémoires tampons ou buffers) que de temps CPU (processeur) pour l'assemblage, le désassemblage et prévoit pas la possibilité d'établir une connexion à partir du réseau vers la carte.
L'invention a pour but de proposer un protocole de communication entre une carte de type pro-active ISO 7816-3/4 et son terminal d'accueil qui élimine ou réduit sensiblement les inconvénients présentés ci-dessus et notamment qui donne à la carte la capacité de dialoguer avec une infrastructure de réseau distant dans de bonnes conditions de fiabilité et de rapidité tout en présentant des conditions de programmation facilitées.
A cette fin l'invention propose un protocole de communication destiné entre autres à gérer les transferts de données entre une carte à puce pro-active conforme ou compatible ISO 7816-3/4 ou capable, éventuellement à l'aide d'une machine proxy, d'émuler le protocole ISO 7816-3/4 ou des protocoles supportant ce protocole ISO 7816-3/4 , ci-après la carte initiatrice, et son terminal d'accueil, ledit protocole de communication comportant au moins les commandes pro-actives de carte ou de lecteur de carte correspondant aux opérations suivantes : Activation de lecteur de carte, Transfert (s) de données, Désactivation de lecteur de carte, et une procédure de Notification de carte de type Evénement sur lecteur de carte, ledit protocole de communication étant caractérisé en ce que lesdits transferts de données sont gérés par sessions de communication sur carte pro-active comportant au moins la séquence d'opérations suivante: Ouverture de session, l'ouverture étant locale à partir de la carte ou distante à partir du terminal, Transfert (s) de données synchrone (s) ou asynchrone (s) , Fermeture de session, la fermeture étant locale à partir de la carte ou distante à partir du terminal, au moyen de commandes pro-actives étendues dérivées desdites commandes pro-actives de carte ou de lecteur de carte et d'une procédure de Notification de carte étendue dérivée de ladite procédure de Notification de carte de type Evénement sur lecteur de carte.
Ainsi le protocole de communication selon l'invention est basé sur l'utilisation de sessions de communication entre la carte et son terminal d'accueil avec ouverture (et fermeture) bidirectionnelles des sessions tout en bénéficiant des acquis des commandes pro-actives d'origine de carte ou de lecteurs de carte pour obtenir au final des commandes pro-actives très homogènes. On obtient ainsi un protocole de communication nettement plus performant que le protocole SMS, avec notamment un niveau élevé des débits des données transférées, obtenu grâce au transfert par sessions, et beaucoup plus facile à mettre en oeuvre (notamment au niveau de la programmation) que- le protocole BIP, ce dernier restant un protocole à ouverture et fermeture monodirectionnelles à partir de la carte seulement.
Avantageusement selon une première variante de l'invention, le protocole selon l'invention est utilisé dans une ou plusieurs sessions de communication sur carte pro-active localement distinctes pour des transferts de données carte à carte au travers d'une chaîne de sessions de communication assurant la connexion directe et permanente entre les deux cartes pendant la durée des sessions. Cette connexion carte à carte est importante dans le domaine des cartes à puce car elle permet une authentification réelle et sûre, ce qui est très recherché pour les transactions dans le cadre du commerce électronique. On notera que le protocole BIP ne prévoit pas de telle connexion carte à carte.
Plus particulièrement le protocole selon l'invention est utilisé pour le transfert de données au travers du terminal d'accueil entre la carte initiatrice et au moins une carte locale connectée audit terminal par un lecteur de carte local réel ou virtuel ou au moins une carte réseau connectée à un réseau de données externe ou distant par un lecteur réseau réel ou virtuel. On notera que l'invention prévoit, à côté des lecteurs réels (les lecteurs physiques) , des lecteurs virtuels définis par des applications logicielles qui par émulation appropriée agrandissent très considérablement le champ d'action de l'invention.
De plus le protocole selon l'invention n'est pas limité à la carte initiatrice et est également utilisé sur au moins une desdites cartes locales ou au moins une desdites cartes réseau, ce qui accélère, uniformise et facilite d'autant les dialogues entre cartes, qu'elles soient initiatrice, locale ou distante.
Avantageusement les transferts de données entre la carte initiatrice, les cartes locales et/ou les cartes réseau sont réalisés en tout ou partie sur une ou plusieurs interfaces au travers de canaux de communication alloués dynamiquement. Plus particulièrement une commande d'ouverture d'une session de communication sur carte pro- active génère l'attribution locale entre la carte et le terminal d'un numéro de session et l'attribution d'un numéro de canal de communication. Ainsi l'ouverture d'une session de communication de carte pro-active réserve de façon exclusive le canal de communication correspondant à la session aussi longtemps que celle-ci ne sera pas fermée. On notera également parmi les avantages du protocole selon l'invention que ce protocole est capable au niveau de la carte de gérer plusieurs sessions simultanément et que de plus la lecture synchrone ou asynchrone est possible. 8
Selon une autre variante d'utilisation le protocole selon l'invention est utilisé de façon bidirectionnelle aux deux extrémités d'une connexion entre deux cartes proactives distantes, chaque carte étant connectée localement à son terminal correspondant par une session de communication sur carte pro-active, les deux terminaux étant connectés entre eux par au moins une session réseau et adaptés pour gérer les conversions de protocoles entre les sessions sur cartes pro-actives et la session réseau et les flux de données dans les canaux de communications correspondants. Ce schéma de connexion entre une carte et un réseau externe est particulièrement performant, notamment au niveau de la fiabilité des transferts de données .
Avantageusement l'adresse utilisée pour les lecteurs est constituée d'un numéro de téléphone, notamment pour les réseaux du type X25, ATM, RNIS ou analogue, d'une adresse IP (Internet Protocol) avec numéro de port implicite prédéfini, d'une adresse IP avec numéro de port TCP/IP ou un nom logique, définitif ou temporaire, composé d'un nom de machine, par exemple son adresse réseau, et d'un nom d'application logicielle, par exemple son AID (Application Identifier Discriminator) .
On notera que le mode d'adressage logique temporaire facilite le contrôle direct de la connexion de bout en bout carte à carte, étant fait remarquer que l'adressage d'un lecteur est souvent remplacé grâce à l'adressage logique temporaire par un adressage direct de la carte insérée de façon temporaire dans ce lecteur.
Avantageusement et en variante optionnelle le protocole selon l'invention utilisant un nom logique avec un adressage réseau est caractérisé en ce que : - à l'ouverture de session une première connexion est d'abord établie entre deux applications réseau, ladite première connexion ou connexion réseau étant suivie d'une connexion de type applicatif avec échange de messages sur la connexion réseau, et
- à la fermeture de session, la fermeture de ladite connexion de type applicatif est réalisée dans un premier temps puis suivie de la fermeture de la connexion réseau.
L'utilisation de plusieurs niveaux de connexion, y compris des connexions virtuelles logicielles, facilite grandement la programmation avec l'utilisation d'un langage applicatif de haut niveau.
Selon encore plusieurs variantes du protocole de communication selon l'invention la carte initiatrice est connectée :
I) soit en mode APDU strict avec transfert de données au format APDU sur session: la) avec un lecteur de carte associé localement au lecteur de la carte initiatrice, par exemple un mobile GSM bi-fentes avec carte initiatrice SIM et une carte classique de débit/crédit ; Ib) avec un lecteur de carte distant, associé à un réseau externe de données, la carte initiatrice accédant au réseau par des serveurs de réseaux, par exemple par une machine proxy locale à la carte initiatrice et une machine proxy locale au lecteur de carte distant; ou le) une carte à puce virtuelle définie par une application informatique locale ou distante émulant le protocole ISO 7816-3/4 ou des protocoles supportant ce protocole ISO 7816-3/4;
II) soit en mode binaire sur session avec transfert de données en format binaire : lia) avec un lecteur de carte associé localement au lecteur de la carte initiatrice et supportant un 10
protocole supportant l'ouverture de session de communication sur carte pro-active;
Ilb) avec un lecteur de carte distant associé à un réseau externe de données et supportant un protocole supportant l'ouverture de session, la carte initiatrice accédant à des serveurs de réseau assurant la gestion de la session carte initiatrice et de la session réseau distant; ou Ile) une carte à puce virtuelle définie par une application informatique locale ou distante et gérant des sessions de type TCP ou X25.
Plus particulièrement le protocole de l'invention selon lequel ladite carte initiatrice est connectée, en mode APDU strict avec transfert de données au format APDU sur session, avec un lecteur de carte distant associé à un réseau externe de données, est caractérisé en ce que ladite carte initiatrice est connectée à un coffre-fort électronique de type SAM ou à une carte RMI (Remote Method Invocation de l'environnement Java) utilisant un protocole basé sur le protocole ISO 7816-3/4, la carte initiatrice accédant au réseau par des serveurs de réseaux, par exemple par une machine proxy locale à la carte initiatrice et une machine proxy locale au lecteur de carte distant.
Plus particulièrement encore le protocole de l'invention selon lequel la carte initiatrice est connectée, en mode binaire sur session avec transfert de données en format binaire, avec un lecteur de carte associé localement au lecteur de la carte initiatrice et supportant un protocole supportant l'ouverture de session de communication sur carte pro-active, caractérisé en ce que ladite carte initiatrice est connectée à un mobile GSM bi-fentes avec carte initiatrice SIM et une carte pro- active supportant le protocole de l'invention défini ci- 11
avant ou le protocole GSM/BIP , et hébergeant un mini- serveur Web comportant des données personnelles.
Plus particulièrement encore le protocole de l'invention selon lequel la carte initiatrice est connectée, en mode binaire sur session avec transfert de données en format binaire, avec une carte à puce virtuelle définie par une application informatique locale ou distante et gérant des sessions de type TCP ou X25, caractérisé en ce que ladite carte initiatrice est connectée à des serveurs Web distants, des serveurs de bases de données ou un navigateur résidant sur un PC auquel est raccordé le lecteur de la carte initiatrice.
Ainsi le protocole selon l'invention peut être utilisé pour 1 ' acheminement de données de type APDU entre la carte initiatrice et des terminaux supportant indifféremment le mode APDU ou le mode binaire pour permettre au niveau carte l'utilisation d'interfaces de programmation d'application, également dénommées API (Application Programming Interfaces) , homogènes et de haut niveau .
Selon un mode de réalisation préférentiel de l'invention, le protocole selon l'invention est utilisé avec une carte initiatrice de type carte SIM pro-active et un terminal d'accueil compatible GSM, le protocole comportant une extension de commandes pro-actives de lecteur de carte local de la spécification GSM 11.14/classe a de façon à utiliser des commandes pro-actives étendues uniformes pour gérer les transferts de données entre la carte SIM et indifféremment un lecteur local ou un lecteur réseau externe .
Cette caractéristique, par l'utilisation maximale du préexistant, a pour avantage d'une part de réduire le 12
nombre des modifications nécessaires de la spécification GSM 11.14/classe a et d'autre part d'offrir une grande souplesse d'utilisation pour le développeur-programmeur au niveau de la compatibilité avec la version GSM 11.14/classe a d'origine.
Toujours selon le mode de réalisation préférentiel du protocole de l'invention, les commandes de lecteur de carte de la spécification GSM 11.14/classe a faisant l'objet d'une extension sont les suivantes :
- POWER ON CARD/ACTIVATION LECTEUR DE CARTE utilisée pour l'Ouverture locale de session
- PERFORM CARD APDU/EXECUTION COMMANDE APDU PAR LE LECTEUR CARTE utilisée pour les Transferts de données synchrones - POWER OFF CARD/DESACTIVATION LECTEUR DE CARTE utilisée pour la fermeture locale de session et de façon optionnelle la commande :
- GET READER STATUS/RECHERCHE STATUT LECTEUR DE CARTE.
Ainsi les quatre commandes lecteur de carte de la spécification GSM 11.14/classe a (au départ utilisées pour un lecteur local sans session de communication) , sont après extension d'une part utilisées en session de communication pour un lecteur local, et d'autre part utilisées pour gérer une session de communication avec un lecteur distant, en l'espèce un lecteur réseau, en particulier la commande primitive PERFORM CARD APDU est utilisée pour l'envoi synchrone de données sous forme d'APDU.
De façon particulièrement avantageuse, le protocole selon l'invention présente la capacité d'insertion dynamique des lecteurs réseau et de réalisation de sessions de communication sur carte pro-active à partir de cartes distantes et/ou de cartes locales, avec possibilité d'ouverture et de fermeture de session distantes à partir 13
du terminal d'accueil, par extension de la procédure de Notification de carte EVENT DOWNLOAD - CARD READER STATUS /NOTIFICATION D'EVENEMENT - STATUT LECTEUR DE CARTE de la spécification GSM 11.14/classe a. Ainsi une connexion peut être initiée de façon simple de manière événementielle asynchrone à partir du réseau, donnant au protocole selon l'invention un véritable caractère bidirectionnel (ce que le protocole BIP ne prévoit pas) .
Ainsi le protocole selon l'invention peut également être utilisé pour l'envoi asynchrone de données vers une application en état de session ouverte ou l'extraction asynchrone de données à partir d'une application en état de session ouverte.
Selon une première variante optionnelle du mode de réalisation préférentiel du protocole selon l'invention, les commandes étendues sont optimisées pour combiner en une seule commande une commande d'opération de transfert de données avec une commande de fermeture de session.
Cette caractéristique facilite la programmation et procure un gain de temps appréciable pour 1 ' exécution des transactions et permet d'optimiser la manipulation du flux de données.
Selon une seconde variante optionnelle du mode de réalisation préférentiel du protocole selon l'invention, la commande étendue PERFORM CARD ADPU pour la lecture à partir de la carte SIM pro-active, est optimisée pour permettre lors de la lecture d'une chaîne d'octets à accès séquentiel, ci-après flux de données, de réaliser au moins une des opérations : - de glissement du pointeur de lecture du flux de données par intégration d'une commande complémentaire SKIP_DATA /GLISSER_DONNEES, 14
- d'élimination de tous les caractères du flux de données en attente de lecture par intégration d'une commande complémentaire FLUSH_DATA/VIDER_DONNEES et
- de recherche dans les caractères du flux de données en attente de lecture par intégration d'une commande complémentaire FIND_DATA/TROUVER_DONNEES .
Cette caractéristique permet d'optimiser la manipulation d'un flux de données et facilite pour la carte SIM pro- active l'accès à des bases de données de tailles importantes (réseau Internet) .
Tout aussi avantageusement pour augmenter les débits de transfert sur le réseau externe le terminal d'accueil de la carte initiatrice supporte la compatibilité GSM/GPRS permettant l'exécution de sessions de communication GPRS
(General Packet Radio Service) et/ou supporte la compatibilité UMTS (Universal Mobile Télécommunication
System) permettant l'exécution de sessions de communication UMTS .
D'autres buts, avantages et caractéristiques de 1 ' invention apparaîtront à la lecture de la description qui va suivre du mode de réalisation préférentiel du protocole de communication selon 1 ' invention donné à titre d'exemple non limitatif en référence aux dessins ci-annexés dans lesquels: la figure 1 montre un schéma de communication illustrant la mise en oeuvre du protocole de communication selon l'invention entre la carte pro-active et son terminal d'accueil; la figure 2 montre un schéma de communication illustrant la mise en oeuvre du protocole de communication associé à la figure 1 dans une structure locale; et 15
la figure 3 montre un schéma de communication illustrant la mise en oeuvre du protocole de communication associé la figure 1 dans une structure de réseau externe.
Il est à noter au préalable qu'il pourra être avantageux lors de la lecture du présent exposé de se reporter aux normes ISO concernant les cartes à puce, notamment les normes ISO 7816-3/4 et aux diverses publications de l'ETSI, notamment celles concernant les spécifications GSM dont la spécification GSM 11.14 V8.2.0 (2000-04).
D'une façon générale le protocole de communication selon l'invention est mis en oeuvre dans un système télématique liant télécommunications et informatique (matérielle et logicielle) dont la plupart des éléments, pour certains rapidement présentés ci-après, sont connus et ne seront décrits en détail.
Comme tout mode opératoire, le protocole selon l'invention comporte un certain nombre de mécanismes logiques et de règles, souvent traduits sous forme de logiciels, destinés à la mise en oeuvre globale et unitaire des éléments physiques du système, y compris la gestion des interfaces entre ces divers éléments physiques. En l'espèce le protocole selon l'invention a pour objet la communication et les échanges de données entre une carte à puce SIM pro-active d'abord avec son terminal d'accueil puis avec un réseau de données local ou distant par exemple le réseau Internet.
Selon le mode de réalisation préférentiel du protocole de communication de l'invention maintenant décrit à titre d'exemple non limitatif, les échanges de données entre une carte à puce pro-active CPA 10 conforme ou compatible ISO 7816-3/4, et son terminal d'accueil TAC 12 au travers 16
d'un lecteur de carte LEC 11 sont réalisés selon le schéma de communication illustré à la figure 1.
Si l'on considère la figure 1, les différents équipements, carte CPA 10, lecteur LEC 11 et terminal d'accueil TAC 12 sont illustrés selon la représentation graphique de couches logicielles, les parallèles en pointillés définissant un même niveau de protocole pour les divers équipements, c'est à dire que chaque composant physique ou chaque application logicielle situé à la même « latitude » utilise le même dialecte protocolaire ; par exemple le même langage applicatif est utilisé pour le dialogue entre l'application APPLI (CPA) et l'application APPLI(TAC) illustré par la double flèche 54. De plus une série de doubles flèches 51, 52 et 53 illustre les liens entre les trois équipements et le réseau externe. Concrètement le lien 51 entre la carte 10 et le lecteur 11 schématise l'interface par contacts entre ces deux équipements, le lien 52 entre le lecteur 11 et le terminal 12, en l'espèce un ordinateur compatible PC, schématise un câble série (RS232 ou USB) et le lien 53 entre le terminal 12 et le réseau externe (non représenté) schématise un câble réseau.
La carte CPA 10 est représentée de façon simplifiée avec quatre couches logicielles concernées par l'invention allant du plus bas niveau au plus haut :
- la couche du protocole ISO (ISO 7816-3/4)
- la couche du protocole des commandes pro-actives PCPA y compris la procédure de Notification carte d'Evénement sur lecteur de carte (par exemple en environnement GSM, le protocole selon la spécification GSM 11.14/classe a)
- la couche du protocole de communication selon l'invention PCINV (protocole avec sessions de communication sur carte pro-active) 17
- la couche application carte APPLI (CPA), par exemple l'affichage de données sur l'écran du terminal.
Le lecteur LEC 11 est représenté de façon simplifiée avec deux couches logicielles concernées par l'invention, allant du plus bas niveau au plus haut :
- la couche du protocole ISO (ISO 7816-3/4)
- en parallèle à la couche ISO 7816-3/4 une pile de deux couches, une couche RS232, USB, etc.. surmontée par exemple d'une couche PC/SC (protocole standard défini par
® la société MICROSOFT pour l'interface entre les terminaux PC et les lecteurs de cartes à puce) ou d'une couche d'un protocole analogue.
- une couche d'adaptation de protocole AP(LEC) entre la couche ISO et la couche PC/SC.
Le terminal TAC 12 est représenté de façon simplifiée avec cinq couches logicielles concernées par l'invention allant du plus bas niveau au plus haut : - une pile de 4 couches composée de la couche RS232, USB ou analogue, la couche PC/SC, la couche PCPA et la couche PCINV,
- en parallèle à la pile 4 couches, une couche réseau TCP/IP, X25 ou analogue, - surmontant la pile 4 couches, une couche d'application terminal APPLI (TAC) d'une part et une couche d'adaptation de protocole AP(TAC) entre la couche PCINV et la couche TCP/IP d'autre part.
On notera que : i) pour certaines cartes CPA (non GSM) il est possible que certains composants PC/SC se trouvent dans la carte. Toutefois le schéma de la figure 1 se limite au regard de PC/SC au dialogue entre le terminal PC 12 et le lecteur de carte 11. 18
ii) en environnement GSM le protocole PC/SC n'existe pas, les applications terminal APPLI (TAC) dialoguant directement avec le lecteur ; de même le lien 52 n'existe pas .
La figure 2 montre un schéma de communication illustrant la mise en oeuvre du protocole de communication selon l'invention dans une structure locale.
Tel que représenté sur la figure 2 le terminal local TLOC 21 est équipé de deux lecteurs de carte 22 et 23 pour lesquels les couches de protocole de terminal pour accéder à ces lecteurs ne sont pas représentées. Le terminal 21, par son lecteur 22 disposant des couches ISO 7816-3/4, PCPA et PCINV (protocole de communication selon l'invention), dialogue avec la carte pro-active 20 dite initiatrice par définition et disposant des mêmes couches ISO 7816-3/4, PCPA et PCINV par l'intermédiaire du lien 61 (supportant en l'espèce une session de communication selon l'invention) . De même le terminal 21 par son lecteur 23 disposant des couches ISO 7816-3/4, PCPA et PCINV dialogue avec la carte pro-active CPA-2 24 disposant des mêmes couches ISO 7816-3/4, PCPA et PCINV par l'intermédiaire du lien 62 (supportant en l'espèce une autre session de communication selon l'invention distincte de la session supportée par le lien 61) . Le terminal 21 comporte également les protocoles et procédures (représentés par les doubles flèches 223 et 225) adaptées pour gérer et réaliser la résolution des adresses, l'établissement des connexions, les transferts et les conversions de protocoles entre le lecteur 22 de la carte initiatrice 20 et une application terminal 220 APPLI (TLOC) d'une part (double flèche 223) et entre les deux lecteurs 22 et 23 d'autre part (double flèche 225). 19
Dans la configuration représentée le terminal 21 dispose de l'application APPLI (TLOC) 220, par exemple un serveur Web utilisant sur le lien 61 une session de communication de la carte pro-active CPA 20 pour afficher des données sur le terminal 21 ou pour gérer l'interface utilisateur de ce terminal .
De plus le lien 62 est utilisé pour le dialogue entre les deux cartes pro-actives CPA 20 et CPA-2 24, par exemple entre les applications APPLI (CPA) 200 et APPLI (CPA-2) 240, les liens 61 et 62 supportant chacun une session de communication selon l'invention, ces sessions étant distinctes l'une de l'autre.
Enfin le terminal 21 après reconfiguration du lecteur 23 peut aussi acheminer des données vers l'application 250 de la carte CISO 25 seulement conforme ou compatible ISO 7816-3/4 par une session établie sur le lien 61 entre la carte pro-active CPA 20 et le terminal TLOC 21. Dans ce cas circuleront sur le lien 61 des données de type APDU sur session et sur le lien 63 des données de type APDU strict, ce dernier lien ne supportant que des données dans le mode APDU strict (sans session) .
La figure 3 montre un schéma de communication illustrant la mise en oeuvre du protocole de communication selon l'invention dans une structure de réseau externe.
Tel que représenté sur la figure 3 le terminal local TLOC 31 est équipé d'un lecteur de carte 32 et d'une interface réseau 33 pour lesquels les couches de protocole de terminal pour accéder à ce lecteur ou à cette interface réseau ne sont pas représentées. Le terminal local 31 par son lecteur 32 disposant des couches ISO 7816-3/4, PCPA et PCINV (protocole de communication selon l'invention) dialogue avec la carte pro-active CPA 30 dite initiatrice 20
par définition et disposant des mêmes couches ISO 7816- 3/4, PCPA et PCINV par l'intermédiaire du lien 71 (supportant en l'espèce une ou plusieurs sessions de communication selon l'invention). De même le terminal 31, par son interface réseau 33 disposant de la pile réseau TCP/X25 dialogue au travers de la pile réseau TCP/X25 de l'interface réseau 35 avec un terminal distant TDIS 34 par l'intermédiaire du lien 72 (supportant en l'espèce une session de communication réseau) .
Le terminal distant 34, par son lecteur de carte 36 disposant des couches ISO 7816-3/4, PCPA et PCINV (protocole de communication selon l'invention), dialogue avec la carte réseau pro-active CPA-3 37 disposant des mêmes couches ISO 7816-3/4, PCPA et PCINV par l'intermédiaire du lien 73 (supportant en l'espèce une ou plusieurs sessions de communication selon l'invention).
Le terminal local 31 et le terminal distant 34 comportent chacun les protocoles et procédures (représentés par les doubles flèches 310 et 320) adaptées pour gérer et réaliser la résolution des adresses, l'établissement des connexions, les transferts et les conversions de protocoles entre chaque lecteur 32, 36 de carte pro- active et la pile réseau TCP/X25 correspondante des interfaces réseau 33, 35. Dans cette configuration les terminaux 31, 34 disposent chacun d'un équipement ou d'une application logicielle faisant fonction de proxy
310, 320 qui fait la conversion de protocole entre le protocole de l'invention PCINV et les protocoles réseau.
Ainsi les deux cartes pro-actives 30, 37 [ou les deux applications carte APPLI (CPA) 300 et APPLI (CPA-3) 340] peuvent se connecter et dialoguer directement entre elles, les liens 71 et 73 supportant chacun une session 21
selon l'invention et le lien 72 supportant une session réseau.
Dans une autre variante de structure de réseau non représentée dans laquelle la carte pro-active 37 est remplacée par une carte classique seulement conforme ou compatible ISO 7816-3/4, le terminal distant comporte un équipement proxy distant pour effectuer la conversion entre protocole réseau et le protocole APDU, permettant ainsi une connexion en session de la carte locale proactive vers la carte classique par l'intermédiaire de deux sessions distinctes (une session selon l'invention entre la carte pro-active et le terminal local et une session réseau entre les deux terminaux) suivie d'un transfert de données en mode APDU entre le terminal distant et la carte classique.
Bien entendu il est possible dans le cadre de l'invention d'utiliser des terminaux mixtes (non représentés) combinant les deux types de structures locale et distante, chaque terminal possédant au moins deux lecteurs de carte dont au moins un est équipé de la couche du protocole selon l'invention PCINV et au moins une carte réseau permettant le dialogue entre toutes les cartes à puce sur lecteur associées localement ou à distance. De même les lecteurs de carte physiques locaux ou distants susceptibles de dialoguer entre eux ou avec la carte initiatrice peuvent être remplacés par des lecteurs virtuels pour autant que ces lecteurs supportent la compatibilité ISO 7816-3/4 ou sont capables d'émuler ou de supporter le protocole ISO 7816-3/4 ainsi qu'il a été présenté ci-avant dans le préambule du présent exposé.
Après avoir présenté le protocole de communication de l'invention dans son concept le plus large (en 22
particulier non nécessairement limité à l'environnement GSM) et notamment plusieurs modes de mises en oeuvre et/ou d'utilisation de ce protocole en structure locale et en réseau externe, il convient d'exposer 1 ' i plémentation du protocole selon l'invention au niveau de l'extension des commandes pro-actives de carte ou de lecteur de carte d'un protocole de type PCPA. A titre d'exemple non limitatif on décrira ci-après un mode préférentiel d' implémentation selon l'invention dans l'environnement GSM, les cartes pro-actives CPA (capables d'initier des actions de la carte vers le terminal) étant choisies du type SIM pro-active avec pour protocole de commandes pro-actives PCPA le protocole selon la spécification GSM 11.14/classe a et pour terminal d'accueil un terminal compatible GSM.
D'une façon générale, les cartes à microprocesseur SIM (Subscriber Identity Module) sont définies par les spécifications GSM tout en étant compatibles avec les normes ISO 7816-3/4. Ces cartes comportent une zone de personnalisation, en l'espèce d'identité d'un abonné, l'IMSI, (International Mobile Subscriber Identity). Les cartes SIM trouvent leur application la plus courante dans les terminaux mobiles de radiotéléphonie compatible GSM.
En l'espèce la carte SIM utilisée pour la présente invention est du type pro-active (également appelée de type SIM_Toolkit) et compatible avec la spécification GSM 11.14. /classe a. Toutefois pour la suite de l'exposé, une carte SIM pro-active sera sauf mention particulière simplement appelée carte SIM.
Le protocole de communication selon l'invention, conforme aux normes ISO 7816-3/4 ou compatible avec elles, utilise de ce fait des commandes logicielles APDU au départ du 23
terminal GSM, ou terminal ou mobile ME (Mobile Equip ent) , et qui selon ces normes commencent par un entête de 5 octets définis ci après : octet 1 (CLA)= classe de l'application octet 2 (INS) = instruction octet 3 et 4 (PI et P2) = paramètres de l'instruction octet 5 (P3) = longueur commande ou longueur réponse. Cet en-tête est éventuellement suivi par un champ de données présent dans la commande .
De plus la réponse de la carte SIM à une commande APDU comporte un épilogue de deux octets SW1 et SW2 (Status Word) éventuellement précédé d'un champ de données. Le code de SW1 est compris en codage hexadécimal (hex) entre 90 (acquittement positif) et 9F ou entre 60 et 6F en cas de problème indépendant de l'application. Le code SW2 sert à expliciter la cause du refus d'exécution de la commande .
Le protocole de communication selon la variante d' implémentation préférentielle de l'invention intègre la spécification GSM 11.14 selon laquelle l'émission d'une commande pro-active à partir de la carte SIM se fait selon le protocole spécifique suivant : - émission par la carte d'une réponse en retour d'une commande APDU du terminal, la réponse comportant les deux octets de statut SW1/SW2 avec SWl(hex)=91 pour indiquer une commande pro-active en attente et SW2 (hex) =xx où xx est la longueur de la commande pro-active. Le terminal ME émet alors une commande APDU FETCH vers la carte SIM dont la réponse en retour vers le terminal contiendra la commande pro-active en attente. La commande pro-active est exécutée par le terminal ME qui émet ensuite une réponse appelée TERMINAL RESPONSE pour rendre compte du résultat de l'exécution de la commande pro-active ou de son inexécution. 24
Pour la suite de la présentation du protocole selon l'invention les opérations d'émission du «statut» = 91xx et de la commande FETCH à partir du terminal GSM seront, sauf indication particulière, considérées comme implicites (ou implicitement remplacées par des opérations produisant les mêmes effets) .
Par ailleurs la spécification GSM 11.14/classe a conceptualise la notion de lecteur de carte (card reader) par : i) les quatre commandes carte : POWER ON CARD, PERFORM
CARD APDU, POWER OFF CARD, GET READER STATUS, et ii) une commande terminal ENVELOPE (...) associée à la procédure de Notification à la carte d'Evénement sur lecteur de carte : ENVELOPE (EVENT DOWNLOAD - card reader status) dans laquelle la structure EVENT = card reader status est encapsulée dans la commande EVENT DOWNLOAD
(Notification d'événement) elle-même encapsulée dans la commande terminal plus générale ENVELOPE (...).
Ces commandes permettent respectivement à une application carte :
- de mettre sous tension un lecteur carte résidant dans le mobile,
- d'envoyer des données sous forme d'APDU,
- de mettre ce lecteur hors-tension,
- de vérifier le statut du lecteur, et
- d'être notifiée d'événements lecteur carte.
Selon le protocole de l'invention on utilise les 4 commandes carte et la notification de carte Evénement du lecteur de carte (card reader) pour gérer une session de communication vers un lecteur de carte distant ou local : ouverture de la session, transfert de données sur la 25
session et contrôle de la session, fermeture de la session et notification de changement de session.
On étend ainsi la localisation des lecteurs du mobile GSM vers Internet ou les autres réseaux tout en conservant une compatibilité avec les applications existantes. La carte SIM pro-active utilisera donc les mêmes commandes pour adresser un lecteur carte situé sur le réseau, par exemple un coffre fort électronique SAM, qu'un lecteur local comportant un porte-monnaie électronique.
Pour faciliter la compréhension de la suite de l'exposé on rappellera brièvement quelques caractéristiques des commandes de lecteur carte (card reader) de la spécification GSM 11.14/classe a. Comme toutes les commandes pro-actives les 4 commandes de lecteur carte (card reader) incluent un discriminant « identités des équipements » (Device identities) qui spécifie l'équipement émetteur et l'équipement destinataire.
Dans le sens « Carte SIM vers Mobile ME » le discriminant Device identities est positionné pour les 4 commandes de lecteur carte avec :
- Identité Emetteur = 81 (hex) = Carte SIM - Identité Destinataire = 10 (hex) à 17 (hex) = Lecteur carte additionnel x (0 à 7) (additionnai card reader x) .
Par exemple une commande POWER ON CARD (non encore étendue selon l'invention) pourra s'écrire selon la spécification GSM 11.14/classe a:
POWER ON CARD (hex) = D0 09 01 03 01 31 00 02 02 81 11 90
00 dans laquelle
- D0 09 01 03 01 31 00 forme l'en-tête de la commande pro-active avec à la fin un octet d'attribut de commande 26
(Command Qualifier) CQ = 00 réservé pour usage futur (rfu) .
- 02 02 81 11 est un champ de donnée comportant en épilogue les identités de l'émetteur 81 (la carte SIM) et le destinataire 11 (le lecteur résidant 11), et
- 90 00 correspond à SW1/SW2.
Dans le sens « Mobile ME vers Carte SIM » la réception de l'Evénement card reader status permet à l'application SIM_Toolkit d'être notifiée d'une modification de l'état du lecteur, par exemple 'carte insérée', 'carte retirée'. Cet événement fait partie de la commande terminal ENVELOPE (EVENT DOWNLOAD - card reader status) qui inclut un discriminant Device identities positionné avec : - Identité Emetteur = 82 (hex) = Mobile ME
- Identité Destinataire = 81 (hex) = Carte SIM et un champ card -reader status (codé sur un octet) = n° lecteur (3 bits) + ' drapeaux' (flags) d'état de statut .
Enfin la réponse TERMINAL RESPONSE aux commandes de lecteur carte du type PERFORM CARD APDU contient le discriminant Device Identities positionné avec
- Identité Emetteur = 82 (hex) = Mobile ME. - Identité Destinataire = 81 (hex) = Carte SIM
PRESENTATION DES COMMANDES PRO-ACTIVES GSM 11.14/ CLASSE A (COMMANDES Card Reader) ETENDUES UTILISEES DANS LE PROTOCOLE SELON L'INVENTION
I MODE SYNCHRONE
Selon l'invention la correspondance entre les commandes card reader et les opérations de gestion d'une session de communication commence par l'ouverture d'une session par la carte SIM pro-active avec établissement de la 27
connexion et l'introduction d'un numéro de session à 1 ' aide de la commande POWER ON CARD étendue .
OUVERTURE D'UNE SESSION PAR LA CARTE SIM (OUVERTURE LOCALE) / ETABLISSEMENT D'UNE CONNEXION (POWER ON CARD)
Plus particulièrement selon l'invention la commande POWER ON CARD étendue comporte deux champs complémentaires constitués chacun d'une chaîne de caractères au format « machine_l : application_2 », (format non limitatif) . En pratique chaque chaîne définit un champ de type TLV (Tag/Length/Value) indiquant l'identité Address de 1 ' équipement Emetteur ou de 1 ' équipement Destinataire .
Selon un premier exemple avec un lecteur local destinataire la commande POWER ON CARD étendue pourra s'écrire (hex) [après mise en caractères gras des champs ajoutés ou modifiés dans leurs interprétations] : D0090103013100020281110606FF00000000010606FF00000001039000
dans laquelle l'Identité Destinataire = 11 (lecteur local) et le N° de canal = 11 - 10 = 1
- le TLV 0606FF0000000001 = Address-Emetteur (adresse
AID) - le TLV 0606FF0000000103 = Address-Destinataire (adresse AID) , et l'attribut de commande CQ ≈ 00 (mode APDU) .
La réponse TERMINAL RESPONSE s'écrira : A01400001701030131000202828103010021092802063BF01100FF00
où l'identité Emetteur = 82 = Mobile.
On notera que 1 'Address-Destinataire doit toujours être une adresse application AID ou à défaut une adresse machine par exemple : www.bull.net : 8070 (où 8070 est le 28
code du Serveur Web et 70 le code du numéro de port TCP) soit en codage (hex) -.7777772E62756C6C2E6E65743A38303730
Selon un second exemple avec un lecteur réseau destinataire (la machine www. bull .net : 8070) la commande POWER ON CARD étendue pourra s'écrire (hex) [après mise en caractères gras des champs ajoutés ou modifiés dans leurs interprétations] :
D0230103013102020281210606FF0606FF00000000010612FF7777772 E62756C6C2E6E65743A383037309000 avec :
- l'attribut de commande CQ = 02 signifie que le dialogue s'effectue en mode binaire. - l'Identité Destinataire = 21 (lecteur réseau) et le N° de canal (hex) = 21 - 20 = 01
- le TLV 0606FF0000000001 = Address-Emetteur (adresse AID)
- le TLV 0612FF7777772E62756C6C2E6E65743A38303730 Address-Destinataire avec une adresse machine.
La réponse TERMINAL RESP0NSE s'écrira :
A01400001701030131000202838103010021092802063BF01100FF00 où l'identité Emetteur = 83 = Réseau (Network) au lieu de 82 = Mobile.
Par convention le numéro du lecteur de carte reste le numéro des lecteurs du mobile pour les valeurs (hex) 10 à 17 et devient égal à (hex) 20 à 2F pour les lecteurs distants, ce qui garantit la compatibilité avec la spécification GSM 11.14/classe a existante.
A titre d'exemple non limitatif, on donne par convention et par commodité le numéro d'Identité Destinataire comme numéro de session de communication. Ainsi la présence du motif binaire 0010 xxxx qui correspond à la plage (hex) 29
20 à 2F permet au mobile i) d'interpréter la commande comme une commande de gestion de session avec un lecteur réseau par opposition au motif binaire 0001 Oxxx qui identifie les numéros logiques (0 à 7) des lecteurs cartes locaux résidants dans le mobile et ii) d'aller lire le nom du lecteur réseau Identité Destinataire qui sera un champ supplémentaire dans la structure Device identities .
Ainsi le numéro de session défini par la commande POWER ON CARD sera utilisé par les autres commandes de la séquence PERFORM CARD APDU, POWER OFF CARD et GET READER STATUS lors du déroulement séquentiel ou synchrone de la session.
Le mobile se sert de ce numéro de session pour :
- créer en réception de la commande POWER ON CARD un tunnel entre le mobile et le lecteur réseau ou le site rattaché au lecteur carte, utilisant ainsi la possibilité d'envoyer des APDU par un tunnel GPRS,
- fermer ce tunnel en fonction des événements réseaux ou de l'ordre carte POWER OFF CARD,
- gérer le flot de données en provenance de la carte SIM et du tunnel (par la commande PERFORM CARD APDU) , - notifier à la carte SIM des changements d'état de la connexion par réception de l'événemen card reader status' ou par la commande carte GET READER STATUS.
La validité du numéro de session expire à la fin de la session par la commande POWER OFF CARD du lecteur distant, une réinitialisation de la carte SIM, ou un problème de liaison dans la connexion.
On notera que plusieurs sessions peuvent être gérées simultanément au niveau de la carte SIM et que la lecture synchrone/asynchrone sur plusieurs canaux est possible. 30
ECRITURE SYNCHRONE DE DONNEES PAR LA CARTE SIM (PERFORM CARD APDU)
Selon 1 ' invention la commande PERFORM CARD APDU étendue est complétée par :
- un attribut de commande (Command Qualifier) CQ(hex) = 02 (ou 04) où CQ = 02 = PUT_DATA = transfert de n octets de la carte SIM vers le mobile, les données échangées étant du type APDU ou binaires sur APDU ; et où CQ = 04 = PUT_DATA_END transfert de n octets de la carte SIM vers le mobile avec la fin du transfert ;
- une Identité Destinataire = 21 - un objet données TLV = C_APDU contenant les données à transférer [en l'espèce AAAA = (hex) 41414141 de longueur quatre octets L = 04] .
La commande PERFORM CARD DATA (ECRITURE) s'écrit : D00F010301300202028121220441414141
La réponse TERMINAL RESPONSE contiendra un TLV = R_APDU contenant les données à transférer en réponse, en l'espèce (hex) 0000 et s'écrit :
A01400001001030130020202838103010023020000
où l'Identité Emetteur = 83 = Réseau (Network)
LECTURE SYNCHRONE DE DONNEES PAR LA CARTE SIM (PERFORM CARD APDU)
Pour cette opération de lecture par la carte SIM la commande PERFORM CARD APDU étendue est complétée selon l'invention par :
- un attribut de commande Command Qualifier CQ(hex) = 01 31
où CQ = 01 = GET_DATA = transfert de n octets du Mobile vers la carte SIM
- une Identité Destinataire (hex) = 21 donnant le n° de canal = 21 - 20 = 01 - un objet données TLV = C_APDU contenant des valeurs nulles sur deux octets [en l'espèce (hex) 0000 avec L = 02] .
La commande PERFORM CARD DATA (LECTURE) s'écrit
D00D010301300102028121220200009000
La réponse TERMINAL RESPONSE contiendra un objet TLV = R_APDU contenant les données à transférer en réponse, en l'espèce (hex) 414243 et s'écrira :
A0140000FA0103013002020283810301002303414243
où l'Identité Emetteur = 83 = Réseau (Network) et où l'attribut de commande Command Qualifier CQ = 02 (ou 04) avec
CQ = 02 = lecture incomplète, autres données disponibles sur le Mobile
CQ = 04 = lecture complète, plus de données disponibles.
FERMETURE D'UNE SESSION PAR LA CARTE SIM (FERMETURE
LOCALE) / FIN DE CONNEXION (POWER OFF CARD)
Pour cette opération de fermeture par la carte SIM la commande POWER OFF CARD étendue est complétée selon
1 ' invention par :
- une Identité Destinataire (hex) = 21 donnant le n° de canal = 21 - 20 = 01
La commande s'écrit alors : D0090103013200020281219000 32
II MODE ASYNCHRONE
Le mode asynchrone est caractérisé par la venue au coup par coup de Notifications à la carte SIM pro-active de 1 ' Evénement card reader status par 1 ' intermédiaire de la commande terminal ENVELOPE, étant fait remarquer que le contenu de l'événement card reader status est modifié selon le type d'événement « lecteur » à prendre en considération par la carte SIM (ouverture de session, transfert de données, fermeture de session) .
OUVERTURE D'UNE SESSION PAR LE RESEAU OU PAR UN LECTEUR LOCAL A PARTIR DU MOBILE (OUVERTURE DISTANTE)/ ENVELOPE (EVENT DOWNLOAD - card reader status)
Une caractéristique très intéressante du protocole selon l'invention réside dans la possibilité d'avertir la carte SIM de l'ouverture d'une session par le réseau ou par un lecteur local. On est ainsi en présence d'une requête Serveur (ouverture distante) par opposition à une requête Client (ouverture locale où la carte SIM prend l'initiative de l'ouverture de la session tel que présenté ci-avant) .
La réception de l'événement GSM 11.14 card reader status par la carte SIM grâce à la commande terminal ENVELOPPE (EVENT DOWNLOAD - card reader status) permet à l'application SIM_Toolkit d'être notifiée d'une modification de l'état du lecteur (par exemple 'carte insérée' / 'carte retirée'). L'application SIM_Toolkit peut alors dérouler une procédure correspondant à une demande de connexion ou à une fin de connexion. Une demande de connexion peut correspondre à une requête Serveur, l'application SIM_Toolkit étant configurée dans ce cas en Serveur par exemple en Serveur TCP/IP ou HTTP si la pile logicielle adéquate est présente au dessus des quatre commandes 33
lecteur carte de l'API GSM 11.14/classe a. Les détails de la notification au niveau du mobile d'une demande de connexion réseau doit faire l'objet d'un protocole spécifique d'échange de données GPRS ou autre (IP, X25, etc .. ) .
Dans la pratique la gestion du statut du lecteur local résidant dans le mobile ou du lecteur réseau peut se faire tout en gardant la compatibilité réciproque à l'aide d'un champ Device identities de la structure
TERMINAL RESPONSE qui contient l'identité de l'Emetteur
(Source Device Identity) avec :
(hex) 82 = Mobile pour les lecteurs locaux résidant dans le Mobile (hex) 83 = Réseau (Network) pour les connexions réseau
Il est à noter que d'une façon distincte, la demande de statut par la carte SIM pro-active par la commande GET READER STATUS peut se faire en utilisant le numéro de session (hex) 20 à 2F, la présence du motif binaire 0010 xxxx permet au mobile d'interpréter la commande comme une demande des statuts des sessions en cours par opposition au motif binaire 0001 lxxx qui identifie les numéros logiques (0 à 7) des lecteurs carte résidant dans le mobile. Le mobile envoie alors à la carte SIM la concaténation des statuts de tous les lecteurs carte réseau soit n fois une structure de 3 octets TLV (Tag/Length/Status) .
Selon l'invention la structure EVENT DOWNLOAD - card reader status est étendue par l'ajout en fin de structure d'un champ card reader status (hex) = 81 par exemple et de deux objets TLV donnant 1 'Address-Emetteur = 0606FF0000000001 et 1 'Address-Destinataire= 0612FF- 7777772E62756C6C2E6E65743A38303730. 34
La structure EVENT DOWNLOAD - Card reader status pourra alors s'écrire :
A0C4000028D626190106020283812001810606FF00000000010612FF 7777772E62756C6C2E6E65743A38303730 où l'octet du card reader status = 81 = ssss iiii où ssss = statut et iiii = canal id = (hex) 1 = 1 avec
- statut (hex) = 8 = SESSION_OPEN (ouverture session) et 8x = requête du Mobile pour l'ouverture d'une session sur le canal x,
- statut (hex) = 0 = SESSION_CLOSE (fermeture session) et Ox = requête du Mobile pour la fermeture d'une session sur le canal x,
- statut (hex) = C = SESSION_DATA (transfert données) et Cx = requête du Mobile pour le transfert de données sur le canal x,
Dans le cas présent Statut = 81 correspond à une ouverture de session sur le canal 1 avec en ce qui concerne l'identification de l'Emetteur :
(hex) 82 = Mobile pour les lecteurs locaux résidant dans le Mobile
(hex) 83 = Réseau (Network) pour les connexions réseau
(cas présent) .
LECTURE ASYNCHRONE DE DONNEES PAR LA CARTE SIM / ENVELOPE
(EVENT DOWNLOAD - card reader status)
Cette opération de lecture asynchrone par la carte SIM est également réalisée par l'intermédiaire de la commande terminal ENVELOPPE (EVENT DOWNLOAD - card reader status).
Selon l'invention la structure EVENT DOWNLOAD - card reader status est étendue par l'ajout en fin de structure : 35
i) d'un champ card reader status (hex) = Cl par exemple, avec statut (hex) = C = SESSION_DATA (transfert données) et Cx = requête du Mobile pour le transfert de données sur le canal x et statut = Cl correspondant à 1 ' arrivée de données nouvelles sur le canal 1; ii) et d'un objet TLV de type R-APDU qui contient le données A1A2A3A4A5 à transférer à la carte, par exemple TLV (R-APDU) = 2305A1A2A3A4A5.
La structure EVENT DOWNLOAD - card reader status pourra s'écrire :
AOC2000013D611190106020283812001C12305A1A2A3A4A5
avec en ce qui concerne l'identification de l'Emetteur : (hex) 82 = Mobile pour les lecteurs locaux résidant dans le Mobile
(hex) 83 = Réseau (Network) pour les connexions réseau (cas présent) .
FERMETURE D'UNE SESSION PAR LE RESEAU OU PAR UN LECTEUR LOCAL A PARTIR DU MOBILE (FERMETURE DISTANTE) / ENVELOPE (EVENT DOWNLOAD - card reader status)
D'une façon parallèle à l'ouverture distante d'une session (établissement d'une connexion) par le réseau ou par un lecteur local, la fermeture distante d'une session (fin de connexion) est réalisée par l'intermédiaire de la commande terminal ENVELOPE encapsulant la structure EVENT DOWNLOAD - card reader status.
Selon 1 ' invention la structure EVENT DOWNLOAD - card reader status est étendue par le positionnement en fin de structure d'un champ card reader status (hex) = 01 par exemple. Dans le cas présent statut = 01 correspond à une requête de fin de connexion (ssss = 0) sur le canal 01 (iiii = 1) 36
La structure EVENT DOWNLOAD - card reader status pourra s'écrire :
AOC200000CD60A19010602028381200101
avec en ce qui concerne l'identification de l'Emetteur : (hex) 82 = Mobile pour les lecteurs locaux résidant dans le Mobile
(hex) 83 = Réseau (Network) pour les connexions réseau (cas présent) .
En conclusion le protocole selon l'invention décrit ci- avant dans sa version de base présente un certain nombre d'avantages déjà mis en avant au cours de l'exposé de l'invention et qui sont résumés ci-après.
Le protocole selon 1 ' invention permet une programmation simplifiée puisque que les ordres (commandes) sont soumis séquentiellement vers le lecteur sans nécessité de sortir de l'application à chaque ordre. En particulier le lecteur reste « bloqué » et indisponible pour une autre session jusqu'à réception du résultat de la commande proactive (ceci n'empêchant pas l'envoi de Notifications de carte par la commande ENVELOPE) , toute erreur rencontrée pouvant ainsi être traitée immédiatement.
Pour le mobile le taux de transfert est amélioré par le protocole selon l'invention par rapport à l'utilisation des mini messages SMS, le mobile étant susceptible d'utiliser un circuit externe GPRS dans l'état actuel de l'art d'un débit d'au moins 9600 bits/s.
Par ailleurs les données sont échangées par une API uniforme quelque soit la localisation du lecteur (lecteur local résidant dans le mobile ou lecteur réseau distant) et la compatibilité avec le mécanisme de base de la 37
spécification GSM 11.14/classe a pour le dialogue avec un lecteur est respectée.
De plus la disponibilité du canal de communication de données (réseau Internet, lien GPRS) est connue dès l'ouverture de la session par la commande POWER ON CARD qui retournera une erreur si le Mobile est dans l'incapacité d'ouvrir ce canal, par exemple si toutes les sessions sont actives, si la couverture radio est mauvaise ou si la machine distante ne répond pas au delà d'un certain délai (ti e out) , par exemple de plusieurs secondes .
La disponibilité d'un circuit et la vitesse des transfert permettent d'envisager des transactions courtes ainsi que la mise en place sur la carte SIM pro-active de piles de protocoles tels que TCP étant données la simplicité de l'API (4 commandes) et son efficacité.
Enfin la connaissance avant de démarrer la transaction de la disponibilité du lien avec le lecteur et la rapidité du transfert de données obtenues grâce au protocole selon l'invention permet d'envisager avec ce protocole des applications de commerce électronique beaucoup plus fiables qu'en mode SMS.
III OPTIMISATION DE LA COMMANDE (PERFORM CARD APDU)
Au delà de son implémentation de base, le protocole de communication selon l'invention comporte également en une première variante optionnelle un jeu de commandes optimisées pour combiner en une seule commande une commande d'opération de transfert de données avec une commande de fermeture de session. 38
COMMANDE COMBINEE D'ECRITURE A PARTIR DE LA CARTE SIM ET DE FERMETURE DE SESSION (PERFORM CARD APDU)
Par rapport à la commande d'écriture étendue PERFORM CARD APDU décrite ci-avant, la commande combinée comporte un attribut de commande Command Qualifier CQ = 06 (PUT_DATA_AND_CLOSE) , avec
- une Identité Destinataire = 21
- un objet données TLV = C_APDU contenant les données à transférer [en l'espèce AAAA = (hex) 41414141 de longueur quatre octets L = 04] .
La commande PERFORM CARD DATA (ECRITURE + FERMETURE) s'écrira : DOOF010301300602028121220441414141
Dans le cas présent l'attribut Command Qualifier CQ = 06 correspond au transfert de n octets de la carte SIM vers le Mobile, à la clôture d'écriture (absence d'octets à transférer) et à la fin de la connexion.
La réponse TERMINAL RESPONSE contiendra un TLV = R_APDU contenant les données à transférer en réponse, en l'espèce (hex) 0000, et s'écrira : A01400001001030130060202838103010023020000 avec l'Identité Emetteur = 83 = Réseau (Network)
COMMANDE COMBINEE D'ECRITURE A PARTIR DU MOBILE (LECTURE DE DONNEES PAR LA CARTE SIM) ET DE FERMETURE DE SESSION (PERFORM CARD APDU)
Pour cette opération de lecture par la carte SIM la commande PERFORM CARD APDU étendue est complétée selon
1 ' invention par :
- un attribut de commande (Command Qualifier) CQ(hex) = 01 avec CQ = 01 = GET_DATA= transfert de n octets du
Mobile vers la carte SIM 39
- une Identité Destinataire (hex) = 21 donnant le n° de canal = 21 - 20 = 01
- un objet données TLV = C_APDU contenant les données à transférer [en l'espèce (hex) 0000 avec L= 02].
La commande PERFORM CARD DATA (LECTURE) s'écrit au départ carte SIM sans changement par rapport à la commande étendue correspondante : D00D010301300102028121220200009000
Par contre la modification apparaîtra dans la réponse
TERMINAL RESPONSE dont le champ attribut de commande
Command Qualifier sera porté à la valeur (hex) CQ = 06
(au lieu de CQ = 02 = lecture incomplète ou CQ = 04 = lecture complète) et correspondant à la fin de la lecture par la carte en fait de l'écriture par le Mobile, toutes les données étant disponibles dans l'objet TLV R_APDU, et à la fin de la connexion.
Ainsi la réponse TERMINAL RESPONSE qui contient un TLV = R_APDU contenant les données à transférer en réponse, en l'espèce (hex) 414243 s'écrira : A0140000110103013006020283810301002303414243
où l'Identité Emetteur = 83 = Réseau (Network) et où le champ Command Qualifier CQ = 06.
De plus le protocole selon l'invention comporte également en une seconde variante optionnelle un jeu de commandes optimisées pour la lecture d'une chaîne d'octets à accès séquentiel, ci-après « flux de données » (stream) , et notamment pour réaliser au moins une des opérations :
- de glissement du pointeur de lecture du flux de données par intégration d'une commande complémentaire SKIP_DATA /GLISSER_DONNEES, 40
- d'élimination de tous les caractères du flux de données en attente de lecture par intégration d'une commande complémentaire FLUSH_DATA/VIDER_D0NNEES et
- de recherche dans les caractères du flux de données en attente de lecture par intégration d'une commande complémentaire FIND_DATA/TROUNER_DONNEES .
LECTURE OPTIMISEE A PARTIR DE LA CARTE SIM (PERFORM CARD APDU)
Dans cette seconde variante la commande de lecture entendue PERFORM CARD APDU [qui dans sa version de base présente un champ attribut de commande Command Qualifier CQ = 01 (GETJDATA) ] voit le champ CQ élargi selon les options d'écriture suivantes: CQ = 01 (GET_DATA)
CQ ≈ 03 (SKIP_DATA) avec glissement du pointeur de lecture du flux de données venant du Mobile de N octets, N étant spécifié dans l'objet TLV (C_APDU) CQ = -1 (FLUSH_DATA) avec élimination de tous les caractères du flux de données en attente de lecture CQ = 05 (FIND_DATA) avec glissement du pointeur de lecture du flux de données venant du Mobile jusqu'à trouver dans les caractères du flux de données en attente de lecture l'élément TLV, ASN, etc.. dont la valeur est spécifiée dans l'objet TLV (C_APDU) .
Ainsi la commande PERFORM CARD ADPU (SKIP_DATA) s'écrit: D00D010301300302028111220202AE9000 où l'Identité Destinataire (hex) = 21 permet de connaître le n° de canal = 21 -20 = 01 et où N(hex) = 02AE soit 686 octets.
En retour le TERMINAL RESPONSE correspondant s'écrira : AO140000110103013002020283810301002303414243 41
où CQ = 02 (lecture incomplète) l'Identité Emetteur = 83 (Réseau/Network)
TLV (R_APDU) = 2303414243 contient les données (hex) à transférer à la carte soit en l'espèce 414243.
Cette dernière commande de lecture PERFORM CARD APDU optimisée est particulièrement performante pour la lecture dans des bases de données de grandes dimensions souvent rencontrées dans les réseaux de données, notamment dans le réseau Internet.
Dans la pratique on notera que ces extensions selon l'invention des commandes pro-actives GSM 11.14/classe a et de la procédure de Notification carte Evénement sur lecteur de carte sont réalisées sous la forme d'une ou plusieurs applications logicielles conformes aux nouvelles règles et procédures présentées ci-avant pour les commandes pro-actives de carte ou de lecteur de carte et la procédure de Notification ainsi modifiées, ces applications logicielles étant regroupées pour former de façon non limitative la couche logicielle du protocole de communication selon l'invention PCINV.
On rappellera pour finir que bien entendu le protocole de communication selon l'invention n'est pas limité à sa mise en oeuvre et à son implémentation dans l'environnement GSM décrites ci-devant mais est susceptible d'être mis en oeuvre dans le cadre de l'invention défini par les revendications ci-après dans toute application utilisant une carte pro-active conforme ou compatible ISO 7816-3/4 ou capable d'émuler ou de supporter le protocole ISO 7816-3/4 et comportant un jeu de commandes pro-actives de carte ou de lecteur de carte susceptibles d'être étendues pour gérer une session de communication entre la carte et son terminal d'accueil.

Claims

42REVENDICATIONS :
1. Protocole de communication apte à gérer les transferts de données entre une carte à puce pro-active (10,20,30) conforme ou compatible ISO 7816-3/4 ou capable d'émuler le protocole ISO 7816-3/4 ou des protocoles supportant ce protocole ISO 7816-3/4 , ci-après la carte initiatrice, et son terminal d'accueil (11-12,21,31), ledit protocole de communication comportant au moins une commande pro- active de carte ou de lecteur de carte et/ou une procédure de Notification de carte de type Evénement sur lecteur de carte, ledit protocole de communication étant caractérisé en ce que lesdits transferts de données sont gérés par sessions de communication sur carte pro-active, au moyen d'au moins une commande pro-active étendue dérivée de la ou desdites commandes pro-actives de carte ou de lecteur de carte et/ou d'une procédure de Notification de carte étendue dérivée de ladite procédure de Notification de carte de type Evénement sur lecteur de carte.
2. Protocole selon la revendication 1, caractérisé en ce qu'il est utilisé dans une ou plusieurs sessions de communication sur carte pro-active localement distinctes pour des transferts de données carte à carte au travers d'une chaîne de sessions de communication assurant la connexion directe et permanente entre les deux cartes (20-24, 30-37) pendant la durée des sessions.
3. Protocole selon la revendication 1, caractérisé en ce qu'il est utilisé pour le transfert de données au travers du terminal d'accueil (21) entre la carte initiatrice (20,30) et au moins une carte locale (24) connectée audit terminal (21) par un lecteur de carte local réel ou virtuel (22) ou au moins une carte réseau (37) connectée 43
à un réseau de données externe ou distant (72,34,73) par un lecteur réseau réel ou virtuel (36) .
4. Protocole selon la revendication 1, caractérisé en ce que les transferts de données entre ladite carte initiatrice (20,30), les cartes locales (24,25) et/ou les cartes réseau (37) sont réalisés en tout ou partie sur une ou plusieurs interfaces au travers de canaux de communication alloués dynamiquement.
5. Protocole selon la revendication 1, caractérisé en ce qu'il est utilisé de façon bidirectionnelle aux deux extrémités d'une connexion entre deux cartes pro-actives distantes (30-37), chaque carte (30-37) étant connectée localement à son terminal correspondant (31-34) par une session de communication sur carte pro-active, les deux terminaux (31-34) étant connectés entre eux par au moins une session réseau et adaptés pour gérer les conversions de protocoles entre les sessions sur cartes pro-actives et la session réseau et les flux de données dans les canaux de communications correspondants.
6. Protocole selon la revendication 1, utilisant un nom logique avec un adressage réseau, caractérisé en ce que : - à l'ouverture de session une première connexion est d'abord établie entre deux applications réseau, ladite première connexion ou connexion réseau étant suivie d'une connexion de type applicatif avec échange de messages sur la connexion réseau, et - à la fermeture de session, la fermeture de ladite connexion de type applicatif est réalisée dans un premier temps puis suivie de la fermeture de la connexion réseau.
7. Protocole selon la revendication 1, caractérisé en ce que ladite carte initiatrice (20,30) est connectée : 44
I) soit en mode APDU strict avec transfert de données au format APDU sur session: la) avec un lecteur de carte (25) associé localement au lecteur de la carte initiatrice (22), par exemple un mobile GSM bi-fentes avec carte initiatrice SIM et une carte classique de débit/crédit ;
Ib) avec un lecteur de carte distant associé à un réseau externe de données, la carte initiatrice accédant au réseau par des terminaux (31,34) formant serveurs de réseaux, par exemple par une machine proxy locale à la carte initiatrice et une machine proxy locale au lecteur de carte distant; ou le) une carte à puce virtuelle définie par une application informatique locale ou distante émulant le protocole ISO 7816-3/4 ou des protocoles supportant ce protocole ISO 7816-3/4;
II) soit en mode binaire sur session avec transfert de données en format binaire: lia) avec un lecteur de carte (24) associé localement au lecteur de la carte initiatrice (20) et supportant un protocole supportant l'ouverture de session de communication sur carte pro-active;
Ilb) avec un lecteur de carte distant (37) associé à un réseau externe de données (72) et supportant un protocole supportant l'ouverture de session, la carte initiatrice (30) accédant à des terminaux (31,34) formant serveurs de réseau assurant la gestion de la session carte initiatrice et de la session réseau distant; ou Ile) une carte à puce virtuelle définie par une application informatique locale ou distante et gérant des sessions de type TCP ou X25.
8. Protocole selon la revendication i, caractérisé en ce qu'il est utilisé avec une carte initiatrice (10,20,30) de type carte SIM pro-active et un terminal d'accueil compatible GSM, ledit protocole comportant une extension 45
de commandes pro-actives de lecteur de carte local de la spécification GSM 11.14/classe a de façon à utiliser des commandes pro-actives étendues uniformes pour gérer les transferts de données entre la carte SIM (10,20,30) et indifféremment un lecteur local (24) ou un lecteur réseau externe (37) .
9. Protocole selon la revendication 1, caractérisé en ce qu'il présente la capacité d'insertion dynamique des lecteurs réseau (36) et/ou de lecteurs locaux (24) et de réalisation de sessions de communication sur carte proactive à partir de cartes distantes (37) et/ou de cartes locales (24), avec possibilité d'ouverture et de fermeture de session distantes à partir du terminal d'accueil, par extension de la procédure de Notification de carte .
10. Protocole selon la revendication 1, caractérisé en ce que les commandes étendues sont optimisées pour combiner en une seule commande une commande d'opération de transfert avec une commande de fermeture de session.
11. Protocole selon la revendication 1, caractérisé en ce que la commande étendue pour la lecture à partir de la carte pro-active (10,20,30) est optimisée pour permettre lors de la lecture d'une chaîne d'octets à accès séquentiel, ci-après flux de données, de réaliser au moins une des opérations :
- de glissement du pointeur de lecture du flux de données par intégration d'une commande complémentaire SKIP_DATA
/GLISSER_DONNEES,
- d'élimination de tous les caractères du flux de données en attente de lecture par intégration d'une commande complémentaire FLUSH_DATA/VIDER_D0NNEES et 46
- de recherche dans les caractères du flux de données en attente de lecture par intégration d'une commande complémentaire FIND_DATA/TROUNER_DONNEES .
12. Terminal apte à transmettre et/ou recevoir des données d'une carte pro-active conforme ou compatible ISO 7816-3/4 ou capable d'émuler le protocole ISO 7816- 3/4 ou des protocoles supportant ce protocole ISO 7816- 3/4 , ci-après la carte initiatrice, ledit protocole de communication comportant au moins une commande pro-active de carte ou de lecteur de carte et/ou une procédure de Notification de carte de type Evénement sur lecteur de carte, caractérisé en qu'il implémente un protocole de communication apte à gérer lesdits transferts de données au moyen d'au moins une commande pro-active étendue dérivée de la ou desdites commandes pro-actives de carte ou de lecteur de carte et/ou d'une procédure de Notification de carte étendue dérivée de ladite procédure de Notification de carte de type Evénement sur lecteur de carte.
13. Carte pro-active conforme ou compatible ISO 7816-3/4 ou capable d'émuler le protocole ISO 7816-3/4 ou des protocoles supportant ce protocole ISO 7816-3/4, apte à transmettre et/ou recevoir des données d'un terminal, ledit protocole de communication comportant au moins une commande pro-active de carte ou de lecteur de carte et/ou une procédure de Notification de carte de type Evénement sur lecteur de carte, caractérisée en ce qu'elle implémente un protocole de communication apte à gérer lesdits transferts de données avec ledit terminal au moyen d'au moins une commande pro-active étendue dérivée de la ou desdites commandes pro-actives de carte ou de lecteur de carte et/ou d'une procédure de Notification de carte étendue dérivée de ladite procédure de Notification de carte de type Evénement sur lecteur de carte.
PCT/FR2001/003505 2000-11-10 2001-11-09 Protocole de communication entre une carte a puce de type pro-active et son terminal d'accueil WO2002039369A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0014440A FR2816785B1 (fr) 2000-11-10 2000-11-10 Protocole de communication entre une carte a puce de type pro-active et son terminal d'accueil
FR00/14440 2000-11-10

Publications (1)

Publication Number Publication Date
WO2002039369A1 true WO2002039369A1 (fr) 2002-05-16

Family

ID=8856280

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2001/003505 WO2002039369A1 (fr) 2000-11-10 2001-11-09 Protocole de communication entre une carte a puce de type pro-active et son terminal d'accueil

Country Status (2)

Country Link
FR (1) FR2816785B1 (fr)
WO (1) WO2002039369A1 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2878685A1 (fr) * 2004-11-30 2006-06-02 Gemplus Sa Declenchement de session pro-active depuis une applet dans une carte a puce
CN101383994B (zh) * 2007-09-07 2016-05-25 锐迪科微电子（上海）有限公司 一种apdu命令的数据处理方法
CN113965228A (zh) * 2021-10-08 2022-01-21 深圳市汇顶科技股份有限公司 扩展nfc卡模拟功能的方法、nfc扩展设备和nfc终端
US12147523B2 (en) 2020-12-29 2024-11-19 Hid Global Gmbh Reader device and method of configuring the same

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0744708A2 (fr) * 1995-05-23 1996-11-27 Kabushiki Kaisha Toshiba Unité de lecture et d'écriture de carte à circuit intégrée et méthode de transfert de données
US5581708A (en) * 1993-03-23 1996-12-03 Kabushiki Kaisha Toshiba Data transmission system using electronic apparatus having a plurality of transmission protocols
WO1998052160A2 (fr) * 1997-05-15 1998-11-19 Mondex International Limited Systeme et procede permettant de charger de maniere flexible une carte a circuit integre
WO1999001960A2 (fr) * 1997-06-30 1999-01-14 Schlumberger Systemes Commande par carte a memoire de ressources de terminaux et de reseaux
WO2000003363A1 (fr) * 1998-07-10 2000-01-20 Gemplus Systemes d'organisation de carte a puce en vue de son utilisation en tant que serveur dans un reseau du type internet

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5581708A (en) * 1993-03-23 1996-12-03 Kabushiki Kaisha Toshiba Data transmission system using electronic apparatus having a plurality of transmission protocols
EP0744708A2 (fr) * 1995-05-23 1996-11-27 Kabushiki Kaisha Toshiba Unité de lecture et d'écriture de carte à circuit intégrée et méthode de transfert de données
WO1998052160A2 (fr) * 1997-05-15 1998-11-19 Mondex International Limited Systeme et procede permettant de charger de maniere flexible une carte a circuit integre
WO1999001960A2 (fr) * 1997-06-30 1999-01-14 Schlumberger Systemes Commande par carte a memoire de ressources de terminaux et de reseaux
WO2000003363A1 (fr) * 1998-07-10 2000-01-20 Gemplus Systemes d'organisation de carte a puce en vue de son utilisation en tant que serveur dans un reseau du type internet

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2878685A1 (fr) * 2004-11-30 2006-06-02 Gemplus Sa Declenchement de session pro-active depuis une applet dans une carte a puce
WO2006058817A1 (fr) * 2004-11-30 2006-06-08 Gemplus Declenchement de session pro-active depuis une applet dans une carte a puce
CN101383994B (zh) * 2007-09-07 2016-05-25 锐迪科微电子（上海）有限公司 一种apdu命令的数据处理方法
US12147523B2 (en) 2020-12-29 2024-11-19 Hid Global Gmbh Reader device and method of configuring the same
CN113965228A (zh) * 2021-10-08 2022-01-21 深圳市汇顶科技股份有限公司 扩展nfc卡模拟功能的方法、nfc扩展设备和nfc终端
CN113965228B (zh) * 2021-10-08 2022-08-12 深圳市汇顶科技股份有限公司 扩展nfc卡模拟功能的方法、nfc扩展设备和nfc终端

Also Published As

Publication number Publication date
FR2816785B1 (fr) 2002-12-20
FR2816785A1 (fr) 2002-05-17

Similar Documents

Publication Publication Date Title
EP1044436B1 (fr) Procede de communication entre une station d'utilisateur et un reseau, notamment du type internet, et architecture de mise en oeuvre
EP1208684B1 (fr) Procede de transmission de flux de donnees a haut debit sur un reseau de type internet entre un serveur et un terminal a carte a puce
EP1142256B1 (fr) Terminal securise muni d'un lecteur de carte a puce destine a communiquer avec un serveur via un reseau de type internet
EP1855229B1 (fr) Procédé de routage de données sortantes et entrantes dans un chipset NFC
FR2805107A1 (fr) Procede de gestion de transmissions de donnees multimedias via un reseau de type internet, notamment de donnees telephoniques, et carte a puce pour la mise en oeuvre du procede
FR2805108A1 (fr) Procede d'enregistrement d'un usager sur un serveur d'annuaire d'un reseau de type internet et/ou de localisation d'un usager sur ce reseau, et carte a puce pour la mise en oeuvre du procede
EP1188116A1 (fr) Procede de chargement d'une piece de logiciel dans une carte a puce, notamment du type dit "applet"
FR2901077A1 (fr) Procede de routage de donnees entrantes et sortantes dans un jeu de puces nfc
EP1074007A1 (fr) Systeme embarque possedant des moyens d'interface de reseau, et procede d'activation d'applications localisees dans ce systeme embarque
EP1849320A1 (fr) Procede et dispositif d'acces a une carte sim logee dans un terminal mobile par l'intermediaire d'une passerelle domestique
EP1726124B1 (fr) Systeme et procede de controle d'equipements a distance a l'aide de commandes at, dispositif, module de radiocommunication et programme correspondants
EP1415454B1 (fr) Procede et dispositif de mise en compatibilite de communication sur reseau de terminaux, par exemple pour permettre un dialogue avec une application sur carte a puce
WO2002039369A1 (fr) Protocole de communication entre une carte a puce de type pro-active et son terminal d'accueil
EP1356656A2 (fr) Protocole de transmission d'une pluralite de flux logiques d'echange multiple de couples de commande/reponse sur un canal physique unique
WO2001065480A1 (fr) Procede de commande d'une carte a puce
EP1817890B1 (fr) Procede, systeme et carte a microcontroleur pour la communication de services d'application depuis une carte a microcontroleur vers un terminal
EP1178405B1 (fr) Procédé de sécurisation de l'accès à une application résidante sur une carte utilisateur coopérant avec un terminal d'un système de communication, et terminal correspondant
WO2020254761A1 (fr) Système d'applications de service pour terminaux de paiement
WO2002008897A1 (fr) Protocole d'echange de messages entre applications implantees sur un systeme embarque, et systeme embarque correspondant
Balacheff et al. Smartcards–from security tokens to intelligent adjuncts
WO2002058004A1 (fr) Interconnexion de micromodules de cartes a puce et dispositif electronique portable comprenant une pluralite de micromodules de cartes a puce, connectes en reseau
EP1337980A1 (fr) Carte a puce avec descripteur d'application
WO2001020565A1 (fr) Systeme et methode de chargement de donnees dans une carte a puce a travers un reseau de telecommunication au moyen de mels

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): CN JP US

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP

点击 这是indexloc提供的php浏览器服务，不要输入任何密码和下载