Method for exporting telecommunications profile from source secure element to target secure element and corresponding secure element

Abstract

The invention relates to a method for exporting a telecommunications profile from a source secure element (10) to a target secure element (13) by an LPA of a device comprising the source secure element and the target secure element (10, 13), the method comprising:-sending its certificate and at least a signed profile ID from the source secure element (10) to the target secure element (13); -verifying, at the target secure element (13), the validity of the certificate on the basis of the source certificate and the signature profile ID; if the verification is positive, sending a signed download request of the configuration file and a certificate of the target secure element (13) from the target secure element (13) to the source secure element (10); -at the source secure element (10), verifying the authenticity of the certificate of the target secure element (13), generating a profile encryption key PEK and a credential encryption key CEK; encrypting credentials of the profile with the CEK; -encrypting a profile comprising the encrypted credentials with the PEK; -encrypting the CEK and the PEK as a CEK and a PEK, respectively, with the public key of the target secure element (13); -sending the encrypted profile and PEK from the source secure element (10) to the target secure element (13); -at the target secure element (13), decrypting the received PEK with its private key to obtain a PEK, decrypting the configuration file with the PEK, and installing the configuration file; -sending a first signature message from the target secure element (13) to the source secure element (10) indicating that the configuration file has been successfully installed; -at the source secure element (10), when a first signature message indicating that the configuration file has been successfully installed is received, removing the configuration file and sending to the target secure element (13) a CEK and a second signature message with a private key of the source secure element (10) indicating that the configuration file in the source secure element (10) has been successfully removed; -at the target secure element (13), verifying the validity of the second signature message, decrypting the CEK to obtain the CEK, and decrypting the credential with the CEK.

Description

[0001] This invention relates to telecommunications, and more particularly to peer-to-peer transmission of profiles between two secure elements, such as an embedded SIM, also known as an embedded UICC (eUICC) or an integrated UICC (iUICC)).

[0002] Peer-to-peer transmission of configuration files is a feature not currently authorized by the GSMA RSP specification, but it has been shown that it can be accomplished in a proprietary manner.

[0003] This type of transmission can cause some problems.

[0004] The first question is how to provide some form of control over the transmission, or control by the profile owner. This transmission is reciprocal, not involving authorization or transmission from a remote server system. However, the first issue is how to provide control to the profile owner (MNO—the mobile network operator) to control, authorize, or deauthorize such transmissions, and how to authorize such transmissions under specific conditions. The MNO is issuing profiles for a given user and a given device with embedded security elements. In short, what conditions are provided by the profile owner who needs verification?

[0005] The second key point regarding transmission is ensuring its atomicity to prevent configuration file cloning while maintaining ease of use. Preventing cloning means avoiding the dual transmission of the same configuration file to two different devices and its activation on both devices. This must be absolutely prevented.

[0006] Another key point is to avoid losing configuration files while providing such anti-cloning systems.

[0007] In the known prior art (GSMA specification SGP21 V3.0), there are some protections in terms of authorization: rules are defined in the policy that mention whether to delete the configuration file or whether to activate the configuration file, but these rules are irrelevant to the transport.

[0008] The purpose of this invention is to provide solutions to these problems.

[0009] More specifically, the present invention provides the method according to claim 1 and the safety element according to claims 2 and 3.

[0010] The invention will be better understood by reading the following description, which uses only the accompanying drawings to illustrate the exchange between the source security element and the target security element (here, eUICC).

[0011] The entity represented is:

[0012] -Source eUICC 10

[0013] -LPA of source device 11

[0014] - LPA of target device 12

[0015] -Target eUICC 13

[0016] The source eUICC or the target eUICC can also be an iUICC.

[0017] The single accompanying diagram illustrates a flowchart of the exchange between these different entities.

[0018] The source eUICC 10 is the eUICC that stores the configuration file, and the target eUICC 13 is the eUICC that must download the configuration file from the source eUICC 10.

