WO2014029939A1 - Procede d'activation d'un nouveau profil dans un element de securite - Google Patents

Procede d'activation d'un nouveau profil dans un element de securite Download PDF

Info

Publication number
WO2014029939A1
WO2014029939A1 PCT/FR2013/051939 FR2013051939W WO2014029939A1 WO 2014029939 A1 WO2014029939 A1 WO 2014029939A1 FR 2013051939 W FR2013051939 W FR 2013051939W WO 2014029939 A1 WO2014029939 A1 WO 2014029939A1
Authority
WO
WIPO (PCT)
Prior art keywords
entity
profile
security
request
domain
Prior art date
Application number
PCT/FR2013/051939
Other languages
English (en)
Inventor
Saïd GHAROUT
Jean-Luc Grimault
Ahmad Saif
Original Assignee
Orange
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 Orange filed Critical Orange
Publication of WO2014029939A1 publication Critical patent/WO2014029939A1/fr

Links

Classifications

    • 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
    • H04W48/00—Access restriction; Network selection; Access point selection
    • H04W48/08—Access restriction or access information delivery, e.g. discovery data delivery
    • H04W48/12—Access restriction or access information delivery, e.g. discovery data delivery using downlink control channel
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/70—Services for machine-to-machine communication [M2M] or machine type communication [MTC]

