A METHOD FOR CONTROLLING REMOTELY THE PERMISSIONS AND RIGHTS OF A TARGET SECURE ELEMENT

Abstract

This invention relates to a method for controlling remotely the rights of a target secure element to an execute an operation, said target secure element being configured to load a profile image and to store a first set of at least one parameter indicating if the secure element is locked or unlocked and, in case it is locked, who is the locker of said secure element. The method is operated by an image delivery server, said method and comprises the following steps: receiving a second set of at least one parameter and an operation code OP defining a requested operation to be performed by the target secure element, receiving a profile image to be transmitted to the secure element; generating a security scheme descriptor (SSD) file adapted to bind the profile image with the target secure element and further comprising the second set of at least one parameter and the operation code OP; sending the received image profile and the associated security scheme descriptor (SSD) file to the target secure element.

Claims

1. A method for controlling remotely the rights of a target secure element to execute an operation, said target secure element being configured to load a profile image and to store a first set of at least one parameter indicating if the secure element is locked or unlocked and, in case it is locked, who is the locker of said secure element, the method being operated by an image delivery server, said method comprising the following steps: receiving a second set of at least one parameter and an operation code (OP) defining a requested operation to be performed by the target secure element, said second set of at least one parameter being adapted for controlling the rights to execute the requested operation by the target secure element depending on the result of a comparison between said first and second sets of parameters; receiving a profile image to be transmitted to the secure element; generating a security scheme descriptor (SSD) file adapted to bind the profile image with the target secure element and further comprising the second set of at least one parameter and the operation code (OP); sending the received image profile and the associated security scheme descriptor (SSD) file to the target secure element.

2. The method according to claim 1, wherein the first set of at least one parameter corresponds to a universally unique identifier UUID_L indentifying the locker of the target secure element.

3. The method according to claim 1, wherein the second set of at least one parameter comprises a universally unique identifier UUID_G indentifying a business owner.

4. The Method according to claim 1, wherein the second set of at least one parameter comprises a universally unique identifier UUID_R indentifying an image owner.

5. The method according to claim 1, wherein the operation code is adapted to code a requested operation from a group of at least two operations codes.

6. The method according to claim 5, wherein one of the operation code OP corresponds to an operation for a business owner to grant the rights to an image owner for conditionally loading an image into the secure element.

7. The method according to claim 5, wherein one of the operation code OP corresponds to the operation of locking an unlocked target secure element, the execution of this operation implying to set UUID_L value of the first set of parameter to a UUID_G value transmitted with the second set of parameter.

8. The method according to claim 5, wherein one of the operation code OP corresponds to the operation of unlocking a target secure element.

9. The method according to claim 5, wherein one of the operation code OP corresponds to the operation deleting at least a portion of data memorised by the target secure element.

10. The method according to claim 5, wherein one of the operation code OP corresponds to the operation of transferring the rights of a first business owner to a second business owner.

11. The method according to claim 1, wherein the security scheme descriptor (SSD) file comprises a Policy Control Function (PCF) certificate identifying securely the business owner for whom the profile image is provided.

12. The method according to claim 2, wherein the Policy Control Function (PCF) certificate is verified by the target secure element in order to know if the business owner associated to the certificate corresponds to the locker of the target secure element, the execution of the operation code (OP) being allowed in that case and not allowed otherwise.

13. The method according to claim 11, wherein the Policy Control Function (PCF) certificate comprises at least one parameter defining a validity period of said certificate.

14. The method according to claim 13, wherein the validity period is defined such that the date at which the verification is performed by the security element is not earlier than a timestamp date representative of the time at which the profile image was bound to the secure element and not older than an expiration date, said timestamp date and expiration date being transmitted together with the Policy Control Function (PCF) certificate.

15. The method according to claim 13, wherein the timestamp is signed by the image delivery server (403) with an ephemeral key known by the secure element in order to avoid the image owner to modify the profile image.