[0019] Globally, LPAs cannot be considered trusted entities. However, they are required to at least provide initial connectivity between eUICCs, and the LPAs there are merely there to pass profile packets between the source and target eUICCs. The connection of the LPA is labeled 20 in the attached diagram and can be accomplished via any connectivity, such as via telecommunications networks (4G, 5G, ...), Wi-Fi, Bluetooth, or even via a USB cable.

[0020] In order to transfer the configuration file, it must be ensured that the target eUICC 13 knows which configuration file was exported from the source eUICC 10.

[0021] Therefore, in the first step, indicated by reference numeral 21 in the attached figure, the source eUICC 10 exports its certificate, which has a signed list of the exportable configuration files it contains, and all of them are signed. This is the case where several configuration files exist at the level of the source eUICC 10. The source eUICC 10 may also contain only a single configuration file. This export is received by the LPA of the source device 11, and the user selects the available configuration file he / she wants to download in the target eUICC 13 (step 22).

[0022] At step 23, the target LPA provides the target eUICC 13 with a signature profile ID and source certificate selected by the user. The LPA is completely transparent here.

[0023] The target eUICC 13 (step 24) then verifies the validity of the source certificate based on the source certificate and the signing profile ID. Therefore, the target eUICC 13 is able to verify the certificate of the source eUICC 10 based on the GSMA certificate of the source eUICC 10, ensuring that the profile originates from a trusted source.

[0024] In configuration files provided based on user consent or user acceptance, in either case, the target eUICC 13 signs the configuration file to be downloaded (actually its ID). More precisely, the target eUICC 13 generates a signature request to download the selected configuration file (including the selected configuration file ID, the target eUICC 13 certificate, and eUICC 13 capabilities). At step 25, this request is sent to the source eUICC 10.

[0025] Therefore, at the end of this phase, we have mutually certified embedded source eUICC 10 and target eUICC 13. We also have a download configuration file request with at least a signature from the target eUICC 13.

[0026] Therefore, this type of transmission is very similar to the transmissions performed by eUICC and RSP systems. However, in the present invention discussed, the target eUICC 13 is communicating with another eUICC 10, and it must verify its certificate.

[0027] This transmission can be fully encrypted or unencrypted, depending on the configuration. Importantly, the response to a request from the target eUICC 13 to the source eUICC 10 for at least the download of the configuration file is signed by the target eUICC 13, allowing the source eUICC 10 to also verify the identity of the target eUICC 13.

[0028] The source eUICC 10 can be considered as a machine dedicated to distributing configuration files to different target eUICC 13 (it can store multiple configuration files and corresponding certificates).

[0029] From there, the source eUICC 10 can be used to verify the target eUICC 13 identity.

[0030] This step is implemented during step 26, where the source is eUICC 10:

[0031] - Verify the validity of the received request;

[0032] - Verify the certificate and authenticity of the target eUICC 13, and verify that the selected configuration file is in the exportable configuration file. This corresponds to the verification of the target eUICC 13's capabilities relative to the requested configuration file, to ensure that it can be correctly executed and installed on the target eUICC 13;

[0033] - Verify the eligibility of the target eUICC 13 installation for the selected configuration file;

[0034] - Generate the configuration file encryption key (PEK) and credential encryption key (CEK).

[0035] The generation of these two keys is a step that ensures the atomicity of transactions. One key (PEK) is used to encrypt the configuration file to ensure that only the target eUICC 13 can decrypt the configuration file and the credential encryption key CEK. The key CEK is dedicated to encrypting the long-term key of the configuration file to be exported (as well as other credentials such as oPC).

[0036] Then, source eUICC 10:

[0037] - Encrypt credentials with CEK (e.g., the long-term key K of eUICC 10).

[0038] - Decrease the remaining number of configuration file exports by 1. This is not a mandatory step;

[0039] - Encrypt the requested configuration file, including the encrypted credentials, using PEK;

