WO2010001046A2 - Procede d'installation d'une application de gestion et procede de gestion de donnees d'applications d'une zone memoire contenue sur un module de securite associe a un terminal mobile, module de securite, terminal mobile et serveur de gestion associes - Google Patents

Procede d'installation d'une application de gestion et procede de gestion de donnees d'applications d'une zone memoire contenue sur un module de securite associe a un terminal mobile, module de securite, terminal mobile et serveur de gestion associes Download PDF

Info

Publication number
WO2010001046A2
WO2010001046A2 PCT/FR2009/051240 FR2009051240W WO2010001046A2 WO 2010001046 A2 WO2010001046 A2 WO 2010001046A2 FR 2009051240 W FR2009051240 W FR 2009051240W WO 2010001046 A2 WO2010001046 A2 WO 2010001046A2
Authority
WO
WIPO (PCT)
Prior art keywords
type
module
management
security module
mobile terminal
Prior art date
Application number
PCT/FR2009/051240
Other languages
English (en)
Other versions
WO2010001046A3 (fr
Inventor
Thierry Morel
Ahmad Saif
Original Assignee
France Telecom
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 France Telecom filed Critical France Telecom
Publication of WO2010001046A2 publication Critical patent/WO2010001046A2/fr
Publication of WO2010001046A3 publication Critical patent/WO2010001046A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/326—Payment applications installed on the mobile devices
    • G06Q20/3263—Payment applications installed on the mobile devices characterised by activation or deactivation of payment capabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357—Cards having a plurality of specified features
    • G06Q20/3572—Multiple accounts on card
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/086—Access security using security domains
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H04W12/35—Protecting application or service provisioning, e.g. securing SIM application provisioning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W8/00—Network data management
    • H04W8/22—Processing or transfer of terminal data, e.g. status or physical capabilities
    • H04W8/24—Transfer of terminal data
    • H04W8/245—Transfer of terminal data from a network towards a terminal

Definitions

  • the present invention relates to the field of telecommunications, and more particularly to the integration and management of services on a secure element of a mobile terminal.
  • Microprocessor cards including ISO 7816 cards, contain a microprocessor for recording and executing programs, called applications, that can be used with a card reader. These programs are, for example, applications for payment, loyalty, transportation ... These cards are either contact and introduced in a card reader, or they are called “contactless” and the dialogue between the reader and the card is then a contactless dialogue using a contactless technology, for example an NFC (for Near Field Contactless) technology.
  • a contactless technology for example an NFC (for Near Field Contactless) technology.
  • This security module can be a memory module of the terminal or a removable medium (for example a subscriber chip card) inserted in the terminal. This configuration prevents the user from holding a large number of cards.
  • this allows easy remote management of these applications, the management server or servers applications that can access the security module, via the mobile terminal and via a telecommunications network.
  • contactless cards that do not contain a microprocessor.
  • Mifare Classic registered trademark
  • the integration of these cards in a mobile terminal requires adaptations.
  • the modified terminal is able to communicate with a reader Mifare type and allows the reading and writing of data in a memory area of the terminal according to Mifare specifications.
  • a JavaCard-specific application installed on a security module of the terminal, allows access to the recorded data. Using this application requires knowing passwords associated with Mifare data.
  • This system has several disadvantages: On the one hand, it requires to manage several passwords in addition to the keys intrinsic to Mifare. Indeed, in this system, a password is assigned to each sector of a Mifare card, which includes at least 16 sectors.
  • the present invention proposes a method for installing an application for managing application data of a first type contained in a first type memory zone of a security module associated with a mobile terminal, the first type memory zone being accessible by an external equipment of the first type according to a protocol of the first type, said security module comprising a management module of secure memory areas adapted to receive applications of a second type accessible by a telecommunication network via management keys and accessible by an external equipment of the second type according to a protocol of the second type, characterized in that the method comprises:
  • access to data of the first type for example Mifare type data
  • stored on a security module is made from a secure management module that already exists and is able to manage applications of the second type, for example in ISO format. Since this management is secured by management keys, it is not necessary to use other security systems, such as passwords, to access the Mifare zone.
  • the creation command is a predetermined command readable and interpretable by the management module.
  • This command further comprises at least one parameter relating to the type of the application data.
  • the command used is the same regardless of the protocol used.
  • the parameters of the command determine whether the application data that will be managed by means of the secure memory area is first type or second type. The parameters thus determine the role of the secure memory area to be created.
  • the installation method can be performed by a state of the art management system. It does not require the introduction of a new management system.
  • the installation step comprises an update of at least one activation indicator associated with the at least part of the first type memory zone.
  • This indicator provides additional security, by controlling, when receiving a request for access to a portion of the memory area, if this portion of the memory area is accessible.
  • the first type memory zone is a Mifare zone comprising one or more sectors and in which the creation control comprises at least one sector identifier.
  • the method of the invention makes it possible to manage the Mifare type cards inserted into a security module of a mobile terminal without requiring the modification of the Mifare system (terminals, protocol, etc.).
  • the present invention also proposes a method for managing the Mifare system.
  • said security module comprising a secure memory area management module capable of receiving applications of a second type accessible by a telecommunications network via management keys and accessible by an external equipment of second type according to a second type protocol characterized in that a management application is installed according to an installation method according to the claim 1, in a secure memory zone associated with at least a portion of the first type memory zone, the management application being able to access application data of the at least part of the first type memory zone and in that the method comprises:
  • the management of the data of applications of the first type can be carried out by means of a management server able to manage applications of the second type and does not require the development of specific platforms.
  • the received access command is encrypted, and the method further comprises a step of decrypting said access command.
  • Encryption helps to ensure security of access.
  • the access control is consecutive to access to a part of the first type memory zone, by an external equipment of the first type, according to the protocol of the first type and the message sent is a message display control relating to said access on a screen of the terminal.
  • This characteristic makes it possible to inform the user in real time of the transactions made.
  • the invention also relates to a security module associated with a mobile terminal comprising a module for managing secure memory areas capable of receiving applications of a second type accessible by a telecommunications network via management keys and accessible by a user.
  • external equipment of second type according to a second type of protocol and a first type memory zone containing first type of application data and accessible by an external equipment of the first type according to a protocol of the first type, characterized in that comprises: means for receiving, via the telecommunication network, a command for creating a secure memory zone comprising at least one identifier of at least part of the first type memory zone,
  • the security module further comprises means for receiving, from a communication module of the mobile terminal, an access command to application data of the at least part of the first type memory zone.
  • the invention also relates to a communication terminal comprising a contactless communication module able to communicate with an external equipment of the first type according to a protocol of the first type, a communication module able to communicate with a telecommunication network, and a communication module. security module as previously described
  • the contactless communication module is furthermore able to communicate with external equipment of the second type according to a protocol of the second type, for example an ISO protocol.
  • the invention also relates to a management server able to access, via a telecommunications network and via management keys, data of applications of a second type contained in secure memory areas managed by a management module.
  • a security module associated with a mobile terminal characterized in that it comprises means for transmitting a command for creating a secure memory area comprising at least one identifier of at least part of a memory area of first type of security module in which are stored application data of a first type, accessible by a first type of external equipment according to a protocol of the first type.
  • the management server is an existing server adapted to be able to transmit modified creation commands.
  • an existing management server can be adapted to be able to access and manage application data of the first type.
  • the invention also relates to a signal conveying a creation message for the installation of an application data management application of a first type contained in a first type memory zone of a security module associated with a mobile terminal, the first type memory zone being accessible by an external equipment of the first type according to a protocol of the first type, characterized in that the message comprises at least one parameter relating to the type of the application data and at least one identifier at least a part of the memory zone of the first type, said message being intended to be sent to the security module comprising a module for managing secure memory areas able to receive applications of a second type accessible by a telecommunications network via management keys and accessible by a second type of external equipment according to a second type protocol.
  • the invention finally relates to a computer program product comprising instructions for implementing the steps of the installation method as described above and / or the management method as described above when it is loaded and executed by a processor.
  • FIG. 1 is a diagram illustrating a system according to a embodiment of the invention
  • FIG. 2 is a flowchart illustrating the various steps of an installation method according to the invention
  • FIG. 3 is a flowchart illustrating the various steps of a management method following the execution of an installation method according to the invention
  • FIG. 4 is a block diagram illustrating a security module according to a method of Embodiment of the invention
  • FIG. 5 is a flowchart illustrating a particular embodiment of the installation method
  • FIG. 6 is a block diagram illustrating a correspondence table used in a management method according to an embodiment of the invention.
  • FIG. 1 is a diagram illustrating a system according to a embodiment of the invention
  • FIG. 2 is a flowchart illustrating the various steps of an installation method according to the invention
  • FIG. 3 is a flowchart illustrating the various steps of a management method following the execution of an installation method according to the invention
  • FIG. 4 is a block diagram illustrating a security module according to a
  • FIG. 7 is a flowchart illustrating a first particular embodiment of a management method according to the invention
  • FIG. 8 is a flowchart illustrating a second embodiment of a management method according to the invention.
  • FIG. 9 is a block diagram representing a management server able to carry out the steps of an installation method according to one embodiment of the invention
  • a user has a mobile terminal 100 which is, for example a mobile phone or a PDA (for "Personal Digital Assistant").
  • This mobile terminal has a communication module 130, for example a GSM module, enabling communication, via a communication network R, with remote servers, for example with management servers (SP, SPO).
  • This communication is for example an "OTA" communication (for "Over The Air”), that is to say a conventional wireless communication.
  • the mobile terminal is connected to the network R by a wired telephone line.
  • the mobile terminal 100 also comprises a security module 120.
  • the security module 120 is for example a removable support type SIM or UICC (for "Universal Integrated Circuit Card”), a secure memory area of the mobile terminal or a memory card hosting a secure element (SD card, Embedded Secure control. ..)) •
  • the mobile terminal 100 also conventionally comprises an interface module (not shown) capable of transmitting and receiving data to and from the security module 120.
  • the mobile terminal 100 also comprises a contactless communication module 140 enabling the exchange of messages according to a first type of dialogue protocol between a BM terminal of the first type, for example a terminal of the type
  • the BM terminal is an outdoor equipment of the first type.
  • this module 140 also allows the dialogue between a terminal B of the second type and the security module 120 of the mobile terminal according to the ISO protocol which is a second type of dialogue protocol.
  • Terminal B is an external equipment of the second type.
  • the security module 120 may comprise one or more secure memory areas (SD2) containing applications corresponding to applications (AP2) of a second type. These applications are accessible by terminal B using the ISO protocol, which corresponds to a second type of dialogue protocol. They are also accessible via the network R, by a management server (SP) having keys associated with the secure memory area that hosts them.
  • SD2 secure memory areas
  • AP2 applications
  • SP management server
  • the security module 120 includes an ISD management module of secure memory areas. This management module is able to manage the installation of the secure memory areas of the security module 120.
  • the security module 120 also comprises a storage module ZM comprising a memory area MMF, which is a first type memory area, in which application data of a first type are stored.
  • a storage module ZM is able to communicate with the terminal BM, according to a protocol of dialogue of the first type.
  • the BM terminal of the first type periodically sends messages to mobile terminals.
  • the contactless module 140 receives this message and transmits it to the security module 120 which transmits it to the storage module ZM for processing.
  • Zone Z is a part of the MMF zone.
  • zone Z corresponds to the MMF zone.
  • the ISD management module of the security module proceeds to the creation of a secure memory area SD1 associated with the zone Z, during a step E2.
  • a secure memory area such as SD1
  • SD1 is a protected memory zone read and write by keys shared with a remote server such as for example the server SP.
  • Step E2 is followed by a step E3 during which the security module 120 installs a management application PGC in the secure memory area SD1.
  • This PGC application is able to access the data contained in the zone Z.
  • the creation of the secure memory zone SD1 allowing the management of the data of the zone Z which is a memory zone of the first type is carried out by an existing module of the security module capable of creating secure memory areas for managing data of second type applications.
  • This management method is implemented following the installation of a management application according to for example an installation method as described above.
  • the security module 120 receives an access command
  • This access command is, for example, a write command of one or more data of zone Z.
  • the access control is a read command.
  • this command is transmitted to the security module by the remote server SP via the communication module 130 of the mobile terminal.
  • This command then contains an identifier of zone Z. This embodiment is described in the following description with reference to FIG. 7.
  • the command is triggered by the reception of an event, for example the reception of an end of transaction event transmitted by the contactless communication module 140 of the mobile terminal to the security module. This embodiment is described in the following description with reference to FIG. 8.
  • the security module 120 constructs an access request REQ from the received CA command and transmits this request REQ to the storage module ZM, during a step E20.
  • This access request is for example a write or read order of data in zone Z.
  • the security module 120 receives in return a response REP, during a step E30.
  • the response to a write command is for example an acknowledgment message.
  • the response to a read command contains for example all or part of the data of the zone Z.
  • Step E30 is followed by a step E40 during which the security module 120 transmits, via a transmitting / receiving module, to the mobile terminal 100, for example to its interface module, an MSG message containing the transmitted response. by the storage module ZM during step 30.
  • the MMF module is a module comprising data of the Mifare Classic (registered trademark) type
  • the security module 120 is a removable memory card compatible with the specifications of GlobalPlatform (GlobalPlatform Card Specification - version 2.2 March 2006).
  • the security module 120 comprises in particular a microprocessor 122, a transmission-reception module 124, one or more RAM type memories 125 and one or more memories 126 of the type ROM or EEPROM in which programs that can be executed by the microprocessor 122 are recorded.
  • the memory 126 contains in particular a program P which is the main program of the card.
  • This program P is also called “OS” (for "operating system”).
  • the security module 120 also includes an ISD management module of secure memory areas.
  • the ISD management module is a security domain conforming to the Global Platform specifications.
  • a security domain is a secure memory area protected from read and write by shared keys with a management server.
  • a shared key is either the same known key of two entities, or a pair of associated keys.
  • An example of associated keys is a pair of keys, one of which is secret and known only to one entity and the other public to the other entity.
  • the ISD management module has keys shared with an SPO management server of the security module, for example the server of a telephone operator.
  • the security module 120 may comprise one or more secure memory areas (not shown) containing applications corresponding to applications of a second type and operating using the ISO protocol, which corresponds to a second type of dialogue protocol.
  • the security module 120 also comprises a storage module ZM containing a data area MMF, an access module MAF to this data area MMF and two interface modules II and 12.
  • the MMF data area has one or more zones called "Mifare Classic cards".
  • the size of a card is either 1 kbyte (this is an Ik card) or 4 kbyte (4k card).
  • a Mifare Classic card comprises, in a conventional manner, a structure in sectors and blocks.
  • a Mifare Ik card has 16 sectors of 4 blocks each.
  • a 4k card has 32 sectors of 4 blocks and 8 sectors of 16 blocks.
  • Block 0 is a block containing the manufacturer's information.
  • Blocks 1 and 2 contain application data.
  • Block 4 contains keys and is not accessible. Each sector is associated with a key pair KeyA, KeyB.
  • the MMF data area contains 4 distinct Mifare cards: 1 Mifare 4k (Cl) card and 3 Mifare Ik cards (C2, C3, C4).
  • the MMF area may have a different number of Mifare cards and a different distribution between Ik cards and 4k cards.
  • Each block has 16 bytes.
  • the data stored in a block is read and write protected by the keys of the sector of which they are part.
  • the data in the MMF area is therefore identified by a map number, a sector number and a block number. Addressing in the MMF zone is unknown to the other modules of the security module and in particular to the main program P of the security module.
  • the terminal of the first type BM does not have means for selecting or activating a card. Activation of a card is performed by the security module following a request from the user. The number of the activated card is saved in a CMF memory of the security module.
  • the MAF module also has this information, either by accessing this memory CMF, or by recording this information in an area internal to this module.
  • a card is activated by default, for example, the card allowing access to a means of transport.
  • the user can then, using a menu of the mobile terminal select another card, for example to perform a payment transaction.
  • this operation may be transparent to the operator.
  • the user selects a payment application and this selection operation will trigger the sending of the request to select another Mifare card to the security module.
  • the first type terminal BM periodically sends messages to the mobile terminals.
  • the contactless module 140 receives this message and transmits it to the main program P of the security module, via the transmission / reception module 124.
  • the main program P determines that it is a message type Mifare.
  • the message received is a read or write message in a sector of a Mifare type card. It contains an address (sector number and block number) as well as data coded with the sector keys.
  • the algorithm used for coding is a secret, proprietary and confidential algorithm of Mifare.
  • the program P stores the sector address (sector number and block number) contained in the message in a memory DER memory 126, then transmits the received message to the MAF access module via the interface II.
  • the access module MAF accesses the MMF zone to decrypt this message by using the keys associated with the sector and perform the requested read or write operation. It then retransmits a response to the terminal of the first type BM, via the interface II.
  • the access module MAF does not have information on the activated card number, it transmits the information to the addressed sector of all the cards and only the card that can decrypt the message answers.
  • the MMF data area is not directly accessible by the main program P of the security module 120.
  • the interface 12 allows access, internal security module, data area MMF.
  • the MMF module is a module comprising data of the Mifare (registered trademark) type.
  • This method comprises steps E1, E2 and E3 corresponding to steps E1, E2 and E3 described above.
  • the server SPO which is for example the server of the operator managing the security module, transmits to the security module, via the communication module 130 and the interface module of the mobile terminal, a CREAT creation command of a security domain SD1 associated with sectors 5 and 10 of the map C2 of the MMF zone.
  • the security domain SD1 constitutes a secure memory area.
  • the SPO server is also able to transmit to the security module security domain creation commands able to manage data of second type applications.
  • a single server is used for the creation of security domains able to manage data of applications of the first type and for the creation of security domains able to manage data of applications of the second type.
  • This CREAT creation command is received by the transmission / reception module 124 of the security module 120 during the step E1. In a conventional manner, this command is transmitted encrypted with keys shared between the SPO server and the management module. ISD of the security module 120, then decrypted by the security module.
  • This command or creation message comprises at least one parameter relating to the type of the application data and at least one identifier of a portion of the memory zone of the first type.
  • This create command is an "Install for Install” command defined in the Global Platform V2.2 specification in which the "Privileges" parameter indicates that the SDL security domain is paired with a memory zone of type
  • the security domain SD1 is able to allow the management of one or more sectors of the MMF area.
  • the data relating to the identification of the memory zone, that is to say the number or numbers of the cards and sectors, are transmitted in the field "Install Parameters Field" of the command "Install for
  • the Global Platform specifications define a "Privilege" field, for the "Install for install” command, consisting of 3 bytes, of which 7 bits are reserved for future use. In the embodiment described here, one of these 7 bits is used to indicate the type of the security domain. This bit is set to 1 to indicate that the security domain to be created is of type "Mifare”. It is set to 0 otherwise.
  • the creation step E2 will now be described in more detail.
  • the main program P verifies, in a correspondence table T, that the sector identifiers contained in the creation command received do not correspond to sectors managed by another security domain of the module. security.
  • the correspondence table T stored in a memory 126 of the security module includes, for each sector S of each card C of the memory area MMF, a CID field containing an identifier AID of a security domain. This CID field is empty when no security domain is associated with it.
  • the CDD field has a predetermined value, for example "0", when no security domain is associated.
  • the verification carried out during the substep E102 consists in verifying that the field CDD corresponding to the sectors contained in the creation CREAT command is empty.
  • the sector is managed by another security domain and the main program P sends back to the server SPO a message indicating its refusal to create this security domain.
  • the security module does not respond to the creation command. The process stops.
  • This check avoids pairing a sector with multiple security domains and increases security.
  • the main program P reserves a memory area in the memory 126 (in step E104). It then records in the correspondence table T, an identifier ADD1 of this security domain SD1 in association with the associated card and sector number (in step E106).
  • steps E102 to E106 are executed for each sector.
  • the identifier ADD1 is stored on the one hand in association with the card C2 and the sector 5 and, on the other hand, in association with the card C2 and the card. sector 10.
  • the main program P then transmits to the server SPO, during a substep E108, an acknowledgment message ACQ.
  • the server SPO transmits to the security module 220 the keys K associated with the zone SD1, for example using a "PutKey” or "Installffor" command.
  • Customization] / StoreData "defined in the GlobalPlatform specifications. These keys are also known from an SP server, able to manage the SDL security domain.
  • the security module stores these keys in the security domain SD1, during a substep El 12.
  • the security module then positions the security domain in the "activated" position (in step El 14). This transition to the "enabled” state corresponds to the transition to the "Personalized” state described in the Global PlatForm specifications part “Card Specifications"
  • the transition to the "enabled" state of the security domain SD1 allows the server SP, which shares these keys with the security domain SD1, to access the security domain SD1.
  • the security module and more particularly the ISD management module, is thus able to manage security domains able to receive applications of the first type and able to receive applications of the second type.
  • the server SP controls the installation of a management application PGC in the security domain SD1. More precisely, during a first sub-step E302, the server SP controls the downloading of a management application PGC in the security domain SD1.
  • This PGC application is able to access the data contained in the part of the MMF zone designated in the creation control of the security domain SD1, that is to say sectors 5 and 10 of the card C2.
  • the download of the PGC application is done in a conventional manner and will not be described here. This operation is described in particular in the Global Platform V2.2 standard.
  • the PCG program has been downloaded into the security module in a previous step and the download step is to transfer this program to the area SD1.
  • the substep E302 download is followed by a substep E304 activation program PCG.
  • This step consists in updating a register allowing the main program of the security module to know that the program is activated.
  • the register used is the GPRegistry register defined in the Global Platform specifications.
  • the substep E304 is followed by an activation substep E305 of the sectors associated with the security domain SD1. For this, a field is added to the GPRegistry register. This field contains as many bits as sectors contained in the MMF area.
  • the validation sub-step E3O5 consists in setting, for example at the value 1, the bit corresponding to each sector associated with the security domain SD1. Such a bit constitutes an activation indicator.
  • the management server SP is able to install an application of a first type in a security domain of the first type.
  • the management server SP is also able to install second-type applications in security domains of the second type.
  • Existing management servers can be used. It is therefore not necessary to develop specific servers for the management of data of applications of the first type.
  • Steps E1, E2 and E3 are performed by the microprocessor 122 of the security module 120.
  • a management server SP accesses data of the memory module MMF which is a module comprising data of the Mifare (registered trademark) type, will now be described.
  • a step E400 the server SP establishes a secure channel with the security domain SD1 of the security module 120.
  • the establishment of such a channel is described in the Global Platform specifications.
  • the access control is a read command.
  • the CA access control is transmitted encrypted with the keys of the security domain SD1.
  • the use of a key system allows for secure management and avoids the use of other security systems such as passwords to access data in the MMF memory area.
  • This access command is received by the security module 120 during a step E410. More precisely, it is received by the transmission / reception module 124 which transmits it to the PGC program of the domain SD1.
  • the program PGC verifies, during a step E412, in the correspondence table T that it is authorized to access the sector S of the card C. For this, it checks that the AID stored in the correspondence table T in correspondence with the sector S of the card C is the identifier of the security domain SDl.
  • the security module does not respond or transmits an error message.
  • This verification step increases the security of the system by ensuring that the SP server does not attempt to access sectors for which it is not authorized.
  • the program PGC builds a write order of the requested sector and transmits it to the interface 12 of the storage module ZM, during a step E414.
  • the write command is intercepted by the main program P of the security module which checks, in the correspondence table T, that the program PGC is authorized to access the sector S of the card C. For this, it verifies that the AID stored in the correspondence table T in correspondence with the sector S of the map X is the identifier of the security domain SDl.
  • the security module does not respond or transmits an error message. This verification step increases the security of the system by ensuring that the PGC program does not attempt to access sectors for which it is not authorized.
  • the interface 12 receives the command transmitted during the substep E414 and transmits the request to the access module MAF which accesses the sector S of the card C, enters the new value in this sector and sends an acknowledgment to the program PGC via the interface 12 (step E416).
  • This acknowledgment is, for example, one or more bytes, the value of which indicates whether the write has taken place correctly or not.
  • the program PGC transmits a message containing the acknowledgment to the management server SP, via the transmission / reception module 124, an interface module of the mobile terminal and the communication module 130. mobile terminal.
  • the data management of at least a portion of the memory area MMF can be performed by a management server able to also manage data of applications of the second type; the management of these data of applications of the first type does not therefore require the development of specific platforms.
  • the MMF module is a module comprising Mifare type data (registered trademark).
  • a transaction takes place between the terminal BM and the storage module ZM of the security module 220.
  • the terminal BM is installed in a city bus and the block 2 of the sector 5 of the ZM module card 2 includes a value corresponding to a number of transport tickets purchased by the owner of the mobile terminal.
  • the transaction between the BM terminal and the module security allows the decrementation of 1 of the value stored in the block 2 sector 5 of the card 2.
  • the main program P of the security module checks, upon receipt of a message of the terminal of the first type BM, if this sector is in activated mode (step E501) and refuses any dialogue with the terminal BM if this sector is not activated in the register GPRegistry.
  • the Mifare sectors are visible and / or addressable by an external contactless reader only when a security domain has been created for the management of these sectors and this security domain is in "activated" mode. .
  • Any Mifare sector that is not attached to an activated security domain is not visible and is therefore unusable.
  • the contactless module 140 of the mobile terminal 100 sends the main program P of the security module 120 an end of transaction indication, during a step E502.
  • the main program reads from the memory module CMF the value corresponding to the activated card and the DER memory of the security module the value corresponding to the sector that has just been accessed (step E504).
  • step E506 it looks in the correspondence table T for the identifier AID of the associated security domain.
  • the main program P then wakes up the PGC program of the security domain SD1, for example by sending it an end-of-transaction event (step E510).
  • the program PGC of the security domain SDl reads in the memory CMF the card number, and in the memory DER the sector and block number for which a transaction has just taken place (step E5O8 )
  • a read command of one or more blocks of this sector is an access request to the storage module ZM.
  • the interface 12 receives this command and transmits the request to the access module MAF which accesses the sector 5 of the card 2 and returns, during a step E514, via the interface 12 to the program PGC a message containing the contents of the sector read.
  • the program PGC constructs an MR message containing this content.
  • This message is, for example, consisting of a predetermined text and the contents of the read block; for example, the message is "Bus - City of ... - You have ... tickets left".
  • the constructed message is then transmitted by the transmission / reception module 124, during a step E518, to the mobile terminal, via the interface module. Then, the mobile terminal displays the message on its screen.
  • the program PGC makes it possible to communicate to the user information following a transaction performed between a Mifare type terminal and a mobile terminal containing a Mifare type data area.
  • CMF are stored in a memory 126 of the security module. As an alternative, all or some of these values are stored in the ZM storage area. They are then accessible via the interface 12 via a specific application command.
  • Mifare Classic type data is installed in an environment in which it is managed in a secure manner without requiring the knowledge of passwords.
  • a management server implementing an installation method according to the invention is, for example, a microcomputer 500 which comprises, in a known manner, notably a processing unit 502 equipped with a microprocessor, a read-only ROM or EEPROM type 503, a RAM RAM 504 and a communication interface 505 with a communication network R.
  • the microcomputer 500 may comprise in a conventional and non-exhaustive manner the following elements: a keyboard, a screen, a microphone, a speaker, a disk drive, a storage medium ...
  • This server 500 comprises a module ME1 for transmitting data to the network R and a processing module MT1.
  • the processing module MT1 is able to prepare a message containing a command for creating at least one secure memory zone associated with at least a part of a first memory zone, containing application data of a first type, said first zone being accessible by outdoor equipment of the first type according to a protocol of the first type.
  • the transmission module ME1 is able to transmit the prepared message.
  • the MTl module is also able to prepare a download command for a first-class application data management application.
  • the module ME1 is able to transmit the prepared command.
  • the read-only memory 503 comprises registers storing a computer program PG1 comprising program instructions adapted to transmit, via the telecommunications network R, a command for creating a secure memory area (SD1) associated with at least a portion of the network. a memory zone of the first type.
  • SD1 secure memory area
  • the program PG1 stored in the read-only memory 503 is transferred into the random access memory which will then contain executable code and registers for storing the variables necessary for the implementation of a transmission step, via the telecommunication network R, a command for creating a secure memory area (SD1) associated with at least a portion of a first type memory zone.
  • SD1 secure memory area
  • a means of storage readable by a computer or by a microprocessor, integrated or not into the device, possibly removable, stores a program implementing a transmission step, via the network.
  • telecommunication R a command for creating a secure memory area (SDl) associated with at least a portion of a memory zone of the first type, according to the invention.
  • SDl secure memory area
  • a management server implementing a management method according to the invention is for example a computer of the PC 600 type which comprises, in a known manner, notably a processing unit 602 equipped with a microprocessor, a read-only memory ROM 603, RAM RAM type 604.
  • the terminal 600 may include in a conventional and non-exhaustive manner the following elements: a keyboard, a screen, a microphone, a speaker, a communication interface, a disk drive, a storage medium ...
  • This server comprises a module ME2 for sending data to a communication network R, a module MR2 for receiving data from the communication network R and a module MT2 for processing.
  • the processing module MT2 is able to prepare a message containing an access command to application data of at least a part of a first memory zone, containing application data of a first type, said first zone being accessible by external equipment of the first type, according to a protocol of the first type.
  • the transmission module ME2 is able to transmit the prepared message.
  • the reception module MR2 is able to receive a message containing a response to said access command.
  • the ROM 603 includes registers storing a computer program PG2 having program instructions adapted to transmit a message containing an access command to at least a portion of the first type memory area and to receive a response to said command. access.
  • the program PG2 stored in the read-only memory 603 is transferred into the random access memory which will then contain the executable code of the invention as well as registers for storing the variables necessary for the performing a step of transmitting a message containing an access command to at least a portion of a first type zone and a step of receiving a response to said access command
  • a means of storage readable by a computer or by a microprocessor, integrated or not into the device, possibly removable, stores a program implementing the steps of transmitting a message containing an access command to at least a part of an area of first type and receiving a response to said access command.

Abstract

L'invention se rapporte à un procédé d'installation d'une application de gestion de données d'applications d'un premier type contenues dans un module de sécurité associé à un terminal mobile, ledit module de sécurité comprenant un module de gestion (ISD) de zones mémoires sécurisées (SD2) aptes à recevoir des applications (AP2) d'un second type accessibles par un réseau de télécommunication (R) via des clés de gestion et par un équipement (B) de second type selon un protocole de second type. Selon l'invention, les données d'applications de premier type sont stockées dans une zone mémoire (MMF) de premier type accessible par un équipement (BM) de premier type selon un protocole de premier type, et le procédé comprend la création d'une zone mémoire sécurisée (SDl) associée à une partie de la zone mémoire de premier type, et l'installation dans la zone créée, d'une application de gestion (PGC) apte à accéder à des données de la partie de la zone mémoire de premier type. L'invention se rapporte également à un module de sécurité (120) et à un terminal mobile (100) comprenant ce module de sécurité.

Description

Procédé d'installation d'une application de gestion et procédé de gestion de données d'applications d'une zone mémoire contenue sur un module de sécurité associé à un terminal mobile, module de sécurité, terminal mobile et serveur de gestion associés
La présente invention se rapporte au domaine des télécommunications, et plus particulièrement à celui de l'intégration et de la gestion de services sur un élément sécurisé d'un terminal mobile.
Les cartes à microprocesseur, notamment les cartes au format ISO 7816 contiennent un microprocesseur permettant l'enregistrement et l'exécution des programmes, appelés applications, aptes à être utilisés avec un lecteur de cartes. Ces programmes sont par exemple, des applications de paiement, de fidélité, de transport... Ces cartes sont soit à contact et introduites dans un lecteur de carte, soit elles sont dites "sans contact" et le dialogue entre le lecteur et la carte est alors un dialogue sans contact utilisant une technologie sans contact, par exemple une technologie NFC (pour "Near Field Contactless").
De plus en plus, ces applications sont téléchargées dans les modules de sécurité des terminaux mobiles. Le dialogue entre le lecteur et l'application est alors effectué via le terminal mobile. Ce module de sécurité peut être un module mémoire du terminal ou un support amovible (par exemple une carte à puce d'abonné) inséré dans le terminal. Cette configuration évite à l'utilisateur de détenir un grand nombre de cartes.
De plus, ceci permet une gestion aisée à distance de ces applications, le ou les serveurs gestionnaires des applications pouvant accéder, au module de sécurité, via le terminal mobile et via un réseau de télécommunication.
Les dialogues entre ces applications existantes et les équipements extérieurs (appelés "bornes" ou lecteurs) sont conformes aux spécifications ISO 7816.
Par ailleurs, il existe des cartes sans contact qui ne contiennent pas de microprocesseur. Parmi celles-ci, les cartes sans contact les plus répandues actuellement dans le monde du transport sont des cartes basées sur une technologie Mifare Classic (marque déposée). Le dialogue entre une telle carte basée sur une technologie Mifare Classic et un équipement extérieur, par exemple une borne située à l'entrée d'un moyen de transport, est non compatible avec les standards ISO. Aussi, l'intégration de ces cartes dans un terminal mobile nécessite des adaptations. Certains constructeurs ont essayé d'intégrer une ou plusieurs cartes de type
Mifare dans un téléphone portable. Le terminal modifié est apte à dialoguer avec un lecteur de type Mifare et permet la lecture et l'écriture de données dans une zone mémoire du terminal suivant les spécifications Mifare. De plus, une application spécifique de type JavaCard, installée sur un module de sécurité du terminal, permet l'accès aux données enregistrées. L'utilisation de cette application nécessite de connaître des mots de passe associés aux données Mifare.
La demande de brevet US 2008/0073426 Al publiée le 27 mars 2008 décrit un tel système.
Ce système présente plusieurs inconvénients : D'une part, il nécessite de gérer plusieurs mots de passe en plus des clés intrinsèques à Mifare. En effet, dans ce système, un mot de passe est attribué à chaque secteur d'une carte Mifare, celle-ci comportant au minimum 16 secteurs.
Ce système introduit une vulnérabilité supplémentaire car la seule connaissance d'un mot de passe permet d'atteindre la zone ou secteur correspondant. D'autre part, la gestion de ces applications Java installées sur des téléphones portables n'est pas compatible avec la gestion des applications de type ISO. La gestion de l'installation, de la personnalisation, de l'activation, du blocage, de la suppression des programmes Java associées aux cartes Mifare nécessite le développement de plates-formes spécifiques, les plates-formes existantes pour la gestion des applications au format ISO n'étant pas compatibles.
Il existe donc un besoin d'intégrer ces cartes Mifare dans un environnement dans lequel elles puissent être gérées de façon sécuritaire sans nécessiter la connaissance de mots de passe spécifiques à ces cartes.
A cet effet la présente invention propose un procédé d'installation d'une application de gestion de données d'applications d'un premier type contenues dans une zone mémoire de premier type d'un module de sécurité associé à un terminal mobile, la zone mémoire de premier type étant accessible par un équipement extérieur de premier type selon un protocole de premier type, ledit module de sécurité comprenant un module de gestion de zones mémoires sécurisées aptes à recevoir des applications d'un second type accessibles par un réseau de télécommunication via des clés de gestion et accessible par un équipement extérieur de second type selon un protocole de second type caractérisé en ce que le procédé comporte :
- une étape de réception, par le réseau de télécommunication, d'une commande de création d'une zone mémoire sécurisée comportant au moins un identifiant d'au moins une partie de la zone mémoire de premier type,
- une étape de création de la zone sécurisée par le module de gestion,
- une étape d'installation dans la zone mémoire sécurisée d'une application de gestion apte à accéder à des données d'applications de la au moins une partie de la zone mémoire de premier type. Ainsi, selon l'invention, l'accès à des données de premier type, par exemple des données de type Mifare, stockées sur un module de sécurité est effectué à partir d'un module de gestion sécurisé qui existe déjà et qui est apte à gérer des applications de second type, par exemple au format ISO. Comme cette gestion est sécurisée par le biais des clés de gestion, il n'est pas nécessaire d'utiliser d'autres systèmes de sécurité, comme des mots de passe, pour accéder à la zone Mifare.
Selon un mode de réalisation particulier, la commande de création est une commande prédéterminée lisible et interprétable par le module de gestion. Cette commande comporte en outre au moins un paramètre relatif au type des données d'applications. Ainsi, la commande utilisée est la même quel que soit le protocole utilisé. Les paramètres de la commande permettent de déterminer si les données d'applications qui seront gérées au moyen de la zone mémoire sécurisée sont de premier type ou de second type. Les paramètres déterminent ainsi le rôle de la zone mémoire sécurisée à créer. Ainsi, le procédé d'installation peut être effectué par un système de gestion de l'état de l'art. Il ne nécessite pas la mise en place d'un nouveau système de gestion.
Selon une caractéristique particulière, l'étape d'installation comprend une mise à jour d'au moins un indicateur d'activation associé à la au moins une partie de la zone mémoire de premier type.
Cet indicateur apporte une sécurité supplémentaire, en permettant de contrôler, lors de la réception d'une demande d'accès à une partie de la zone mémoire, si cette partie de zone mémoire est accessible.
Selon un mode de réalisation particulier, la zone mémoire de premier type est une zone de type Mifare comprenant un ou plusieurs secteurs et dans lequel la commande de création comprend au moins un identifiant de secteur.
Le procédé de l'invention permet de gérer les cartes de type Mifare insérées dans un module de sécurité d'un terminal mobile sans nécessiter la modification du système Mifare (bornes, protocole...) La présente invention propose également un procédé de gestion de données d'applications d'un premier type contenues dans une zone mémoire de premier type d'un module de sécurité associé à un terminal mobile, la zone mémoire de premier type étant accessible par un équipement extérieur de premier type selon un protocole de premier type, ledit module de sécurité comprenant un module de gestion de zones mémoires sécurisées aptes à recevoir des applications d'un second type accessibles par un réseau de télécommunication via des clés de gestion et accessibles par un équipement extérieur de second type selon un protocole de second type, caractérisé en ce qu'une application de gestion est installée, selon un procédé d'installation conforme à la revendication 1, dans une zone mémoire sécurisée associée à au moins une partie de la zone mémoire de premier type, l'application de gestion étant apte à accéder à des données d'applications de la au moins une partie de la zone mémoire de premier type et en ce que le procédé comporte :
- une étape de réception, par un module d'émission/réception du module de sécurité, en provenance d'un module de communication du terminal mobile, d'une commande d'accès à des données d'applications de la au moins une partie de la zone mémoire de premier type,
- une étape de transmission, à un module de stockage du module de sécurité, d'une requête d'accès à des données d'applications de la au moins une partie de la zone mémoire de premier type,
- une étape de réception, en provenance du module de stockage, d'une réponse relative aux données d'applications,
- une étape d'envoi, par le module d'émission/réception, d'un message contenant ladite réponse. Ainsi, la gestion des données d'applications de premier type peut être effectuée au moyen d'un serveur de gestion apte à gérer des applications de second type et ne nécessite pas le développement de plates-formes spécifiques.
Selon un mode de réalisation particulier, la commande d'accès reçue est chiffrée, et le procédé comporte en outre une étape de déchiffrement de ladite commande d'accès.
Le chiffrement permet d'assurer la sécurité de l'accès.
Selon une caractéristique de l'invention, la commande d'accès est consécutive à un accès à une partie de la zone mémoire de premier type, par un équipement extérieur de premier type, selon le protocole de premier type et le message envoyé est un message de commande d'affichage relatif audit accès sur un écran du terminal.
Cette caractéristique permet d'informer l'utilisateur en temps réel des transactions effectuées.
L'invention se rapporte également à un module de sécurité associé à un terminal mobile comprenant un module de gestion de zones mémoires sécurisées aptes à recevoir des applications d'un second type accessibles par un réseau de télécommunication via des clés de gestion et accessibles par un équipement extérieur de second type selon un protocole de second type, et une zone mémoire de premier type contenant des données d'applications de premier type et accessible par un équipement extérieur de premier type selon un protocole de premier type, caractérisé en ce qu'il comprend: - des moyens de réception, via le réseau de télécommunication, d'une commande de création d'une zone mémoire sécurisée comportant au moins un identifiant d'au moins une partie de la zone mémoire de premier type,
- des moyens de création de la zone mémoire sécurisée, - des moyens d'installation dans la zone mémoire sécurisée d'une application de gestion apte à accéder à des données d'applications de la au moins une partie de la zone mémoire de premier type.
Le module de sécurité comporte en outre des moyens de réception, en provenance d'un module de communication du terminal mobile, d'une commande d'accès à des données d'applications de la au moins une partie de la zone mémoire de premier type, des moyens de transmission, à un module de stockage, d'une requête d'accès auxdites données d'applications de la au moins une partie de la zone mémoire de premier type, des moyens de réception, en provenance du module de stockage, d'une réponse relative aux données d'applications et des moyens d'émission d'un message contenant ladite réponse.
L'invention se rapporte aussi à un terminal de communication comportant un module de communication sans contact apte à communiquer avec un équipement extérieur de premier type selon un protocole de premier type, un module de communication apte à communiquer avec un réseau de télécommunication, et un module de sécurité tel que décrit précédemment
Selon un mode de réalisation, le module de communication sans contact est en outre apte à communiquer avec un équipement extérieur de second type selon un protocole de second type, par exemple un protocole ISO.
L'invention concerne aussi un serveur de gestion apte à accéder, via un réseau de télécommunication et via des clés de gestion, à des données d'applications d'un second type contenues dans des zones mémoires sécurisées gérées par un module de gestion d'un module de sécurité associé à un terminal mobile caractérisé en ce qu'il comporte des moyens d'émission d'une commande de création d'une zone mémoire sécurisée comportant au moins un identifiant d'au moins une partie d'une zone mémoire de premier type du module de sécurité dans laquelle sont stockées des données d'applications d'un premier type, accessibles par un équipement extérieur de premier type selon un protocole de premier type.
Le serveur de gestion est un serveur existant adapté pour être apte à transmettre des commandes de création modifiées. Ainsi, un serveur de gestion existant peut être adapté pour être apte à accéder et gérer des données d'application de premier type.
L'invention se rapporte encore à un signal transportant un message de création pour l'installation d'une application de gestion de données d'applications d'un premier type contenues dans une zone mémoire de premier type d'un module de sécurité associé à un terminal mobile, la zone mémoire de premier type étant accessible par un équipement extérieur de premier type selon un protocole de premier type, caractérisé en ce que le message comporte au moins un paramètre relatif au type des données d'applications et au moins un identifiant d'au moins une partie de la zone mémoire de premier type, ledit message étant destiné à être envoyé au module de sécurité comprenant un module de gestion de zones mémoires sécurisées aptes à recevoir des applications d'un second type accessibles par un réseau de télécommunication via des clés de gestion et accessibles par un équipement extérieur de second type selon un protocole de second type.
L'invention se rapporte enfin à un produit programme d'ordinateur comprenant des instructions pour mettre en œuvre les étapes du procédé d'installation telles que décrites précédemment et/ou du procédé de gestion telles que décrites précédemment lorsqu'il est chargé et exécuté par un processeur.
D'autres particularités et avantages de la présente invention apparaitront dans la description suivante de modes de réalisation donnés à titre d'exemple non limitatif, en référence aux dessins annexés, dans lesquels : la figure 1 est un schéma illustrant un système selon un mode de réalisation de l'invention, la figure 2 est un organigramme illustrant les différentes étapes d'un procédé d'installation selon l'invention, la figure 3 est un organigramme illustrant les différentes étapes d'un procédé de gestion suite à l'exécution d'un procédé d'installation selon l'invention, la figure 4 est un schéma-bloc illustrant un module de sécurité selon un mode de réalisation de l'invention, - la figure 5 est un organigramme illustrant un mode de réalisation particulier du procédé d'installation, la figure 6 est un schéma bloc illustrant une table de correspondance utilisée dans un procédé de gestion selon un mode de réalisation de l'invention, - la figure 7 est un organigramme illustrant un premier mode de réalisation particulier d'un procédé de gestion selon l'invention, la figure 8 est un organigramme illustrant un deuxième mode de réalisation d'un procédé de gestion selon l'invention, la figure 9 est un schéma bloc représentant un serveur de gestion apte à réaliser les étapes d'un procédé d'installation selon un mode de réalisation de l'invention, la figure 10 est un schéma bloc représentant un serveur de gestion apte à réaliser les étapes d'un procédé de gestion selon un mode de réalisation de l'invention.
Un mode de réalisation d'un procédé d'installation d'une application de gestion de données d'applications d'un premier type et d'un procédé de gestion de données de même type selon l'invention va maintenant être décrit en référence aux figures 1 à 3
En référence à la figure 1, un utilisateur dispose d'un terminal mobile 100 qui est, par exemple un téléphone mobile ou un PDA (pour "Personal Digital Assistant"). Ce terminal mobile possède un module de communication 130, par exemple un module GSM, permettant une communication, via un réseau de communication R, avec des serveurs distants, par exemple avec des serveurs de gestion (SP, SPO). Cette communication est par exemple une communication "OTA" (pour "Over The Air"), c'est-à-dire une communication sans fil classique. A titre d'alternative, le terminal mobile est relié au réseau R par une ligne téléphonique filaire. Le terminal mobile 100 comporte également un module de sécurité 120.
Le module de sécurité 120 est par exemple un support amovible de type SIM ou UICC (pour "Universal Integrated Circuit Card"), une zone mémoire sécurisée du terminal mobile ou une carte à mémoire hébergeant un élément sécurisé (SD card, Embeded Secure contrôler ...))•
Le terminal mobile 100 comporte également classiquement un module d'interface (non représenté) apte à émettre et à recevoir des données vers et en provenance du module de sécurité 120.
Le terminal mobile 100 comporte également un module 140 de communication sans contact permettant l'échange de messages selon un protocole de dialogue de premier type entre une borne BM de premier type, par exemple une borne de type
Mifare Classic (marque déposée), et le module de sécurité 120 du terminal mobile.
La borne BM est un équipement extérieur de premier type.
A titre d'alternative, ce module 140 permet également le dialogue entre une borne B de second type et le module de sécurité 120 du terminal mobile selon le protocole ISO qui est un protocole de dialogue de second type. La borne B est un équipement extérieur de second type.
Le module de sécurité 120 peut comporter une ou plusieurs zones mémoire sécurisées (SD2) contenant des applications correspondant à des applications (AP2) d'un second type. Ces applications sont accessibles par la borne B en utilisant le protocole ISO, qui correspond à un protocole de dialogue de second type. Elles sont également accessibles via le réseau R, par un serveur de gestion (SP) possédant des clés associées à la zone mémoire sécurisée qui les héberge.
Le module de sécurité 120 comprend un module de gestion ISD de zones mémoires sécurisées. Ce module de gestion est apte à gérer l'installation des zones mémoires sécurisées du module de sécurité 120.
Le module de sécurité 120 comporte également un module ZM de stockage comprenant une zone mémoire MMF, qui est une zone mémoire de premier type, dans laquelle sont stockées des données d'applications d'un premier type. Un tel module de stockage ZM est apte à dialoguer avec la borne BM, selon un protocole de dialogue de premier type.
La borne BM de premier type émet périodiquement des messages à l'attention des terminaux mobiles. Lorsque le terminal mobile 100 entre dans le champ émis par la borne de premier type BM, le module sans contact 140 reçoit ce message et le transmet au module de sécurité 120 qui le transmet au module de stockage ZM pour traitement.
Un mode de réalisation du procédé d'installation va maintenant être décrit en référence à la figure 2.
Lors d'une première étape El, le module de sécurité 120 reçoit via le réseau R et le module de communication 130 du terminal mobile 100, une commande de création CREAT d'une zone mémoire sécurisée SDl associée à une zone Z de la zone mémoire MMF. La zone Z est une partie de la zone MMF. A titre d'alternative, la zone Z correspond à la zone MMF.
Suite à la réception de cette commande, le module de gestion ISD du module de sécurité procède à la création d'une zone mémoire sécurisée SDl associée à la zone Z, lors d'une étape E2.
Une zone mémoire sécurisée, telle que SDl, est une zone mémoire protégée en lecture et en écriture par des clés partagées avec un serveur distant tel que par exemple le serveur SP.
L'étape E2 est suivie d'une étape E3 lors de laquelle le module de sécurité 120 installe une application de gestion PGC dans la zone mémoire sécurisée SDl. Cette application PGC est apte à accéder aux données contenues dans la zone Z. Ainsi, la création de la zone mémoire sécurisée SDl permettant la gestion des données de la zone Z qui est une zone mémoire de premier type, est effectuée par un module existant du module de sécurité apte à créer des zones mémoire sécurisées permettant la gestion de données d'applications de second type. En référence à la figure 3, un mode de réalisation du procédé de gestion selon l'invention va maintenant être présenté.
Ce procédé de gestion est mis en œuvre suite à l'installation d'une application de gestion selon par exemple un procédé d'installation tel que décrit précédemment. Lors d'une étape ElO, le module de sécurité 120 reçoit une commande d'accès
CA à la zone Z. Cette commande d'accès est, par exemple, une commande d'écriture d'une ou plusieurs données de la zone Z.
A titre d'alternative, la commande d'accès est une commande de lecture.
Dans un mode de réalisation, cette commande est transmise au module de sécurité par le serveur distant SP, via le module de communication 130 du terminal mobile. Cette commande contient alors un identifiant de la zone Z. Ce mode de réalisation est décrit dans la suite de la description en référence à la figure 7.
Dans un autre mode de réalisation, la commande est déclenchée par la réception d'un événement, par exemple la réception d'un événement de fin de transaction transmis par le module de communication sans contact 140 du terminal mobile au module de sécurité. Ce mode de réalisation est décrit dans la suite de la description en référence à la figure 8.
Suite à la réception de cette commande, le module de sécurité 120 construit une requête d'accès REQ à partir de la commande CA reçue et transmet cette requête REQ au module de stockage ZM, lors d'une étape E20. Cette requête d'accès est par exemple un ordre d'écriture ou de lecture de données dans la zone Z.
Le module de sécurité 120 reçoit en retour une réponse REP, lors d'une étape E30. La réponse à un ordre d'écriture est par exemple un message d'acquittement. La réponse à un ordre de lecture contient par exemple tout ou partie des données de la zone Z.
L'étape E30 est suivie d'une étape E40 lors de laquelle le module de sécurité 120 transmet via un module d'émission/réception, au terminal mobile 100, par exemple à son module d'interface, un message MSG contenant la réponse transmise par le module de stockage ZM lors de l'étape 30. Un mode de réalisation particulier du procédé d'installation et du procédé de gestion dans lequel le module MMF est un module comportant des données de type Mifare Classic (marque déposée) va maintenant être décrit en référence aux figures 4 à 8. Dans ce mode de réalisation, le module de sécurité 120 est une carte à mémoire amovible compatible avec les spécifications de GlobalPlatform (GlobalPlatform Card Spécification - version 2.2 de mars 2006).
En référence à la figure 4, selon un mode de réalisation particulier, le module de sécurité 120 comprend notamment un microprocesseur 122, un module d'émission-réception 124, une ou plusieurs mémoires 125 de type RAM et une ou plusieurs mémoires 126 de type ROM ou EEPROM dans laquelle sont enregistrés des programmes pouvant être exécutés par le microprocesseur 122.
La mémoire 126 contient notamment un programme P qui est le programme principal de la carte. Ce programme P est également appelé "OS" (pour "operating System").
Le module de sécurité 120 comprend également un module de gestion ISD de zones mémoires sécurisées.
Dans ce mode de réalisation, le module de gestion ISD est un domaine de sécurité conforme aux spécifications Global Platform. Un domaine de sécurité est une zone mémoire sécurisée, protégée en lecture et en écriture par des clés partagées avec un serveur de gestion.
De façon classique, une clé partagée est soit une même clé connue de deux entités, soit une paire de clés associées. Un exemple de clés associées est un couple de clés dont l'une est secrète et n'est connue que d'une seule entité et l'autre publique utilisée par l'autre entité.
Le module de gestion ISD possède des clés partagées avec un serveur de gestion SPO du module de sécurité, par exemple le serveur d'un opérateur téléphonique.
Le module de sécurité 120 peut comporter une ou plusieurs zones mémoire sécurisées (non représentées) contenant des applications correspondant à des applications d'un second type et fonctionnant en utilisant le protocole ISO, qui correspond à un protocole de dialogue de second type.
Le module de sécurité 120 comporte également un module de stockage ZM contenant une zone de données MMF, un module MAF d'accès à cette zone de données MMF et deux modules d'interface II et 12.
La zone de données MMF comporte une ou plusieurs zones appelées "cartes Mifare Classic". La taille d'une carte est soit de 1 koctet (il s'agit alors d'une carte Ik), soit de 4 koctets (carte 4k).
Une carte Mifare Classic comporte, de façon classique, une structure en secteurs et blocs. Une carte Mifare Ik comporte 16 secteurs de 4 blocs chacun. Une carte 4k comporte 32 secteurs de 4 blocs et 8 secteurs de 16 blocs. Le bloc 0 est un bloc contenant les informations du fabriquant. Les blocs 1 et 2 contiennent des données d'applications. Le bloc 4 contient des clés et n'est pas accessible. A chaque secteur est associé un couple de clés KeyA, KeyB. Dans ce mode particulier de réalisation, la zone de données MMF contient 4 cartes Mifare distinctes : 1 carte Mifare 4k (Cl) et 3 cartes Mifare Ik (C2, C3, C4).
A titre d'alternative, la zone MMF peut comporter un nombre de cartes Mifare différent et une répartition entre les cartes Ik et les cartes 4k différente.
Chaque bloc comporte 16 octets. Les données stockées dans un bloc sont protégées en lecture et en écriture par les clés du secteur dont elles font partie.
Les données de la zone MMF sont donc identifiées par un numéro de carte, un numéro de secteur et un numéro de bloc. L'adressage dans la zone MMF est inconnu des autres modules du module de sécurité et notamment du programme principal P du module de sécurité. La borne de premier type BM ne possède pas de moyens de sélection ou d'activation d'une carte. L'activation d'une carte est effectuée par le module de sécurité suite à une requête de l'utilisateur. Le numéro de la carte activée est enregistré dans une mémoire CMF du module de sécurité. Le module MAF dispose également de cette information, soit par accès à cette mémoire CMF, soit par enregistrement de cette information dans une zone interne à ce module. Dans ce mode de réalisation, une carte est activée par défaut, par exemple, la carte permettant l'accès à un moyen de transport. L'utilisateur peut ensuite, à l'aide d'un menu du terminal mobile sélectionner une autre carte, par exemple pour effectuer une opération de paiement. En alternative, cette opération peut être transparente pour l'opérateur. Par exemple, l'utilisateur sélectionne une application de paiement et cette opération de sélection va déclencher l'envoi de la requête de sélection d'une autre carte Mifare au module de sécurité.
La borne de premier type BM émet périodiquement des messages à l'attention des terminaux mobiles. Lorsque le terminal mobile 100 entre dans le champ émis par la borne de premier type BM, le module sans contact 140 reçoit ce message et le transmet au programme principal P du module de sécurité, via le module d'émission/réception 124.
Le programme principal P détermine alors qu'il s'agit d'un message de type Mifare.
Le message reçu est un message de lecture ou d'écriture dans un secteur d'une carte de type Mifare. Il contient une adresse (numéro de secteur et numéro de bloc) ainsi que des données codées avec les clés du secteur. L'algorithme utilisé pour le codage est un algorithme secret, propriétaire et confidentiel de Mifare. Le programme P enregistre l'adresse du secteur (numéro de secteur et numéro de bloc) contenu dans le message dans une mémoire DER de la mémoire 126, puis transmet le message reçu au module d'accès MAF via l'interface II.
Suite à la réception du message, le module d'accès MAF accède à la zone MMF pour déchiffrer ce message en utilisant les clés associées au secteur et réaliser l'opération de lecture ou d'écriture demandée. Il retransmet ensuite une réponse à la borne de premier type BM, via l'interface II.
Dans un mode de réalisation où le module d'accès MAF ne dispose pas d'information concernant le numéro de la carte activée, il transmet l'information au secteur adressé de toutes les cartes et seule la carte pouvant déchiffrer le message lui répond. La zone de données MMF n'est pas directement accessible par le programme principal P du module de sécurité 120.
Comme il va être décrit par la suite, l'interface 12 permet un accès, interne au module de sécurité, aux données de la zone MMF.
En référence à la figure 5, un mode de réalisation du procédé d'installation dans lequel le module MMF est un module comportant des données de type Mifare (marque déposée) va maintenant être décrit.
Ce procédé comporte des étapes El, E2 et E3 correspondant aux étapes El, E2 et E3 décrites précédemment.
Lors d'une première étape EO, le serveur SPO, qui est par exemple le serveur de l'opérateur gérant le module de sécurité, transmet au module de sécurité, via le module de communication 130 et le module d'interface du terminal mobile, une commande de création CREAT d'un domaine de sécurité SDl associé aux secteurs 5 et 10 de la carte C2 de la zone MMF. Le domaine de sécurité SDl constitue une zone mémoire sécurisée.
Le serveur SPO est également apte à transmettre au module de sécurité des commandes de création de domaines de sécurité aptes à gérer des données d'applications de second type. Ainsi, un seul serveur est utilisé pour la création de domaines de sécurité apte à gérer des données d'applications de premier type et pour la création de domaines de sécurité apte à gérer des données d'applications de second type.
Cette commande de création CREAT est reçue par le module d'émission/réception 124 du module de sécurité 120 lors de l'étape El. De façon classique, cette commande est transmise chiffrée avec des clés partagées entre le serveur SPO et le module de gestion ISD du module de sécurité 120, puis déchiffrée par le module de sécurité.
L'utilisation de telles clés permet une gestion sécurisée. Cette commande ou message de création comporte au moins un paramètre relatif au type des données d'applications et au moins un identifiant d'une partie de la zone mémoire de premier type.
Cette commande de création est une commande "Install for Install" définie dans les spécifications Global Platform V2.2 dans laquelle le paramètre "Privilèges" indique que le domaine de sécurité SDl est appairé à une zone mémoire de type
Mifare, c'est-à-dire que le domaine de sécurité SDl est apte à permettre la gestion d'un ou plusieurs secteurs de la zone MMF. Les données relatives à l'identification de la zone mémoire, c'est-à-dire le ou les numéros de cartes et de secteurs, sont transmises dans le champ "Install Parameters Field" de la commande "Install for
Install".
Les spécifications Global Platform définissent un champ "Privilèges", pour la commande "Install for install", constitué de 3 octets, dont 7 bits sont réservés pour une utilisation future. Dans le mode de réalisation décrit ici, un bit parmi ces 7 bits est utilisé pour indiquer le type du domaine de sécurité. Ce bit est positionné à 1 pour indiquer que le domaine de sécurité à créer est de type "Mifare". Il est positionné à 0 sinon.
La commande CREAT de création est reçue, par le programme principal P, via le module d'émission/réception 124. Le programme P déchiffre cette commande de création en utilisant les clés du domaine de sécurité ISD, partagée avec l'opérateur et procède, lors de l'étape E2, à la création du domaine de sécurité SDl.
L'étape E2 de création va maintenant être décrite plus en détail.
Lors d'une première sous étape E 102, le programme principal P vérifie, dans une table de correspondance T que les identifiants de secteurs contenus dans la commande de création reçue ne correspondent pas à des secteurs gérés par un autre domaine de sécurité du module de sécurité.
Comme illustré sur la figure 6, la table de correspondance T enregistrée dans une mémoire 126 du module de sécurité comporte, pour chaque secteur S de chaque carte C de la zone mémoire MMF, un champ CID contenant un identifiant AID d'un domaine de sécurité. Ce champ CID est vide lorsqu'aucun domaine de sécurité n'y est associé.
A titre d'alternative, le champ CDD comporte une valeur prédéterminée, par exemple "0", lorsqu'aucun domaine de sécurité n'est associé. La vérification effectuée lors de la sous étape E102 consiste à vérifier que le champ CDD correspondant aux secteurs contenus dans la commande CREAT de création est vide.
Si ce n'est pas le cas, le secteur est géré par un autre domaine de sécurité et le programme principal P renvoie au serveur SPO un message indiquant son refus de créer ce domaine de sécurité. A titre d'alternative, le module de sécurité ne répond pas à la commande de création. Le processus s'arrête.
Cette vérification évite l'appairage d'un secteur avec plusieurs domaines de sécurité et permet de renforcer la sécurité.
Si le champ CDD lu est vide, le programme principal P réserve une zone mémoire dans la mémoire 126 (sous étape E104). Il enregistre ensuite dans la table de correspondance T, un identifiant ADDl de ce domaine de sécurité SDl en association avec le numéro de carte et de secteur associé (sous étape E106).
Si la commande reçue contient plusieurs numéros de secteur, les étapes E102 à E 106 sont exécutées pour chaque secteur. Ainsi, dans le mode de réalisation décrit, comme illustré sur la figure 6, l'identifiant ADDl est stocké d'une part en association avec la carte C2 et le secteur 5 et, d'autre part en association avec la carte C2 et le secteur 10.
Le programme principal P transmet ensuite au serveur SPO, lors d'une sous étape E108, un message d'acquittement ACQ. Suite à la réception de ce message d'acquittement, lors d'une sous étape EI lO, le serveur SPO transmet au module de sécurité 220 les clés K associées à la zone SDl, en utilisant par exemple un ordre "PutKey" ou "Installffor Personnalisation]/StoreData" définis dans les spécifications GlobalPlatform. Ces clés sont également connues d'un serveur SP, apte à gérer le domaine de sécurité SDl. Le module de sécurité enregistre ces clés dans le domaine de sécurité SDl, lors d'une sous étape El 12.
Le module de sécurité positionne ensuite le domaine de sécurité en position "activé" (sous étape El 14). Ce passage à l'état "activé" correspond au passage à l'état "Personalized" décrit dans les spécifications Global PlatForm partie "Card Spécifications"
Le passage à l'état "activé" du domaine de sécurité SDl permet au serveur SP, qui partage ces clés avec le domaine de sécurité SDl, d'accéder au domaine de sécurité SDl. Le module de sécurité, et plus particulièrement le module de gestion ISD, est ainsi apte à gérer des domaines de sécurité aptes à recevoir des applications de premier type et aptes à recevoir des applications de second type.
Lors de l'étape E3 suivante, le serveur SP commande l'installation d'une application de gestion PGC dans le domaine de sécurité SDl. Plus précisément, lors d'une première sous étape E302, le serveur SP commande le téléchargement d'une application de gestion PGC dans le domaine de sécurité SDl. Cette application PGC est apte à accéder aux données contenues dans la partie de la zone MMF désignée dans la commande de création du domaine de sécurité SDl, c'est-à-dire aux secteurs 5 et 10 de la carte C2. Le téléchargement de l'application PGC s'effectue de façon classique et ne sera pas décrite ici. Cette opération est notamment décrite dans la norme Global Platform V2.2.
A titre d'alternative, le programme PCG a été téléchargé dans le module de sécurité lors d'une étape précédente et l'étape de téléchargement consiste à transférer ce programme dans la zone SDl.
La sous étape E302 de téléchargement est suivie d'une sous étape E304 d'activation du programme PCG. Cette étape consiste à mettre à jour un registre permettant au programme principal du module de sécurité de savoir que le programme est activé. Dans le mode de réalisation décrit ici, le registre utilisé est le registre GPRegistry défini dans les spécifications Global Platform. La sous étape E304 est suivie d'une sous étape E305 d'activation des secteurs associés au domaine de sécurité SDl. Pour cela, un champ est ajouté au registre GPRegistry. Ce champ contient autant de bits que de secteurs contenus dans la zone MMF. La sous étape E3O5 de validation consiste à positionner, par exemple à la valeur 1, le bit correspondant à chaque secteur associé au domaine de sécurité SDl. Un tel bit constitue un indicateur d'activation.
A titre d'alternative, la sous étape E305 n'est pas réalisée.
Ainsi, le serveur de gestion SP est apte à installer une application d'un premier type dans un domaine de sécurité de premier type. Le serveur de gestion SP est par ailleurs apte à installer des applications de second type dans des domaines de sécurité de second type. Les serveurs de gestion existants peuvent être utilisés. Il n'est donc pas nécessaire de développer des serveurs spécifiques pour la gestion de données d'applications de premier type.
Les étapes El, E2 et E3 sont réalisées par le microprocesseur 122 du module de sécurité 120.
En référence à la figure 7, un mode de réalisation d'un procédé de gestion dans lequel un serveur de gestion SP accède à des données du module mémoire MMF qui est un module comportant des données de type Mifare (marque déposée), va maintenant être décrit.
L'exécution des étapes suivantes est subordonné à l'exécution préalable des étapes EO à E3 du procédé d'installation décrit en référence à la figures 5.
Lors d'une étape E400, le serveur SP établit un canal sécurisé avec le domaine de sécurité SDl du module de sécurité 120. L'établissement d'un tel canal est décrit dans les spécifications Global Platform.
Suite à l'établissement d'un tel canal, le serveur SP et le programme PGC sont aptes à s'échanger des messages applicatifs spécifiques.
Lors d'une étape E402, le serveur SP transmet au module de sécurité 120 un message applicatif spécifique qui est une commande d'accès CA à une partie de la zone MMF. Cette commande d'accès est, par exemple, un ordre d'écriture du secteur S de la carte X.
A titre d'alternative, la commande d'accès est un ordre de lecture.
La commande d'accès CA est transmise chiffrée avec les clés du domaine de sécurité SDl.
L'utilisation d'un système de clés permet une gestion sécurisée et évite l'utilisation d'autres systèmes de sécurité comme des mots de passe pour accéder aux données de la zone mémoire MMF.
Cette commande d'accès est reçue par le module de sécurité 120 lors d'une étape E410. Plus précisément, elle est reçue par le module d'émission/réception 124 qui la transmet au programme PGC du domaine SDl.
Le programme PGC vérifie, lors d'une étape E412, dans la table de correspondance T qu'il est autorisé à accéder au secteur S de la carte C. Pour cela, il vérifie que l'AID stocké dans la table de correspondance T en correspondance avec le secteur S de la carte C est l'identifiant du domaine de sécurité SDl.
Si ce n'est pas le cas, le module de sécurité ne répond pas ou transmet un message d'erreur.
Cette étape de vérification permet d'augmenter la sécurité du système en s'assurant que le serveur SP ne tente pas d'accéder à des secteurs pour lequel il n'est pas autorisé.
Si l'accès est autorisé, le programme PGC construit un ordre d'écriture du secteur demandé et le transmet à l'interface 12 du module de stockage ZM, lors d'une étape E414.
Lors d'une étape E415, l'ordre d'écriture est intercepté par le programme principal P du module de sécurité qui vérifie, dans la table de correspondance T que le programme PGC est autorisé à accéder au secteur S de la carte C. Pour cela, il vérifie que l'AID stocké dans la table de correspondance T en correspondance avec le secteur S de la carte X est l'identifiant du domaine de sécurité SDl.
Si ce n'est pas le cas, le module de sécurité ne répond pas ou transmet un message d'erreur. Cette étape de vérification permet d'augmenter la sécurité du système en s'assurant que le programme PGC ne tente pas d'accéder à des secteurs pour lequel il n'est pas autorisé.
L'interface 12 reçoit l'ordre transmis lors de la sous étape E414 et transmet la demande au module d'accès MAF qui accède au secteur S de la carte C, inscrit la nouvelle valeur dans ce secteur et renvoie un accusé de réception au programme PGC via l'interface 12 (étape E416). Cet accusé de réception est, par exemple, un ou plusieurs octets dont la valeur indique si l'écriture a eu lieu correctement ou non.
Lors d'une étape E418 suivante, le programme PGC transmet un message contenant l'accusé de réception au serveur de gestion SP, via le module d'émission/réception 124, un module d'interface du terminal mobile et le module de communication 130 du terminal mobile.
Ainsi, la gestion des données d'au moins une partie de la zone mémoire MMF peut être effectuée par un serveur de gestion apte à gérer également des données d'applications de second type; la gestion de ces données d'applications de premier type ne nécessite donc pas le développement de plates-formes spécifiques.
En référence à la figure 8, un deuxième mode de réalisation d'un procédé de gestion dans lequel des données d'applications de premier type sont communiquées à l'utilisateur suite à une transaction effectuée avec une borne BM de premier type, va maintenant être décrit. Dans ce mode de réalisation, le module MMF est un module comportant des données de type Mifare (marque déposée).
L'exécution des étapes suivantes est subordonnée à l'exécution préalable des étapes EO à E3 du procédé d'installation décrit en référence à la figure 5. Lors d'une étape préalable E500, suite à l'entrée du terminal mobile dans le champ émis par la borne de premier type BM, une transaction a lieu entre la borne BM et le module de stockage ZM du module de sécurité 220. Par exemple, la borne BM est installée dans un bus de ville et le bloc 2 du secteur 5 de la carte 2 du module ZM comprend une valeur qui correspond à un nombre de tickets de transport achetés par le propriétaire du terminal mobile. La transaction entre la borne BM et le module de sécurité permet la décrémentation de 1 de la valeur stockée dans le bloc 2 secteur 5 de la carte 2.
Si la sous étape E3O5 d'activation a été réalisée lors de la phase d'installation du domaine de sécurité SDl associé au secteur 5 de la carte 2, le programme principal P du module de sécurité vérifie, lors de la réception d'un message de la borne de premier type BM, si ce secteur est en mode activé (étape E501) et refuse tout dialogue avec la borne BM si ce secteur n'est pas activé dans le registre GPRegistry.
Ainsi, les secteurs Mifare ne sont visibles et/ou adressables par un lecteur sans contact externe qu'à partir du moment où un domaine de sécurité a été créé pour la gestion de ces secteurs et que ce domaine de sécurité est en mode "activé".
Tout secteur Mifare qui n'est pas rattaché à un domaine de sécurité activé n'est pas visible et est donc inutilisable.
Si la transaction a lieu, en fin de transaction, le module sans contact 140 du terminal mobile 100 envoie au programme principal P du module de sécurité 120 une indication de fin de transaction, lors d'une étape E502.
Le programme principal lit dans la mémoire CMF du module de sécurité la valeur correspondant à la carte activée et dans la mémoire DER du module de sécurité la valeur correspondant au secteur qui vient d'être accédé (étape E504).
Lors de l'étape suivante E506, il recherche dans la table de correspondance T, l'identifiant AID du domaine de sécurité associé.
Le programme principal P réveille ensuite le programme PGC du domaine de sécurité SDl, par exemple en lui envoyant un événement de fin de transaction (étape E510).
Suite à la réception de cet événement, le programme PGC du domaine de sécurité SDl lit dans la mémoire CMF le numéro de carte, et dans la mémoire DER le numéro de secteur et de bloc pour lequel une transaction vient d'avoir lieu (étape E5O8)
Puis lors d'une étape E512, il envoie un ordre de lecture d'un ou plusieurs blocs de ce secteur au module MAF via l'interface 12. Cet ordre de lecture est une requête d'accès au module de stockage ZM. L'interface 12 reçoit cet ordre et transmet la demande au module d'accès MAF qui accède au secteur 5 de la carte 2 et renvoie, lors d'une étape E514, via l'interface 12 au programme PGC un message contenant le contenu du secteur lu.
Lors de l'étape E516 suivante, le programme PGC construit un message MR contenant ce contenu. Ce message est, par exemple, constitué d'un texte prédéterminé et du contenu du bloc lu; par exemple, le message est "Bus - ville de ... - II vous reste ... tickets".
Le message construit est ensuite transmis par le module d'émission/réception 124, lors d'une étape E518, au terminal mobile, via le module d'interface. Puis, le terminal mobile affiche le message sur son écran.
Ainsi, le programme PGC permet de communiquer à l'utilisateur des informations suite à une transaction réalisée entre une borne de type Mifare et un terminal mobile contenant une zone de données de type Mifare.
Dans les modes de réalisation décrits, la table T ainsi que les valeurs DER et
CMF sont enregistrées dans une mémoire 126 du module de sécurité. A titre d'alternative, tout ou partie de ces valeurs sont enregistrées dans la zone de stockage ZM. Elles sont alors accessibles via l'interface 12 via une commande applicative spécifique.
Ainsi, les données de type Mifare Classic sont installées dans un environnement dans lequel elles sont gérées de façon sécuritaire sans nécessiter la connaissance de mots de passe.
Selon un mode de réalisation choisi et représenté à la figure 9, un serveur de gestion mettant en œuvre un procédé d'installation selon l'invention est par exemple un micro-ordinateur 500 qui comporte de façon connue, notamment une unité de traitement 502 équipée d'un microprocesseur, une mémoire morte de type ROM ou EEPROM 503, une mémoire vive de type RAM 504 et une interface de communication 505 avec un réseau de communication R. Le micro-ordinateur 500 peut comporter de manière classique et non exhaustive les éléments suivants: un clavier, un écran, un microphone, un haut- parleur, un lecteur de disque, un moyen de stockage...
Ce serveur 500 comprend un module MEl d'émission de données vers le réseau R et un module MTl de traitement.
Le module MTl de traitement est apte à préparer un message contenant une commande de création d'au moins une zone mémoire sécurisée associée à au moins une partie d'une première zone mémoire, contenant des données d'applications d'un premier type, ladite première zone étant accessible par un équipement extérieur de premier type selon un protocole de premier type.
Le module MEl de transmission est apte à transmettre le message préparé.
Le module MTl est également apte à préparer une commande de téléchargement d'une application de gestion de données d'applications de premier type. Le module MEl est apte à transmettre la commande préparée.
La mémoire morte 503 comporte des registres mémorisant un programme d'ordinateur PGl comportant des instructions de programme adaptées à transmettre, via le réseau de télécommunication R, une commande de création d'une zone mémoire sécurisée (SDl) associée à au moins une partie d'une zone mémoire de premier type.
Lors de la mise sous tension, le programme PGl stocké dans la mémoire morte 503 est transféré dans la mémoire vive qui contiendra alors un code exécutable ainsi que des registres pour mémoriser les variables nécessaires à la mise en œuvre d'une étape de transmission, via le réseau de télécommunication R, d'une commande de création d'une zone mémoire sécurisée (SDl) associée à au moins une partie d'une zone mémoire de premier type.
De manière plus générale un moyen de stockage, lisible par un ordinateur ou par un microprocesseur, intégré ou non au dispositif, éventuellement amovible, mémorise un programme mettant en œuvre une étape de transmission, via le réseau de télécommunication R, d'une commande de création d'une zone mémoire sécurisée (SDl) associée à au moins une partie d'une zone mémoire de premier type, selon l'invention.
Selon un mode de réalisation choisi et représenté à la figure 10, un serveur de gestion mettant en œuvre un procédé de gestion selon l'invention est par exemple un ordinateur de type PC 600 qui comporte de façon connue, notamment une unité de traitement 602 équipée d'un microprocesseur, une mémoire morte de type ROM 603, une mémoire vive de type RAM 604. Le terminal 600 peut comporter de manière classique et non exhaustive les éléments suivants: un clavier, un écran, un microphone, un haut-parleur, une interface de communication, un lecteur de disque, un moyen de stockage...
Ce serveur comprend un module ME2 d'émission de données vers un réseau de communication R, un module MR2 de réception de données en provenance du réseau de communication R et un module MT2 de traitement.
Le module MT2 de traitement est apte à préparer un message contenant une commande d'accès à des données d'applications d'au moins une partie d'une première zone mémoire, contenant des données d'applications d'un premier type, ladite première zone étant accessible par un équipement extérieur de premier type, selon un protocole de premier type.
Le module ME2 de transmission est apte à transmettre le message préparé. Le module MR2 de réception est apte à recevoir un message contenant une réponse à ladite commande d'accès.
La mémoire morte 603 comporte des registres mémorisant un programme d'ordinateur PG2 comportant des instructions de programme adaptées à transmettre un message contenant une commande d'accès à au moins une partie de la zone mémoire de premier type et à recevoir une réponse à ladite commande d'accès.
Lors de la mise sous tension, le programme PG2 stocké dans la mémoire morte 603 est transféré dans la mémoire vive qui contiendra alors le code exécutable de l'invention ainsi que des registres pour mémoriser les variables nécessaires à la réalisation d'une étape de transmission d'un message contenant une commande d'accès à au moins une partie d'une zone de premier type et d'une étape de réception d'une réponse à ladite commande d'accès
De manière plus générale un moyen de stockage, lisible par un ordinateur ou par un microprocesseur, intégré ou non au dispositif, éventuellement amovible, mémorise un programme mettant en œuvre les étapes de transmission d'un message contenant une commande d'accès à au moins une partie d'une zone de premier type et de réception d'une réponse à ladite commande d'accès.

Claims

REVENDICATIONS
1. Procédé d'installation d'une application de gestion de données d'applications d'un premier type contenues dans une zone mémoire (MMF) de premier type d'un module de sécurité (120) associé à un terminal mobile (200), la zone mémoire
(MMF) de premier type étant accessible par un équipement extérieur (BM) de premier type selon un protocole de premier type, ledit module de sécurité comprenant un module de gestion (ISD) de zones mémoires sécurisées (SD2) aptes à recevoir des applications (AP2) d'un second type accessibles par un réseau de télécommunication
(R) via des clés de gestion et accessibles par un équipement extérieur (B) de second type selon un protocole de second type, caractérisé en ce que le procédé comporte :
- une étape de réception (El), par le réseau de télécommunication, d'une commande de création d'une zone mémoire sécurisée (SDl) comportant au moins un identifiant d'au moins une partie de la zone mémoire de premier type,
- une étape de création (E2) de la zone mémoire sécurisée (SDl) par le module de gestion (ISD),
- une étape d'installation (E3) dans la zone mémoire sécurisée, d'une application de gestion (PGC) apte à accéder à des données d'applications de la au moins une partie de la zone mémoire de premier type.
2. Procédé d'installation selon la revendication 1 dans lequel la commande de création est une commande prédéterminée interprétable par le module de gestion, qui comporte en outre au moins un paramètre relatif au type des données d'applications.
3. Procédé d'installation selon la revendication 1 dans lequel l'étape d'installation comprend une mise à jour d'au moins un indicateur d'activation associé à la au moins une partie de la zone mémoire de premier type.
4. Procédé d'installation selon la revendication 1 dans lequel la zone mémoire de premier type est une zone de type Mifare comprenant une pluralité de secteurs et dans lequel la commande de création comporte au moins un identifiant de secteur.
5. Procédé de gestion de données d'applications d'un premier type contenues dans une zone mémoire (MMF) de premier type d'un module de sécurité (120) associé à un terminal mobile (100), la zone mémoire (MMF) de premier type étant accessible par un équipement extérieur (BM) de premier type selon un protocole de premier type, ledit module de sécurité comprenant un module de gestion (ISD) de zones mémoires sécurisées (SD2) aptes à recevoir des applications (AP2) d'un second type accessibles par un réseau de télécommunication (R) via des clés de gestion et accessibles par un équipement extérieur (B) de second type selon un protocole de second type, caractérisé en ce qu'une application de gestion (PGC) est installée, selon un procédé d'installation conforme à la revendication 1, dans une zone mémoire sécurisée (SDl) associée à au moins une partie de la zone mémoire de premier type, l'application de gestion (PGC) étant apte à accéder à des données de la au moins une partie de la zone mémoire de premier type et en ce que le procédé comporte :
- une étape de réception (ElO), par un module d'émission/réception (124) du module de sécurité, en provenance d'un module de communication du terminal mobile, d'une commande d'accès (CA) à des données d'applications de la au moins une partie de la zone mémoire de premier type,
- une étape de transmission (E20), à un module de stockage (ZM) du module de sécurité, d'une requête d'accès auxdites données d'application de la au moins une partie de la zone mémoire de premier type,
- une étape de réception (E30), en provenance du module de stockage (ZM), d'une réponse relative aux données d'application,
- une étape d'envoi (E40) par le module d'émission/réception (124) d'un message contenant ladite réponse.
6. procédé de gestion selon la revendication 5 caractérisé en ce que la commande d'accès reçue est chiffrée, et en que le procédé comporte en outre une étape de déchiffrement de ladite commande.
7. procédé de gestion selon la revendication 5 dans lequel la commande d'accès est consécutive à un accès à une partie de la zone mémoire de premier type, par l'équipement extérieur de premier type, selon le protocole de premier type, et dans lequel le message envoyé est un message de commande d'affichage relatif audit accès sur un écran du terminal.
8. Module de sécurité (120) associé à un terminal mobile (100) comprenant un module de gestion (ISD) de zones mémoires sécurisées (SD2) aptes à recevoir des applications (AP2) d'un second type accessibles par un réseau de télécommunication (R) via des clés de gestion et accessibles par un équipement extérieur (B) de second type selon un protocole de second type , et une zone mémoire (MMF) de premier type contenant des données d'applications de premier type et accessible par un équipement extérieur (BM) de premier type selon un protocole de premier type, caractérisé en ce qu'il comprend:
- des moyens de réception via le réseau de télécommunication, d'une commande de création d'une zone mémoire sécurisée (SDl) comportant au moins un identifiant d'au moins une partie de la zone mémoire de premier type,
- des moyens de création de la zone mémoire sécurisée,
- des moyens d'installation dans la zone mémoire sécurisée d'une application de gestion (PGC) apte à accéder à des données d'application de la au moins une partie de la zone de premier type.
9. Module de sécurité selon la revendication 8 caractérisé en ce qu'il comporte en outre : - des moyens de réception, en provenance d'un module de communication du terminal mobile, d'une commande d'accès à des données d'applications de la au moins une partie de la zone mémoire de premier type,
- des moyens de transmission à un module de stockage, d'une requête d'accès auxdites données d'applications de la au moins une partie de la zone mémoire de premier type,
- des moyens de réception, en provenance du module de stockage, d'une réponse relative aux données d'applications,
- des moyens d'émission d'un message contenant ladite réponse.
10. Terminal de communication (100) comportant un module de communication sans contact (140) apte à communiquer avec un équipement extérieur (BM) de premier type selon un protocole de premier type, un module de communication (130) apte à communiquer avec un réseau de télécommunication (R), et un module de sécurité (120) selon la revendication 8 ou 9.
11. Terminal selon la revendication 10 caractérisé en ce que le module de communication sans contact (140) est en outre apte à communiquer avec un équipement extérieur (B) de second type selon un protocole de second type.
12. Serveur de gestion (SPO) apte à accéder, via un réseau de télécommunication (R) et via des clés de gestion, à des applications (AP2) d'un second type contenues dans des zones mémoires sécurisées (SD2) gérées par un module de gestion (ISD) d'un module de sécurité (120) associé à un terminal mobile (100), caractérisé en ce qu'il comporte des moyens d'émission d'une commande de création d'une zone mémoire sécurisée (SDl) comportant au moins un identifiant d'au moins une partie d'une zone mémoire (MMF) de premier type du module de sécurité dans laquelle sont stockées des données d'applications d'un premier type, accessibles par un équipement extérieur (BM) de premier type selon un protocole de premier type.
13. Signal transportant un message de création pour l'installation d'une application (PGC) de gestion de données d'applications d'un premier type contenues dans une zone mémoire (MMF) de premier type d'un module de sécurité associé à un terminal mobile, la zone mémoire (MMF) de premier type étant accessible par un équipement extérieur de premier type selon un protocole de premier type, caractérisé en ce que le message comporte au moins un paramètre relatif au type des données d'applications et au moins un identifiant d'au moins une partie de la zone mémoire de premier type, ledit message étant destiné à être envoyé au module de sécurité comprenant un module de gestion (ISD) de zones mémoires sécurisées
(SD2) aptes à recevoir des applications (AP2) d'un second type accessibles par un réseau de télécommunication via des clés de gestion et accessibles par un équipement extérieur de second type selon un protocole de second type.
14. Produit programme d'ordinateur comprenant des instructions pour mettre en œuvre les étapes du procédé d'installation selon l'une des revendications 1 à 4 et/ou du procédé de gestion selon l'une des revendications 5 à 7 lorsqu'il est chargé et exécuté par un processeur.
PCT/FR2009/051240 2008-07-01 2009-06-26 Procede d'installation d'une application de gestion et procede de gestion de donnees d'applications d'une zone memoire contenue sur un module de securite associe a un terminal mobile, module de securite, terminal mobile et serveur de gestion associes WO2010001046A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0854428A FR2933559A1 (fr) 2008-07-01 2008-07-01 Procede d'installation d'une application de gestion et procede de gestion de donnees d'application d'un module de securite associe a un terminal mobile
FR0854428 2008-07-01

Publications (2)

Publication Number Publication Date
WO2010001046A2 true WO2010001046A2 (fr) 2010-01-07
WO2010001046A3 WO2010001046A3 (fr) 2010-03-18

Family

ID=40548594

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2009/051240 WO2010001046A2 (fr) 2008-07-01 2009-06-26 Procede d'installation d'une application de gestion et procede de gestion de donnees d'applications d'une zone memoire contenue sur un module de securite associe a un terminal mobile, module de securite, terminal mobile et serveur de gestion associes

Country Status (2)

Country Link
FR (1) FR2933559A1 (fr)
WO (1) WO2010001046A2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013098117A1 (fr) * 2011-12-27 2013-07-04 Telefonica, S.A. Procédé pour gérer une communication sans contact dans un dispositif d'utilisateur
CN104348951A (zh) * 2013-07-24 2015-02-11 北京握奇数据系统有限公司 一种卡片应用管理系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6005942A (en) * 1997-03-24 1999-12-21 Visa International Service Association System and method for a multi-application smart card which can facilitate a post-issuance download of an application onto the smart card
US20040140351A1 (en) * 2002-12-11 2004-07-22 Scheidt & Bachmann Gmbh Methods and systems for user media interoperability
US20080073426A1 (en) * 2006-09-24 2008-03-27 Rfcyber Corp. Method and apparatus for providing electronic purse
EP1909462A2 (fr) * 2006-10-05 2008-04-09 Societé Française du Radiotéléphone Procédé de mise à disposition cloisonnée d'un service électronique

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6005942A (en) * 1997-03-24 1999-12-21 Visa International Service Association System and method for a multi-application smart card which can facilitate a post-issuance download of an application onto the smart card
US20040140351A1 (en) * 2002-12-11 2004-07-22 Scheidt & Bachmann Gmbh Methods and systems for user media interoperability
US20080073426A1 (en) * 2006-09-24 2008-03-27 Rfcyber Corp. Method and apparatus for providing electronic purse
EP1909462A2 (fr) * 2006-10-05 2008-04-09 Societé Française du Radiotéléphone Procédé de mise à disposition cloisonnée d'un service électronique

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"Globalplatform Card Specification Version 2.2" GLOBALPLATFORM, 1 mars 2006 (2006-03-01), pages 1-375, XP007908232 *
GSMA: "Mobile NFC technical guidelines" INTERNET CITATION, [Online] novembre 2007 (2007-11), pages 1-95, XP002558746 Extrait de l'Internet: URL:http://www.gsmworld.com/documents/gsma_nfc2_wp.pdf> [extrait le 2010-01-14] *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2013098117A1 (fr) * 2011-12-27 2013-07-04 Telefonica, S.A. Procédé pour gérer une communication sans contact dans un dispositif d'utilisateur
ES2409807R1 (es) * 2011-12-27 2013-10-11 Telefonica Sa Metodo para gestionar comunicacion sin contacto en un dispositivo de usuario
CN104348951A (zh) * 2013-07-24 2015-02-11 北京握奇数据系统有限公司 一种卡片应用管理系统

Also Published As

Publication number Publication date
FR2933559A1 (fr) 2010-01-08
WO2010001046A3 (fr) 2010-03-18

Similar Documents

Publication Publication Date Title
EP2263359B1 (fr) Procédé d'accès et de transfert de données liées à une application installée sur un module de sécurité associé à un terminal mobile, module de sécurité, serveur de gestion et système associés
EP2008483B1 (fr) Procédé de sécurisation de l'accès à un module de communication de proximité dans un terminal mobile
EP0906603B1 (fr) Systeme de communication permettant une gestion securisee et independante d'une pluralite d'applications par chaque carte utilisateur, carte utilisateur et procede de gestion correspondants
EP2143053B1 (fr) Procédé de communication et de transmission d'un message concernant une transaction d'une application sans contact, terminal, module sécurisé et système associés
EP1080453A1 (fr) Procede d'authentification d'un code personnel d'un utilisateur d'une carte a circuit integre
WO2006087438A1 (fr) Procede et dispositif d'acces a une carte sim logee dans un terminal mobile par l'intermediaire d'une passerelle domestique
FR3025377A1 (fr) Gestion de tickets electroniques
EP2232815B1 (fr) Procédé de contrôle d'applications installées sur un module de sécurité associé à un terminal mobile, module de sécurité, terminal mobile et serveur associés
US20090124287A1 (en) Retrospective Implementation of Sim Capabilities In a Security Module
EP3087543B1 (fr) Transmission et traitement de données relatives a une transaction sans contact
WO2010001046A2 (fr) Procede d'installation d'une application de gestion et procede de gestion de donnees d'applications d'une zone memoire contenue sur un module de securite associe a un terminal mobile, module de securite, terminal mobile et serveur de gestion associes
WO2009007653A1 (fr) Procédé de protection des applications installées sur un module sécurisé, terminal, module de sécurité et équipement communicant associés
WO2000042731A1 (fr) Procede de chargement securise de donnees entre des modules de securite
EP1609326B1 (fr) Procede de protection d'un terminal de telecommunication de type telephone mobile
EP2471237B1 (fr) Dispositif électronique nomade configuré pour établir une communication sans fil sécurisé
EP1413158B1 (fr) Procede d'acces a un service specifique propose par un operateur virtuel et carte a puce d'un dispositif correspondant
EP2911365B1 (fr) Procédé et système de sécurisation de transactions offertes par une pluralité de services entre un appareil mobile d'un utilisateur et un point d'acceptation
EP0817144B1 (fr) Procédé de contrôle de l'utilisation d'un messageur, messageur fonctionnant selon ce procédé et carte à puce pour l'accès conditionné à un messageur
FR2853785A1 (fr) Entite electronique securisee avec compteur modifiable d'utilisations d'une donnee secrete
EP2302518B1 (fr) Procédé et dispositif d'installation d'une application MIFARE dans une mémoire MIFARE
FR2913162A1 (fr) Procede de verification d'un code identifiant un porteur, carte a puce et terminal respectivement prevus pour la mise en oeuvre dudit procede.
WO2003003655A1 (fr) Procede de communication radiofrequence securisee
FR2833440A1 (fr) Systeme de controle d'acces a un reseau et procede de controle d'acces correspondant

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09772728

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09772728

Country of ref document: EP

Kind code of ref document: A2