16. The method according to claim 13, wherein the timestamp is encrypted by the image delivery server with an ephemeral key known by the secure element in order to avoid the image owner to modify the profile image.

17. The method according to claim 15, wherein an asymmetric key pair comprising a public key and a secret key is allocated by the locker of the target secure element, the secret key being used to sign the Policy Control Function (PCF) certificate and the public key being transmitted to the target secure element for it to be able of verifying the said certificate.

18. (canceled)

19. An image delivery server comprising a first and a second hardware security module, adapted to control remotely the rights of a target secure element to execute an operation, configured to load a profile image and to store a first set of at least one parameter indicating if the secure element is locked or unlocked and, in case it is locked, who is the locker of said secure device, the image delivery server, being configured to: receive by the first hardware security module a second set of at least one parameter and an operation code (OP) defining a requested operation for changing the rights attributed to a target secure element, said second set of at least one parameter being adapted for controlling the rights to execute the requested operation by the target secure element depending of the result of a comparison between said first and second set of parameters; receive a profile image to be transmitted to the secure element; send by the first hardware security module to the second hardware security module the second set of parameters, the operation code OP and a signature generated by the second hardware security module using as an input the second set of parameters and the operation code OP, said signature identifying the first hardware security manager as the sender; generate a security scheme descriptor (SSD) which is an encrypted file binding the profile image with the target secure element and comprising the second set of at least one parameter, the operation code (OP) and their associated signature, said file being decryptable by the target secure element; send the received image profile and the associated security scheme descriptor (SSD) file to the targeted secure element.

20. The image delivery server according to claim 19 further configured to: receive by the first hardware security module at least one credential uniquely associated to the secure element; verify by the first hardware security module the authenticity of the at least one received credential.

21. A secure element (400) configured to receive from an image delivery server (403) an image profile and an associated security scheme descriptor (SSD) associated to said image profile produced by the image delivery server by: receiving a second set of at least one parameter and an operation code (OP) defining a requested operation to be performed by the target secure element, said second set of at least one parameter being adapted for controlling the rights to execute the requested operation by the target secure element depending on the result of a comparison between said first and second sets of parameters; receiving a profile image to be transmitted to the secure element; generating a security scheme descriptor (SSD) file adapted to bind the profile image with the target secure element and further comprising the second set of at least one parameter and the operation code (OP); and sending the received image profile and the associated security scheme descriptor (SSD) file to the target secure element; and further configured to execute a requested operation OP transmitted with the associated security scheme descriptor depending of the result of a comparison between the first and second set of parameters.

22. A computer program storage medium storing instructions for instructing a computer to perform a method, comprising: receiving a second set of at least one parameter and an operation code (OP) defining a requested operation to be performed by the target secure element, said second set of at least one parameter being adapted for controlling the rights to execute the requested operation by the target secure element depending on the result of a comparison between said first and second sets of parameters; receiving a profile image to be transmitted to the secure element; generating a security scheme descriptor (SSD) file adapted to bind the profile image with the target secure element and further comprising the second set of at least one parameter and the operation code (OP); sending the received image profile and the associated security scheme descriptor (SSD) file to the target secure element.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Additional features and advantages of the invention will be more clearly understandable after reading a detailed description of one preferred embodiment of the invention, given as an indicative and non-limitative example, in conjunction with the following drawings:

[0038] FIG. 1 illustrates schematically the principle of a Primary Boot Loader and of a Profile Image;

[0039] FIG. 2 is provides a schematic representation of a PBL based telecommunications system;

[0040] FIG. 3 is an example of diagram providing rules for a secure element to check if it has to apply a command received from an Image Delivery Server;

[0041] FIG. 4 illustrates schematically how an image delivery server prepares and sends a profile image associated with a request for changing/granting the rights associated to a target secure element;

[0042] FIG. 5 illustrates an example of data flow between the secure element and the IDS server.

DETAILED DESCRIPTION