[0040] - Encrypt CEK and PEK into CEK using the target certificate (the target certificate is a public key). and PEK .

[0041] In other words, the source eUICC 10 first encrypts the credentials with the CK key, then reduces the number of times the configuration file is exported, and finally encrypts the entire configuration file with the PEK key. Here, finally, we have the encrypted configuration file and the credentials encrypted with another key. The entire configuration file can then be exported.

[0042] The configuration file key is encrypted with the public key of the target eUICC 13, so that only the target eUICC 13 can decrypt it with its private key.

[0043] At step 27, the source eUICC 10 sends the entire encrypted configuration file (along with the credentials Ki, OPc, ri, ci used for the Milenage algorithm) and the encrypted key PEK to the target eUICC 13. .

[0044] At step 28, target eUICC 13:

[0045] - Decrypt the received PEK using its private key. To obtain PEK;

[0046] - Decrypt the received configuration file using the PEK. At this point, the credentials are still encrypted with the CEK key (credential encryption key), ensuring that even if the transaction terminates here for any reason, the target eUICC 13 cannot use the configuration file because the long-term key or the configuration file's credentials are still encrypted with the CEK. Encryption, and the target eUICC 13 is unaware of CEK. .

[0047] - Verify the validity of the received encrypted configuration file and verify that it corresponds to the configuration file ID selected by the user;

[0048] - If the decrypted configuration file is valid, install the configuration file and generate a signed installation state (SIS).

[0049] The next step for the target eUICC 13 is, once it has installed the configuration file and ensured its usability, to sign the installation status message acknowledgment and send it to the source eUICC 10. Now, when the source eUICC 10 receives it, it can be assured that the target eUICC 13 has correctly installed the configuration file and is operational. However, the only missing part is the credentials, which are still encrypted at the target eUICC 13's level.

[0050] At step 29, target eUICC 13 sends the SIS to source eUICC 10.

[0051] At step 30, source eUICC 10:

[0052] - Verify the validity of the SIS, and if the configuration file is successfully installed in the target eUICC 13, remove the stored configuration file depending on the configuration file publisher's policy;

[0053] - Generate a configuration file ID and CEK that include the removed configuration files. The certificate was removed because it was signed with its private key.

[0054] In other words, when the source eUICC 10 receives an acknowledgment from the target eUICC 13, it first verifies the message signature and then generates a CEK. The process involves removing the configuration file certificate (which contains the key to the encrypted credentials of the configuration file), and then removing the stored configuration file. This is done to ensure that the configuration file has been removed from the source eUICC 10 and that the certificate can be sent to the target eUICC 13. The target eUICC 13 can decrypt everything and use the decryption key to decrypt the credentials and use the configuration file. Here, the key question is: what might happen if the certificate is missing or lost? The invention also proposes optionally storing the certificate in the source device LPA 11 or the source UICC 10, so that it can be read or resent to the target eUICC 13. To ensure that even if the certificate is lost or not received by the target eUICC 13 during transmission, the target eUICC can still retrieve and activate it, because the message is simply the certificate plus the encrypted key, which remains in the context and is encrypted only with the target's public key, making it decryptable only by the target eUICC 13.

[0055] In step 31, the source eUICC 10 sends a signature removal certificate to the target eUICC 13.

[0056] At step 32, target eUICC 13:

[0057] - Verify the validity of the removed certificate;

[0058] - Decrypt CEK using its private key To obtain CEK;

[0059] - Use CEK to decrypt the configuration file credentials.

[0060] The target is eUICC 13, and then the configuration file credentials can be installed.

[0061] Remove configuration file certificate and CEK At that time, the target eUICC 13 can be copied to prove to the MNO that the subscription has not been copied.

[0062] Optionally, the metadata of the configuration file includes the following additional strategies:

[0063] - Is the configuration file exportable?

[0064] - It can still be exported a certain number of times;