Definitions

  • the invention relates to the management of security elements. More specifically, the invention relates to a method for activating a new profile in a security element.
  • the invention finds a particularly interesting application in areas such as those of mobile telephony, or machine-to-machine communication (the term usually used to designate this domain is the term "M2M", from the English "Machine To Machine ").
  • equipment such as a mobile terminal or a machine equipped with sensors embeds a security module, for example a (U) SIM card (of the English “(Universal) Subscriber Identity Module”).
  • the security module may be preconfigured to allow subsequent loading of operational subscription data to a telecommunications network, when assigning such a module to a subscriber.
  • operational data constitutes a subscriber communication profile.
  • a profile includes configuration data, for example subscriber identification and authentication data from a network such as a subscriber number, an authentication key, and applications and information. cryptographic algorithms used when accessing the network. This data is shared with the network.
  • a subscriber in a first network operated by a first operator wishes to change operator to establish communications in a second network operated by a second operator
  • the security element is updated so that the profile of the second operator subscriber in the second network is installed and activated in the security module instead of the subscriber's profile in the first network.
  • the profile of the subscriber in the first network is active, that is to say that the data it comprises allow him to access the first network.
  • the profile in the second network is the active profile, instead of the profile in the first network and allows the subscriber to access the second network.
  • a first solution for such an update is to provide the subscriber a new security module that stores the identification and authentication data specific to the second network.
  • Another solution is to make such an update once the security element circulates in the first network. This is called post-allocation.
  • the application of the Applicant published under the number WO2011001076 describes a change of a first authentication key and a first subscriber identification number on a card (U) SIM, specific to a first operator of network operating a first network, by a second authentication key and a second subscriber identification number, specific to a second operator operating a second network.
  • a master key key generation own the second network is stored in the card during a pre-configuration phase performed before the commissioning of the card.
  • the second operator transmits to the first operator a second subscriber identification number in the second network.
  • the first operator transmits to the card (U) SIM, through its network a random and the second subscriber identification number received, it also sends the hazard to the second network operator.
  • the card then generates a second authentication key by applying a key diversification algorithm to the hazard and to the master key stored in the card and specific to the second network.
  • the second operator calculates the same authentication key with the same master key of its own and the received randomness of the first network.
  • the second operator stores in a subscriber base of the network, the second authentication key in association with the second subscriber identification number.
  • the first authentication key is replaced in the card by the second authentication key and the first subscriber identification number is replaced in the card by the second subscriber identification number.
  • the (U) SIM card is then ready for operation in the second network.
  • One of the aims of the invention is to remedy the shortcomings / disadvantages of the state of the art and / or to make improvements thereto.
  • the invention proposes a method for activating a second profile, a first active profile being stored in a security module in which the first profile is associated with a first entity, the second profile being associated with a second one. entity, the module security system comprising a first security domain controlled by the first entity, the method comprising the following steps, implemented by the security module:
  • the method thus makes it possible, in the context of mobile telephony, to activate a second subscriber communication profile specific to a second network, without the subscriber user changing or manipulating his security module.
  • This mode of activation is particularly interesting in the field of machine-to-machine communication, or M2M. Indeed, in this area, a security module is inserted into a machine that is sometimes very difficult to access. In this context, the activation of a second profile is done remotely, without human intervention on the machine and in a completely transparent manner.
  • the activation request is made to a trusted entity. More precisely, this trusted entity is neutral vis-à-vis any network operator. In particular, the activation request is not made to the first entity, for example the first network operator. This relationship can facilitate collaboration between network operators to activate security modules once they are released.
  • the method advantageously uses the delegated management mechanism, usually used in a security module to load applications, install them, delete them, make them selectable.
  • This mechanism allows a security domain to request the security domain of the ISD issuer an authorization to execute an action.
  • This authorization is given by the ISD in the form of an authorization token.
  • the requested operation here the activation of the second profile is implemented by the security domain of the transmitter.
  • the second profile is stored by the security module. Such storage can be performed during a configuration phase of the module, prior to its release.
  • the second communication profile does not have to be transmitted by the second entity, under control of the first entity.
  • the first and the second entity are a first and a second network operator
  • the second operator may wish to prevent the second profile from being transported by means of an OTA procedure via the network of the first operator.
  • the profile includes sensitive security data that an operator wishes to fully control.
  • the trusted entity only needs to request an activation authorization token from the first entity for activation of the second profile.
  • the second profile is already stored in the security module and therefore does not need to be installed.
  • the method according to the invention further comprises: a step of reception by the second security domain of a request for installation of the second profile, the installation request comprising the second profile and a installation authorization token received by the trusted entity from the first entity,
  • the second profile is transmitted by the trusted entity to the management security domain along with an installation authorization token.
  • the method comprises a step of receiving by the first entity an activation authorization token request from the trusted entity.
  • This authorization is required by the second entity from the trusted entity that is neutral with respect to any entity.
  • the trusted entity relays a legitimate request to the first entity.
  • the activation process comprises a step of reception by the first entity of a request for security. installation authorization token from the trusted entity.
  • the trusted entity that is authorized to request from the first entity the installation of the second profile.
  • this operation is also subject to authorization and thus guarantees the integrity of the security module.
  • the method further comprises a step of deactivating the first profile by the first security domain.
  • the second profile is activated instead of the first active profile.
  • the first and second profiles are communication profiles specific to network operators, this allows the user to access the network of his choice when using his mobile terminal for access to the network.
  • the method further comprises a step of transferring control of the security module from the first to the second entity, implemented by the security module.
  • the method of the invention thus makes it possible to transfer the control of a security module from a first operator to a second network operator, without manual intervention on the security module.
  • the security module initially configured to be operational in the second network, following the deactivation of the first profile and the activation of the second profile.
  • the transfer of control thus ensures consistency in the security module which is thus controlled by the same operator as the one who shares with the user the second profile that has just been activated.
  • the invention also relates to a method for processing a request to take control of a security module by activating a first profile, said first profile being associated with a first entity, the security module storing a second active profile associated with a second entity, the security module comprising a first security domain controlled by the second entity and a second security domain controlled by a trusted entity, the method comprising the following steps, implemented by the trusted entity :
  • the method of processing an activation request makes it possible to put on equal footing the first and the second entity.
  • the activation request which if necessary can include the new profile to activate is not directly transmitted from the first to the second entity, which initially controls the security module.
  • potentially sensitive data such as secret authentication keys from the first to the second entity.
  • the trusted entity is an intermediary between the first and the second entity. This gives the process a better level of security than existing solutions where a potentially confidential data exchange occurs between the first and the second entity.
  • the invention also relates to a security module, comprising a first security domain controlled by a first entity and a second security domain, controlled by a trusted entity, comprising:
  • reception means arranged to receive from the second security domain a request for activation of a second profile issued by the trusted entity, the request comprising an activation authorization token received from the first entity by the trusted entity, the second profile being associated with a second entity,
  • the invention also relates to a system for activating a second profile, comprising:
  • an entity of confidence comprising:
  • means for sending an authorization token request arranged to send an activation authorization token request to the first entity
  • means for sending an activation request for the second profile arranged to send the security module the activation request comprising the activation authorization token.
  • the invention also relates to a program on a data carrier and loadable in the internal memory of a security module, the program comprising code instructions for the implementation of the steps of the method according to the invention, when the program is executed on said module.
  • the invention also relates to a data carrier on which is recorded the computer program according to the invention.
  • FIG. 1 shows the steps of a method of activating a second profile in a security module, according to a first embodiment
  • FIG. 2 presents the steps of a method for activating a second profile in a security module, according to a second exemplary embodiment
  • FIG. 3 is a schematic representation of a security module, according to a first embodiment.
  • the invention applies to security modules conforming to GlobalPlatform specifications.
  • GlobalPlatform specifications are available in the document: "Specifications: GlobalPlatform Card Specifications v2.2.1 Public Release”.
  • the GlobalPlatform specifications describe components that make it possible to disregard a security module as a hardware device, through interfaces to access applications installed on the module.
  • the hardware device is a "UICC” card (or “Universal Integrated Circuit Card”), or “eUICC” (for "embedded”, or embedded).
  • An example of such cards is for example a "(U) SIM” card (for "(Universal) Suscriber Identity Module") inserted in a mobile terminal and used in mobile telephony.
  • a security module is structured into several logical security domains.
  • Security domains are disjoint and secure environments of the module.
  • a first security domain referred to as the Issuer Security Domain, or ISD
  • ISD Issuer Security Domain
  • the security domain of the transmitter comprises cryptographic primitives and keys specific to a transmitter for implementing these primitives.
  • the issuer is an entity external to the module that has the keys of the security domain of the issuer and therefore controls this domain.
  • Cryptographic primitives are intended to allow secure management of applications stored on the module. For example, these primitives are intended to control and secure installation, deletion, update, blocking, etc. operations, applications on the module, applications belonging to the module's transmitter or to the module. other application providers.
  • a security module may also include security domains that represent service providers on the module.
  • a service provider may thus own one or more security domains of a module.
  • Each security domain has its own cryptographic keys that can only be used by the service provider that owns the security domain.
  • a service provider can then address the security module, more precisely the security domain or domains it owns to install applications, delete them, block them, etc.
  • OTA over the air
  • the security module 10 conforms to the GlobalPlatform specifications presented briefly above and comprises a security domain of the transmitter, or ISD 10-1, controlled by a first entity 11.
  • This first entity 11 is for example a first mobile network operator.
  • the security module 10 also comprises a management security domain 10-2, denoted SMSD, controlled by an external management entity 12, denoted SM.
  • SMSD management security domain
  • SM management security domain
  • the SM management entity 12 owns the SMSD management domain 10-2; it holds cryptographic keys that allow it to address this domain, install data, applications, remove them, etc. Only the SM 12 entity is authorized to access and implement operations in the SMSD 10-2 domain.
  • the management security domain SMSD 10-2 can be addressed by the management entity SM 12 by means of an "OTA" (over the air) procedure, via the network of the first operator, owner of ISD 10-1.
  • the external entity SM 12 is deemed to be a neutral and trusted entity vis-à-vis any entity that may become the owner of the security domain of the ISD 10-1 transmitter.
  • the security module 10 is already in circulation, that is to say that it is already configured and assigned to a user (not shown in FIG. 1), and that it comprises a first active profile specific to the user and the first entity 11.
  • this active profile is called the active communication profile; it contains operational data identifying and authenticating the user with the first network.
  • Such data include, for example, a subscriber number, an authentication key, applications and information on cryptographic algorithms used when accessing this first network.
  • the communication profile data is shared with the first network. The profile is said to be active in the sense that this profile is systematically used by the terminal in which the module is inserted during access to the network. Thus, when the user uses his mobile terminal, the communications are established using the first network.
  • a second external entity 13 sends the management entity SM 12 a request to take control of the security module 10.
  • This takeover request comprises a second communication profile, specific to the user. and the second entity 13.
  • This request is intended to indicate to the management entity SM 12 that the second entity 13 requests to take control of the security module 10, currently controlled by the first entity 11.
  • the control request is received by the management entity SM 12 in a step El.
  • the control request is consecutive for example to a request (not shown in FIG. 1) addressed to the second entity 13 by a user holding the security module 10.
  • the second entity 13 is a second network operator or an entity acting on behalf of a second network operator and the user, initially subscribed to the first operator, wishes to change network operator from the first network operated by the first operator to the second network operated by the second operator.
  • the management entity SM 12 sends a request for a first authorization token to the first entity 11.
  • the request for a first authorization token is intended to requesting the first entity 11 which controls the module 10, authorization to perform a specific action on the security module 10. More specifically, this action consists of the installation and activation of the second communication profile on the module 10.
  • the request for a first authorization token is received by the first entity 11 during step E3.
  • the first entity 11 In a step E4 for generating and sending the first authorization token, the first entity 11 generates and sends the first requested authorization token to the management entity SM 12.
  • the first token is received by the SM management 12 during step E5.
  • the first authorization token is data securely generated by the entity that controls the security module, in this case the first entity 11. This data is intended to authorize the execution of an action, here the installation and activation of the second communication profile on the module 10.
  • the first authorization token specifies the action for which an authorization was required.
  • the first token is generated by the first entity 11 because the request originates from the SM 12 entity, deemed to be trustworthy with respect to the first entity 11.
  • the generation of the first token is secured in the sense that cryptographic controls can to be carried out later to ensure the integrity of the first token, its source, and its contents.
  • a second profile installation request step E6 the management entity SM 12 sends the SMSD management security domain 10-2 a request for installation of the second profile which comprises the second profile and the first token of the second profile. authorization. It is recalled here that the management entity SM 12 owns the management security domain SMSD 10-2 and as such it is authorized to send information and requests to the management security domain SMSD 10-2. , for execution by this one. In the case of mobile telephony, this sending is done by means of an OTA procedure, via the first network. The installation request of the second profile is received by the SMSD management security domain 10-2 during a reception step E7.
  • a first token verification request step E8 the SMSD management security domain 10-2 sends the security domain of the ISD transmitter 10-1 a request to verify the first authorization token.
  • the request includes the first token.
  • the security domain of the ISD transmitter 10-1 receives and verifies the validity of the first token.
  • the security domain of the ISD transmitter 10-1 checks the integrity of the received authorization token, its origin and the content of the token. The integrity of the first token is verified using crypto-graphic procedures and data.
  • the first token is signed by the first entity 11 by means of a private key, and verified by the security domain of the ISD transmitter 10-1 by means of a public key associated with the key. private, at the disposal of the security domain of the ISD 10-1 transmitter.
  • the security domain of the transmitter 10-1 shares with the first entity 11 a secret key used by the first entity 11 to calculate a message "MAC" (Message Authentication Code). ) of the first token that is transmitted with the request to verify the first token.
  • the MAC message is then verified by the security domain of the ISD transmitter 10-1 according to a known method.
  • the security domain of the ISD transmitter 10-1 also checks the origin of the first token by checking a specific field of this data. Finally, the security domain of the transmitter 10-1 verifies the contents of the first token and ensures that the requested action is known.
  • step E10 the security domain of the ISD transmitter 10-1 sends to the management security domain SMSD 10-2 a message informing of the positive result of the verification. This message is received by the SMSD management security domain 10-2 during a reception step El 1.
  • the process stops.
  • the SMSD management security domain 10-2 creates a security sub-domain SSD2 (not shown in FIG. 1) and downloads therein. the second profile of the user received during the receiving step E7.
  • the SSD2 security subdomain is a child domain of the SMSD 10-2 management security domain. This parent relationship authorizes the SMSD management domain 10-2 to implement the download of the second profile that it has received from the management entity SM 12.
  • SMSD management security domain 10-2 detaches the SSD2 security subdomain. By this operation, the SMSD management security domain 10-2 cuts the parentage link that links it to the SSD2 subdomain.
  • the SSD2 security sub-domain is attached to the security domain of the ISD transmitter 10-1.
  • SSD2 security subdomain is a child of the security domain of the ISD 10-1 transmitter.
  • the security domain of the ISD 10-1 transmitter is arranged so that the security sub-domains detached from security domains are automatically attached to it.
  • the management entity SM 12 sends a request for a second authorization token to the first entity 11.
  • This second token is intended to request the security domain of the second entity.
  • ISD transmitter 10-1 to activate the second communication profile which has just been attached during the step El 4 attachment.
  • This request for a second authorization token is received during a step E16.
  • a step E17 of sending the second token the first entity 11 sends the management entity SM 12 the second authorization token.
  • the second token is received by the management entity SM 12 during a receiving step E18.
  • the management entity SM 12 sends the SMSD management security domain 10-2 a request to activate the second profile of the user.
  • This request includes the second token received in step E18. This request is received during the receiving step E20.
  • the SMSD management security domain 10-2 sends the security domain of the ISD transmitter 10-1 a request for verification of the second token.
  • This request includes of course the second authorization token.
  • the security domain of the ISD transmitter 10-1 receives and verifies the validity of the second token. As previously described, the security domain of the ISD transmitter 10-1 verifies the integrity of the second token, its origin, and the content of the token.
  • the security domain of the ISD transmitter 10-1 deactivates the first profile on the security module 10. stage, no communication profile is active on the mobile terminal in which is inserted the security module 10. The user can no longer access the network. At this stage, however, the first entity 11 still owns the security module 10 since it always shares the keys with the security domain of the ISD transmitter 10-1.
  • a second activation step E24 of the second profile the security domain of the ISD transmitter 10-1 activates the second communication profile of the user.
  • the second profile is active on the mobile terminal.
  • the security domain of the transmitter is always controlled by the first entity 11.
  • a next control transfer step E25 the control of the ISD security domain 10-1 is transferred from the first entity 11 to the second entity 13.
  • This step comprises several substeps which are not detailed in FIG.
  • the transfer involves a security domain of a control authority (not shown in FIG. 1) defined in the GlobalPlatform specifications.
  • the term usually used is the English term "Controlling Authority Security Domain", or "CASD”.
  • the control authority is a third external entity (not shown in Figure 1).
  • the security domain of the control authority is optional and is intended, when present, to reinforce the security policy of the security module 10.
  • the security domain of the supervisory authority comprises a key pair comprising a private key and an associated public key and a public certificate for certifying the public key associated with the private key.
  • the certificate is issued by a certification authority, following a prior secure procedure.
  • the public key and the private key can be used by services that implement security functions, for example an electronic signature service, a data encryption service, and so on.
  • the keys of the CASD are independent of the transmitter of the module 10 and represent the trusted third party entity.
  • the keys and the certificate are installed in the security domain of the control authority at the factory, for example by an inserter.
  • the management entity SM 12 informs the security domain of the ISD 10-1 transmitter that a transfer of control of the security domain of the ISD transmitter 10-1 is to be performed.
  • the security domain of the ISD transmitter 10-1 prepares the transfer by generating an authentication token, for example a random one, which it signs by means of a secret key of its own.
  • the second entity 13 calculates at least one new secret key intended to be installed in the security domain of the transmitter when effective taking control of the module 10.
  • the second entity 13 requests its certificate to the security domain of the CASD control authority.
  • the second entity 13 then encrypts, using the public key of the security domain of the CASD control authority, data comprising the new keys that it has calculated as well as the signed authentication token.
  • the second entity 13 sends the encrypted data to the security domain of the ISD transmitter 10-1. The latter then sends the encrypted data to the security domain of the CASD control authority, asking him to decrypt them.
  • the security domain of the CASD control authority decrypts the data using the private key associated with the public key used to encrypt the data and then sends the decrypted data to the security domain of the ISD transmitter 10-1. This checks the integrity of the authentication token included in the decrypted data. If the verification of the authentication token is positive, the security domain of the ISD transmitter 10-1 stores the new keys of the second entity 13 included in the decrypted data and erases all the keys initially stored, and specific to the first one. Entity 11. Thus, at the end of this transfer step E25, the control of the security module 10 is effectively transferred from the first 11 to the second entity 13.
  • the order of steps E23, E24 and E25 is different.
  • the transfer security control step E25 of the issuer security domain is implemented first.
  • the second entity 13 controls the security domain of the ISD transmitter 10-1.
  • the deactivation step E23 is then executed.
  • the security domain of the ISD transmitter 10-1 disables the first always active communication profile.
  • the activation step E24 of the second profile is executed and the second communication profile is activated in place of the first profile that has just been deactivated.
  • the security module 10 is controlled by the second entity 13. Moreover, the second entity 13 is thus assured that the second profile sharing with the user is not active in a security module that is controlled by another entity, which may be concurrent.
  • the step E25 for transferring control to the second entity 13 when the step E25 for transferring control to the second entity 13 is executed, then there is automatic deactivation of the first active profile, specific to the first entity 11, and automatic activation of the second profile, which is specific to the first entity. to the second entity 13. More specifically, before installing the cryptographic keys specific to the second entity 13 for the security domain of the ISD transmitter 10-1, there is deactivation of the first profile. After receiving the keys of the second entity 13 by the security domain of the ISD transmitter 10-1 through the first network, the module 10 activates the second profile. Both deactivation and activation operations are implemented by the module 10, during the transfer of the control. In this embodiment, mechanisms internal to the module 10 must be implemented so as to identify that the second profile is specific to the entity to which the control is transferred.
  • the first authorization token transmitted from the management entity 12 to the SMSD management security domain 10-2 plays the role of the first authorization token and the second authorization token.
  • the generation request of the first token, implemented by the trusted entity 12 during the step E2 is intended to ask the security domain of the ISD transmitter 10-1 to install the second one. communication profile and then activate it.
  • the steps E15 of requesting a second token E22 for receiving and verifying the second token, intended to request the activation of the second profile in the security module are not implemented. .
  • the deactivation of the first profile, implemented during step E23 and the activation of the second profile, implemented during step E24 are therefore executed after the installation of the second profile in the security module.
  • a single authorization token needs to be requested from the first entity 11, in this case the authorization authorization token of the second profile which corresponds to a request for authorization to activate. the second profile.
  • the second entity 13 sends the management entity SM 12 a request to take control of the security module 10.
  • the second profile is not passed in the request.
  • the takeover request is received during step El 01.
  • the SM management entity 12 sends an authorization token request to the first entity 11.
  • the token request is received in step E103. Steps E102 and E103 are identical to steps E2 and E3 according to FIG.
  • a step E104 for generating and sending the token the first entity 11 generates and sends the requested token to the management entity SM 12.
  • the authorization token comprises the action to be executed, in this case the activation of the second profile.
  • the authorization token is received by the management entity SM 12 during a step E105. Steps E104 and E105 are identical to steps E4 and E5 according to FIG.
  • a token sending step E106 the management entity SM 12 sends the authorization token it has received to the SMSD management security domain 10-2.
  • the token is received by the SMSD management domain 10-2 during a step E107.
  • the second profile is not sent to the SMSD management security domain 10-2.
  • a token verification request step E108 the SMSD management security domain 10-2 sends to the security domain of the ISD transmitter 10-1 a request to verify the authorization token. This step is identical to step E8 according to FIG.
  • a token receiving and verification step E109 the security domain of the ISD transmitter 10-1 receives and verifies the validity of the token. This step is identical to step E9 according to FIG.
  • This step is identical to the deactivation step E23 according to FIG.
  • step El 11 activation the security domain of the transmitter activates the second profile, specific to the user and the second entity 13. This step is identical to step E24 according to Figure 1.
  • a next transfer step El 12 comparable to the transfer step E25 according to FIG. 1, the control of the security domain of the ISD transmitter 10-1 is transferred from the first entity 11 to the second entity 13.
  • E110, El 11 and E112 are made in another order, in a manner comparable to that described in the first embodiment.
  • the first and second profiles are communication profiles, specific to mobile network operators. When a user wishes to access the network by means of his mobile terminal, he uses the only active communication profile to access the mobile network to which he subscribes. There are other types of profiles, suitable for other types of service than mobile telephony.
  • service profiles are called service profiles.
  • service profiles specific to "NFC" (Near Field Communication) applications service profiles specific to banking services, etc.
  • These service profiles include service-specific configuration data to which the user, holder of the mobile terminal is subscribed.
  • the different types of profiles are independent.
  • active profiles of different types, and independent of each other, can therefore coexist on the security module 10.
  • a profile that is active can be selected by the mobile terminal, and for example the NFC service profile can be selected by the mobile terminal in a near-field communication context for implementing one or more NFC services, independently of a communication service that allows the mobile terminal to access the mobile network via the operator to which the user is subscribed.
  • the deactivation step E23 according to FIG. 1, and El 10 according to FIG. 2 is optional.
  • the transfer step E25 according to Figure 1 and El 12 according to Figure 2 is optional. It may be requested by a service provider when it requests the activation of a service profile of its own but refused by the entity that controls the domain of the ISD 10-1 transmitter and whose profile is active. is a main profile.
  • a security module 10, able to implement the activation method of a second profile described above will now be described in connection with FIG. 3.
  • a security module designates a module capable of performing critical, sensitive operations in a secure environment. These operations are for example the storage of secret data, cryptographic operations, application installations, etc.
  • the security module 10 complies with the GlobalPlatform specifications and therefore comprises several logical security domains: a first security domain, or security domain of the ISD 10-1 transmitter,
  • SMSD management security domain 10-2 a second security domain, called the SMSD management security domain 10-2.
  • a security domain of a CASD control authority in one embodiment of the invention, a security domain of a CASD control authority.
  • the first domain comprises at least a first secret key specific to the first entity 11 which controls the security module 10 and is intended to secure the exchanges between the module 10 and external entities.
  • the SMSD management domain 10-2 comprises a second secret key specific to the management entity SM 12.
  • processor 101 or "CPU” (of the "Central Processing Unit"), or processing unit, intended to load instructions in memory, to execute them, to perform operations.
  • the processor 101 is connected to a set of memories:
  • ROM Read Only Memory
  • Security mechanisms such as, for example, cryptographic algorithms
  • RAM Random Access Memory
  • EEPROM for "Electrically erasable read-only memory
  • the programmable memory 104 stores the first and second secret keys of the security areas of the module 10.
  • the memory 104 also stores the profile or profiles.
  • the security module 10 also hosts an application in the form of a program, able to implement the activation method of a second profile in place of a first active profile according to the invention.
  • the security module 10 also comprises:
  • reception means 105 arranged to receive an activation request from the second profile sent by the trusted entity SM 12, the request comprising an authorization token received from the first entity 11 by the trusted entity SM,
  • verification means 106 arranged to check the authorization token. Checking a token consists of verifying the integrity of the token, its contents and its provenance. Verification of integrity is performed using procedures and cryptographic data,
  • the module 10 also comprises: means 108 for deactivating a profile, arranged to deactivate the first profile, and
  • the deactivation and transfer means 108 appear in dashed lines in FIG. 2.
  • the receiving means 106, 106 verification, 107 activation, 108 deactivation and transfer are preferably software modules comprising software instructions for executing the steps of the activation method of a second profile described above.
  • the invention therefore also relates to:
  • the software modules can be stored in, or transmitted by, a data carrier.
  • a data carrier This may be a hardware storage medium, for example a CD-ROM, a magnetic diskette or a hard disk, or a transmission medium such as a signal or a telecommunications network.
  • the software modules described above are installed by a manufacturer of security modules 10 in the EEPROM 104, before the equipment that embeds the module is marketed.
  • the means are installed by the module manufacturer in the ROM memory 102.
  • the program is downloaded to the equipment which embeds the module, after the equipment has been put into operation. in circulation. Such equipment is for example a mobile terminal.
  • the invention also relates to a system for activating a second communication profile.
  • This system comprises a security module 10 according to the invention, and a trusted entity SM 12.
  • the trusted entity SM 12 comprises:
  • means for sending a request for an authorization token arranged to send an authorization token request to the first entity
  • means for receiving the authorization token arranged to receive the authorization token, and means for sending an activation request for the second profile, arranged to send the security module the activation request comprising the authorization token.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé d'activation d'un deuxième profil, un premier profil actif étant mémorisé dans un module de sécurité (10), dans lequel le premier profil est associé à une première entité (11), le deuxième profil étant associé à une deuxième entité (13), le module de sécurité comprenant un premier domaine de sécurité (10-1) contrôlé par la première entité, le procédé comprenant les étapes suivantes, mises en œuvre par le module de sécurité : - une étape de réception (E20, E107) par un deuxième domaine de sécurité (10-2) d'une requête d'activation du deuxième profil émise par une entité de confiance (12), la requête comprenant un jeton d'autorisation d'activation reçu par l'entité de confiance en provenance de la première entité, - une étape de vérification (E22, E109) du jeton par le premier domaine de sécurité, - si la vérification est positive, une étape d'activation (E24, E111) du deuxième profil par le premier domaine de sécurité.