[0043] Herein under is considered a case in which the invention is supported by an Image Delivery Server (IDS) and an embedded secure element cooperating with an OEM device such as a Smartphone. However, it is only for exemplifying purposes and is not considered to reduce the scope of the present invention. The skilled person will understand that the invention is applicable, for example, to an Image Delivery Server and an embedded secure element cooperating with a machine-to-machine (M2M) device. More generally, the invention is applicable to any embedded/removable secure element which can be located into any kind of devices, a chip within a body card or a passport for example. The skilled person will also appreciate that the invention is applicable to a secure enclave, which is for example part of a System-On-Chip (SoC) design.

[0044] While the subject invention will now be described in detail with reference to the figures, it is done so in connection with the illustrative embodiments.

[0045] In the following description, numerous specific details are set forth. However, it is understood that embodiments may be practiced without these specific details. In other instances, well known circuits, structures and techniques have not been show in detail in order not to obscure the understanding of the description.

[0046] FIG. 1 illustrates schematically the principle of a Primary Boot Loader and of a Profile Image. The PBL solution behaves just like a card connector with a full card image (OS), called Profile Image (OS and Custom data), and loaded on an eSE chip 100.

[0047] This chip 100, which can be an embedded secure element (eSE) or a removable secure element (SE), is loaded at manufacturing with a secured firmware 101 called Primary Boot Loader (PBL).

[0048] The Profile Image 102 is securely downloaded through an IP/high-speed channel 103 and comprises for example the OS, OS customization including native code, the required algorithms and the profile personalization elements, including keys and applications.

[0049] In other terms, the Profile Image regroups as a bundle the following items: OS (including all customs and algorithms), applications, and the provisioning or operational profile parameters.

[0050] The one or several applications comprised in the profile can be for example: [0051] implementation of 3GPP requirements (3rd Generation Partnership Project), [0052] any MNO-specific mechanism (including the Network Authentication algorithms), [0053] features such as Digital Payment, Mobile Marketing, Transport, QoE, Mobile ID, Social Networks, back-up of End User data on the Cloud, [0054] any qualified third parties application.

[0055] The Profile Image is fully downloadable on a dedicated chip, which can be either on a soldered or removable packaging, provided that it has been certified. This requires a chip certification to be executed.

[0056] FIG. 2 provides a schematic representation of a PBL based telecommunications system.

[0057] This telecommunications system comprises a Profile Business owner 200 adapted to generate Profile Images (PI). These PI that can be designed, specified and validated in collaboration with an MNO (or an MVNO).

[0058] In order to ease the understanding of the role of the multiple actors involved in the ecosystem, the following definitions can be used: [0059] Business Owner: it is the one that has the lock of an eSE and which can grant rights to an Image Owner; [0060] Image Owner: it is the one selecting the OS and custom data/application of the full image profile. The Image owner purchases the Full Image Profile to an Image maker and is in charge of the business relationships to the user and the service providers. An Image Owner can be a Business Owner; [0061] Image Maker: it is the one building the full image profile (batch mode). The full image profile is encrypted with a set of ephemeral transport keys. The Image Maker receives the Input Files from the Image Owner and returns the Output Files to same Image Owner; [0062] Image Delivery Server: it is the server in charge to bind a full image profile and an eSE in generating the means for the eSE to access the ephemeral transport keys of the full image profile.

[0063] The Image owner 200 receives for example the input files provided by the legacy Operational Support System (OSS)/Business Support System (BSS) of the MNO and turns into a Profile Image. These Input Files can be generated in advance as in happens in the current process. Every image is encrypted with ephemeral transport keys. Images are sent by batches to the Image Delivery Server. The Image Maker generates the corresponding output files, in full compliancy with the IT systems currently in use by the MNO.

[0064] An Image Delivery Server 201, also designated with the acronym IDS, is required to process a packaged Profile Image and bundle/download it to the proper and unique destination UICC compatible chip deployed on the field.