[0065] -Which target eUICC version can receive the exported configuration file;

[0066] -What action should the source eUICC perform when the export is successful (delete configuration file, disable configuration file, etc.)?

[0067] - What action must the target eUICC perform to activate the configuration file (e.g., do nothing, or notify the remote server to transfer the data)?

[0068] Therefore, the configuration file can include additional fields in the metadata to authorize the transfer of the configuration file, the possible reduction in the number of transfers per transfer, allowing the target to transfer the configuration file to another eUICC. However, operators may want to customize this option and, for example, restrict it before downloading a new configuration file. Then, we can imagine other parameters that should be included in the metadata for actions, whether the transfer is successful or not, or in the case of an unsuccessful transfer. The LPA can store transfer audit information to know whether some configuration files have been correctly transferred to some eUICCs, etc.

[0069] Optionally, as mentioned above, the target LPA may also request the publisher or SM-DP+ to indicate or notify whether the transmission has been completed correctly.

[0070] The advantage is that we allow peer-to-peer transmission of MNO configuration file distribution control. This solution avoids the need for a remote server and then allows the MNO to have complete control over the transmission of configuration files, both offline and online.

[0071] As previously mentioned, LPA 11 can store removed certificates, making them available for auditing or resending to the target eUICC 13 if necessary.

[0072] The present invention also relates to a source security element 10 configured to export a telecommunications profile to a target security element 13 via an LPA of a device including the source security element 10 and the target security element 13, wherein the source security element 10 is configured to:

[0073] - Send its certificate and at least the signed profile ID to the target security element 13;

[0074] - Receive the signature download request for the configuration file and the certificate of the target security element 13 from the target security element 13;

[0075] - Verify the authenticity of the certificate of the target security element 13, and generate the configuration file encryption key PEK and the credential encryption key CEK;

[0076] - Encrypt the credentials for the configuration file using CEK;

[0077] - Encrypt the configuration file containing the encrypted credentials using PEK;

[0078] - Encrypt CEK and PEK into CEK using the target secure element 13 public key. and PEK ;

[0079] - Send the encrypted configuration file and PEK to the target secure element 13 ;

[0080] - Receive a first signature message from the target security element 13 indicating that the configuration file has been successfully installed;

[0081] - Remove the configuration file and send a CEK to the target security element 13. And a second signed message indicating that the configuration file in the source security element 10 has been successfully removed, containing the private key of the source security element 10.

[0082] Finally, the invention also relates to a target security element 13 configured to receive a telecommunications profile from the source security element 10 via an LPA of a device including the source security element 10 and the target security element 13, the security element being configured to:

[0083] - Receive its certificate and at least the signed profile ID from the source secure element 10;

[0084] - Verify certificate validity based on source certificate and signature profile ID;

[0085] - If the verification is positive, send a signature download request for the configuration file and the certificate for the target security element 13 to the source security element 10;

[0086] - Receive encrypted configuration file and key PEK from source secure element 10 ;

[0087] - Decrypt the received key PEK using its private key. To obtain the key PEK, use PEK to decrypt the configuration file, and then install the configuration file;

[0088] - Send a first signature message to the source security element 10 indicating that the configuration file has been successfully installed;

[0089] - Receive CEK from source safety element 10 And a second signed message containing the private key of source security element 10 indicating that the configuration file in source security element 10 has been successfully removed;

[0090] - Verify the validity of the second signed message and decrypt the CEK. Obtain the CEK and use the CEK to decrypt the credentials.

[0091] The advantages of this invention are:

[0092] - What was previously done in the SM-DP+ server is now done in LPA 11 and at the embedded eUICC 10 level;

[0093] - Mutual confirmation of transmissions ensures the atomicity of transactions. Certificates exist for deletion and activation from source to destination, as well as for activation of the key itself.

[0094] - The anti-cloning part is atomic, ensuring atomicity. The fact is, the credentials for the configuration file are encrypted with an additional key, which is a credential instruction key, different from the configuration file encryption key itself, and this is done in two steps, as we have already seen.