Description

Procédé d'activation d'un nouveau profil dans un élément de sécurité
L'invention concerne la gestion d'éléments de sécurité. Plus précisément, l'invention porte sur un procédé d'activation d'un nouveau profil dans un élément de sécurité.
L'invention trouve une application particulièrement intéressante dans des domaines tels que ceux de la téléphonie mobile, ou de la communication machine à machine (le terme habituellement utilisé pour désigner ce domaine est le terme « M2M », de l'anglais « Machine To Machine »). Dans ces domaines, des équipements comme un terminal mobile ou une machine équipée de capteurs embarquent un module de sécurité, par exemple une carte (U)SIM (de l'anglais « (Universal) Subscriber Identity Module »). Le module de sécurité peut être préconfiguré de manière à permettre un chargement ultérieur de données d'abonnement opérationnelles à un réseau de télécommunications, lors de l'attribution d'un tel module à un abonné. De telles données opérationnelles constituent un profil de communication d'abonné. Ainsi, un profil comprend des données de configuration, par exemple des données d'identification et d'authentifi cation d'un abonné auprès d'un réseau telles qu'un numéro d'abonné, une clé d'authentification et des applications et informations sur des algorithmes cryptographiques utilisés lors de l'accès au réseau. Ces données sont partagées avec le réseau.
Lorsqu'un abonné à un premier réseau opéré par un premier opérateur souhaite changer d'opérateur pour établir des communications dans un deuxième réseau opéré par un deuxième opérateur, il est nécessaire de mettre à jour l'élément de sécurité afin que le profil de l'abonné dans le deuxième réseau soit installé et activé dans le module de sécurité à la place du profil de l'abonné dans le premier réseau. Initialement, le profil de l'abonné dans le premier réseau est actif, c'est-à-dire que les données qu'il comprend lui permettent d'accéder au premier réseau. Au terme de la mise à jour, le profil dans le deuxième réseau est le profil actif, à la place du profil dans le premier réseau et permet à l'abonné d'accéder au deuxième réseau. Une première solution pour une telle mise à jour consiste à fournir à l'abonné un nouveau module de sécurité qui mémorise les données d'identification et d'authentification propres au deuxième réseau. Cependant, une telle solution est peu pratique, voire inacceptable dans le domaine du M2M où les modules de sécurité embarqués dans des machines sont parfois difficilement accessibles. Une autre solution consiste à faire une telle mise à jour une fois l'élément de sécurité mis en circulation dans le premier réseau. On parle alors de post-allocation.
Par exemple, la demande de la Demanderesse publiée sous le numéro WO2011001076 décrit un changement d'une première clé d'authentification et d'un premier numéro d'identification d'abonné sur une carte (U)SIM, propres à un premier opérateur de réseau opérant un premier réseau, par une deuxième clé d'authentification et un deuxième numéro d'identification d'abonné, propres à un deuxième opérateur opérant un deuxième réseau.
A cette fin, une clé maîtresse de génération de clés propre au deuxième réseau est mémorisée dans la carte lors d'une phase de pré-configuration réalisée avant la mise en service de la carte. Ainsi, lorsque la carte est mise en circulation pour fonctionner dans le premier réseau et qu'une demande de changement vers le deuxième opérateur est reçue, le deuxième opérateur transmet au premier opérateur un deuxième numéro d'identification d'abonné dans le deuxième réseau. Le premier opérateur transmet à la carte (U)SIM, à travers son réseau un aléa et le deuxième numéro d'identification d'abonné reçu, il envoie également l'aléa au deuxième opérateur de réseau. La carte génère ensuite une deuxième clé d'authentification en appliquant un algorithme de diversification de clés à l'aléa et à la clé maîtresse mémorisée dans la carte et propre au deuxième réseau. De son côté, le deuxième opérateur calcule la même clé d'authentification avec la même clé maîtresse qui lui est propre et l'aléa reçu du premier réseau. Le deuxième opérateur mémorise dans une base d'abonnés du réseau, la deuxième clé d'authentification en association avec le deuxième numéro d'identification d'abonné. Au terme du procédé, la première clé d'authentification est remplacée dans la carte par la deuxième clé d'authentification et le premier numéro d'identification d'abonné est remplacé dans la carte par le deuxième numéro d'identification d'abonné. La carte (U)SIM est alors prête à fonctionner dans le deuxième réseau.
Ainsi, il est possible de transmettre le contrôle d'un élément de sécurité d'un premier opérateur à un deuxième opérateur, une fois que l'élément de sécurité a été mis en circulation. Ce transfert peut être opéré sans que l'abonné ne change de module de sécurité ou n'intervienne manuellement sur ce module.
Cependant, une telle solution nécessite que l'on connaisse, initialement, c'est-à-dire lors de la configuration initiale du module de sécurité, l'ensemble des opérateurs susceptibles d'obtenir le contrôle de l'élément de sécurité. En effet, il est nécessaire de charger des clés maîtresses propres à chacun de ces opérateurs de réseau. Ainsi, il n'est pas possible de configurer le module pour un nouvel opérateur, inconnu lors de la configuration initiale du module.
Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations.
A cette fin, l'invention propose un procédé d'activation d'un deuxième profil, un premier profil actif étant mémorisé dans un module de sécurité dans lequel le premier profil est associé à une première entité, le deuxième profil étant associé à une deuxième entité, le module de sécurité comprenant un premier domaine de sécurité contrôlé par la première entité, le procédé comprenant les étapes suivantes, mises en œuvre par le module de sécurité :
- une étape de réception par un deuxième domaine de sécurité d'une requête d'activation du deuxième profil émise par une entité de confiance, la requête comprenant un jeton d'autorisation d'activation reçu par l'entité de confiance en provenance de la première entité,
- une étape de vérification du jeton par le premier domaine de sécurité,
- si la vérification est positive, une étape d'activation du deuxième profil par le premier domaine de sécurité.
Le procédé permet ainsi, dans le cadre de la téléphonie mobile d'activer un deuxième profil de communication d'abonné propre à un deuxième réseau, sans que l'utilisateur abonné ne change ou ne manipule son module de sécurité.
Ce mode d'activation est particulièrement intéressant dans le domaine de la communication machine à machine, ou M2M. En effet, dans ce domaine, un module de sécurité est inséré dans une machine qui est parfois très difficilement accessible. Dans ce contexte, l'activation d'un deuxième profil se fait à distance, sans intervention humaine sur la machine et de manière complètement transparente.
Par ailleurs, avec le procédé de l'invention, la demande d'activation est faite auprès d'une entité de confiance. Plus précisément, cette entité de confiance est neutre vis-à-vis de tout opérateur de réseau. En particulier, la demande d'activation n'est pas faite auprès de la première entité, par exemple le premier opérateur de réseau. Cette relation peut faciliter la collaboration entre opérateurs de réseau pour activer des modules de sécurité une fois ceux-là mis en circulation.
Le procédé utilise avantageusement le mécanisme de gestion déléguée, habituellement utilisé dans un module de sécurité pour charger des applications, les installer, les supprimer, les rendre sélectionnables. Ce mécanisme permet à un domaine de sécurité de demander au domaine de sécurité de l'émetteur ISD une autorisation d'exécuter une action. Cette autorisation est donnée par l'ISD sous forme d'un jeton d'autorisation. Selon l'invention, l'opération de demandée, ici l'activation du deuxième profil est mise en œuvre par le domaine de sécurité de l'émetteur.
Dans un exemple de réalisation, le deuxième profil est mémorisé par le module de sécurité. Une telle mémorisation peut être effectuée lors d'une phase de configuration du module, préalable à sa mise en circulation. Dans cet exemple de réalisation, le deuxième profil de communication n'a pas à être transmis par la deuxième entité, sous contrôle de la première entité. Dans le cas de la téléphonie mobile où la première et la deuxième entité sont un premier et un deuxième opérateur de réseau, on comprend que le deuxième opérateur peut souhaiter éviter que le deuxième profil soit transporté au moyen d'une procédure OTA via le réseau du premier opérateur. En effet, le profil comprend des données de sécurité sensibles qu'un opérateur souhaite maîtriser complètement.
Dans ce mode de réalisation, l'entité de confiance n'a besoin de demander qu'un jeton d'autorisation d' activation à la première entité pour Γ activation du deuxième profil. En effet, le deuxième profil est déjà mémorisé dans le module de sécurité et n'a donc pas besoin d'être installé.
Dans un autre exemple de réalisation, le procédé selon l'invention comprend en outre : - une étape de réception par le deuxième domaine de sécurité d'une requête d'installation du deuxième profil, la requête d'installation comprenant le deuxième profil et un jeton d'autorisation d'installation reçu par l'entité de confiance en provenance de la première entité,
- une étape de vérification du jeton d'autorisation d'installation par le premier domaine de sécurité,
- si la vérification est positive :
- une étape de création d'un sous-domaine de sécurité du deuxième domaine de sécurité, et de chargement dudit deuxième profil dans ledit sous-domaine,
- une étape de détachement du sous-domaine de sécurité, et
- une étape de rattachement du sous-domaine au premier domaine de sécurité.
Dans ce mode de réalisation, le deuxième profil est transmis par l'entité de confiance au domaine de sécurité de gestion en même temps qu'un jeton d'autorisation d'installation.
Dans un exemple de réalisation, le procédé comprend une étape de réception par la première entité d'une demande de jeton d'autorisation d'activation en provenance de l'entité de confiance.
C'est la première entité, qui contrôle le domaine de sécurité de l'émetteur, qui est ainsi apte à autoriser une deuxième entité à activer le deuxième profil. Cette autorisation est requise par la deuxième entité auprès de l'entité de confiance qui est neutre vis-à-vis de toute entité. L'entité de confiance relaie une demande légitime à la première entité.
Dans un exemple de réalisation où le deuxième profil est transmis au module de sécurité lors d'une requête de demande d'activation du deuxième profile la requête, le procédé d'activation comprend une étape de réception par la première entité d'une demande de jeton d'autorisation d'installation en provenance de l'entité de confiance. Ici encore, c'est l'entité de confiance qui est habilitée à demander auprès de la première entité l'installation du deuxième profil. Ainsi, cette opération est soumise également à autorisation et garantit ainsi l'intégrité du module de sécurité.
Selon un exemple de réalisation, le procédé comprend en outre une étape de désactivation du premier profil par le premier domaine de sécurité.
Dans cet exemple de réalisation, le deuxième profil est activé à la place du premier profil actif. Ainsi, un seul profil est actif sur le module de sécurité. Dans le cas où les premier et deuxième profils sont des profils de communication propres à des opérateurs de réseau, cela permet à l'utilisateur d'accéder au réseau de son choix lors de l'utilisation de son terminal mobile pour un accès au réseau.
Avantageusement, selon cet exemple de réalisation, le procédé comprend en outre une étape de transfert du contrôle du module de sécurité de la première à la deuxième entité, mise en œuvre par le module de sécurité.
Dans cet exemple de réalisation, le procédé de l'invention permet ainsi de transférer le contrôle d'un module de sécurité d'un premier opérateur à un deuxième opérateur de réseau, sans intervention manuelle sur le module de sécurité. En effet, lors de ce transfert de contrôle, le module de sécurité initialement configuré de manière à être opérationnel dans le deuxième réseau, suite à la désactivation du premier profil et l'activation du deuxième profil. Le transfert de contrôle garantit ainsi une cohérence au niveau du module de sécurité qui est ainsi contrôlé par le même opérateur que celui qui partage avec l'utilisateur le deuxième profil qui vient d'être activé.
L'invention concerne aussi un procédé de traitement d'une requête de prise de contrôle d'un module de sécurité par activation d'un premier profil, ledit premier profil étant associé à une première entité, le module de sécurité mémorisant un deuxième profil actif associé à une deuxième entité, le module de sécurité comprenant un premier domaine de sécurité contrôlé par la deuxième entité et un deuxième domaine de sécurité contrôlé par une entité de confiance, le procédé comprenant les étapes suivantes, mises en œuvre par l'entité de confiance :
- réception d'une requête de prise de contrôle du module de sécurité, en provenance de la première entité,
- envoi d'une demande de jeton d'autorisation à la deuxième entité,
- réception du jeton d'autorisation, en provenance de la deuxième entité,
- envoi du jeton d'autorisation au deuxième domaine de sécurité.
Le procédé de traitement d'une requête d' activation, mis en œuvre par l'entité de confiance, permet de mettre sur un même pied d'égalité la première et la deuxième entité. En effet, la requête d' activation, qui le cas échéant peut comprendre le nouveau profil à activer n'est pas directement transmise de la première à la deuxième entité, qui initialement contrôle le module de sécurité. Ainsi, il n'y a pas transmission de données potentiellement sensibles, telles que des clés secrètes d'authentification de la première à la deuxième entité. Avec le procédé de l'invention, l'entité de confiance est un intermédiaire entre la première et la deuxième entité. Cela confère au procédé un meilleur niveau de sécurité que des solutions existantes où un échange de données, potentiellement confidentielles intervient entre la première et la deuxième entité.
L'invention concerne aussi un module de sécurité, comprenant un premier domaine de sécurité contrôlé par une première entité et un deuxième domaine de sécurité, contrôlé par une entité de confiance, comprenant :
- des moyens de mémorisation d'un profil, agencés pour mémoriser au moins un premier profil, dit profil actif, ledit profil actif étant associé à la première entité,
- des moyens de réception, agencés pour recevoir du deuxième domaine de sécurité une requête d'activation d'un deuxième profil émise par l'entité de confiance, la requête comprenant un jeton d'autorisation d'activation reçu de la première entité par l'entité de confiance, le deuxième profil étant associé à une deuxième entité,
- des moyens de vérification, agencés pour vérifier le jeton,
- des moyens d'activation d'un profil, agencés pour activer le deuxième profil.
L'invention porte aussi sur un système d'activation d'un deuxième profil, comprenant :
- un module de sécurité selon l'invention, et
- une entité de confiance comprenant :
- des moyens d'envoi d'une demande de jeton d'autorisation, agencés pour envoyer une demande de jeton d'autorisation d'activation à la première entité,
- des moyens de réception du jeton d'autorisation, agencés pour recevoir le jeton d'autorisation d'activation, et
- des moyens d'envoi d'une demande d'activation du deuxième profil, agencés pour envoyer au module de sécurité la demande d'activation comprenant le jeton d'autorisation d'activation.
L'invention concerne également un programme sur un support de données et chargeable dans la mémoire interne d'un module de sécurité, le programme comprenant des instructions de code pour la mise en œuvre des étapes du procédé selon l'invention, lorsque le programme est exécuté sur ledit module.
L'invention concerne aussi un support de données sur lequel est enregistré le programme d'ordinateur selon l'invention. De nombreux détails et avantages de l'invention seront mieux compris à la lecture de la description d'un mode particulier de réalisation en référence aux dessins annexés donnés à titre non limitatif, et dans lesquels :
- la figure 1 présente les étapes d'un procédé d'activation d'un deuxième profil dans un module de sécurité, selon un premier exemple de réalisation ;
- la figure 2 présente les étapes d'un procédé d'activation d'un deuxième profil dans un module de sécurité, selon un deuxième exemple de réalisation ;
- la figure 3 est une représentation schématique d'un module de sécurité, selon un premier exemple de réalisation.
Les étapes d'un procédé d'activation d'un deuxième profil de communication, selon un premier exemple de réalisation vont maintenant être décrites en relation avec la figure 1.
L'invention s'applique à des modules de sécurité conformes aux spécifications GlobalPlatform. De telles spécifications sont accessibles dans le document : « Spécifications: GlobalPlatform Card spécifications v2.2.1 Public Release ». Les spécifications GlobalPlatform décrivent des composants qui permettent de faire abstraction d'un module de sécurité en tant que dispositif matériel, grâce à des interfaces permettant d'accéder à des applications installées sur le module. Le dispositif matériel est une carte « UICC » (de l'anglais « Universal Integrated Circuit Card »), ou « eUICC » (pour « embedded », ou embarquée). Un exemple de telles cartes est par exemple une carte « (U)SIM » (pour « (Universal) Suscriber Identity Module ») insérée dans un terminal mobile et utilisée en téléphonie mobile. Selon les spécifications GlobalPlatform, un module de sécurité est structuré en plusieurs domaines de sécurité logiques. Les domaines de sécurité constituent des environnements disjoints et sécurisés du module. Un premier domaine de sécurité, appelé domaine de sécurité de l'émetteur (le terme anglais « Issuer Security Domain », ou « ISD » est habituellement utilisé) est le principal domaine de sécurité du module. Il dispose par défaut de tous les privilèges pour agir sur le module de sécurité. Le domaine de sécurité de l'émetteur comprend des primitives cryptographiques et des clés propres à un émetteur permettant de mettre en œuvre ces primitives. L'émetteur est une entité externe au module qui possède les clés du domaine de sécurité de l'émetteur et qui contrôle donc ce domaine. Les primitives cryptographiques sont destinées à permettre la gestion sécurisée des applications stockées sur le module. Par exemple, ces primitives sont destinées à contrôler et sécuriser des opérations d'installation, de suppression, de mise à jour, de blocage, etc., d'applications sur le module, les applications appartenant à l'émetteur du module ou à d'autres fournisseurs d'applications. Dans le domaine de la téléphonie mobile, l'ISD est typiquement contrôlé par un opérateur de réseau mobile qui constitue l'entité externe, ou par une entité qui agit au nom d'un opérateur de réseau. A l'instar du domaine de sécurité de l'émetteur, un module de sécurité peut également comprendre des domaines de sécurité qui représentent des fournisseurs de services sur le module. Un fournisseur de services peut ainsi être propriétaire d'un ou de plusieurs domaines de sécurité d'un module. Chaque domaine de sécurité dispose de clés cryptographiques qui lui sont propres et qui ne peuvent être utilisées que par le fournisseur de services propriétaire du domaine de sécurité. Un fournisseur de services peut alors adresser le module de sécurité, plus précisément le ou les domaines de sécurité qu'il possède afin d'y installer des applications, les supprimer, les bloquer, etc. Dans le cas de la téléphonie mobile, de telles opérations peuvent être réalisées par le fournisseur de services au moyen d'une procédure « OTA » (de l'anglais « Over The Air »), via le réseau de l'opérateur propriétaire du domaine de sécurité de l'émetteur ISD.
Dans l'exemple de réalisation décrit ici, le module de sécurité 10 est conforme aux spécifications GlobalPlatform présentées succinctement précédemment et comprend un domaine de sécurité de l'émetteur, ou ISD 10-1, contrôlé par une première entité 11. Cette première entité 11 est par exemple un premier opérateur de réseau mobile. Le module de sécurité 10 comprend également un domaine de sécurité de gestion 10-2, noté SMSD, contrôlé par une entité externe de gestion 12, notée SM. Ainsi, conformément aux spécifications GlobalPlatform, l'entité de gestion SM 12 est propriétaire du domaine de sécurité de gestion SMSD 10-2 ; elle détient des clés cryptographiques qui lui permettent d'adresser ce domaine, y installer des données, des applications, les supprimer, etc. Seule l'entité SM 12 est habilitée à accéder et à mettre en œuvre des opérations dans le domaine SMSD 10-2. Dans le cas de la téléphonie mobile, le domaine de sécurité de gestion SMSD 10-2 peut être adressé par l'entité de gestion SM 12 au moyen d'une procédure « OTA » (de l'anglais « Over The Air »), via le réseau du premier opérateur, propriétaire de l'ISD 10-1. L'entité externe SM 12 est réputée être une entité neutre et de confiance vis-à-vis de toute entité susceptible de devenir propriétaire du domaine de sécurité de l'émetteur ISD 10-1.
On suppose qu'initialement, le module de sécurité 10 est déjà en circulation, c'est-à-dire qu'il est déjà configuré et attribué à un utilisateur (non représenté sur la figure 1), et qu'il comprend un premier profil actif propre à l'utilisateur et à la première entité 11. Dans le cas de la téléphonie mobile, ce profil actif est appelé profil de communication actif ; il contient des données opérationnelles d'identification et d'authentification de l'utilisateur auprès du premier réseau. De telles données comprennent par exemple un numéro d'abonné, une clé d'authentification, des applications et des informations sur des algorithmes cryptographiques utilisés lors de l'accès à ce premier réseau. Les données du profil de communication sont partagées avec le premier réseau. Le profil est dit actif dans le sens où ce profil est systématiquement utilisé par le terminal dans lequel le module est inséré lors d'un accès au réseau. Ainsi, lorsque l'utilisateur utilise son terminal mobile, les communications sont établies au moyen du premier réseau.
Dans une étape initiale E0, une deuxième entité externe 13 adresse à l'entité de gestion SM 12 une requête de prise de contrôle du module de sécurité 10. Cette requête de prise de contrôle comprend un deuxième profil de communication, propre à l'utilisateur et à la deuxième entité 13. Cette requête est destinée à indiquer à l'entité de gestion SM 12 que la deuxième entité 13 demande à prendre le contrôle du module de sécurité 10, actuellement contrôlé par la première entité 11. La requête de contrôle est reçue par l'entité de gestion SM 12 dans une étape El.
La requête de contrôle est consécutive par exemple à une demande (non représentée sur la figure 1) adressée à la deuxième entité 13 par un utilisateur détenteur du module de sécurité 10. Dans le cadre de la téléphonie mobile, la deuxième entité 13 est un deuxième opérateur de réseau ou une entité qui agit au nom d'un deuxième opérateur de réseau et l'utilisateur, initialement abonné auprès du premier opérateur, souhaite changer d'opérateur réseau et passer du premier réseau opéré par le premier opérateur au deuxième réseau opéré par le deuxième opérateur.
Dans une étape suivante E2 de demande d'un premier jeton, l'entité de gestion SM 12 envoie une demande d'un premier jeton d'autorisation à la première entité 11. La demande d'un premier jeton d'autorisation est destinée à demander à la première entité 11 qui contrôle le module 10, une autorisation pour exécuter une action déterminée sur le module de sécurité 10. Plus précisément, cette action consiste en l'installation et l'activation du deuxième profil de communication sur le module 10. La demande d'un premier jeton d'autorisation est reçue par la première entité 11 au cours de l'étape E3.
Dans une étape E4 de génération et d'envoi du premier jeton d'autorisation, la première entité 11 génère et envoie le premier jeton d'autorisation demandé à l'entité de gestion SM 12. Le premier jeton est reçu par l'entité de gestion SM 12 au cours de l'étape E5. Le premier jeton d'autorisation est une donnée générée de manière sécurisée par l'entité qui contrôle le module de sécurité, en l'espèce la première entité 11. Cette donnée est destinée à autoriser l'exécution d'une action, ici l'installation et l'activation du deuxième profil de communication sur le module 10. Ainsi, le premier jeton d'autorisation précise l'action pour laquelle une autorisation a été requise. Le premier jeton est généré par la première entité 11 car la demande émane de l'entité SM 12, réputée de confiance vis-à-vis de la première entité 11. La génération du premier jeton est sécurisée en ce sens que des contrôles cryptographiques peuvent être effectués ultérieurement de manière à s'assurer de l'intégrité du premier jeton, de sa provenance, et de son contenu.
Dans une étape E6 de requête d'installation du deuxième profil, l'entité de gestion SM 12 envoie au domaine de sécurité de gestion SMSD 10-2 une requête d'installation du deuxième profil qui comprend le deuxième profil et le premier jeton d'autorisation. On rappelle ici, que l'entité de gestion SM 12 est propriétaire du domaine de sécurité de gestion SMSD 10-2 et qu'à ce titre elle est autorisée à envoyer des informations et des requêtes au domaine de sécurité de gestion SMSD 10-2, pour exécution par celui-ci. Dans le cas de la téléphonie mobile, cet envoi est effectué au moyen d'une procédure OTA, via le premier réseau. La requête d'installation du deuxième profil est reçue par le domaine de sécurité de gestion SMSD 10-2 au cours d'une étape E7 de réception.
Dans une étape E8 de demande de vérification du premier jeton, le domaine de sécurité de gestion SMSD 10-2 envoie au domaine de sécurité de l'émetteur ISD 10-1 une demande de vérification du premier jeton d'autorisation. La demande comprend le premier jeton.
Dans une étape E9 de réception et de vérification du premier jeton, le domaine de sécurité de l'émetteur ISD 10-1 reçoit et vérifie la validité du premier jeton. Typiquement, le domaine de sécurité de l'émetteur ISD 10-1 vérifie l'intégrité du jeton d'autorisation reçu, son origine et le contenu du jeton. L'intégrité du premier jeton est vérifiée au moyen de procédures et de données crypto graphiques. Dans un exemple de réalisation, le premier jeton est signé par la première entité 11 au moyen d'une clé privée, et vérifié par le domaine de sécurité de l'émetteur ISD 10-1 au moyen d'une clé publique associée à la clé privée, à disposition du domaine de sécurité de l'émetteur ISD 10-1. Dans un autre exemple de réalisation, le domaine de sécurité de l'émetteur 10-1 partage avec la première entité 11 une clé secrète utilisée par la première entité 11 pour calculer un message « MAC » (de l'anglais « Message Authentication Code ») du premier jeton qui est transmis avec la demande de vérification du premier jeton. Le message MAC est ensuite vérifié par le domaine de sécurité de l'émetteur ISD 10-1 selon une méthode connue. Le domaine de sécurité de l'émetteur ISD 10-1 vérifie par ailleurs l'origine du premier jeton en contrôlant un champ spécifique de cette donnée. Enfin, le domaine de sécurité de l'émetteur 10-1 vérifie le contenu du premier jeton et s'assure que l'action demandée est connue.
Dans un cas où la vérification effectuée au cours de l'étape E9 est positive (branche Ok sur la figure 1), dans une étape E10 de réponse le domaine de sécurité de l'émetteur ISD 10-1 envoie au domaine de sécurité de gestion SMSD 10-2 un message informant du résultat positif de la vérification. Ce message est reçu par le domaine de sécurité de gestion SMSD 10-2 au cours d'une étape El 1 de réception. Dans un deuxième cas où la vérification est négative (branche « Nok » sur la figure 1), le procédé s'arrête.
Dans une étape E12 de création d'un sous-domaine de sécurité et de chargement du deuxième profil, le domaine de sécurité de gestion SMSD 10-2 crée un sous-domaine de sécurité SSD2 (non représenté sur la figure 1) et y télécharge le deuxième profil de l'utilisateur reçu au cours de l'étape E7 de réception. Le sous-domaine de sécurité SSD2 est un domaine fils du domaine de sécurité de gestion SMSD 10-2. Cette relation de filiation autorise le domaine de sécurité de gestion SMSD 10-2 à mettre en œuvre le téléchargement du deuxième profil qu'il a reçu de l'entité de gestion SM 12.
Dans une étape suivante E13 de détachement, le domaine de sécurité de gestion SMSD
10-2 détache le sous-domaine de sécurité SSD2. Par cette opération, le domaine de sécurité de gestion SMSD 10-2 coupe le lien de filiation qui le lie au sous-domaine SSD2.
Dans une étape suivante E14 de rattachement, le sous-domaine de sécurité SSD2 est rattaché au domaine de sécurité de l'émetteur ISD 10-1. Désormais, le sous domaine de sécurité SSD2 est un fils du domaine de sécurité de l'émetteur ISD 10-1. Le domaine de sécurité de l'émetteur ISD 10-1 est agencé pour que les sous-domaines de sécurité détachés de domaines de sécurité lui soit automatiquement rattachés.
Dans une étape suivante E15 de demande d'un deuxième jeton, l'entité de gestion SM 12 envoie une demande d'un deuxième jeton d'autorisation à la première entité 11. Ce deuxième jeton est destiné à demander au domaine de sécurité de l'émetteur ISD 10-1 d'activer le deuxième profil de communication qui vient de lui être rattaché au cours de l'étape El 4 de rattachement. Cette demande de deuxième jeton d'autorisation est reçue au cours d'une étape E16.
Dans une étape E17 d'envoi du deuxième jeton, la première entité 11 envoie à l'entité de gestion SM 12 le deuxième jeton d'autorisation. Le deuxième jeton est reçu par l'entité de gestion SM 12 au cours d'une étape E18 de réception.
Dans une étape E19 de demande d'activation du deuxième profil, l'entité de gestion SM 12 envoie au domaine de sécurité de gestion SMSD 10-2 une demande d'activation du deuxième profil de l'utilisateur. Cette demande comprend le deuxième jeton reçu au cours de l'étape E18. Cette demande est reçue au cours de l'étape E20 de réception.
Dans une étape E21 de demande de vérification du deuxième jeton, le domaine de sécurité de gestion SMSD 10-2 envoie au domaine de sécurité de l'émetteur ISD 10-1 une demande de vérification du deuxième jeton. Cette demande comporte bien sûr le deuxième jeton d'autorisation. Dans une étape E22 de réception et de vérification du deuxième jeton, le domaine de sécurité de l'émetteur ISD 10-1 reçoit et vérifie la validité du deuxième jeton. Comme décrit précédemment, le domaine de sécurité de l'émetteur ISD 10-1 vérifie l'intégrité du deuxième jeton, son origine et le contenu du jeton.
Dans un cas où la vérification est positive (branche Ok sur la figure 1), alors dans une étape E23 de désactivation, le domaine de sécurité de l'émetteur ISD 10-1 désactive le premier profil sur le module de sécurité 10. A ce stade, aucun profil de communication n'est actif sur le terminal mobile dans lequel est inséré le module de sécurité 10. L'utilisateur ne peut donc plus accéder au réseau. A ce stade, la première entité 11 est cependant encore propriétaire du module de sécurité 10 puisqu'elle partage toujours les clés avec le domaine de sécurité de l'émetteur ISD 10-1.
Dans une étape suivante E24 d'activation du deuxième profil, le domaine de sécurité de l'émetteur ISD 10-1 active le deuxième profil de communication de l'utilisateur. Au terme de cette étape, le deuxième profil est actif sur le terminal mobile. Ainsi, l'utilisateur peut désormais accéder au deuxième réseau. Cependant, au terme de cette étape E24, le domaine de sécurité de l'émetteur est toujours contrôlé par la première entité 11.
Dans un deuxième cas où la vérification est négative (branche Nok sur la figure 1), le procédé s'arrête.
Dans une étape suivante E25 de transfert du contrôle, le contrôle du domaine de sécurité ISD 10-1 est transféré de la première entité 11 à la deuxième entité 13. Cette étape comprend plusieurs sous-étapes qui ne sont pas détaillées sur la figure 1. Dans un exemple de réalisation, le transfert fait intervenir un domaine de sécurité d'une autorité de contrôle (non représenté sur la figure 1) défini dans les spécifications GlobalPlatform. Le terme habituellement utilisé est le terme anglais « Controlling Authority Security Domain », ou « CASD ». L'autorité de contrôle est une entité externe tierce (non représentée sur la figure 1). Le domaine de sécurité de l'autorité de contrôle est optionnel et est destiné, lorsqu'il est présent, à renforcer la politique de sécurité du module de sécurité 10. Le domaine de sécurité de l'autorité de contrôle comprend un couple de clés comprenant une clé privée et une clé publique associée ainsi qu'un certificat public destiné à certifier la clé publique associée à la clé privée. Le certificat est délivré par une autorité de certification, au terme d'une procédure sécurisée préalable. Une fois le certificat délivré, la clé publique et la clé privée peuvent être utilisées par des services qui mettent en œuvre des fonctions de sécurité, par exemple un service de signature électronique, un service de chiffrement de données, etc. Les clés du CASD sont indépendantes de l'émetteur du module 10 et représentent l'entité tierce de confiance. Les clés et le certificat sont installés dans le domaine de sécurité de l'autorité de contrôle en usine, par exemple par un encarteur. L'entité de gestion SM 12 informe le domaine de sécurité de l'émetteur ISD 10-1 qu'un transfert du contrôle du domaine de sécurité de l'émetteur ISD 10-1 doit être effectué. Le domaine de sécurité de l'émetteur ISD 10-1 prépare le transfert en générant un jeton d'authentification, par exemple un aléa, qu'il signe au moyen d'une clé secrète qui lui est propre. Il transmet ensuite ce jeton d'authentification signé à la première entité 11, qui le relaye à la deuxième entité 13. La deuxième entité 13 calcule au moins une nouvelle clé secrète destinée à être installée dans le domaine de sécurité de l'émetteur lors de la prise effective du contrôle du module 10. La deuxième entité 13 demande ensuite son certificat au domaine de sécurité de l'autorité de contrôle CASD. La deuxième entité 13 chiffre alors au moyen de la clé publique du domaine de sécurité de l'autorité de contrôle CASD des données comprenant les nouvelles clés qu'elle a calculées ainsi que le jeton d'authentification signé. La deuxième entité 13 envoie les données chiffrées au domaine de sécurité de l'émetteur ISD 10-1. Celui-ci envoie alors les données chiffrées au domaine de sécurité de l'autorité de contrôle CASD en lui demandant de les déchiffrer. Le domaine de sécurité de l'autorité de contrôle CASD déchiffre les données au moyen de la clé privée associée à la clé publique utilisée pour chiffrer les données puis envoie les données déchiffrées au domaine de sécurité de l'émetteur ISD 10-1. Celui-ci vérifie l'intégrité du jeton d'authentification compris dans les données déchiffrées. Si la vérification du jeton d'authentification est positive, le domaine de sécurité de l'émetteur ISD 10-1 mémorise les nouvelles clés de la deuxième entité 13 comprises dans les données déchiffrées et efface toutes les clés initialement mémorisées, et propres à la première entité 11. Ainsi, au terme de cette étape E25 de transfert, le contrôle du module de sécurité 10 est transféré de manière effective de la première 11 à la deuxième entité 13.
Dans une première variante de réalisation de l'invention, l'ordre des étapes E23, E24 et E25 est différent. Par exemple, l'étape E25 de transfert du contrôle du domaine de sécurité de l'émetteur est mise en œuvre en premier. Ainsi, au terme de cette étape, la deuxième entité 13 contrôle le domaine de sécurité de l'émetteur ISD 10-1. L'étape E23 de désactivation est ensuite exécutée. Ainsi, le domaine de sécurité de l'émetteur ISD 10-1 désactive le premier profil de communication toujours actif. Puis enfin, l'étape E24 d'activation du deuxième profil est exécutée et le deuxième profil de communication est activé à la place du premier profil qui vient d'être désactivé. Cette solution présente l'avantage que le domaine de sécurité de l'émetteur ISD 10-1 est contrôlé par la deuxième entité 13 lors de l'activation du deuxième profil. Ainsi, il y a une cohérence entre le contrôle de l'ISD 10-1 et le profil actif. Dès que le deuxième profil propre à la deuxième entité 13 est activé, le module de sécurité 10 est contrôlé par la deuxième entité 13. Par ailleurs, la deuxième entité 13 est ainsi assurée que le deuxième profil qu'elle partage avec l'utilisateur n'est pas actif dans un module de sécurité qui est contrôlé par une autre entité, qui peut être concurrente.
Dans une deuxième variante de réalisation, lorsque l'étape E25 de transfert du contrôle à la deuxième entité 13 est exécutée, alors il y a désactivation automatique du premier profil actif, propre à la première entité 11, et activation automatique du deuxième profil, propre à la deuxième entité 13. Plus précisément, avant d'installer les clés cryptographiques propres à la deuxième entité 13 pour le domaine de sécurité de l'émetteur ISD 10-1, il y a désactivation du premier profil. Après réception des clés de la deuxième entité 13 par le domaine de sécurité de l'émetteur ISD 10-1 à travers le premier réseau, le module 10 active le deuxième profil. Les deux opérations de désactivation et d'activation sont mises en œuvre par le module 10, lors du transfert du contrôle. Dans ce mode de réalisation, des mécanismes internes au module 10 doivent être mis en œuvre de manière à identifier que le deuxième profil est propre à l'entité à qui le contrôle est transféré.
Dans un autre exemple de réalisation (non représenté sur la figure 1), le premier jeton d'autorisation transmis de l'entité de gestion 12 au domaine de sécurité de gestion SMSD 10-2 joue le rôle du premier jeton d'autorisation et du deuxième jeton d'autorisation. Dans ce cas, la demande de génération du premier jeton, mise en œuvre par l'entité de confiance 12 au cours de l'étape E2 est destinée à demander au domaine de sécurité de l'émetteur ISD 10-1 d'installer le deuxième profil de communication, puis de l'activer. Ainsi, dans cet exemple de réalisation, les étapes E15 de demande d'un deuxième jeton à E22 de réception et de vérification du deuxième jeton, destinées à demander l'activation du deuxième profil dans le module de sécurité, ne sont pas mises en œuvre. La désactivation du premier profil, mise en œuvre au cours de l'étape E23 et l'activation du deuxième profil, mise en œuvre au cours de l'étape E24 sont donc exécutées après l'installation du deuxième profil dans le module de sécurité.
Dans un deuxième exemple de réalisation de l'invention, décrit en relation avec la figure 2, on suppose que le deuxième profil de communication est déjà mémorisé dans le module de sécurité 10.
Dans ce mode de réalisation, un seul jeton d'autorisation a besoin d'être demandé à la première entité 11, en l'espèce le jeton d'autorisation d'activation du deuxième profil qui correspond à une demande d'autorisation d'activer le deuxième profil.
Ainsi dans une étape initiale E100, comparable à l'étape E0 décrite en relation avec la figure 1, la deuxième entité 13 adresse à l'entité de gestion SM 12 une requête de prise de contrôle du module de sécurité 10. Ici, le deuxième profil n'est pas transmis dans la requête. La requête de prise de contrôle est reçue au cours de l'étape El 01. Dans une étape E102 de demande de jeton, l'entité de gestion SM 12 envoie une demande de jeton d'autorisation à la première entité 11. La demande de jeton est reçue au cours de l'étape E103. Les étapes E102 et E103 sont identiques aux étapes E2 et E3 selon la figure 1.
Dans une étape E104 de génération et d'envoi du jeton, la première entité 11 génère et envoie le jeton demandé à l'entité de gestion SM 12. Le jeton d'autorisation comprend l'action à exécuter, en l'espèce l'activation du deuxième profil. Le jeton d'autorisation est reçu par l'entité de gestion SM 12 au cours d'une étape E105. Les étapes E104 et E105 sont identiques aux étapes E4 et E5 selon la figure 1.
Dans une étape E106 d'envoi du jeton, l'entité de gestion SM 12 envoie le jeton d'autorisation qu'elle a reçu au domaine de sécurité de gestion SMSD 10-2. Le jeton est reçu par le domaine de gestion SMSD 10-2 au cours d'une étape E107. A la différence des étapes E6 d'envoi du deuxième profil et du premier jeton, et E7 de réception de ces données, le deuxième profil n'est pas envoyé au domaine de sécurité de gestion SMSD 10-2.
Dans une étape E108 de requête de vérification du jeton, le domaine de sécurité de gestion SMSD 10-2 envoie au domaine de sécurité de l'émetteur ISD 10-1 une requête de vérification du jeton d'autorisation. Cette étape est identique à l'étape E8 selon la figure 1.
Dans une étape E109 de réception et de vérification du jeton, le domaine de sécurité de l'émetteur ISD 10-1 reçoit et vérifie la validité du jeton. Cette étape est identique à l'étape E9 selon la figure 1.
Dans un cas où la vérification est positive (branche « ok » sur la figure 1), alors dans une étape El 10 de désactivation du premier profil, le domaine de sécurité de l'émetteur ISD 10-
1 désactive le premier profil de communication, propre à l'utilisateur et à la première entité 11.
Cette étape est identique à l'étape E23 de désactivation selon la figure 1.
Dans une étape suivante El 11 d'activation, le domaine de sécurité de l'émetteur active le deuxième profil, propre à l'utilisateur et à la deuxième entité 13. Cette étape est identique à l'étape E24 selon la figure 1.
Dans une étape suivante El 12 de transfert, comparable à l'étape de transfert E25 selon la figure 1, le contrôle du domaine de sécurité de l'émetteur ISD 10-1 est transféré de la première entité 11 à la deuxième entité 13.
Dans cet exemple de réalisation, il est possible également de prévoir que les étapes
E110, El 11 et E112 soient réalisées dans un autre ordre, de manière comparable à ce qui a été décrit dans le premier exemple de réalisation.
Dans un troisième exemple de réalisation, lorsqu'il y a activation du deuxième profil sur le module de sécurité 10, il n'y a pas désactivation systématique du premier profil actif. Ainsi, dans cet exemple, plusieurs profils actifs peuvent coexister sur le module de sécurité 10. Dans ce cas, on distingue un profil actif principal et un ou plusieurs profil(s) actif(s) secondaire(s). Le profil actif principal est celui qui appartient à l'entité qui contrôle le domaine de sécurité de l'émetteur ISD 10-1. Cet exemple trouve une application intéressante lorsque différents types de profils coexistent sur le module. Dans les modes de réalisation décrits précédemment, les premier et deuxième profils sont des profils de communication, propres à des opérateurs de réseau mobile. Lorsqu'un utilisateur souhaite accéder au réseau au moyen de son terminal mobile, celui-ci utilise le seul profil de communication actif pour accéder au réseau mobile auquel il est abonné. Il existe d'autres types de profil, adaptés à d'autres types de service que la téléphonie mobile. On qualifie ces profils de profils de service. Par exemple, il est possible de mémoriser sur le module 10 des profils de service propres à des applications « NFC » (de l'anglais « Near Field Communication »), des profils de service propres à des services bancaires, etc. Ces profils de service comprennent des données de configuration propres à des services auxquels l'utilisateur, détenteur du terminal mobile est abonné. On remarque que les différents types de profils sont indépendants. Plusieurs profils actifs de types différents, et indépendants les uns des autres, peuvent donc coexister sur le module de sécurité 10. Un profil qui est actif peut être sélectionné par le terminal mobile, et par exemple le profil de service NFC peut être sélectionné par le terminal mobile dans un contexte de communication en champ proche pour mettre en œuvre un ou des services NFC, indépendamment d'un service de communication qui permet au terminal mobile d'accéder au réseau mobile via l'opérateur auprès duquel l'utilisateur est abonné. Ainsi, dans le cas où plusieurs profils actifs peuvent coexister, l'étape de désactivation E23 selon la figure 1, et El 10 selon la figure 2, est optionnelle. De même, l'étape de transfert E25 selon la figure 1 et El 12 selon la figure 2 est optionnelle. Elle peut être demandée par un fournisseur de service lorsque celui-ci demande l'activation d'un profil de service qui lui est propre mais refusée par l'entité qui contrôle le domaine de l'émetteur ISD 10-1 et dont le profil actif est un profil principal.
Un module de sécurité 10, apte à mettre en œuvre le procédé d'activation d'un deuxième profil décrit précédemment va maintenant être décrit en relation avec la figure 3.
Par définition, un module de sécurité désigne un module apte à réaliser des opérations critiques, sensibles, dans un environnement sécurisé. Ces opérations sont par exemple le stockage de données secrètes, des opérations cryptographiques, des installations d'applications, etc.
Dans un exemple de réalisation, le module de sécurité 10 selon l'invention est conforme aux spécifications GlobalPlatform et comprend donc plusieurs domaines de sécurité logiques : - un premier domaine de sécurité, ou domaine de sécurité de l'émetteur ISD 10-1,
- un deuxième domaine de sécurité, appelé domaine de sécurité de gestion SMSD 10-2, et
- dans un mode de réalisation de l'invention, un domaine de sécurité d'une autorité de contrôle CASD.
Le premier domaine comprend au moins une première clé secrète propre à la première entité 11 qui contrôle le module de sécurité 10 et est destinée à sécuriser les échanges entre le module 10 et des entités externes. Le domaine de sécurité de gestion SMSD 10-2 comprend une deuxième clé secrète propre à l'entité de gestion SM 12. Ces domaines de sécurité sont des éléments logiques du module de sécurité 10. A ce titre ils ne sont pas représentés sur la figure 3. Ces domaines de sécurité logiques s'appuient sur :
- un processeur 101, ou « CPU » (de l'anglais « Central Processing Unit »), ou unité de traitement, destiné à charger des instructions en mémoire, à les exécuter, à effectuer des opérations. Le processeur 101 est relié à un ensemble de mémoires :
- une mémoire morte 102, ou « ROM » (pour « Read Only Memory »), adaptée pour mémoriser un système d'exploitation du module de sécurité 10, des mécanismes de sécurité, comme par exemple des algorithmes cryptographiques,
- une mémoire vive 103, ou « RAM » (pour « Random Access Memory »), utilisée pour exécuter des instructions de code, stocker des variables, etc.,
- une mémoire programmable et effaçable 104, ou « EEPROM » (pour « Electrically
Erasable Programmable Read Only Memory »), qui contient des éléments propres au détenteur du module de sécurité 10 et à l'utilisation qu'il est prévu de faire du module 10. Ainsi, la mémoire programmable 104 mémorise les première et deuxième clés secrètes des domaines de sécurité du module 10. La mémoire 104 mémorise également le ou les profils.
Le module de sécurité 10 héberge également une application sous forme de programme, apte à mettre en œuvre le procédé d'activation d'un deuxième profil à la place d'un premier profil actif selon l'invention. A cette fin, le module de sécurité 10 comprend également :
- des moyens 105 de réception, agencés pour recevoir une requête d'activation du deuxième profil émise l'entité de confiance SM 12, la requête comprenant un jeton d'autorisation reçu de la première entité 11 par l'entité de confiance SM,
- des moyens 106 de vérification, agencés pour vérifier le jeton d'autorisation. La vérification d'un jeton consiste à vérifier l'intégrité du jeton, son contenu et sa provenance. La vérification de l'intégrité est réalisée au moyen de procédures et de données cryptographiques,
- des moyens 107 d'activation d'un profil, agencés pour activer le deuxième profil. Selon un exemple de réalisation de l'invention, le module 10 comprend également : - des moyens 108 de désactivation d'un profil, agencés pour désactiver le premier profil, et
- des moyens 109 de transfert du contrôle du module de sécurité.
Les moyens 108 de désactivation et 109 de transfert apparaissent en pointillés sur la figure 2.
Les moyens 105 de réception, 106 de vérification, 107 d'activation, 108 de désactivation et 109 de transfert sont de préférence des modules logiciels comprenant des instructions logicielles pour faire exécuter les étapes du procédé d'activation d'un deuxième profil précédemment décrit.
L'invention concerne donc aussi :
- un programme d'ordinateur comportant des instructions pour la mise en œuvre du procédé d'activation d'un deuxième profil tel que décrit précédemment lorsque ce programme est exécuté par le module de sécurité 10 ;
- un support d'enregistrement lisible sur lequel est enregistré le programme d'ordinateur décrit ci-dessus.
Les modules logiciels peuvent être stockés dans, ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal ou un réseau de télécommunication.
Dans l'exemple de module 10 présenté à la figure 3, les modules logiciels décrits précédemment sont installés par un fabricant de modules de sécurité 10 dans la mémoire EEPROM 104, avant que l'équipement qui embarque le module ne soit commercialisé. Dans un deuxième exemple de réalisation, les moyens sont installés par le fabricant de modules dans la mémoire ROM 102. Dans un troisième exemple de réalisation, le programme est téléchargé sur l'équipement qui embarque le module, après que l'équipement ait été mis en circulation. Un tel équipement est par exemple un terminal mobile.
L'invention concerne également un système d'activation d'un deuxième profil de communication. Ce système comprend un module de sécurité 10 selon l'invention, et une entité de confiance SM 12. A cette fin, l'entité de confiance SM 12 comprend :
- des moyens d'envoi d'une demande d'un jeton d'autorisation, agencés pour envoyer une demande de jeton d'autorisation à la première entité,
- des moyens de réception du jeton d'autorisation, agencés pour recevoir le jeton d'autorisation, et - des moyens d'envoi d'une demande d'activation du deuxième profil, agencés pour envoyer au module de sécurité la demande d'activation comprenant le jeton d'autorisation.

Claims

REVENDICATIONS
1. Procédé d'activation d'un deuxième profil dans un module de sécurité (10), un premier profil actif étant mémorisé dans le module de sécurité , le premier profil étant associé à une première entité (11), le deuxième profil étant associé à une deuxième entité (13), le module de sécurité comprenant un premier domaine de sécurité (10-1) contrôlé par la première entité, le procédé comprenant les étapes suivantes, mises en œuvre par le module de sécurité :
- une étape de réception (E20, E107) par un deuxième domaine de sécurité (10-2) d'une requête d'activation du deuxième profil émise par une entité de confiance (12), la requête comprenant un jeton d'autorisation d'activation reçu par l'entité de confiance en provenance de la première entité, ledit jeton étant destiné à demander au premier domaine de sécurité l'activation du deuxième profil,
- une étape de vérification (E22, E109) du jeton par le premier domaine de sécurité,
- si la vérification est positive, une étape d'activation (E24, El 11) du deuxième profil par le premier domaine de sécurité.
2. Procédé selon la revendication 1, comprenant en outre :
- une étape (E7) de réception par le deuxième domaine de sécurité (10-2) d'une requête d'installation du deuxième profil, la requête d'installation comprenant le deuxième profil et un jeton d'autorisation d'installation reçu par l'entité de confiance en provenance de la première entité,
- une étape (E9) de vérification du jeton d'autorisation d'installation par le premier domaine de sécurité,
- si la vérification est positive :
- une étape (E12) de création d'un sous-domaine de sécurité du deuxième domaine de sécurité, et de chargement dudit deuxième profil dans ledit sous-domaine,
- une étape (El 3) de détachement du sous-domaine de sécurité, et
- une étape (E14) de rattachement du sous-domaine au premier domaine de sécurité.
3. Procédé selon l'une des revendications précédentes, comprenant en outre une étape (E103, E16) de réception par la première entité d'une demande de jeton d'autorisation d'activation en provenance de l'entité de confiance.
4. Procédé selon l'une des revendications 2 à 3, comprenant une étape (E3) de réception par la première entité d'une demande de jeton d'autorisation d'installation en provenance de l'entité de confiance.
5. Procédé selon l'une des revendications précédentes, comprenant en outre une étape de désactivation (E23, El 10) du premier profil par le premier domaine de sécurité.
6. Procédé selon la revendication précédente, comprenant en outre une étape (E25, El 12) de transfert du contrôle du module de sécurité de la première à la deuxième entité, mise en œuvre par le module de sécurité.
7. Procédé de traitement d'une requête de prise de contrôle d'un module de sécurité par activation d'un premier profil, ledit premier profil étant associé à une première entité (13), le module de sécurité mémorisant un deuxième profil actif associé à une deuxième entité (11), le module de sécurité comprenant un premier domaine de sécurité (10-1) contrôlé par la deuxième entité et un deuxième domaine de sécurité (10-2) contrôle par une entité de confiance (12), le procédé comprenant les étapes suivantes, mises en œuvre par l'entité de confiance (12) :
- réception d'une requête de prise de contrôle du module de sécurité, en provenance de la première entité (13),
- envoi d'une demande de jeton d'autorisation à la deuxième entité (11), ledit jeton étant destiné à demander au premier domaine de sécurité Γ activation du deuxième profil,
- réception du jeton d'autorisation, en provenance de la deuxième entité,
- envoi du jeton d'autorisation au deuxième domaine de sécurité.
8. Module de sécurité, comprenant un premier domaine de sécurité (10-1) contrôlé par une première entité (11) et un deuxième domaine de sécurité (10-2), contrôlé par une entité de confiance (12), comprenant :
- des moyens (104) de mémorisation d'un profil, agencés pour mémoriser au moins un premier profil, dit profil actif, ledit profil actif étant associé à la première entité,
- des moyens (105) de réception, agencés pour recevoir du deuxième domaine de sécurité une requête d'activation d'un deuxième profil émise par l'entité de confiance, la requête comprenant un jeton d'autorisation d'activation reçu de la première entité par l'entité de confiance, le deuxième profil étant associé à une deuxième entité (13),
- des moyens (106) de vérification, agencés pour vérifier le jeton, - des moyens (107) d'activation d'un profil, agencés pour activer le deuxième profil.
9. Système d'activation d'un deuxième profil, comprenant :
- un module de sécurité (10), selon la revendication 8, et
- une entité de confiance (12) comprenant :
- des moyens d'envoi d'une demande de jeton d'autorisation, agencés pour envoyer une demande de jeton d'autorisation d'activation à la première entité,
- des moyens de réception du jeton d'autorisation, agencés pour recevoir le jeton d'autorisation d'activation, et
- des moyens d'envoi d'une demande d'activation du deuxième profil, agencés pour envoyer au module de sécurité la demande d'activation comprenant le jeton d'autorisation d'activation.
10. Programme sur un support de données et chargeable dans la mémoire interne d'un module de sécurité, le programme comprenant des instructions de code pour la mise en œuvre des étapes du procédé d'activation d'un deuxième profil selon l'une des revendications 1 à 6, lorsque le programme est exécuté sur ledit module.
11. Support de données sur lequel est enregistré le programme d'ordinateur selon la revendication 10.
PCT/FR2013/051939 2012-08-20 2013-08-13 Procede d'activation d'un nouveau profil dans un element de securite WO2014029939A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1257876 2012-08-20
FR1257876A FR2994622A1 (fr) 2012-08-20 2012-08-20 Procede d'activation d'un nouveau profil dans un element de securite

Publications (1)

Publication Number Publication Date
WO2014029939A1 true WO2014029939A1 (fr) 2014-02-27

Family

ID=46963972

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2013/051939 WO2014029939A1 (fr) 2012-08-20 2013-08-13 Procede d'activation d'un nouveau profil dans un element de securite

Country Status (2)

Country Link
FR (1) FR2994622A1 (fr)
WO (1) WO2014029939A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220322090A1 (en) * 2021-04-02 2022-10-06 Vmware, Inc. System and method for establishing trust between multiple management entities with different authentication mechanisms

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN106031119B (zh) * 2014-08-13 2019-06-21 华为技术有限公司 一种安全域管理方法、装置及***

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090191857A1 (en) * 2008-01-30 2009-07-30 Nokia Siemens Networks Oy Universal subscriber identity module provisioning for machine-to-machine communications
WO2011001076A2 (fr) 2009-06-30 2011-01-06 France Telecom Procédé de changement d'une clé d'authentification

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090191857A1 (en) * 2008-01-30 2009-07-30 Nokia Siemens Networks Oy Universal subscriber identity module provisioning for machine-to-machine communications
WO2011001076A2 (fr) 2009-06-30 2011-01-06 France Telecom Procédé de changement d'une clé d'authentification

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
"3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Feasibility study on the security aspects of remote provisioning and change of subscription for Machine to Machine (M2M) equipment (Release 9)", 3GPP STANDARD; 3GPP TR 33.812, 3RD GENERATION PARTNERSHIP PROJECT (3GPP), MOBILE COMPETENCE CENTRE ; 650, ROUTE DES LUCIOLES ; F-06921 SOPHIA-ANTIPOLIS CEDEX ; FRANCE, no. V9.2.0, 22 June 2010 (2010-06-22), pages 1 - 87, XP050441986 *
BARRIGA L ET AL: "M2M Remote-Subscription Management", INTERNET CITATION, 2 May 2011 (2011-05-02), pages 1 - 6, XP002686983, Retrieved from the Internet <URL:http://www.ericsson.com/res/thecompany/docs/publications/ericsson_review/2011/m2m_remotesubscriptions.pdf> [retrieved on 20121112] *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220322090A1 (en) * 2021-04-02 2022-10-06 Vmware, Inc. System and method for establishing trust between multiple management entities with different authentication mechanisms
US11689924B2 (en) * 2021-04-02 2023-06-27 Vmware, Inc. System and method for establishing trust between multiple management entities with different authentication mechanisms
US20230336991A1 (en) * 2021-04-02 2023-10-19 Vmware, Inc. System and method for establishing trust between multiple management entities with different authentication mechanisms

Also Published As

Publication number Publication date
FR2994622A1 (fr) 2014-02-21

Similar Documents

Publication Publication Date Title
EP1687953B1 (fr) Méthode d&#39;authentification d&#39;applications
KR101618274B1 (ko) 복수의 액세스 제어 클라이언트를 지원하는 모바일 장치, 및 대응 방법들
EP2957086B1 (fr) Procédé de création d&#39;un profil dans un domaine de sécurité d&#39;un élément sécurisé
EP2767111B1 (fr) Procédé de transfert du contrôle d&#39;un module de sécurité d&#39;une première entité à une deuxième entité
EP3348085A1 (fr) Procédé de chargement d&#39;une clé virtuelle au sein d&#39;un terminal utilisateur et terminal utilisateur associé
US9578019B2 (en) Method and system for managing an embedded secure element eSE
CN105027493A (zh) 安全移动应用连接总线
FR2847756A1 (fr) Procede d&#39;etablissement et de gestion d&#39;un modele de confiance entre une carte a puce et un terminal radio
EP3014849B1 (fr) Procédé de changement de clé d&#39;authentification
EP3010175A1 (fr) Rejeu d&#39;un batch de commandes sécurisees dans un canal sécurisé
TWI469655B (zh) 電子存取用戶端之大規模散佈之方法及裝置
WO2011001076A2 (fr) Procédé de changement d&#39;une clé d&#39;authentification
EP3107030B1 (fr) Procede de deploiement d&#39;une application dans un domaine securise d&#39;un element securise
WO2014029939A1 (fr) Procede d&#39;activation d&#39;un nouveau profil dans un element de securite
EP3607765B1 (fr) Procédé d&#39;obtention d&#39;une commande relative à un profil d&#39;accès à un réseau
US11617086B2 (en) Loading security information with restricted access
EP3363178B1 (fr) Dispositif électronique comprenant un module sécurisé supportant un mode de gestion locale de configuration d&#39;un profil souscripteur
CN109818900B (zh) 一种数据管理***及应用服务器
FR3103987A1 (fr) Procede de securisation de flux de donnees entre un equipement de communication et un terminal distant, equipement mettant en oeuvre le procede
EP2911365B1 (fr) Procédé et système de sécurisation de transactions offertes par une pluralité de services entre un appareil mobile d&#39;un utilisateur et un point d&#39;acceptation
EP4362394A1 (fr) Elément sécurisé, terminal hôte associé, procédé de génération de certificat dans un élément sécurisé et programme d ordinateur associé
FR2980072A1 (fr) Procede d&#39;association d&#39;un dispositif portable

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: 13773280

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13773280

Country of ref document: EP

Kind code of ref document: A1