[0065] The IDS binds Profile Images and an embedded/removable secure element associated to the same Part Numbers. A security scheme associated to a security architecture drives all operations. The IDS stores a repository of Profile Images, monitors and reports all operations for informing all involved actors.

[0066] Profile Images are received encrypted from the Image maker to a given IDS and exposes three parts: [0067] A manifest: describing the structure and the credentials related to the next parts. The manifest can be based on an XML meta-language. This part is not encrypted; [0068] A small encrypted file named SSD (Security Scheme Descriptor). This part is encrypted by a ephemeral transport key and contains all segment descriptors (location, size, decrypting key, integrity check); [0069] A binary file containing the encrypted segments of memory to load into the SE. This part is never decrypted by IDS; [0070] A certificate issued by the business owner for delegation; [0071] A certificate issued by the image owner for authentication.

[0072] The IDS can be operated by one of the following actors: [0073] The Business Owner, [0074] The OEM device maker, [0075] The Image Owner.

[0076] The IDS acts as the Image Logistician of the ecosystem. The Image Owner plays the role of services aggregator by contracting business agreement with service providers (SP).

[0077] A Service Provider (SP) as the MNO 204 plays their traditional role of connectivity provider, who provides access capability and communication services to its End Users through a mobile network infrastructure.

[0078] The Silicon Vendor 203 produces SE Chips. These chips will have to comply to a set of requirements making them compatible with the download of Profile Images and their installation into the chip thanks to the PBL loader. They will therefore have to be certified accordingly. The Silicon vendor will initialize the SE chip by loading the PBL firmware and the associated certified credentials.

[0079] The OEM 205 manufactures Consumer OEM Devices with communication capabilities for End Users 206.

[0080] A certificate Issuer 210 ensures the confidence of cross communications between all actors of the ecosystem.

[0081] A possible journey within our ecosystem can be illustrated as follow: [0082] The user selects the features of her application (e.g. the subscription of the MNO application) directly with an employee of a shop or from a portal of virtual store. The shop employee or the virtual store returns an activation code to the user. [0083] The user enters the activation code via an application named Connectivity Center into the OEM device. [0084] The OEM device connects the IDS with the activation code as a parameter. [0085] The SE via the Connectivity Center transfers its credentials to the IDS. [0086] The IDS matches the activation code and the user's record containing the profile of the image to select. [0087] The IDS extracts a full image profile related to the user's selection. [0088] The IDS reads the image profile manifest and extracts the SSD. [0089] The IDS computes, thanks an HSM, an ephemeral key KS3 and additional credentials (AC) from the SE credentials and from a certificate (CD) extracted from the manifest. [0090] The IDS transfers the SSD, AC and KS3 to an HSM which deduces the SSD transport key, decrypts the SSD, add the (AC) additional credentials and encrypt all previous data with KS3 then prefix the all with a header (H). [0091] The IDS inserts the new SSD into the full image profile which from now on ready for a download from the OEM device. [0092] The OEM device downloads the full image profile from the IDS. [0093] The full image profile manifest leads the Connectivity Center for loading the SSD and the binary file, segment after segment, into the secure element.

[0094] Profile Image design, validation and generation is handled by the Image maker from requirements of the Image Owner. Ordering process is still based on Image Owner sending Input Files (IF). Based on the IF, the Image maker 200 generates the Profile Images, stores them in the appropriate DB/repository, and sends back the Output Files to the image Owner 204.

[0095] The hardware supply chain is handled in two possible flows.

[0096] In a first possible flow, the secure element, manufactured by the Silicon Vendor 203, duly certified, and with PBL and key(s) on-board, is provided directly to the OEM 205 then receives the first Profile Image based on the process above.

[0097] In a second possible flow, the secure element is sourced by the Card Manufacturer 207, who loads an initial Profile Image that will be either delivered: [0098] to the OEM 205; [0099] or to the OEM 205 via the Image Owner 204; [0100] or to the Image Owner 204.