[0095] It does not require an internet connection to transfer configuration files.

[0096] One application of the invention is, for example, when a user has a profile on his smartphone and wants to transfer that profile to his connected watch for runtime.

[0097] All steps of this invention are performed by applets installed on the source and target devices.

Claims

1. A method for exporting a telecommunications profile from the source security element (10) to the target security element (13) via an LPA of a device including a source security element and a target security element (10, 13), the method comprising: - Send its certificate and at least the signature profile ID from the source security element (10) to the target security element (13); - The validity of the certificate is verified at the target security element (13) based on the source certificate and the signature profile ID; -If the verification is positive, send the signature download request for the configuration file and the certificate of the target security element (13) from the target security element (13) to the source security element (10); - At the source security element (10), verify the authenticity of the certificate of the target security element (13) and generate the configuration file encryption key PEK and the credential encryption key CEK; - Encrypt the credentials of the configuration file using CEK; - Encrypt the configuration file containing the encrypted credentials using PEK; - Encrypt CEK and PEK into CEK using the public key of the target security element (13). and PEK ; - Send the encrypted configuration file and the PEK from the source security element (10) to the target security element (13). ; - At the target security element (13), decrypt the received PEK with its private key. To obtain the PEK, use the PEK to decrypt the configuration file, and then install the configuration file; - Send a first signature message from the target security element (13) to the source security element (10) indicating that the configuration file has been successfully installed; - At the source security element (10), upon receiving the first signature message indicating that the configuration file has been successfully installed, the configuration file is removed, and a CEK is sent to the target security element (13). And a second signed message having the private key of the source security element (10) indicating that the configuration file in the source security element (10) has been successfully removed; - At the target security element (13), verify the validity of the second signature message and decrypt the CEK. Obtain the CEK and use the CEK to decrypt the credentials.

2. A security element referred to as a source security element (10), the security element being configured to export a telecommunications profile to the target security element (13) via an LPA of a device including the source security element and the target security element (10, 13), the source security element (10) being configured to: - Send its certificate and at least the signature profile ID to the target security element (13); - Receive the signature download request for the configuration file and the certificate of the target security element (13) from the target security element (13); - Verify the authenticity of the certificate of the target security element (13) and generate the configuration file encryption key PEK and the credential encryption key CEK; - Encrypt the credentials of the configuration file using CEK; - Encrypt the configuration file containing the encrypted credentials using PEK; - Encrypt CEK and PEK into CEK using the public key of the target security element (13). and PEK ; - Send the encrypted configuration file and the PEK to the target security element (13). ; - Receive a first signature message from the target security element (13) indicating that the configuration file has been successfully installed; - Remove the configuration file and send a CEK to the target security element (13). And a second signed message containing the private key of the source security element (10) indicating that the configuration file in the source security element (10) has been successfully removed.

3. A security element referred to as a target security element (13), the security element being configured to receive a telecommunications profile from the source security element (10) via an LPA of a device including a source security element and the target security element (10, 13), the security element being configured to: - Receive its certificate and at least the signature profile ID from the source security element (10); - Verify the validity of the certificate based on the source certificate and the signature configuration file ID; -If the verification is positive, send the signature download request for the configuration file and the certificate of the target security element (13) to the source security element (10); - Receive the encrypted configuration file and key PEK from the source security element (10). ; - Decrypt the received key PEK using its private key. Obtain the key PEK, use PEK to decrypt the configuration file, and install the configuration file; - Send a first signature message to the source security element (10) indicating that the configuration file has been successfully installed; - Receive CEK from the source security element (10) And a second signed message having the private key of the source security element (10) indicating that the configuration file in the source security element (10) has been successfully removed; - Verify the validity of the second signed message and decrypt the CEK. Obtain the CEK and use the CEK to decrypt the credentials.

Images