[0101] All the model's components such as Profile Image or secure elements are certified before being made available.

[0102] Such certification is performed prior to any possible use. The binding of a Profile Image with a secure element is, instead, a real-time operation.

[0103] FIG. 3 is an example of diagram providing rules for a secure element to check if it has to apply a command received from an Image Delivery Server.

[0104] In this description, a business owner designates an organisation that has the right to control a secure element by allowing operations, for example by locking it, unlocking it, and allowing it to load a Profile Image or other types of operation. As an example, a Service Provider is an MNO having a business agreement with an Image Owner. A business Owner subsidizes a plurality of user OEM devices. The Business Owner grants the permission rights of operations to the Image Owner.

[0105] An image owner designates an organisation to which the right to control a secure element, at least partially, has been delegated by a business owner.

[0106] According to this invention, there is proposed a method for controlling the right to perform operations into a secure element (embedded or removable) or the equivalent trusted execution environment operating within a System on Chip.

[0107] For example, a service provider is an MNO A, an Image Owner is an MNO B, a Business Owner is an MNO C which has subsidized the device purchased by the end-user. The delegation of rights, that is to say the remote control of rights and permissions of a target secure element, can be implemented using some of the following operations (not limited): [0108] loading an image of the code running into a secure element and containing the essential credentials for granting the access to a service such as the mobile communication. The secure element or the equivalent function is embedded in a portable/wearable device which may be subsidized a business owner; [0109] locking a blank secure element; according to one embodiment, this can be done only one time; [0110] unlocking a secure element from a business owner or from a delegation; according to one embodiment, this can be done only one time; [0111] transferring the business owner rights to a third party that will becomes the new business owner of the secure element; [0112] deleting the session means for reloading an Image Profile previously loaded. Then the secure element will definitively be not able to reload the Image Profile.

[0113] The proposed method can use three identifiers, one for the business owner, one for the image owner and one for the secure element.

[0114] In one embodiment, these identifiers are universally unique identifiers (UUID) type 3 such as defined in the request for comments RFC4122.

[0115] For example, the business owner (the giver) is dully identified by its UUID_G, the image owner (the receiver) is dully identified by its UUID_R and the secure element the Secure Element stores a given UUID namely the locker UUID_L.

[0116] A Profile Image is transmitted to the secure element together with a file called security scheme descriptor (SSD). In one embodiment, the SSD file comprises two operands and an operation code: [0117] UUID_G which is the first operand as a UUID and identifies the business owner; [0118] UUID_R which is the second operand as an UUID and identifies the image owner; [0119] OP which is the operation code.

[0120] The operation code is a message to be read by the secure element when receiving the Profile Image which indicates which operation is requested to the target secure element. This operation code can take for example five binary values corresponding for example to: [0121] Loading: in that case, a business owner grants the rights to an image owner for conditionally loading an image into the secure element; [0122] Locking: this operation can be used when the secure element is blank or unlocked. This operation code allows the set UUID_L to a UUID_G value. [0123] Unlocking: this operation code can be used when the secure element is locked or blank then it will switch to unlocked. This state can be persistent and irreversible [0124] Deleting: this command can be used when the secure element contains persistent data related to the prior loading session. The operation allows erasing the data related to a given session and preventing future tentative for reloading the session related image into the chip; [0125] Transferring: this command can be used for a business owner to transfer its rights to another business owner. The operation performs the following transfer UUID_L=UUID_R.

[0126] The secure element can accept an operation from an image owner if UUID_G is the same than the UUID_L.

[0127] Further, the secure element can accept an operation from any business owners if no UUID_L is present in the secure element. This can be the case for example if the secure element is blank. A blank secure element can store a UUID_L with a predefined value such as UUID_L=FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF.

[0128] This can also be the case if the secure element is unlocked, the UUID_L stored in the secure element being equal to a predefined value, for example UUID_L=00000000-0000-0000-0000-000000000000.

[0129] In another embodiment, the secure element can accept an operation from any business owners if the image contains the locker UUID_L and the evidence (a certificate or equivalent) which can be checked by the secure element before the operation.

[0130] According to one aspect of the invention, the server generating the image is able to check a pre-negotiated certificate from the business owner (the giver) for binding the said Profile Image with a secure element. The image owner (the receiver) brings with the image to bind, a certificate for given profile of images, a limited time and a given part number granting the binding and then checkable by the secure element.

[0131] The table below summarize the rules that can be applied by the secure element to determine whether or not the operation corresponding to the operation code should be allowed and therefore executed or rejected.

TABLE-US-00001 TABLE 1 rules to allow or reject an operation requested by the IDS to a target secure element UUID.sub.L UUID.sub.G UUID.sub.R Operation BLANK/UNLOCKED ANY ANY Allowed XXX XXX ANY Allowed XXX YYY ANY Rejected

[0132] Alternatively, the security scheme descriptor file comprises a Policy Control Function (PCF) certificate. This certificate is generated in order to identify securely the business owner for whom the profile image is provided. According to this embodiment, the rules to allow or reject an operation requested by the IDS to a target secure element can be defined as summarized in table 2.

TABLE-US-00002 TABLE 2 rules to allow or reject an operation requested by the IDS to a target secure element UUID.sub.L PCF Certificate UUID.sub.R Operation BLANK/ ANY ANY Allowed UNLOCKED XXX Signed by XXX ANY Allowed XXX Signed by YYY ANY Rejected

[0133] According to one aspect of the invention, the Policy Control Function (PCF) certificate is verified by the target secure element in order to know if the business owner associated to the certificate corresponds to the locker of the target secure element. The execution of the operation code (OP) is allowed in case of a positive verification and not allowed otherwise.

[0134] The Policy Control Function (PCF) certificate comprises for example at least one parameter defining a validity period of said certificate.

[0135] According to one aspect of the invention, the validity period is defined such that the date at which the verification is performed by the security element is not earlier than a timestamp date representative of the time at which the profile image was bound to the secure element and not older than an expiration date. The timestamp date and expiration date are transmitted together with the Policy Control Function (PCF) certificate.

[0136] In one embodiment of the invention, the timestamp is signed and/or encrypted with an ephemeral key know by the secure element by the image delivery server in order to avoid the image owner to modify the profile image.

[0137] As an example, an asymmetric key pair comprising a public key and a secret key can be allocated by the locker of the target secure element, the secret key being used to sign the Policy Control Function (PCF) certificate and the public key being transmitted to the target secure element for it to be able of verifying the said certificate.

[0138] FIG. 4 illustrates schematically how an image delivery server prepares and sends a profile image associated with a request for changing the rights associated to a target secure element.

[0139] According to one aspect of the invention, the image delivery server 403 comprises two hardware security servers 401, 402, a first one designated as HSM1 and a second one designated as HSM2. However, alternative architectures of the IDS can also be considered for this invention.

[0140] In this example, the HSM1 401 of the IDS 403 receives: [0141] the SE credentials containing the parameter UUID_L; [0142] the certificate from the business owner containing the parameters UUID_R and UUID_G as well as an operation code OP; [0143] the certificate from the image owner detailing the image profile and UUID_R.

[0144] The HSM (Hardware Security Module) 1 401 checks all certificates, checks the conditions of the delegations and computes an ephemeral key KS3 and a signature on the parameters UUID_R, UUID_G, the operation code OP. As an example, the electronic signature can be a keyed-hash message authentication code (HMAC). The parameters UUID_R, UUID_G, the operation code OP and a signature on these parameters and the ephemeral key KS3 and the means for the secure element to securely deduce KS3 are securely transferred to a second HSM2 402.

[0145] In an alternative embodiment, UUID_G and OP are transmitted to the IDS 403, without the need to transfer UUID_R. This can be the case if no transfer of right from the business owner identified by UUID_G is requested or need. For a transfer of right to another image owner, the identifier on this image owner UUID_R should be sent together with a UUID_G for the target secure element to be later in position to apply this change of rights.

[0146] In an alternative embodiment, UUID_G is equal to UUID_R informing about a self delegation or transfer of rights from a business owner to itself.

[0147] The second hardware security manager HSM2 402 then generates a security scheme descriptor (SSD) which is an encrypted file binding the Profile Image with the target secure element. An essential aspect of the invention is that this file comprises the parameters and the operation code defining the request for changing the rights associated to a target secure element. The SSD file is generated such that is can be decrypted by the target secure element only.

[0148] The security scheme descriptor (SSD) encrypted with an ephemeral transport key and the means for deducing the said ephemeral transport key are extracted from the image profile thanks some information in the manifest file, is transmitted to the HSM 2 402. The HSM 2 performs the following operations: [0149] Deduce the ephemeral transport key; [0150] Decrypt the SSD; [0151] Append to the SSD the parameters UUID_R, UUID_G, the operation code OP, and their signature; [0152] Encrypt the SSD with KS3 the ephemeral key generated by HSM1; [0153] Append to the SSD the means for the secure element to securely deduce KS3.

[0154] Once received by the secure element 400, the SSD file is decrypted by using the deduced ephemeral key KS3. The execution of the operation defined by OP is allowed or rejected by applying the rules of the Table 1 with the parameter UUID_R, UUID_G from the SSD and UUID_L from the secure element.

[0155] The aforementioned rights attributed to a secure element are for example related to the loading of Profile Images. However, the invention is not restricted to the loading of an Image Profile. For example, the rights attributed and/or modified thanks to the mechanism proposed by the invention are for example rights allowing or restricting any kind of software modification on the secure element and/or on the device.

[0156] If the operation requested by the business owner is a delegation of right, that to say a transfer of right to another image owner, thanks to the invention the Image Delivery Server 403 can report to the initial owner the number delegations of rights which have been granted to a new owner.

[0157] The IDS cannot accurately count the number of delegations in a distributed model where multiple IDS may operate on the behalf of the business owner; consequently a periodic report may constraint a business owner to perform a self control of the usage of the said certificate according to a contract.

[0158] The image owner negotiates with the business owner the delegation for one or several criteria among which: [0159] a given part number, [0160] a given number of images, [0161] a limited time, [0162] any other criteria useful to define the delegation.

[0163] Advantageously, the delegation supports the real-time constraints related to the instant generation of an image and its downloading into a device thanks an agnostic communication channel.

[0164] Another advantage is that the operations related to this delegation require a low power of computation in the secure element and in the HSM.

[0165] Additionally, the delegation supports a pre-negotiation of the terms of the granting between the business owner and the image owner. This advantage may avoid time consuming data exchanges between the IDS generating the bounded image profile and the business owner server.

[0166] FIG. 5 illustrates an example of data flow between the secure element and the IDS server.

[0167] It is assumed hereafter that all static keys are in the same ECC domain.

[0168] The ESE embeds the following long term credentials: [0169] CERT.PN.ECDSA: The certificate of the PN signed by the CI [0170] CERT.ESE.ECDSA: The certificate of the secure element signed by its silicon maker [0171] CERT.CI.ECDSA: The certificate of the Certificate Issuer [0172] SK.ESE.ECDSA: The private key of the ESE.

[0173] The IDS 201 embeds the following long term credentials: [0174] CERT.CI.ECDSA: The certificate of the Certificate Issuer [0175] CERT.PN.ECDSA: The certificate of the PN signed by the CI [0176] CERT.IDS.ECDSA: The certificate of the IDS for signature signed by the CI (Certificate Issuer) [0177] CERT.IDS.ECDSA: The certificate of the IDS for key agreement signed by the CI (Certificate Issuer) [0178] SK.IDS.ECDSA: The private key of the IDS for signature. [0179] SK.IDS.ECKA: The private key of the IDS for key agreement.
Preparation of the ESE credentials [0180] The ESE verifies CERT.IDS.ECKA by using CERT.CI.ECDSA [0181] The ESE generate an ephemeral couple of Diffie-Hellman keys as SK.ESE.ECDHE and PK.ESE.ECDHE which are respectively the private (SK) and the public (PK) key. [0182] The ESE signs a certificate CERT.ESE.ECDHE containing a code CODE-M (activation code sent by Image Owner), a transaction identifier (ID_TRANSAC) and the PK.ESE.ECDHE The ESE verifies the certificate CERT.IDS.ECKA by using CERT.CI.ECDSA [0183] The ESE computes the session key KS1 by deriving SK.ESE.ECDHE and CERT.IDS.ECKA [0184] The certificate of the ESE as CERT.ESE.ECDSA is encrypted by using KS1. The said certificate contains PN which is the Part Number of the ESE. M1 and CERT.ESE.ECDHE, CERT.PN.ECDSA are the credentials which may be used for getting a new image from the IDS.

Computation in the IDS

[0185] The ESE credentials are gathered by the IDS via any means (e.g. a MNO portal). [0186] KS1 is deduced by using SK.IDS.ECKA and CERT.ESE.ECDHE. [0187] The ESE certificate CERT.ESE.ECDSA is decrypted from M1 by using KS1 [0188] CERT.PN.ECDSA is verified by using CERT.CI.ECDSA [0189] The ESE certificate CERT.ESE.ECDSA is verified by using CERT.PN.ECDSA [0190] The IDS computes an ephemeral Diffie-Hellman keys pair as PK.IDS.ECDHE and SK.IDS.ECDHE [0191] The IDS computes a certificate CERT.IDS.ECDHE which includes ID_TRANSAC by using SK.IDS.ECDSA [0192] The IDS computes a session key KS2 by using SK.IDS.ECDSA and CERT.ESE.ECDHE [0193] The IDS derives the key KS1 by KS2 for getting KS3 (Perfect Forward Secrecy): KS3=SHA2(KS1,KS2) [0194] UUID_G, UUID_R and OP are append to the SSD [0195] The signature H_UUID=HMAC of UUID_G, UUID_R and OP by using KS2 is appended to the SSD [0196] The IDS can encrypt the SSD (Security Scheme Descriptor) by using KS3 and gets M2. [0197] A MANIFEST, CERT.IDS.ECDHE, CERT.IDS.ECDSA, M2 and the IMAGE can be transferred to the eSE via an URL from a server or any other means.

Computation in the eSE

[0198] The eSE gets from the IDS: M2, CERT.IDS.ECDHE and CERT.IDS.ECDSA [0199] The eSE verifies both certificates from CERT.CI.ECDSA (root certificate). [0200] The eSE computes KS2 by using PK.IDS.ECDHE, SK.ESE.ECDSA [0201] The eSE derives KS3 from KS2 and KS1 [0202] The eSE decrypts the SSD by using KS3. [0203] The eSE checks the signature H_UUID by using KS2

Structure of the SSD

[0204] The IDS runs two HSM in order to separate the liability and enforce a security policy where: [0205] HSM1: in charge to generate the KS3 ephemeral key, CERT.IDS.ECDHE and the integrity check H_UUID of the pair UUID_G and UUID_R by checking the certificate for delegation from the Business Owner and the certificate of the Image owner associated to the image profile; HSM1 is shared by all ESE makers [0206] HSM2: in charge to generate M2 as the encryption of the SSD by using KS3. HSM2 is shared by all Image Owners
The integrity check H_UUID generates by the HSM1 cannot be changed by HSM2 and the integrity of the couple UUID_G and UUID_R is checkable by the eSE.
The H_UUID is provided as the HMAC of the pair UUID_G, OP (Operation Code) and UUID_R by KS2. KS2 is not provided to HSM2 then this last one cannot forge a new H_UUID.