Provisioning of a subscription profile

Abstract

Methods, devices, a computer-readable storage medium (4412), and a computer program (2214) to provision a subscription profile A first message is received by a communication device (306), CD, from a provisioning server (302), PS, which includes a PS cryptographic certificate certSM-DP+, a first PS signature based on at least a PS ephemeral public key ephPKSM-DP+, and the PS ephemeral public key ephPKSM-DP+. A second message is sent to the PS from the CD which includes a CD ephemeral public key ephPKeUICC and a first CD signature based on at least the PS ephemeral public key ephPKSM-DP+. A third message is received by the CD from the PS, which includes an encrypted subscription profile and integrity protection data. The integrity of the third message is verified as a function of the integrity protection data to authenticate the PS. The encrypted subscription profile is then decrypted to reveal the subscription profile, which is then installed at the CD.

Description

[0001] PROVISIONING OF A SUBSCRIPTION PROFILE

[0002] TECHNICAL FIELD

[0003] The disclosure generally relates to methods for provisioning a subscription profile from a provisioning server to a communication device. Corresponding devices, a computer-readable storage medium, and a computer program are also disclosed.

[0004] BACKGROUND

[0005] GSMA has specified the architecture and protocol for eSIM provisioning. eSIM is the new way of storing and using SIM profiles in 3 GPP devices such as mobile phones. Instead of inserting a physical SIM card (i.e., UICC) holding the SIM profile into a device, eSIM makes it possible to download the SIM profile from a provisioning server (e.g., SM-DP+, SM-DP) onto an embedded UICC (eUICC), integrated UICC (iUICC), or integrated eUICC (ieUICC) on the device. eSIM is often referred to as iSIM in the case of ieUICC. For use in the present disclosure, the terms eSIM and eUICC refer to all variants described herein or as will otherwise be understood by those skilled in the art.

[0006] There are two main variants of eSIM in use today, consumer and M2M, each with separate functions and protocols. Additionally, GSMA has specified a third alternative, as discussed in GSMA SGP.31, “eSIM loT Architecture and Requirements”, Version 1.1, and GSMA SGP.32, “eSIM loT Technical Specification”, Version 1.0.1, which are aimed at constrained loT devices, making it possible to use eSIM with devices that do not support HTTPS but rather other means such as CoAP over DTLS. eSIM for loT builds on the consumer variant, but introduces a new component called eSIM loT remote Manager (elM) for remotely managing profiles of loT devices. In case of constrained loT devices, the elM can be an intermediary device between the loT device (with the eUICC) and the provisioning server (SM-DP+) assisting in the profile download. Acting as a proxy, the elM makes it possible to reuse the provisioning server (SM-DP+), including interactions using HTTPS, while the loT device with the eUICC uses a protocol stack suitable for constrained loT (e.g., CoAP over DTLS). The elM may either be a standalone entity, or it may be implemented by a device management entity such that the protocol stack for secure device management can also be leveraged for secure profile download and profile management. The SGP.32 provisioning flow 10 is shown in FIG. 1. Looking at the profile download communication triggered from the elM and SM-DP+, the device, to which both the eUICC 18 and the IP A 16 belong, needs to be involved in four round trips: initiating authentication 20 (steps 1 to 10), server and client authentication 22 (steps 11 to 14), download preparation 24 (steps 15 to 18), and profile download and installation result reporting 26 (steps 19 to 20). The SGP.32 provisioning flow 10 covers the case where an Activation Code (AC) is used to provide the address of the provisioning server 12 and an AC token, called Matching ID, to locate the prepared profile at the provisioning server 12. The AC may either be delivered to the loT device itself or to the elM 14. For constrained loT devices, the AC handling may be completely handled by the elM 14 to offload the loT device, as shown in FIG. 1.

[0007] Initial connectivity is one main challenge with eSIM, that is, how the eSIM can get connectivity in the first place to be provisioned with the SIM profile and obtain 3GPP connectivity. One suggested approach is that the eSIM come pre-installed with a provisioning profile for 3 GPP access, which can be used for initial connectivity needed for provisioning. Another suggested approach is, when the loT device has a secondary access interface (e.g., Wi-Fi), to use the secondary access interface to connect to a primary device that can provide global connectivity to the loT device for eSIM provisioning.

[0008] In GSMA SGP.32, “eSIM loT Technical Specification,” there is the possibility for the elM to send signed messages (e.g., eUICC Packages) containing profile state management operations (PSMOs) and elM configuration operations (eCOs) to the eUICC. Examples of such messages are: enable profile, disable profile, delete profile, add elM, and delete elM. The signed messages are introduced to protect against potential malware residing in the device that may perform an unauthorized change of an active profile or delete a profile. The signed messages are also protected against replay attacks. The eUICC provides signed response messages and stores the elM public key or elM certificate and highest counter value seen by the eUICC for use in verifying the signed messages.

[0009] The GSMA-specified solutions are for use cases with semi-constrained loT devices. However, eSIM can be available in even more constrained devices, particularly very low power constrained loT devices such as smart fabrics, where any extra communication is reducing the utility of the loT device supporting eSIM. Consequently, there is a need for an improved profile download approach with fewer roundtrips and involving less data transmitted over the possibly constrained network between the loT device and the elM.

[0010] US 2023 / 0164542 Al discloses a method for transmitting a subscription profile from an MNO to a secure element. Accordingly, while these methods have been made and used, it is believed that no one prior to the inventors has made or used an invention as described herein.

[0011] SUMMARY

[0012] An object of the disclosed embodiments is to improve the optimization of power consumption due to communication in a communication system, in particular with respect to provisioning of a subscription profile. A first embodiment of the disclosed technology includes a method for installing a subscription profile from a provisioning server, PS, to a subscriber module of a communication device, CD, the subscriber module having a CD cryptographic certificate associated with a CD public / private key pair and comprising a subscriber module identifier, and the PS having a PS cryptographic certificate associated with a PS public / private key pair. The method comprises receiving, by the CD, a first message, wherein the first message includes the PS cryptographic certificate, a first PS cryptographic signature, and a PS ephemeral public key of a PS ephemeral key pair; and wherein the first PS cryptographic signature has been created using a PS private key of the PS public / private key pair and is based on at least the PS ephemeral public key. Additionally, the method includes verifying, by the subscriber module, the PS cryptographic certificate and verifying, by the subscriber module, the first PS cryptographic signature using the PS cryptographic certificate. The method includes sending a second message toward the PS, the second message comprising a CD ephemeral public key of a CD ephemeral key pair and a first CD signature, wherein the first CD signature is generated by the subscriber module using the CD private key and is based at least on the PS ephemeral public key and the CD ephemeral public key, and wherein the CD ephemeral key pair is generated at the subscriber module of the CD and comprises a CD ephemeral private key and the CD ephemeral public key; receiving, by the CD, a third message, wherein the third message contains a subscription profile, wherein the subscription profile is encrypted using a second session key, and wherein the third message includes integrity protection data; verifying, by the subscriber module, the integrity of the third message as a function of the integrity protection data, wherein the PS is authenticated as a result of the verification; decrypting, by the subscriber module, the subscription profile using the second session key; and attempting, by the subscriber module, to install the subscription profile.

[0013] A second embodiment is the method of the first embodiment, comprising determining, by the CD, whether to send or not send the CD cryptographic certificate as part of the second message, wherein the determining is based on whether the CD has information regarding availability of provisioning of the subscription profile via an intermediate entity eSIM loT remote manager, ERM, whether the ERM is capable of securely providing the CD cryptographic certificate to the PS according to information stored in the CD, and whether the CD is configured to avoid sending the CD cryptographic certificate whenever possible to reduce the number of transmitted bytes.

[0014] A third embodiment is the method of the first embodiment, comprising the CD sending the PS a further message indicating a result of the attempt to install the subscription profile.

[0015] A fourth embodiment is the method of the first embodiment, wherein the second message comprises an encrypted portion having a payload that is encrypted, the payload comprising the CD cryptographic certificate, and wherein the encrypted portion is encrypted by the subscriber module using a first session key.

[0016] A fifth embodiment is the method of the fourth embodiment, wherein the first session key is determined by the subscriber module as a function of the CD ephemeral private key and the PS ephemeral public key.

[0017] A sixth embodiment is the method of the first embodiment, wherein the second message comprises profile identifier information, and wherein the profile identifier information comprises one of a matching identifier, MID, an encrypted MID, and an indication that the MID is not used, wherein the encrypted MID is encrypted by the subscriber module.

[0018] A seventh embodiment is the method of the first embodiment, wherein the second session key is determined by the subscriber module as a function of the CD ephemeral private key and the PS ephemeral public key.

[0019] An eighth embodiment is the method of the first embodiment, wherein the sending and receiving steps each comprise sending information via an eSIM loT remote manager, ERM, the method comprising, before receiving the first message, establishing a secure and authenticated connection between the ERM and the PS, and sending a trigger to receive the first message; wherein receiving the first message comprises receiving, by the ERM, the first message through the secure and authenticated connection, verifying, by the ERM, the PS cryptographic certificate; verifying, by the ERM, the first PS cryptographic signature using the PS cryptographic certificate; and if the two verification steps by the ERM are successful, forwarding the first message to the CD.

[0020] A ninth embodiment is the method of the eighth embodiment, wherein the ERM comprises a database that is configured to store one or more CD certificates, wherein sending the second message, when the second message does not contain an encrypted portion having a payload comprising the CD cryptographic certificate, comprises obtaining the CD cryptographic certificate from the database; and adding the encrypted portion to the second message, the encrypted portion comprising the CD cryptographic certificate, wherein the encrypted portion is encrypted using a third session key.

[0021] A tenth embodiment is the method of the ninth embodiment wherein the third session key is generated using an ERM ephemeral private key and the PS ephemeral public key, wherein an ERM ephemeral key pair is generated by the ERM and comprises the ERM ephemeral private key and an ERM ephemeral public key.

[0022] An eleventh embodiment is the method of the tenth embodiment, wherein the second message comprises the ERM ephemeral public key. A twelfth embodiment is the method of the tenth embodiment, comprising, before receiving the first message, but after establishing a secure and authenticated connection between the ERM and the PS, sending the ERM ephemeral public key to the PS as the trigger to receive the first message, wherein the first message comprises a second PS cryptographic signature generated by the PS using the PS private key and is based on the ERM ephemeral public key; and wherein receiving the first message comprises verifying, by the ERM, the second PS cryptographic signature using the PS cryptographic certificate.

[0023] A thirteenth embodiment is the method of the twelfth embodiment, wherein the ERM has a public / private key pair, and wherein the ERM public key of the ERM public / private key pair is stored in the subscriber module, comprising, after establishing a secure and authenticated connection between the ERM and the PS and before forwarding the first message to the CD, adding, by the ERM, a first ERM signature to the first message, wherein the first ERM signature is generated by the ERM using the ERM private key of the ERM public / private key pair, and said generation is based further on the PS ephemeral public key; and verifying, by the subscriber module, the first ERM signature using the ERM public key.

[0024] A fourteenth embodiment is the method of the eighth embodiment, wherein profile identifier information comprises at least one of a matching identifier, MID, an encrypted MID, and an indication that MID is not used, and wherein the second message comprises the profile identifier information, and wherein the encrypted MID is encrypted by the ERM.

[0025] A fifteenth embodiment is the method of the fourth or fifth embodiment, wherein at least the first CD signature and the profile identifier information of the second message are within the encrypted portion.

[0026] A sixteenth embodiment is the method of the first embodiment, wherein the integrity protection data in the third message comprises a cryptographic signature created by the PS using the PS private key based on at least the CD ephemeral public key, and wherein the PS is authenticated by the subscriber module by verifying the cryptographic signature using the PS public key.

[0027] A seventeenth embodiment is the method of the first embodiment, wherein the integrity protection data in the third message comprises a Message Authentication Code, MAC, created using a MAC key based on at least the CD ephemeral public key, and wherein the PS is authenticated by the subscriber module by verifying the MAC using the MAC key, wherein the MAC key is derived by the subscriber module from the CD private key and the PS public key.

[0028] An eighteenth embodiment is a communication device comprising a subscriber module, wherein the subscriber module is a UICC selected from an embedded UICC, eUICC, integrated UICC, iUICC, or integrated eUICC, ieUICC, the communication device being configured with programming instructions executable to implement the method of any one of the first through seventeenth embodiments.

[0029] A nineteenth embodiment of the disclosed technology includes a method for sending a subscription profile from a provisioning server, PS, to a subscriber module of a communication device, CD, the subscriber module having a CD cryptographic certificate associated with a CD public / private key pair, and the PS having a PS cryptographic certificate associated with a PS public / private key pair and comprising a PS database, the method comprising sending, by the PS, a first message toward the CD, wherein the first message includes the PS cryptographic certificate, a first PS cryptographic signature, and a PS ephemeral public key; where a PS ephemeral key pair comprises the PS ephemeral public key and a PS ephemeral private key; and wherein the first PS cryptographic signature is created by the PS using the PS private key and is based on at least the PS ephemeral public key. The method includes receiving, by the PS, a second message, the second message comprising a CD ephemeral public key, a first CD signature, profile identifier information, and an encrypted portion, wherein the first CD signature is created using the CD private key and is based on at least the PS ephemeral public key and the CD ephemeral public key; wherein the encrypted portion has a payload comprising the CD cryptographic certificate, and wherein the encrypted portion is encrypted using one of a first session key and a third session key. The method includes decrypting, by the PS, the encrypted portion using one of the first session key and the third session key to obtain the CD cryptographic certificate; verifying, by the PS, the CD cryptographic certificate and the first CD signature to authenticate the CD, wherein the verification of the first CD signature is performed using the CD cryptographic certificate; selecting, by the PS, the subscription profile to be provisioned based on the profile identifier information; and sending, by the PS, a third message toward the CD, wherein the third message contains the selected subscription profile; wherein the subscription profile is encrypted using a second session key; and wherein the third message includes integrity protection data.

[0030] A twentieth embodiment is the method of the nineteenth embodiment, comprising the PS receiving from the CD a further message indicating a result of the attempt to install the subscription profile.

[0031] A twenty-first embodiment is the method of the nineteenth embodiment, wherein the first session key is determined as a function of the PS ephemeral private key and the CD ephemeral public key. A twenty-second embodiment is the method of the nineteenth embodiment, wherein the second session key is determined as a function of the PS ephemeral private key and the CD ephemeral public key.

[0032] A twenty -third embodiment is the method of the nineteenth embodiment, wherein the sending and receiving steps each comprise sending information via an eSIM loT remote manager, ERM, and wherein an ERM ephemeral key pair is generated by the ERM and comprises the ERM ephemeral private key and an ERM ephemeral public key, the method comprising, before sending the first message, but after establishing a secure and authenticated connection between the ERM and the PS , receiving the ERM ephemeral public key at the PS as a trigger to send the first message, wherein the first message comprises a second PS cryptographic signature generated by the PS using the PS private key and is based on the ERM ephemeral public key.

[0033] A twenty-fourth embodiment is the method of the nineteenth embodiment, wherein the sending and receiving steps each comprise sending information via an eSIM loT remote manager , ERM, and wherein an ERM ephemeral key pair is generated by the ERM and comprises the ERM ephemeral private key and an ERM ephemeral public key, and wherein the second message comprises the ERM ephemeral public key.

[0034] A twenty-fifth embodiment is the method of the twenty-third or twenty-fourth embodiment, wherein the third session key is determined as a function of the PS ephemeral private key and the ERM ephemeral public key.

[0035] A twenty-sixth embodiment is the method of the nineteenth embodiment, wherein the profile identifier information comprises a matching identifier, MID, where the MID points to a specific subscription profile in the PS database.

[0036] A twenty-seventh embodiment is the method of the twenty-sixth embodiment, wherein the MID is encrypted using one of the first session key and the third session key, and wherein the encrypted MID is decrypted by the PS using one of the first session key and the third session key.

[0037] A twenty-eighth embodiment is the method of the nineteenth embodiment, wherein the profile identifier information comprises an indication that the MID is not used and the subscriber module identifier of the CD cryptographic certificate is used to select a subscription profile in the PS database.

[0038] A twenty-ninth embodiment is the method of the nineteenth embodiment, wherein at least the first CD signature and profile identifier information of the second message is within the encrypted portion.

[0039] A thirtieth embodiment is the method of the nineteenth embodiment, wherein the integrity protection data in the third message comprises a cryptographic signature created at the PS using the PS private key and based on at least the CD ephemeral public key. A thirty-first embodiment is the method of the nineteenth embodiment, wherein the integrity protection data in the third message comprises a Message Authentication Code, MAC, created at the PS using a MAC key and based on at least the CD ephemeral public key, wherein the MAC key is derived from the PS private key and the CD public key.

[0040] A thirty-second embodiment of the disclosure is a method for provisioning a subscription profile from a provisioning server, PS, to a subscriber module of a communication device, CD, via an eSIM loT remote manager, ERM, the subscriber module having a CD cryptographic certificate associated with a CD public / private key pair and comprising a subscriber module identifier, and the PS having a PS cryptographic certificate associated with a PS public / private key pair. This method includes establishing a secure and authenticated connection between the ERM and the PS; receiving, by the ERM, a first message through the secure and authenticated connection, wherein the first message comprises the PS cryptographic certificate, a first PS cryptographic signature, and a PS ephemeral public key of a PS ephemeral key pair and wherein the first PS cryptographic signature has been created using a PS private key of the PS public / private key pair and is based on at least the PS ephemeral public key; verifying, by the ERM, the PS cryptographic certificate; verifying, by the ERM, the first PS cryptographic signature using the PS cryptographic certificate; forwarding, by the ERM, if the two verification steps by the ERM are successful, the first message to the CD. The method includes receiving, by the ERM, a second message from the CD, wherein the second message comprises a CD ephemeral public key of a CD ephemeral key pair and a first CD signature, and wherein the first CD signature is generated by the subscriber module using the CD private key and is based at least on the PS ephemeral public key and the CD ephemeral public key. This method also includes sending, by the ERM, the second message to the PS; receiving, by the ERM, a third message from the PS, wherein the third message contains a subscription profile; wherein the subscription profile is encrypted using a second session key; and wherein the third message includes integrity protection data; and sending, by the ERM, the third message to the CD.

[0041] A thirty-third embodiment is the method of the thirty-second embodiment, wherein the ERM has storage holding one or more CD cryptographic certificates, and wherein the second message does not contain an encrypted portion having a payload comprising the CD cryptographic certificate, and the storage does contain the CD cryptographic certificate, the method comprising the ERM, before sending the second message, obtaining the CD cryptographic certificate from the storage; and adding the encrypted portion to the second message, the encrypted portion comprising the CD cryptographic certificate, wherein the encrypted portion is encrypted using a third session key. A thirty-fourth embodiment is the method of the thirty-third embodiment, wherein the third session key is generated using an ERM ephemeral private key and the PS ephemeral public key, wherein an ERM ephemeral key pair is generated by the ERM and comprises the ERM ephemeral private key and an ERM ephemeral public key.

[0042] A thirty -fifth embodiment is the method of the thirty -fourth embodiment, wherein sending the second message comprises adding the ERM ephemeral public key to the second message.

[0043] A thirty-sixth embodiment is the method of the thirty-fourth embodiment, comprising, after establishing a secure and authenticated connection between the ERM and the PS, but before receiving the first message, sending, by the ERM, the ERM ephemeral public key to the PS as a trigger to prompt the first message, where the first message comprises a second PS cryptographic signature generated by the PS using the PS private key and is based on the ERM ephemeral public key; and wherein after receiving the first message comprises verifying, by the ERM, the second PS cryptographic signature using the PS cryptographic certificate.

[0044] A thirty-seventh embodiment is the method of the thirty-sixth embodiment, wherein the ERM has a public / private key pair, and wherein the ERM public key of the ERM public / private key pair is stored in the subscriber module, the method comprising, after establishing a secure and authenticated connection between the ERM and the PS and before forwarding the first message to the CD, adding, by the ERM, a first ERM signature to the first message, wherein the first ERM signature is created by the ERM using the ERM private key of the ERM public / private key pair and is based on the PS ephemeral public key.

[0045] A thirty-eighth embodiment is the method of the thirty-second embodiment, wherein a profile identifier information comprises at least one of a matching identifier, MID; an encrypted MID encrypted by the ERM; and an indication that the MID is not used, and wherein the second message comprises the profile identifier information.

[0046] A thirty-ninth embodiment of the disclosure is a computer program comprising instructions which, when executed on a processing circuitry, cause the processing circuitry to carry out the method according to any one of the first to the seventeenth and nineteenth to the thirty-eighth embodiments.

[0047] A fortieth embodiment of the disclosure is a computer-readable storage medium comprising instructions which, when executed in a processing circuitry, cause the processing circuitry to carry out the method according to any one of the first to the seventeenth and nineteenth to the thirtyeighth embodiments.

[0048] A forty-first embodiment of the disclosure is a communication device, CD, adapted to receive and install a subscription profile from a provisioning server, PS, the CD comprising a subscriber module having a CD cryptographic certificate associated with a CD public / private key pair and comprising a subscriber module identifier, and the PS having a PS cryptographic certificate associated with a PS public / private key pair. The CD also comprises processing circuitry and memory encoded with programming instructions executable by the processing circuitry to receive a first message, wherein the first message includes the PS cryptographic certificate, a first PS cryptographic signature, and a PS ephemeral public key of a PS ephemeral key pair, and wherein the first PS cryptographic signature has been created using a PS private key of the PS public / private key pair and is based on at least the PS ephemeral public key. The memory is also encoded with programming instructions executable by the processing circuitry to verify the PS cryptographic certificate; verify the first PS cryptographic signature using the PS cryptographic certificate generate a CD ephemeral key pair comprising a CD ephemeral private key and a CD ephemeral public key; generate a first CD signature using the CD private key and based at least on the PS ephemeral public key and the CD ephemeral public key; and send a second message toward the PS, the second message comprising the CD ephemeral public key and the first CD signature. Additional programming instructions are encoded into the memory to receive a third message, wherein the third message contains a subscription profile, wherein the subscription profile is encrypted using a second session key, and wherein the third message includes integrity protection data; verify the integrity of the third message as a function of the integrity protection data, wherein the PS is authenticated as a result of the verification; decrypt the subscription profile using the second session key; and attempt to install the subscription profile.

[0049] A forty-second embodiment is the communication device of the forty-first embodiment, wherein the programming instructions are executable by the processing circuitry to determine whether to send or not send the CD cryptographic certificate as part of the second message, and wherein the determining is based on whether the CD is configured to avoid sending the CD cryptographic certificate whenever possible to reduce the number of transmitted bytes.

[0050] A forty-third embodiment is the communication device of the forty-first embodiment, wherein the programming instructions are executable by the processing circuitry to send the PS a further message indicating a result of the attempt to install the subscription profile.

[0051] A forty-fourth embodiment is the communication device of the forty-first embodiment, wherein the second message comprises an encrypted portion having a payload that is encrypted, the payload comprising the CD cryptographic certificate, and wherein the encrypted portion is encrypted by the subscriber module using a first session key.

[0052] A forty-fifth embodiment is the communication device of the forty-fourth embodiment, wherein the first session key is determined by the subscriber module as a function of the CD ephemeral private key and the PS ephemeral public key. A forty-sixth embodiment is the communication device of the forty -first embodiment, wherein the second message comprises profile identifier information, and wherein the profile identifier information comprises one of a matching identifier, MID, an encrypted MID, and an indication that the MID is not used, wherein the encrypted MID is encrypted by the subscriber module.

[0053] A forty-seventh embodiment is the communication device of the forty-first embodiment, wherein the second session key is determined by the subscriber module as a function of the CD ephemeral private key and the PS ephemeral public key.

[0054] A forty-eighth embodiment of the disclosure is an apparatus, comprising a communication device of the forty-first embodiment, and an eSIM loT remote manager, ERM, in communication with the communication device; wherein the sending and receiving operations of the communication device each comprise sending information via the ERM. Additionally, the programming instructions are executable by the processing circuitry to, before receiving the first message, establish a secure and authenticated connection between the ERM and the PS, and send a trigger to receive the first message. Also, the operation of receiving the first message comprises receiving, using the ERM, the first message through the secure and authenticated connection, verifying, using the ERM, the PS cryptographic certificate; verifying, using the ERM, the first PS cryptographic signature using the PS cryptographic certificate; and if the two verification steps using the ERM are successful, forwarding the first message to the CD.

[0055] A forty -ninth embodiment is the apparatus of the forty-eighth embodiment, wherein the ERM comprises a database that is configured to store one or more CD certificates, wherein the operation of sending the second message, when the second message does not contain an encrypted portion having a payload comprising the CD cryptographic certificate, comprises obtaining the CD cryptographic certificate from the database; and adding the encrypted portion to the second message, the encrypted portion comprising the CD cryptographic certificate, wherein the encrypted portion is encrypted using a third session key.

[0056] A fiftieth embodiment is the apparatus of the forty-ninth embodiment, wherein the third session key is generated using an ERM ephemeral private key and the PS ephemeral public key, wherein an ERM ephemeral key pair is generated using the ERM and comprises the ERM ephemeral private key and an ERM ephemeral public key.

[0057] A fifty-first embodiment is the apparatus of the fiftieth embodiment, wherein the second message comprises the ERM ephemeral public key.

[0058] A fifty-second embodiment is the apparatus of the fiftieth embodiment, wherein the programming instructions are executable by the processing circuitry to before receiving the first message, but after establishing a secure and authenticated connection between the ERM and the PS, send the ERM ephemeral public key to the PS as the trigger to receive the first message, wherein the first message comprises a second PS cryptographic signature generated by the PS using the PS private key and is based on the ERM ephemeral public key; and wherein receiving the first message comprises verifying, using the ERM, the second PS cryptographic signature using the PS cryptographic certificate.

[0059] A fifty-third embodiment is the apparatus of the fifty-second embodiment, wherein the ERM has a public / private key pair, and wherein the ERM public key of the ERM public / private key pair is stored in the subscriber module. The programming instructions are executable by the processing circuitry to after establishing a secure and authenticated connection between the ERM and the PS and before forwarding the first message to the CD, add, using the ERM, a first ERM signature to the first message, wherein the first ERM signature is generated using the ERM using the ERM private key of the ERM public / private key pair, and said generation is based on the PS ephemeral public key; and verify, using the subscriber module, the first ERM signature using the ERM public key.

[0060] A fifty-fourth embodiment is the apparatus of the forty-eighth embodiment, wherein the profile identifier information comprises at least one of a matching identifier, MID, an encrypted MID, and an indication that MID is not used, wherein the second message comprises the profile identifier information, and wherein the encrypted MID is encrypted using the ERM.

[0061] A fifty-fifth embodiment is the apparatus of the forty-fourth and forty-fifth embodiments, wherein at least the first CD signature and the profile identifier information of the second message are within the encrypted portion.

[0062] A fifty-sixth embodiment is the apparatus of the forty-first embodiment, wherein the integrity protection data in the third message comprises a cryptographic signature created by the PS using the PS private key based on at least the CD ephemeral public key, and wherein the programming instructions are executable to use the subscriber module to authenticate the PS by verifying the cryptographic signature using the PS public key.

[0063] A fifty-seventh embodiment is the apparatus of the forty-first embodiment, wherein the integrity protection data in the third message comprises a Message Authentication Code, MAC, created using a MAC key based on at least the CD ephemeral public key, and wherein the programming instructions are executable to use the subscriber module to authenticate the PS by verifying the MAC using the MAC key, wherein the MAC key is derived by the subscriber module from the CD private key and the PS public key.

[0064] A fifty-eighth embodiment is the apparatus of the forty-first embodiment, wherein the subscriber module is a UICC selected from an embedded UICC, eUICC, integrated UICC, iUICC, or integrated eUICC, ieUICC, the communication device being configured with programming instructions executable to implement the method of forty -first embodiment.

[0065] A fifty-ninth embodiment of the disclosure is a provisioning server, PS, adapted to send a subscription profile to a communication device, CD, the PS having a PS cryptographic certificate associated with a PS public / private key pair and comprising a PS database. The PS comprises processing circuitry; and memory encoded with programming instructions executable by the processing circuitry to create a first PS cryptographic signature using the PS private key and based on at least a PS ephemeral public key, where a PS ephemeral key pair comprises the PS ephemeral public key and a PS ephemeral private key; send a first message toward the CD, wherein the first message includes the PS cryptographic certificate, a first PS cryptographic signature, and a PS ephemeral public key. The memory is additionally encoded with programming instructions to receive a second message, the second message comprising a CD ephemeral public key, a first CD signature, profile identifier information, and an encrypted portion, wherein the first CD signature is created using the CD private key and is based on at least the PS ephemeral public key and the CD ephemeral public key; wherein the encrypted portion has a payload comprising the CD cryptographic certificate, and wherein the encrypted portion is encrypted using one of a first session key and a third session key. Programming instructions are also encoded in the memory to decrypt the encrypted portion using one of the first session key and the third session key to obtain the CD cryptographic certificate; verify the CD cryptographic certificate and the first CD signature to authenticate the CD, wherein the verification of the first CD signature is performed using the CD cryptographic certificate; select the subscription profile to be provisioned based on the profile identifier information; and send a third message toward the CD, wherein the third message contains the selected subscription profile; wherein the subscription profile is encrypted using a second session key; and wherein the third message includes integrity protection data.

[0066] A sixtieth embodiment is the provisioning server of the fifty-ninth embodiment, wherein the programming instructions are executable by the processing circuitry to receive from the CD a further message indicating a result of the attempt to install the subscription profile.

[0067] A sixty-first embodiment is the provisioning server of the fifty-ninth embodiment, wherein the first session key is determined as a function of the PS ephemeral private key and the CD ephemeral public key.

[0068] A sixty-second embodiment is the provisioning server of the fifty-ninth embodiment, wherein the second session key is determined as a function of the PS ephemeral private key and the CD ephemeral public key.

[0069] A sixty-third embodiment is the provisioning server of the fifty-ninth embodiment, wherein the sending and receiving operations each comprise sending information via an eSIM loT remote manager, ERM, and wherein an ERM ephemeral key pair is generated by the ERM and comprises the ERM ephemeral private key and an ERM ephemeral public key. The programming instructions are executable by the processing circuitry to before sending the first message, but after establishing a secure and authenticated connection between the ERM and the PS, receive the ERM ephemeral public key as a trigger to send the first message, wherein the first message comprises a second PS cryptographic signature generated by the PS using the PS private key and is based on the ERM ephemeral public key.

[0070] A sixty-fourth embodiment is the provisioning server of the fifty-ninth embodiment, wherein the sending and receiving operations each comprise sending information via an eSIM loT remote manager, ERM, and wherein an ERM ephemeral key pair is generated by the ERM and comprises the ERM ephemeral private key and an ERM ephemeral public key, and wherein the second message comprises the ERM ephemeral public key.

[0071] A sixty-fifth embodiment is the provisioning server of the sixty-third or sixty-fourth embodiments, wherein the third session key is determined as a function of the PS ephemeral private key and the ERM ephemeral public key.

[0072] A sixty-sixth embodiment is the provisioning server of the fifty-ninth embodiment, wherein the profile identifier information comprises a matching identifier, MID, where the MID points to a specific subscription profile in the PS database.

[0073] A sixty-seventh embodiment is the provisioning server of the sixty-sixth embodiment, wherein the MID is encrypted using one of the first session key and the third session key, and wherein the programming instructions are executable by the processing circuitry to decrypt the encrypted MID using one of the first session key and the third session key.

[0074] A sixty-eighth embodiment is the provisioning server of the fifty-ninth embodiment, wherein the profile identifier information comprises an indication that the MID is not used and the subscriber module identifier of the CD cryptographic certificate is used to select a subscription profile in the PS database.

[0075] A sixty-ninth embodiment is the provisioning server of the fifty-ninth embodiment, wherein at least the first CD signature and profile identifier information of the second message is within the encrypted portion.

[0076] A seventieth embodiment is the provisioning server of the fifty-ninth embodiment, wherein the integrity protection data in the third message comprises a cryptographic signature created at the PS using the PS private key and based on at least the CD ephemeral public key.

[0077] A seventy-first embodiment is the provisioning server of fifty-ninth embodiment, wherein the programming instructions are executable by the processing circuitry to create a Message Authentication Code, MAC, using a MAC key and based on at least the CD ephemeral public key, wherein the MAC key is derived from the PS private key and the CD public key, and wherein the integrity protection data in the third message comprises the MAC.

[0078] A seventy-second embodiment of the disclosure is an eSIM loT remote manager, ERM, for facilitating communication of a subscription profile from a provisioning server, PS, to a communication device, CD, the PS having a PS cryptographic certificate associated with a PS public / private key pair, and the CD having a subscriber module and a CD cryptographic certificate associated with a CD public / private key pair and comprising a subscriber module identifier. The ERM comprising processing circuitry and memory encoded with programming instructions executable by the processing circuitry to establish a secure and authenticated connection between the ERM and the PS; receive a first message through the secure and authenticated connection, wherein the first message comprises the PS cryptographic certificate, a first PS cryptographic signature, and a PS ephemeral public key of a PS ephemeral key pair and wherein the first PS cryptographic signature has been created using a PS private key of the PS public / private key pair and is based on at least the PS ephemeral public key; verify the PS cryptographic certificate; verify the first PS cryptographic signature using the PS cryptographic certificate; and verify forward, if the two verification steps by the ERM are successful, the first message to the CD. The memory is also encoded with programming instructions to receive a second message from the CD, wherein the second message comprises a CD ephemeral public key of a CD ephemeral key pair and a first CD signature, and wherein the first CD signature is generated by the subscriber module using the CD private key and is based at least on the PS ephemeral public key and the CD ephemeral public key, send the second message to the PS; receive a third message from the PS, wherein the third message contains a subscription profile; wherein the subscription profile is encrypted using a second session key; and wherein the third message includes integrity protection data; and send the third message to the CD.

[0079] The seventy-third embodiment is the ERM of the seventy-second embodiment, wherein the memory holds one or more CD cryptographic certificates, and wherein the second message does not contain an encrypted portion having a payload comprising the CD cryptographic certificate, and wherein the memory does contain the CD cryptographic certificate, and wherein the programming instructions are executable by the processing circuitry to, before sending the second message obtain the CD cryptographic certificate from the memory; and add the encrypted portion to the second message, the encrypted portion comprising the CD cryptographic certificate, wherein the encrypted portion is encrypted using a third session key.

[0080] The seventy-fourth embodiment is the ERM of the seventy-third embodiment, wherein the third session key is generated using an ERM ephemeral private key and the PS ephemeral public key, wherein an ERM ephemeral key pair is generated by the ERM and comprises the ERM ephemeral private key and an ERM ephemeral public key.

[0081] The seventy-fifth embodiment is the ERM of the seventy-fourth embodiment, wherein sending the second message comprises adding the ERM ephemeral public key to the second message.

[0082] The seventh-sixth embodiment is the ERM of the seventy-fourth embodiment, wherein the programming instructions are executable by the processing circuitry to, after establishing a secure and authenticated connection between the ERM and the PS, but before receiving the first message, send the ERM ephemeral public key to the PS as a trigger to prompt the first message. The first message comprises a second PS cryptographic signature generated by the PS using the PS private key and is based on the ERM ephemeral public key; and wherein receiving the first message comprises verifying, by the ERM, the second PS cryptographic signature using the PS cryptographic certificate.

[0083] The seventy-seventh embodiment is the ERM of the seventy-sixth embodiment, wherein the memory also stores a public / private key pair, and wherein the ERM public key of the ERM public / private key pair is stored in the subscriber module, wherein the programming instructions are executable by the processing circuitry to, after establishing a secure and authenticated connection between the ERM and the PS and before forwarding the first message to the CD, add a first ERM signature to the first message, wherein the first ERM signature is created by the ERM using the ERM private key of the ERM public / private key pair and is based on the PS ephemeral public key.

[0084] The seventy-eighth embodiment is the ERM of the seventy-second embodiment, wherein a profile identifier information comprises at least one of a matching identifier, MID, an encrypted MID encrypted by the ERM, and an indication that the MID is not used, and the second message comprises the profile identifier information.

[0085] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an indication of the scope of the claimed subject matter.

[0086] BRIEF DESCRIPTION OF THE DRAWINGS

[0087] For a more complete understanding of the present disclosure, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

[0088] Fig. l is a sequence diagram illustrating a known method for provisioning a SIM profile; Fig. 2 is a sequence diagram illustrating 3-round trip embodiment for provisioning a SIM profile under the present disclosure;

[0089] Fig. 3 is a sequence diagram illustrating a 2-round trip embodiment for provisioning a SIM profile under the present disclosure;

[0090] Fig. 4 is a sequence diagram illustrating a second 2-round trip embodiment for provisioning a SIM profile under the present disclosure;

[0091] Fig. 5 is a sequence diagram illustrating a third 2-round trip embodiment for provisioning a SIM profile under the present disclosure;

[0092] Fig. 6 is a sequence diagram illustrating a fourth 2-round trip embodiment for provisioning a SIM profile under the present disclosure;

[0093] Fig. 7 depicts one example of provisioning an eSIM profile according to an embodiment of the present disclosure;

[0094] Fig. 8 illustrates a flow-chart of the 3-round trip provisioning flow for the embodiment of Fig. 2;

[0095] Fig. 9 illustrates a flow-chart of the 2-round trip provisioning flow for the embodiment of Fig. 3;

[0096] Fig. 10 shows a schematic of a user equipment (UE) embodiment under the present disclosure; and

[0097] Fig. 11 shows a schematic of a host embodiment under the present disclosure.

[0098] DETAILED DESCRIPTION

[0099] Certain aspects of the disclosure and their embodiments may provide solutions to these or other challenges. For example, by reducing the necessary roundtrips of the GSMA SGP.32 eSIM provisioning protocol for loT, the data needed to be communicated — and, therefore, the power used — by very constrained loT devices with eUICC is reduced. Data may be stored or retrieved from third parties supporting the onboarding.

[0100] Before describing various embodiments of the present disclosure in detail, it is to be understood that this disclosure is not limited to the parameters of the particularly exemplified systems, methods, apparatuses, products, processes, and / or kits, which may, of course, vary. Thus, while certain embodiments of the present disclosure will be described in detail, with reference to specific configurations, parameters, components, elements, etc., the descriptions are illustrative and are not to be construed as limiting the scope of the claimed embodiments. In addition, the terminology used herein is for the purpose of describing the embodiments and is not necessarily intended to limit the scope of the claimed embodiments. As discussed herein, the terms provisioning server, authenticated server, subscription manager - data preparation plus (SM-DP+), and server may be used interchangeably to reference the same device. In addition, the terms subscription profile, SIM profile, eSIM profile, or profile may be used interchangeably to reference the same object, which may generally be a profile for authenticating a UE on a network. Similarly, the terms subscriber module, UICC, eUICC, iUICC, ieUICC, and eSIM may be used interchangeably to generally refer to a component that uses a subscription profile for authenticating a UE on a network. The terms loT device, loT device with eUICC, device, communication device, eSIM device, and client may be used interchangeably and may generally refer to a device comprising a subscriber module (e.g., eUICC) and supporting eSIM protocols for profile provisioning and profile management. Additionally, the term public / private key pair may generally refer to a pair of keys that comprise one private key and one public key.

[0101] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0102] In a 3 -round-trip embodiment, ephemeral keys are exchanged as part of mutual authentication instead of in separate messages after authentication. At the same time, the ephemeral keys, as they are by definition random and temporary, are used as authentication challenges. Furthermore, profile metadata is verified when the profile is downloaded from the provisioning server instead of before the download starts. The verification of the profile metadata may be performed by the device itself or offloaded to the elM.

[0103] In a 2-round trip embodiment, the order of events changes. In both SGP.32 and the 3- round trip embodiment disclosed herein, the provisioning server is authenticated by the client before the client authenticates the provisioning server. However, in the 2-round trip embodiment the client is authenticated before the server, leading to more signaling optimization.

[0104] In both embodiments, the client may, without setting up a separate and dedicated secure channel, protect its certificate and thereby its eSIM identity so that only an authenticated server can obtain it. One manner of achieving this is by using ephemeral keys to perform a Diffie-Hellman key exchange (DH) to derive session keys, which the client can use to encrypt its certificate. Since the session keys can only be derived by the entities holding a private key of an involved ephemeral key pair, and the client uses the ephemeral public key of the server, which is bound to the server via the server’s certificate through a digital signature, only the server can derive the corresponding session keys and thereby decrypt the client certificate. Certain embodiments may provide one or more of the following technical advantages. For example, less signaling is needed during eSIM provisioning, and less data is sent between the elM and the loT device. By reducing the number of bits transmitted by the loT device, the power consumption of the loT device is reduced, which is important for small, battery-powered loT devices (e.g., smart fabrics). In addition, the embodiments disclosed herein work for less constrained devices when the device is communicating directly with the SM-DP+ and no elM is involved as an intermediary.

[0105] 3-Round Trip Embodiment - Protocol Sequence

[0106] As previously mentioned, in a 3-round-trip embodiment, ephemerals keys are exchanged as part of mutual authentication and are also used as authentication challenges. This allows for the eUICC certificate to be encrypted when transmitted.

[0107] FIG. 2 shows a sequence 200 which illustrates a 3 -round trip embodiment. To facilitate discussion, the 3-round-trip embodiment is described as occurring in between a SM-DP+ 202, an elM 204, and a communication device, CD, 206. However, other combinations of devices may be used to implement this embodiment. For example, and as shown in FIG. 2, the CD 206 may be a UE that comprises a subscriber module 207 in the form of a UICC comprised in the UE and a Mobile Equipment (ME). In such a combination, the sequence 200 may still be described as occurring in part with a CD 206, but it is to be understood that some of the steps may be carried out by the subscriber module 207 of the CD 206 despite making reference solely to the CD 206. In other words, in case the CD 206 is a UE, then some steps may be carried out by the ME part of the UE and other steps may be carried out by the subscriber module 207. The steps in this illustrated embodiment include:

[0108] Once the elM 204 has established a secure and authenticated connection with the target SM- DP+ 202, the elM 204 sends 210 a trigger to the eSIM device 206 that it wants to perform eSIM provisioning with.

[0109] At 211, the eSIM device 206 receives the trigger.

[0110] At 212, the CD 206 generates an ephemeral key pair comprising a public key (ephPKeUICC) and a corresponding private key.

[0111] The eSIM device 206 responds 214 to the elM 204 with the public key of that ephemeral key pair (ephPKeUICC) in a message. The message is sent via elM 204 to SM-DP+ 202. In some embodiments, including the present embodiment, the elM 204 serves as an intermediary to facilitate communication between the SM-DP+ 202 and the CD 206. In these embodiments, and unless otherwise specified, discussions of the communication between the SM-DP+ 202 and the CD 206 is to be understood as occurring with the elM 204 as an intermediary to facilitate message transfer even though the elM 204 may not be directly referenced.

[0112] At 215, the SM-DP+ 202 receives the message.

[0113] At 216, the SM-DP+ 202 generates its own ephemeral key pair comprising a public key (ephPKsM-DP+) and a corresponding private key. In some embodiments, the SM-DP+ 202 could perform a DH using the ephemeral keys to derive session keys at this point instead of at 228.

[0114] Then, the SM-DP+ 202 responds 218 to the eSIM device 206 with a package that contains: (1) the public key of that ephemeral key pair (ephPKsM-DP+); (2) a signature, created using the private key corresponding to the certificate of the SM-DP+ 202 (certSM- DP+), over the ephemeral public keys of CD 206 and SM-DP+ 202 ({ephPKsM-DP+, ephPKeUICC}certSM-DP+); and (3) the SM-DP+ 202 certificate (certSM-DP+) used (and, preferably, dedicated) for profile provisioning.

[0115] At 219, the eSIM device 206 receives the package.

[0116] At 220, the CD 206 verifies certSM-DP+- In some embodiments, the elM 204 could also, before forwarding to eSIM device 206 for verification, verify certSM-DP+-

[0117] At 222, the CD 206 verifies that the received ephemeral public key (ephPKsM-DP+) has been signed by the SM-DP+ 202 in order to know that the SM-DP+ 202 has generated and endorses this ephemeral public key. Because the signature received at step 218 also covers the ephemeral public key of the CD 206 (ephPKeU!CC), the signature also authenticates the SM- DP+ 202 because the ephPKeU!CC acts as an authentication challenge, and the CD 206 knows SM-DP+ 202 is trusted as of step 220.

[0118] At 224, the CD 206 performs a DH using its ephemeral private key and the received SM- DP+ ephemeral public key, ephPKsM-DP+, to generate a session key for encryption, ephDH encK.

[0119] Then, the CD 206 generates and sends 226 a package to the SM-DP+ 202 that includes: (1) its own certificate (certgUICC) encrypted using ephDH encK, that is, [certeUICC]ephDH_encK, and (2) a signature, created using the private key corresponding to certeUICC, over the encrypted certificate, that is, {[certeUICC]ephDH_encK}certeUICC- In some alternative embodiments, the CD 206 generates and sends 226 a package to the SM- DP+ 202 that includes: (1) the ephemeral public key of the CD 206 (ephPKeUICC), (2) the ephemeral public keys of both the SM-DP+ 202 and the CD 206 signed using the certificate of the CD 206, that is, {ephPKsM-DP+, ephPKeUICC } certeUICC, and (3) the certificate of the CD 206 encrypted with the session key for encryption, that is, [certeUICC]ephDH_encK. In various embodiments, the package may also include one of a matching ID, an encrypted matching ID, or an indication that a matching ID is not used. The package may also include flags that are part of the signature indicating if a matching ID is used and which component provides the matching ID (eUICC CD or elM 204). Encryption of certeUICC enables the CD 206 identity to remain unexposed when sent from the elM 204 to the SM-DP+ 202 without relying on HTTPS / TLS security. The signature acts as an authentication of the CD 206 to the SM-DP+ 202 because it was calculated over [certeUICC]ephDH_encK. CD 206 signs data that can only be generated using the session key ephDH encK (which is symmetric between SM-DP+ 202 and CD 206) acting as an authentication challenge for the CD 206. In this embodiment, the entire package is generated by the CD 206. In other embodiments, a part of the package may be generated by the elM 204 with another part generated by the CD 206. In such an embodiment, the part generated by the CD 206 may be sent to the elM 204 to complete the package.

[0120] At 227, the SM-DP+ 202 receives the package from the eSIM device 206.

[0121] Then, at 228, if not performed at 216, the SM-DP+ 202 performs a DH using its ephemeral private key and ephPKeUICC to generate the same session key generated by the CD 206, ephDH encK.

[0122] At 230, the SM-DP+ 202 decrypts certeUICC using ephDH_encK.

[0123] At 232, the SM-DP+ 202 verifies the signature on the data received from the eSIM device 206 using certeUICC- This verification acts as authentication of the CD 206. By using certeUICC, the SM-DP+ 202 can verify that the CD 206 has indeed signed the data, which contains data acting as an authentication challenge provided by SM-DP+ 202, namely, in this embodiment, the SM-DP+ ephemeral public key (ephPKsM-DP+)-

[0124] Optionally, some embodiments may have a step 234, where the SM-DP+ 202 performs a DH using certSM-DP+ and certeUICC (i e., using the private key corresponding to the certificate of the SM-DP+ 202 and the public key corresponding to the certificate of the CD 206) to obtain symmetric session keys (certDH macK, certDH encK) bound to the certificates of both devices. Using certDH macK, the SM-DP+ 202 can generate a MAC over the message at 238 instead of a signature, thereby reducing the message size. At 236, the SM-DP+ 202 creates a bound profile package (BPP) containing the SIM profile. The BPP is encrypted using ephDH encK, that is, the SM-DP+ 202 creates [BPP]ephDH_encK.

[0125] The SM-DP+ 202 then sends 238 a package to the eSIM device 206 that includes: (1) [BPP]ephDH_encK and (2) integrity protection data for [BPP]ephDH_encK. Integrity protection data may be determined using certSM-DP+ as shown in Fig. 2. However, in embodiments that include step 234, integrity protection may be achieved by calculating a MAC using certDH macK. In the past, two different SM-DP+ certificates have been used for authentication and profile binding. In some of the presently disclosed embodiments, one SM- DP+ certificate, certSM-DP+, supports both authentication and profile binding. It is still possible for less constrained eSIM devices to use separate SM-DP+ certificates for authentication (an authentication certificate) and profile binding (a separate profile binding certificate), and yet in this step 238 perform integrity protection (with a signature or MAC) using the profile binding certificate. In such embodiments, the profile binding certificate is also included in the package delivered to the eSIM device 206 with the BPP.

[0126] At 239, the eSIM device 206 receives the package.

[0127] Optionally, some embodiments may have a step 240, where the CD 206 performs a DH using certSM-DP+ and certeUICC to obtain session key certDH macK.

[0128] At 242, the CD 206 verifies the integrity of the data received from the SM-DP+ 202 using either certSM-DP+ or certDH macK.

[0129] At 244, the CD 206 decrypts the BPP using ephDH encK.

[0130] At 246, the CD 206 installs the SIM profile.

[0131] Then, the CD device 206 sends 248 an installation result message to the SM-DP+ 202.

[0132] At 249, the SM-DP+ 202 receives the installation result message.

[0133] 3-Round Trip Embodiment - Provisioning Flow

[0134] Fig. 8 illustrates a flowchart of the 3-round-trip provisioning flow 800 for the embodiment of Fig. 2. In this illustration, additional details are provided, such as the profile metadata verification and Matching ID encryption by eUICC 207. The Matching ID encryption in this flow is handled by the eUICC 207. The steps in this illustrated embodiment include:

[0135] At 810, the user has ordered a profile for its constrained eSIM device 206 and obtained an Activation Code (AC) which is now available at the elM 204. Here, the loT Profile Assistant (IP A) 808 and eUICC 207 are part of the eSIM device 206. At 812, if not already established, the loT device 206 and the elM 204 establish a secure communication.

[0136] Then, the function ESipa.TransferEimPackage is sent 814 to the IPA 808.

[0137] At 815, the IPA 808 receives the function ESipa.TransferEimPackage, using it to trigger profile download.

[0138] If eUICCInfol is not known to the elM 204, the IPA 808 requests 816 eUICCInfol from the eUICC 207, which the eUICC 207 receives at 817.

[0139] Then, at 818, the eUICC 207 provides eUICCInfol to the IPA 808, which receives it at 819.

[0140] The IPA 808 then sends 820 ESlOb.AuthenticateServerlnit to the eUICC 207 to trigger a new common mutual authentication, which the eUICC 207 receives at 821.

[0141] At 822, the eUICC 207 generates an ephemeral key pair.

[0142] Then, the eUICC 207 returns 824 the eUICC ephemeral public key of the generated key pair to the IPA 808, which receives it at 825.

[0143] The IPA 808 then calls Esipa.InitiateAuthentication to provide 826 the eUICC ephemeral public key and eUICCInfol, if not already known, to the elM 204, which receives it at 827.

[0144] At 828, using an address from the AC for the SM-DP+ 202, the elM 204 establishes an HTTPS session with the SM-DP+ 202.

[0145] Then, the elM 204 follows GSMA SGP.32 version 1.1, for example, to initiate a mutual authentication flow with the SM-DP+ 202 by calling ES9+.InitiateAuthentication, where the SM- DP+ address, the eUICC ephemeral public key, and eUICCInfol are provided 830 to and received 831 by the SM-DP+ 202. eUICCInfol contains CA key identifiers for signing and verification available at the eUICC 207. If not received at 826, this information may have already been known by the elM 204. eUICCInfol is typically common to a batch of devices and may have been provided, for example, by the eUICC manufacturer to the device owner, and further to the elM when ordering the eUICCs. Alternatively, this information may have been read out earlier from the device, or another device in the batch, or obtained from the device during an earlier profile download.

[0146] At 832, the SM-DP+ 202 validates the SM-DP+ address, selects key identifiers from eUICCInfol, and generates a transaction identifier and an ephemeral key pair. The SM-DP+ 202 signs the transaction ID, SM-DP+ address, the eUICC ephemeral public key, and the SM-DP+ ephemeral public key using its private key corresponding to the SM-DP+ certificate valid for authentication and profile binding, which chains back to the selected CA for verification.

[0147] Then, the SM-DP+ 202 provides 834 the transaction ID, SM-DP+ address, SM-DP+ certificate, SM-DP+ ephemeral public key, signature, and selected CA key identifier to the elM 204 in a package, which the elM 204 receives at 835. At 836, the elM 204 verifies the received certificate and signature and checks that the SM-DP+ OID of the received certificate matches the SM-DP+ OID in the AC, if present. The elM 204 also checks that the received SM-DP+ address matches the address used in 828 and 830.

[0148] Upon the successful verifications at 836, the elM 204 provides 838 the Transaction ID (TID), SM-DP+ address, SM-DP+ certificate, SM-DP+ ephemeral public key, signature, selected CA key identifier, and Matching ID to the IPA 808, which receives it at 839.

[0149] Then, the IPA 808 follows GSMA SGP.32 version 1.1, for example, to call the ESlOb.AuthenticateServer function with TID, SM-DP+ address, SM-DP+ certificate, SM- DP+ ephemeral public key, the signature, profile download flag, device information, selected CA key identifier, and Matching ID to send 840 to the eUICC 207, which receives it at 841.

[0150] At 842, the eUICC 207 verifies the received certificate and signature and stores the TID. Upon successful verification, the SM-DP+ 202 is now authenticated. The eUICC 207 signs the TID, SM-DP+ ephemeral public key, eUICC ephemeral public key, Matching ID, device information, profile download flag, and optionally the SM-DP+ OID obtained from the SM- DP+ certificate. The eUICC certificate corresponding to the private key used to sign is selected so that it chains back to the CA with a key identifier according to the selection by the SM-DP+ 202.

[0151] At 844, the eUICC 207 computes the ECDH shared secret using the eUICC ephemeral private key and the SM-DP+ ephemeral public key and derives an encryption key from the shared secret. The eUICC 207 uses the encryption key to encrypt the Matching ID, MID.

[0152] At 846, if the eUICC 207 is configured to provide the eUICC certificate, the eUICC 207 encrypts the eUICC certificate using the encryption key from 844.

[0153] Then, the eUICC 207 provides 848 the TID, profile download flag, device information, signature, encrypted Matching ID, and optionally the encrypted certificate to the IPA 808, which receives it at 849.

[0154] The IPA 808 then follows GSMA SGP.32 version 1.1, for example, to call the Esipa.AuthenticateClient function to send 850 data to the elM 204, which receives it at 851. The signature and encrypted Matching ID are always sent. However, the following data may optionally be sent: profile download flag, device information, and encrypted eUICC certificate. This is because, in order to reduce the number of bytes transmitted by the loT device 206, the IPA 808 only sends the necessary bytes not already known by the elM 204. Note that the eUICC 207 may always provide an encrypted certificate, and the IPA 808 decides based on its configuration whether to provide the encrypted certificate to the elM 204 or if elM 204 shall encrypt the certificate of the eUICC 207, which the elM 204 already has. In some embodiments, the IPA 808 determines whether to send or not send the encrypted eUICC certificate as a function of whether the IPA 808 has information regarding availability of provisioning of the subscription profile via an intermediate elM 204, whether the elM 204 is capable of securely providing the certificate of the eUICC 207 to the SM-DP+ 202 according to information stored in the eUICC 207 or IPA 808, and whether the IPA 808 is configured to avoid sending the encrypted certificate of the eUICC 207 whenever possible to reduce the number of transmitted bytes.

[0155] At 852, if the elM 204 did not obtain an encrypted eUICC certificate at 850, the elM 204 generates an ephemeral key pair, computes the ECDH shared secret using the elM ephemeral private key and the SM-DP+ ephemeral public key, derives an encryption key from the shared secret, and encrypts the eUICC certificate using the derived encryption key.

[0156] The elM 204 calls the ES9+.AuthenticateClient function to provide 854 the following data in a package to the SM-DP+ 202: TID, profile download flag, encrypted MID, device information, signature, encrypted eUICC certificate, and optionally - if encryption is performed by the elM - the elM ephemeral public key. Any data not provided at 850 is known to the elM 204 and added to this function. The SM-DP+ 202 receives the package at 855.

[0157] At 856, the SM-DP+ 202 computes the ECDH shared secret using the SM-DP+ ephemeral private key and the eUICC ephemeral public key, derives an encryption key from the shared secret, and decrypts the encrypted Matching ID and, if encrypted by the eUICC 207, the encrypted eUICC certificate. If not encrypted by the eUICC 207, the SM-DP+ 202 computes the second ECDH shared secret using the SM-DP+ ephemeral private key and the elM ephemeral public key, derives a second encryption key from the second shared secret, and decrypts the encrypted eUICC certificate using the second encryption key. The SM-DP+ 202 then verifies the eUICC certificate and received signature. After successful verification, the eUICC 207 is authenticated.

[0158] At 858, the SM-DP+ 202 checks that there is a profile prepared for the given Matching ID (and / or EID). The SM-DP+ 202 may perform an eligibility check leveraging the provided device information. After a successful check, the SM-DP+ 202 derives a session MAC key from the first ECDH shared secret derived at 856. The bound profile package (BPP), including profile metadata, is created where the profile is encrypted and integrity-protected using the session keys. The integrity protection also covers the TID such that the BPP is bound to the TID.

[0159] Then, the SM-DP+ 202 responds 860 to the elM 204 with a package that includes the TID and BPP, which the elM 204 receives at 861. If not performed by the loT device 206, at 862 the elM 204 checks whether the profile can be installed using the profile metadata from the BPP.

[0160] The elM 204 then provides 864 the BPP, and optionally the TID should the IPA 808 not have it, to the IPA 808, which receives it at 865. At 866, if supported by the loT device 206, the IPA 808 checks if the profile can be installed using the profile metadata from the BPP.

[0161] Then, the IPA 808 calls the ESlOb.LoadBoundProfilePackage function with the BPP to send 868 the BPP to the eUICC 207, which receives it at 869.

[0162] At 870, the eUICC 207 derives the session MAC key from the ECDH shared secret derived at 844. The profile is decrypted and verified using the derived session keys while installing the profile. A ProfilelnstallationResult notification is prepared by the eUICC 207.

[0163] Then, the ProfilelnstallationResult notification is sent 872 to the IPA 808, which receives it at 873.

[0164] The IPA 808 provides 874 the ProfilelnstallationResult notification to elM 204 by calling the Esipa.HandleNotification function. The elM 204 receives the ProfilelnstallationResult notification at 875.

[0165] The elM 204 then sends 876 an acknowledgement of successful delivery to the IPA 808, which receives it at 877.

[0166] Then, the IPA 808 calls the ESlOb.RemoveNotificationFromList function to send 878 a trigger to the eUICC 207, which the eUICC 207 receives at 879. The trigger makes the eUICC 207 delete the ProfilelnstallationResult notification.

[0167] Finally, the elM 204 delivers 880 the ProfilelnstallationResult notification to the SM- DP+ 202 using the ES9+.HandleNotification function, which the SM-DP+ 202 receives at 881.

[0168] 2-Round Trip Embodiment - Protocol Sequence

[0169] FIG. 3 shows a sequence 300 which illustrates a 2-round-trip embodiment, including the authentication and key agreement aspects. In addition to the benefits of the 3 -round-trip embodiment, encrypting certeUICC in the 2-round trip embodiment disclosed herein serves as authentication because only the intended SM-DP+ can decrypt certeUICC’. To facilitate discussion, the sequence 300 is described as occurring in between a SM-DP+ 302, an elM 304, and a communication device, CD, 306. However, other combinations of devices may be used to implement this embodiment. For example, and as shown in FIG. 3, the CD 306 may be a UE that comprises a subscriber module 307 in the form of a UICC connected to the UE. In such a combination, the sequence 300 may still be described as occurring in part with a CD 306, but it is to be understood that some of the steps may be carried out by the subscriber module 307 of the CD 306 despite making reference solely to the CD 306. In addition, the elM 304 and the CD 306 may be referred to collectively as an apparatus 305. The steps in this illustrated embodiment include: Initially, with a secure and authenticated connection to the SM-DP+ 302 already established, the elM 304 sends 310 a trigger to the SM-DP+ 302 that it wants to perform eSIM provisioning.

[0170] At 311, the SM-DP+ 302 receives the trigger.

[0171] At 312, the SM-DP+ 302 generates an ephemeral key pair comprising a public key (ephPKsM- DP+) and a private key.

[0172] Then, the SM-DP+ 302 responds 314 to the elM 304 with a package that includes: (1) the public key of that ephemeral key pair (ephPKsM-DP+), (2) a signature, created using the private key corresponding to the certificate of the SM-DP+ 302 (certSM-DP+), over the ephemeral public key of SM-DP+ 302 ({ephPKsM-DP+}certSM-DP+), and (3) the SM-DP+ 302 certificate (certSM- DP+) dedicated for profile provisioning. The message is sent via the elM 304 to the eSIM device 306, which receives the message at 315. In some embodiments, including the present embodiment, the elM 304 serves as an intermediary to facilitate communication between the SM-DP+ 302 and the CD 306. In these embodiments, and unless otherwise specified, discussions of the communication between the SM-DP+ 302 and the CD 306 is to be understood as occurring with the elM 304 as an intermediary to facilitate message transfer even though the elM 304 may not be directly referenced.

[0173] At 316, the CD 306 verifies certSM-DP+- In some embodiments, such as the embodiment described in sequence 400 below, the elM 304 could also, before forwarding to eSIM device 306 for verification, verify certSM-DP+-

[0174] At 318, the CD 306 verifies that the received ephemeral public key (ephPKsM-DP+) has been signed by the SM-DP+ 302 in order to know that the SM-DP+ 302 has generated and endorses this ephemeral public key. However, the CD 306 cannot know if the key is fresh (i.e., has not been replayed by an attacker). Receiving the message via the elM 304, a trusted device that has authenticated the SM-DP+ 302 based on its certificate (certSM-DP+), is a way to reduce the risk of a replayed message, at least if the certificate chains back to an eSIM certificate authority (CA).

[0175] At 320, the CD 306 generates its own ephemeral key pair, which includes an ephemeral private key and ephemeral public key (ephPKeUICC), and then performs a DH using its ephemeral private key and the received SM-DP+ ephemeral public key (ephPKsM-DP+) to generate a session key for encryption (ephDH encK).

[0176] The CD 306 generates and sends 322 a package to the SM-DP+ 302 that includes: (1) its own ephemeral public key (ephPKeUICC), (2) a signature, created using the private key corresponding to certeUICC, over ephPKeUICC and ephPKsM-DP+, that is, {ephPKeUICC, ephPKsM- DP+} certeUICC, and (3) its own certificate (certeUICC) encrypted using ephDH encK, or [certeUICC]ephDH_encK. The certeUICC encryption enables the CD 306 identity to remain unexposed when sent from the elM 304 to the SM-DP+ 302 without relying on HTTPS security. The inclusion of ephPKsM-DP+ in the signature serves as completion of a challenge that was provided by the SM-DP+ 302 in a previous package, here at 314. In other embodiments other values provided by the SM-DP+ 302 may be used for the challenge. Examples include a sequence number, a session ID, and a random challenge. Additionally, some embodiments may have the signature encrypted together with certeUICC, such as [{ephPKeUICC, ephPKsM-DP+} certeUICC, certeUICC]ephDH_encK.

[0177] At 323, the SM-DM+ 302 receives the package.

[0178] At 324, the SM-DP+ 302 performs a DH using its ephemeral private key and ephPKeUICC to generate the same session key generated by the CD 306, ephDH encK.

[0179] At 326, the SM-DP+ 302 decrypts certeUICC using ephDH encK.

[0180] At 328, the SM-DP+ 302 verifies the signature of the data received from the eSIM device 306 using certeUICC- This verification acts as authentication of the CD 306. By using certeUICC, the SM-DP+ 302 can verify that the CD 306 has indeed signed the data, which contains data acting as authentication challenge provided by SM-DP+ 302, namely, in this embodiment, the SM-DP+ ephemeral public key (ephPKsM-DP+)-

[0181] Optionally, some embodiments may have a step 330, where the SM-DP+ 302 performs a DH using certSM-DP+ and certeUICC (i e., using the private key corresponding to the certificate of the SM-DP+ 302 and the public key corresponding to the certificate of the CD 306) to obtain symmetric session keys (certDH macK, certDH encK) bound to the certificates of both devices. Using certDH macK, the SM-DP+ 302 can generate a MAC over the message at 334 instead of a signature, thereby reducing message size.

[0182] At 332, the SM-DP+ 302 creates a bound profile package (BPP) containing the SIM profile. The BPP is encrypted using ephDH encK: [BPP]ephDH_encK.

[0183] Then, the SM-DP+ 302 sends 334 a package to the eSIM device 306 which includes: (1) [BPP]ephDH_encK and (2) integrity protection data for [BPP]ephDH_encK and ephPKeUICC- By including ephPKeUICC in the integrity protection data, the integrity protection data also acts as authentication of the SM-DP+ 302 by providing a freshness guarantee that was missing in 318. However, ephPKeUICC does not necessarily have to be included in the package, even though the integrity protection data covers it, as the CD 306 has the local copy it generated at 320 available to verify the integrity protection. Leaving ephPKeUICC out of the package reduces the number of bits transmitted between the elM 304 and the eSIM device 306. Integrity protection may be done using certSM-DP+ as shown in Fig. 3. However, in embodiments that include step 330, integrity protection may be achieved by calculating a MAC using certDH macK. As described earlier, one SM-DP+ certificate may support both authentication and profile binding.

[0184] At 335, the eSIM device 306 receives the package.

[0185] Optionally, some embodiments may have a step 336, where the CD 306 performs DH using certSM-DP+ and certeUICC to obtain session key certDH macK.

[0186] At step 338, the CD 306 verifies the integrity of the data received from the SM-DP+ 302 using either certSM-DP+ or certDH macK. At this point SM-DP+ 302 is authenticated. Including ephPKeUICC in the integrity protection data of 334 acts as an authentication challenge for this authentication response.

[0187] At step 340, the CD 306 decrypts the BPP using ephDH encK.

[0188] At step 342, the CD 306 installs the SIM profile.

[0189] The eSIM device 306 then sends 344 an installation result message to the SM-DP+ 302, which receives it at step 345.

[0190] The shared encryption key (ephDH encK) mentioned throughout the discussion of Fig. 3 may be derived using, for example, the (elliptic curve) Diffie-Hellman key agreement algorithm, where each party derives the encryption key based on its ephemeral private key and the ephemeral public key of its counterpart. In some embodiments, the encryption key may instead be randomly generated by a first party and securely provided to a second party. For example, using the ML- KEM algorithm, the randomly generated encryption key may be encapsulated using the ephemeral public key of the second party to produce a ciphertext. The ciphertext may then be sent from the first party to the second party, allowing the second party to decapsulate the ciphertext with its ephemeral private key to retrieve the encryption key.

[0191] With continuing reference to Fig. 3, embodiments that feature a randomly generated key instead of the Diffie-Hellman key agreement algorithm include modified steps. For example, at step 320, instead of performing a DH, the CD 306 may randomly generate the encryption key (ephDH encK) and encapsulate it using ephPKsM-DP+ to yield a ciphertext. The ciphertext may then be included in the package sent to the SM-DP+ 302 in step 322. In step 324, instead of performing a DH, SM-DP+ 302 may decapsulate the ciphertext using the SM-DP+ 302 ephemeral private key (ephPrKsM-DP+) to obtain ephDH encK.

[0192] In step 330, instead of performing a DH, the SM-DP+ 302 may randomly generate the MAC key (certDH macK) and encapsulate it using ephPKeUICC to yield a ciphertext. The ciphertext may then be included in the package sent to the CD 306 in step 334. In step 336, instead of performing DH, the ciphertext may be decapsulated using the CD 306 ephemeral private key (ephPrKeUICC) to obtain certDH macK. The same approach may apply for certDH encK if certDH encK is used instead of ephDH encK.

[0193] 2-Round Trip Embodiment - Protocol Sequence - Data Transmission Optimization

[0194] FIG. 4 shows a sequence 400 which illustrates a 2-round trip embodiment with reduced data transmission — and consequently reduced energy consumption — for an eSIM device 406 involving an SM-DP+ 402 and elM 404. However, other combinations of devices may be used to implement this embodiment. For example, and as shown in FIG. 4, the communication device, CD, 406 may be a UE that comprises a subscriber module 407 in the form of a UICC in the UE. In such a combination, the sequence 400 may still be described as occurring in part with a CD 406, but it is to be understood that some of the steps may be carried out by the subscriber module 407 and other steps may be carried out by the ME part of the CD 406 despite making reference solely to the CD 406. In this embodiment, the eUICC certificate (certeUICC) is not transmitted by the eSIM device 406 to the elM 404. Rather, the elM 404 adds certeUICC when sending data from the CD 406 to the SM-DP+ 402. Accordingly, the elM 404 first needs to obtain certeUICC, either via a user configuration to the elM 404 or a communication between the elM 404 and the eSIM device 406 (this communication would be a single occurrence and not required for future provisioning of the eSIM device 406). As a result, the data transmission for the eSIM device 406 is reduced as it does not need to transmit its certificate beyond a potential initial occurrence. However, this approach requires a strong trust and explicit collaboration between the elM 404 and the eSIM device 406. The steps in this illustrated embodiment include:

[0195] Initially, with a secure and authenticated connection to the SM-DP+ 402 already established, the elM 404 sends 410 a trigger to the SM-DP+ 402 that it wants to perform eSIM provisioning.

[0196] At 411, the SM-DP+ 402 receives the trigger.

[0197] At 412, the SM-DP+ 402 generates an ephemeral key pair comprising a public key (ephPKsM-DP+) and a private key. Then, the SM-DP+ 402 responds 414 to the elM 404 with a package that includes: (1) the public key of that ephemeral key pair (ephPKsM-DP+), (2) a signature, created using the private key corresponding to the certificate of the SM-DP+ 402 (certSM-DP+), over the ephemeral public key of SM-DP+ 402 ({ephPKsM-DP+}certSM-DP+), and (3) the SM-DP+ 402 certificate (certSM- DP+) dedicated for profile provisioning.

[0198] At 415, the elM 404 receives the package.

[0199] At 416, the elM 404 verifies certSM-DP+-

[0200] At 418, the elM 404 verifies that the received ephemeral public key (ephPKsM-DP+) has been signed by the SM-DP+ 402 in order to know that the SM-DP+ 402 has generated and endorses this ephemeral public key.

[0201] The elM 404 then sends 420 the package to the CD 406.

[0202] At 421, the CD 406 receives the package.

[0203] At 422, the CD 406 verifies certSM-DP+-

[0204] At 424, the CD 406 verifies that the received ephemeral public key (ephPKsM-DP+) has been signed by the SM-DP+ 402 in order to know that the SM-DP+ 402 has generated and endorses this ephemeral public key.

[0205] At 426, the CD 406 generates its own ephemeral key pair, which includes an ephemeral private key and ephemeral public key ephPKeUICC- In embodiments where the BPP created at step 442 is protected with a key derived based on certificates instead of an ephemeral key, the CD 406 in this step may only generate a random value to use as an authentication challenge instead of ephPKeUICC and for integrity protection at step 444.

[0206] Then, the CD 406 generates and sends 428 a package to the elM 404 which includes: (1) its own ephemeral public key (ephPKeUICC) and (2) a signature, created using the private key corresponding to certeUICC, over ephPKsM-DP+ and ephPKeUICC, that is, {ephPKsM-DP+, ephPKeUICC } certeUICC-

[0207] At 429, the elM 404 receives the package.

[0208] At 430, the elM 404 generates its own ephemeral key pair, which includes an ephemeral private key and the ephemeral public key (ephPKe!M), and then performs a DH using its ephemeral private key and ephPKsM-DP+ to generate a session key for encryption (ephDH_encK2) to encrypt certeUICC- The elM 404 then adds to the package: (1) ephPKe!M and (2) certeUICC encrypted using ephDH_encK2, that is, [certeUICC] ephDH_encK2. Afterwards, the package is sent 432 to the SM-DP+ 402. The certeUICC encryption enables the CD 406 identity to remain unexposed when sent from the elM 404 to the SM-DP+ 402 without relying on a security measure, such as HTTPS. The inclusion of ephPKsM-DP+ in the signature serves as completion of a challenge that was provided by the SM-DP+ 402 in a previous package, here at 414. In other embodiments other values provided by the SM-DP+ 402 may be used for the challenge. Examples include a sequence number, a session ID, and a random challenge. Additionally, some embodiments may have the signature encrypted together with certeUICC, that is, [{ephPKeUICC, ephPKsM-DP+} certeUICC, certeUICC] ephDH_encK2.

[0209] At 433, the SM-DP+ 402 receives the package.

[0210] At 434, the SM-DP+ 402 performs a DH using its ephemeral private key and ephPKelM to generate the same session key generated by the elM 404, that is, ephDH_encK2.

[0211] At 436, the SM-DP+ 402 decrypts certeUICC using ephDH_encK2.

[0212] At 438, the SM-DP+ 402 verifies the signature of the data received using certeUICC- This verification acts as authentication of the CD 406. By using certeUICC, the SM-DP+ 402 can verify that the CD 406 has indeed signed the data, which contains data acting as an authentication challenge provided by the SM-DP+ 402, namely, in this embodiment, the SM- DP+ ephemeral public key (ephPKsM-DP+)-

[0213] At 440, the SM-DP+ 402 may perform a DH using its ephemeral private key and the received eUICC ephemeral public key (ephPKeUICC) to generate a session key for encryption (ephDH encK) or a DH using the certificates (certSM-DP+, certeUICC) to obtain MAC key certDH macK. Using certDH macK, the SM-DP+ 402 can generate a MAC over the message at 444 instead of a signature, thereby reducing message size.

[0214] At 442, the SM-DP+ 402 creates a bound profile package (BPP) containing the subscription (SIM) profile. The BPP is encrypted using ephDH encK, that is, the SM-DP+ 402 creates [BPP]ephDH_encK.

[0215] The SM-DP 402 then sends 444 a package to the eSIM device 406 which includes: (1) [BPP]ephDH_encK and (2) integrity protection data for [BPP]ephDH_encK and ephPKeUICC- By including ephPKeUICC in the integrity protection data, the integrity protection data also acts as authentication of the SM-DP+ 402. In alternative embodiments, a random value may be used in lieu of ephPKeUICC for authentication, as described in 426. Integrity protection may be done using certSM-DP+ as shown in Fig. 4. However, in embodiments that include the MAC key (certDH macK) from step 440, integrity protection may be achieved by calculating a MAC using certDH macK. As described earlier, one SM-DP+ certificate may support both authentication and profile binding.

[0216] At 445, the eSIM device 406 receives the package.

[0217] At 446, the CD 406 may perform a DH using its ephemeral private and the received SM-DP+ ephemeral public key (ephPKsM-DP+) to generate a session key for encryption (ephDH encK) or a DH using the certificates (certSM-DP+, certeUICC) to obtain MAC key certDH macK.

[0218] At 448, the CD 406 verifies the integrity of the data received from the SM-DP+ 402 using either certSM-DP+ or certDH macK. At this point, the SM-DP+ 402 is authenticated. Including ephPKeUICC in the integrity protection data of 444 acts as an authentication challenge for this authentication response.

[0219] At step 450, the CD 406 decrypts the BPP using ephDH encK.

[0220] At step 452, the CD 406 installs the subscription (SIM) profile.

[0221] The eSIM device 406 then sends 454 an installation result message to the SM-DP+ 402, which receives it at step 455.

[0222] The shared encryption keys (ephDH encK and ephDH_encK2) and the shared MAC key (certDH macK) mentioned throughout the discussion of Fig. 4 may be derived using, for example, the (elliptic curve) Diffie-Hellman key agreement algorithm. As described in connection with Fig. 3, in some embodiments, the encryption / MAC key may instead be randomly generated by a first party and securely provided to a second party using, for example, the ML-KEM algorithm.

[0223] With continuing reference to Fig. 4, embodiments that feature a randomly generated key instead of the Diffie-Hellman key agreement algorithm include modified steps. For example, at step 430, instead of performing a DH, the elM 404 may randomly generate the encryption key (ephDH_encK2) and encapsulate it using ephPKsM-DP+ to yield a ciphertext. The ciphertext may then be included in the package sent to the SM-DP+ 402 in step 432. In step 434, instead of performing a DH, the ciphertext may be decapsulated using the SM-DP+ 402 ephemeral private key (ephPrKsM-DP+) to obtain ephDH encK.

[0224] In step 440, instead of performing a DH, the SM-DP+ 402 may randomly generate the encryption key (ephDH encK) and encapsulate it using ephPKeUICC to yield a ciphertext. The ciphertext may then be included in the package sent to the CD 406 in step 444. In step 446, instead of performing DH, the ciphertext may be decapsulated using the CD 406 ephemeral private key (ephPrKeUICC) to obtain ephDH encK.

[0225] The generation and sharing of certDH macK may follow the same approach as described in conjunction with Fig. 3.

[0226] 2-Round Trip Embodiment - Protocol Sequence - elM Authenticates SM-DP+

[0227] FIG. 5 shows a sequence 500 which illustrates a 2-round trip embodiment where authentication of an SM-DP+ 502 for the provisioning of a communication device, CD, 506 occurs at an elM 504. However, other combinations of devices may be used to implement this embodiment. For example, and as shown in FIG. 5, the CD 506 may be a UE that comprises a subscriber module 507 in the form of a UICC in the UE. In such a combination, the sequence 500 may still be described as occurring in part with a CD 506, but it is to be understood that some of the steps may be carried out by the subscriber module 507 of the CD 506 and some of the steps may be carried out by the ME part of the UE despite making reference solely to the CD 506. The elM 504 assists the eSIM device 506 by ensuring that the signed ephemeral public key of the SM-DP+ ({ephPKsM-DP+}certSM-DP+) provided to the eSIM device 506 at 523 is not a replay (i.e., it is fresh) by authenticating the SM-DP+ 502 at 520 before using ephPKsM-DP+ in the encryption of the eUICC certificate at 530. The steps in this illustrated embodiment include:

[0228] At 510, the elM 504 generates an ephemeral key pair comprising a public key (ephPKelM) and a private key.

[0229] Then, with a secure and authenticated connection to the SM-DP+ 502 already established, the elM 504 sends 512 a message to the SM-DP+ 502 that includes: (1) a trigger that it wants to perform eSIM provisioning and (2) ephPKelM-

[0230] At 513, the SM-DP+ 502 receives the message.

[0231] At 514, the SM-DP+ 502 generates an ephemeral key pair comprising a public key (ephPKsM-DP+) and a private key.

[0232] The SM-DP+ 502 then responds 516 to the elM 504 with a package that includes: (1) ephPKsM-DP+, (2) a first signature, created using the private key corresponding to the certificate of the SM-DP+ 502 (certSM-DP+), over the ephemeral public key of the SM-DP+ 502, that is, ({ephPKsM-DP+}certSM-DP+), (3) the SM-DP+ 502 certificate (certSM-DP+) dedicated for profile provisioning, and (4) a second signature, creating using certSM-DP+, over ephPKsM-DP+ and the ephemeral public key of the elM 504 (ephPKe!M) • In an alternative embodiment, a MAC may be used in lieu of a signature. In yet another embodiment, step 536 could also be performed during this step using the ephemeral private key of the SM-DP+ 502 and ephPKelM to derive MAC key ephDH macK and calculate an authentication code using ephDH macK.

[0233] At 517, the elM 504 receives the package.

[0234] At 518, the elM 504 verifies certSM-DP+-

[0235] At 520, the elM 504 verifies that the ephemeral public keys ephPKsM-DP+ and ephPKelM have been signed by the SM-DP+ 502 in order to know that the SM-DP+ 502 endorses these ephemeral public keys. In embodiments where a MAC is used, the elM 504 may perform DH in this step instead of 532 to generate a key for verifying the MAC.

[0236] Then, the elM 504 sends 522 parts ( 1 )-(3) of the package to the CD 506.

[0237] At 523, the CD 506 receives parts ( 1 )-(3) of the package.

[0238] At 524, the CD 506 verifies certSM-DP+-

[0239] At 526, the CD 506 verifies that the received ephemeral public key (ephPKsM-DP+) has been signed by the SM-DP+ 502 in order to know that the SM-DP+ 502 has generated and endorses this ephemeral public key.

[0240] At 528, the CD 506 generates its own ephemeral key pair, which includes an ephemeral private key and ephemeral public key ephPKeUICC- In embodiments where the BPP created at step 544 is protected with a key derived based on certificates instead of an ephemeral key, the CD 506 in this step may only generate a random value to use as both an authentication challenge instead of ephPKeUICC and for integrity protection at step 546.

[0241] Then, the CD 506 generates and sends 530 a package to the elM 504 with: (1) its own ephemeral public key (ephPKeUICC) and (2) a signature, created using the private key corresponding to certeUICC, over ephPKsM-DP+ and ephPKeUICC, that is, {ephPKsM-DP+, ephPKeUICC } certeUICC-

[0242] At 531, the elM 504 receives the package.

[0243] At 532, the elM 504 performs a DH using its ephemeral private key and ephPKsM-DP+ to generate a session key for encryption (ephDH_encK2) to encrypt certeUICC- A matching ID may also be encrypted with certeUICC to send to the SM-DP+ 502. The elM 504 then adds to the package certeUICC encrypted using ephDH_encK2, that is, [certeUICC]ephDH_encK2. Afterwards, the package is sent 534 to the SM-DP+ 502. The certeUICC encryption enables the CD 506 identity to remain unexposed when sent from the elM 504 to the SM-DP+ 502 without relying on a security measure, such as HTTPS. The inclusion of ephPKsM-DP+ in the signature serves as completion of a challenge that was provided by the SM-DP+ 502 in a previous package, here at 516. In other embodiments other values provided by the SM-DP+ 502 may be used for the challenge. Examples include a sequence number, a session ID, and a random challenge. Additionally, some embodiments may have the signature encrypted together with certeUICC, for example, [{ephPKeUICC, ephPKsM-DP+} certeUICC, certeUICC] ephDH_encK2.

[0244] At 535, the SM-DP+ 502 receives the package.

[0245] At 536, the SM-DP+ 502 receives the package from the eSIM device 506 and performs a DH using its ephemeral private key and ephPKeiM to generate the same session key generated by the elM 504, ephDH_encK2.

[0246] At 538, the SM-DP+ 502 decrypts certeUICC using ephDH_encK2.

[0247] At 540, the SM-DP+ 502 verifies the signature of the data received using certeUICC- This verification acts as authentication of the CD 506. By using certeUICC, the SM-DP+ 502 can verify that the CD 506 has indeed signed the data, which contains data acting as authentication challenge provided by SM-DP+ 502, namely, in this embodiment, the SM-DP+ ephemeral public key (ephPKsM-DP+)-

[0248] At 542, the SM-DP+ 502 may perform a DH using its ephemeral private key and the received eUICC ephemeral public key (ephPKeUICC) to generate a session key for encryption (ephDH encK) and / or a DH using the certificates (certSM-DP+, certeUICC) to obtain MAC key certDH macK. Using certDH macK, the SM-DP+ 502 can generate a MAC over the message at 546 instead of a signature, thereby reducing message size.

[0249] At 544, the SM-DP+ 502 creates a bound profile package (BPP) containing the subscription (SIM) profile. The BPP is encrypted using ephDH encK, that is, the SM-DP+ 502 creates [BPP]ephDH_encK.

[0250] Then, the SM-DP 502 sends 546 a package to the eSIM device 506 which includes: (1) [BPP]ephDH_encK and (2) integrity protection data for [BPP]ephDH_encK and ephPKeUICC- By including ephPKeUICC in the integrity protection data, the integrity protection data also acts as authentication of the SM-DP+ 502. In alternative embodiments, a random value may be used in lieu of ephPKeUICC for authentication, as described in 528. Integrity protection may be done using certSM-DP+ as shown in Fig. 5. However, in embodiments that include the MAC key certDH macK from 542, integrity protection may be achieved by calculating a MAC using certDH macK. As described earlier, one SM-DP+ certificate may support both authentication and profile binding.

[0251] At 547, the eSIM device 506 receives the package.

[0252] At 548, the CD 506 may perform a DH using its ephemeral private and the received SM-DP+ ephemeral public key (ephPKsM-DP+) to generate a session key for encryption (ephDH encK) or a DH using the certificates (certSM-DP+, certeUICC) to obtain MAC key certDH macK.

[0253] At 550, the CD 506 verifies the integrity of the data received from the SM-DP+ 502 using either certSM-DP+ or certDH macK. At this point SM-DP+ 502 is authenticated. Including ephPKeUICC in the integrity protection data of 546 acts as an authentication challenge for this authentication response.

[0254] At step 552, the CD 506 decrypts the BPP using ephDH encK.

[0255] At step 554, the CD 506 installs the subscription (SIM) profile.

[0256] Then, the CD 506 sends 556 an installation result message to the SM-DP+ 502, which receives it at 557.

[0257] 2-Round Trip Embodiment - Protocol Sequence - elM Verification Proof

[0258] FIG. 6 shows a sequence 600 which illustrates a 2-round trip embodiment for provisioning a communication device, CD, 606, where the key pair of an elM 604 that is used to sign profile state management operations (PSMO) - such as the enable, disable, and delete operations described in GSMA SGP.32 version 1.1 - for the CD 606 is also used to sign a proof that the elM 604 has verified the SM-DP+ 602. The signed proof allows for the CD 606 to be able to verify the SM- DP+ 602 before sending a message to the SM-DP+ 602 via the elM 604 at 630. Because the PSMO has replay protection, a new signed message from the elM 604 is required for each eUICC signing, mitigating replay attacks. Other combinations of devices may be used to implement this embodiment. For example, and as shown in FIG. 6, the CD 606 may be a UE that comprises a subscriber module 607 in the form of a UICC in the UE. In such a combination, the sequence 600 may still be described as occurring in part with a CD 606, but it is to be understood that some of the steps may be carried out by the subscriber module 607 of the CD 606 despite making reference solely to the CD 506. In other words, some of the steps may be carried out by the subscriber module 607 and other steps may be carried out by the ME of the UE. The steps in this embodiment include:

[0259] At 610, the elM 604 generates an ephemeral key pair comprising a public key (ephPKelM) and a private key.

[0260] Then, with a secure and authenticated connection to the SM-DP+ 602 already established, the elM 604 sends 612 a message to the SM-DP+ 602 that includes: (1) a trigger that it wants to perform eSIM provisioning and (2) ephPKelM-

[0261] At 613, the SM-DP+ 602 receives the message.

[0262] At 614, the SM-DP+ 602 generates an ephemeral key pair comprising a public key (ephPKsM-DP+) and a private key.

[0263] The SM-DP+ 602 then responds 616 to the elM 604 with a package that includes: (1) ephPKsM-DP+, (2) a first signature, created using the private key corresponding to the certificate of the SM-DP+ 602 (certSM-DP+), over the ephemeral public key of the SM-DP+ 602, that is, ({ephPKsM-DP+}certSM-DP+), (3) the SM-DP+ 602 certificate (certSM-DP+) dedicated for profile provisioning, and (4) a second signature, creating using certSM-DP+, over ephPKsM-DP+ and the ephemeral public key of the elM 604 (ephPKelM)- In an alternative embodiment, a MAC may be used in lieu of a signature. In yet another embodiment, step 636 could also be performed during this step using the ephemeral private key of the SM-DP+ 602 and ephPKelM to derive MAC key ephDH macK and calculate an authentication code using ephDH macK.

[0264] At 617, the elM 604 receives the package.

[0265] At 618, the elM 604 verifies certSM-DP+-

[0266] At 620, the elM 604 verifies that the ephemeral public keys ephPKsM-DP+ and ephPKelM have been signed by the SM-DP+ 602 in order to know that the SM-DP+ 602 endorses these ephemeral public keys. Additionally, the elM 604 may sign a verification proof with its private key, which is a signed message to the CD 606 to prove that the elM 604 has authenticated the SM-DP+ 602. The verification proof, or signed data, may include ephPKsM-DP+ or its hash. In embodiments where a MAC is used, the elM 604 may perform DH in this step instead of 632 to generate a key for verifying the MAC. Then, the elM 604 sends 622 parts ( 1 )-(3) of the package, along with the signed verification proof to the CD 606. By providing the verification proof to the CD 606, attacks where malware, residing on the device 606, to communicate with a rogue elM and / or a rogue SM-DP+ to circumvent verifications made by a legitimate elM can be mitigated.

[0267] At 623, the CD 606 receives parts ( 1 )-(3) of the package.

[0268] At 624, the CD 606 verifies certSM-DP+-

[0269] At 626, the CD 606 verifies that the received ephemeral public key (ephPKsM-DP+) has been signed by the SM-DP+ 602 in order to know that the SM-DP+ 602 has generated and endorses this ephemeral public key. Additionally, the CD 606 verifies the signed verification proof, proceeding only to 628 if the verification is successful. In order to not increase the amount of data communicated to the CD 606, the eUICC packages described in GSMA SGP.32 version 1.1 can be leveraged. For example, the message transmitted at 622 could serve as the “enable profile” command of the eUICC package, granting automatic enabling of the subscription profile by the CD 606 after successful installation.

[0270] At 628, the CD 606 generates its own ephemeral key pair, which includes an ephemeral private key and ephemeral public key ephPKeUICC- In embodiments where the BPP created at step 644 is protected with a key derived based on certificates instead of an ephemeral key, the CD 606 in this step may only generate a random value to use as an authentication challenge instead of ephPKeUICC and for integrity protection at step 646.

[0271] Then, the CD 606 generates and sends 630 a package to the elM 604 with: (1) its own ephemeral public key (ephPKeUICC) and (2) a signature, created using the private key corresponding to certeUICC, over ephPKsM-DP+ and ephPKeUICC, that is, {ephPKsM-DP+, ephPKeUICC } certeUICC-

[0272] At 631, the elM 604 receives the package.

[0273] At 632, the elM 604 performs a DH using its ephemeral private key and ephPKsM-DP+ to generate a session key for encryption (ephDH_encK2) to encrypt certeUICC- A matching ID may also be encrypted with certeUICC to send to the SM-DP+ 602.

[0274] The elM 604 then adds to the package certeUICC encrypted using ephDH_encK2, namely, [certeUICC] ephDH_encK2. Afterwards, the package is sent 634 to the SM-DP+ 602. The certeUICC encryption enables the CD 606 identity to remain unexposed when sent from the elM 604 to the SM-DP+ 602 without relying on a security measure, such as HTTPS. The inclusion of ephPKsM-DP+ in the signature serves as completion of a challenge that was provided by the SM-DP+ 602 in a previous package, here at 616. In other embodiments other values provided by the SM-DP+ 602 may be used for the challenge. Examples include a sequence number, a session ID, and a random challenge. Additionally, some embodiments may have the signature encrypted together with certeUICC, that is, [{ephPKeUICC, ephPKsM-DP+} certeUICC, certeUICC] ephDH_encK2.

[0275] At 635, the SM-DP+ 602 receives the package.

[0276] At 636, the SM-DP+ 602 performs a DH using its ephemeral private key and ephPKelM to generate the same session key generated by the elM 604, ephDH_encK2.

[0277] At 638, the SM-DP+ 602 decrypts certeUICC using ephDH_encK2.

[0278] At 640, the SM-DP+ 602 verifies the signature of the data received using certeUICC- This verification acts as authentication of the CD 606. By using certeUICC, the SM-DP+ 602 can verify that the CD 606 has indeed signed the data, which contains data acting as authentication challenge provided by the SM-DP+ 602, that is, in this embodiment, the SM-DP+ ephemeral public key (ephPKsM-DP+)-

[0279] At 642, the SM-DP+ 602 may perform a DH using its ephemeral private key and the received eUICC ephemeral public key (ephPKeUICC) to generate a session key for encryption (ephDH encK) and / or a DH using the certificates (certSM-DP+, certeUICC) to obtain MAC key certDH macK. Using certDH macK, the SM-DP+ 602 can generate a MAC over the message at 646 instead of a signature, thereby reducing message size.

[0280] At 644, the SM-DP+ 602 creates a bound profile package (BPP) containing the subscription (SIM) profile. The BPP is encrypted using ephDH encK, that is, the SM-DP+ 602 creates [BPP]ephDH_encK.

[0281] Then, the SM-DP 602 sends 646 a package to the eSIM device 606 which includes: (1) [BPP]ephDH_encK and (2) integrity protection data for [BPP]ephDH_encK and ephPKeUICC- By including ephPKeUICC in the integrity protection data, the integrity protection data also acts as authentication of the SM-DP+ 602. In alternative embodiments, a random value may be used in lieu of ephPKeUICC for authentication, as described in 628. Integrity protection may be done using certSM-DP+ as shown in Fig. 5. However, in embodiments that include the MAC key certDH macK from step 642, integrity protection may be achieved by calculating a MAC using certDH macK. As described earlier, one SM-DP+ certificate may support both authentication and profile binding.

[0282] At 647, the eSIM device 606 receives the package.

[0283] At 648, the CD 606 may perform a DH using its ephemeral private and the received SM-DP+ ephemeral public key (ephPKsM-DP+) to generate a session key for encryption (ephDH encK) or a DH using the certificates (certSM-DP+, certeUICC) to obtain MAC key certDH macK.

[0284] At 650, the CD 606 verifies the integrity of the data received from the SM-DP+ 602 using either certSM-DP+ or certDH macK. At this point SM-DP+ 602 is authenticated. Including ephPKeUICC in the integrity protection data of 646 acts as an authentication challenge for this authentication response.

[0285] At step 652, the CD 606 decrypts the BPP using ephDH encK.

[0286] At step 654, the CD 606 installs the subscription (SIM) profile.

[0287] The eSIM device 606 then sends 656 an installation result message to the SM-DP+ 602, which receives it at 657.

[0288] 2-Round Trip Embodiment - Provisioning Flow

[0289] Fig. 9 illustrates a flow-chart of the 2-round trip provisioning flow 900 for the embodiment of Fig. 3. Here, the elM 304 takes a more active role to reduce the energy expended by the CD 306, such as by encrypting the Matching ID. The steps in this illustrated embodiment include:

[0290] At 910, the user has ordered a profile for its constrained eSIM device 306 and obtained an Activation Code (AC) which is now available at the elM 304. The loT Profile Assistant (IP A) 908 and eUICC 307 are part of the eSIM device 306.

[0291] At 912, the elM 304 generates an ephemeral key pair.

[0292] At 914, using the SM-DP+ address from the AC, the elM 304 establishes an HTTPS session with the SM-DP+ 302.

[0293] Then, the elM 304 follows GSMA SGP.32 version 1.1, for example, to initiate a mutual authentication flow with the SM-DP+ 302 by calling the ES9+.InitiateAuthentication function where the address of the SM-DP+ 302, the elM ephemeral public key, and eUICCInfol are provided 916 to and received 917 by the SM-DP+ 302. The eUICCInfol contains CA key identifiers for signing and verification available at the eUICC 307. This information is typically common to a batch of devices and may for example have been provided by the eUICC manufacturer to the device owner and further to the elM 304 when ordering the eUICCs. Alternatively, this information may, for example, have been read out earlier from the device 306, or another device in the batch. Or this information may have been obtained from the device 306 during an earlier profile download. At 918, the SM-DP+ 302 validates the address and selects key identifiers from eUICCInfol. It generates a transaction identifier and an ephemeral key pair. The SM-DP+ 302 signs the transaction ID and the SM-DP+ ephemeral public key using its private key corresponding to the SM-DP+ certificate valid for authentication and profile binding, which chains back to the selected CA for verification. The SM-DP+ 302 computes an ECDH shared secret using the SM-DP+ ephemeral private key and the elM ephemeral public key and derives a MAC key from the ECDH shared secret. The SM-DP+ 302 computes a MAC over the transaction ID and the SM-DP+ address using the derived MAC key.

[0294] The SM-DP+ 302 then provides 920 the transaction ID, SM-DP+ address, SM-DP+ certificate, SM-DP+ ephemeral public key, signature, selected CA key identifier, and MAC to the elM 304 in a package, which the elM 304 receives at 921.

[0295] At 922, the elM 304 verifies the received certificate and signature, and checks that the SM-DP+ OID of the received certificate matches the SM-DP+ OID in the AC, if present. The elM 304 computes the ECDH shared secret using the elM ephemeral private key and the SM- DP+ ephemeral public key and derives the MAC key from the ECDH shared secret. The elM 304 verifies the MAC using the derived MAC key and checks that the received address matches the used address in 914 and 916. The SM-DP+ 302 is now authenticated by the elM 304. For increased security, the elM 304 may optionally create a signed eUICC package containing a proof that the elM 304 performed the SM-DP+ authentication. The eUICC package is signed using the elM private key whose public key or certificate is stored in the eUICC 307. The proof may contain a hash of the transaction ID, SM-DP+ OID, and the SM- DP+ ephemeral public key to provide proof that elM 304 performed the SM-DP+ authentication and link the proof to SM-DP+ data.

[0296] At 924, upon the successful verifications of 922, the loT device 306 and the elM 304 establish a secure communication if not previously established.

[0297] Then, the function ESipa.TransferEimPackage is used to trigger profile download where the Transaction ID (TID), SM-DP+ certificate, SM-DP+ ephemeral public key, signature, selected CA key identifier, and optionally the eUICC Package are provided 926 to the IPA 908, which it receives at 927.

[0298] The IPA 908 then follows GSMA SGP.32 version 1.1, for example, to call the ESlOb.AuthenticateServer function with TID, SM-DP+ certificate, SM-DP+ ephemeral public key, the signature, profile download flag, device information, selected CA key identifier, and optionally an eUICC Package to send 928 to the eUICC 307, which receives it at 929. At 930, the eUICC 307 verifies the received certificate and signature, and stores the TID. The eUICC 307 may be configured to verify proof from the elM 304 that it authenticated the SM-DP+ 302 and demand such a proof to be provided in the form of a signed eUICC Package. The eUICC 307 (1) verifies the signed eUICC Package signature using the elM public key stored in the eUICC 307 (e.g., elM 304 raw public key or certificate), (2) checks the replay counter, (3) computes the hash of the transaction ID, SM-DP+ OID, and SM-DP+ ephemeral public key, and (4) checks that the hash matches the one in the received eUICC Package. Upon successful verification, the eUICC 307 generates an ephemeral key pair. The eUICC 307 signs the TID, SM-DP+ ephemeral public key, eUICC ephemeral public key, SM-DP+ OID obtained from the SM-DP+ certificate, device information, and profile download flag. The eUICC certificate corresponding to private key used to sign is selected such that it chains back to the CA with key identifier according to the selection by the SM-DP+ 302.

[0299] At 932, if the eUICC 307 is configured to provide the eUICC certificate, the eUICC computes an ECDH shared secret using the eUICC ephemeral private key and the SM-DP+ ephemeral public key and derives an encryption key from the ECDH shared secret. The eUICC 307 uses the encryption key to encrypt the eUICC certificate.

[0300] The eUICC 307 then provides 934 the TID, profile download flag, device information, eUICC ephemeral public key, signature, and optionally the encrypted certificate to the IPA 908, which receives it at 935.

[0301] Then, the IPA 908 follows GSMA SGP.32 version 1.1, for example, to call the ESipa.AuthenticateClient function to send 936 data to the elM 304, which it receives at 937. The signature and eUICC ephemeral public key is always sent. However, the following data may optionally be sent: profile download flag, device information, and encrypted eUICC certificate. This is because, in order to reduce the number of bytes transmitted by the loT device 306, the IPA 908 only sends the necessary bytes not already known by the elM 304. Note that the eUICC 307 may always provide an encrypted certificate, and the IPA 908 decides based on its configuration whether to provide the encrypted certificate to the elM 304 or if the elM 304 shall encrypt the certificate of the eUICC 307, which the elM 304 already has. In some embodiments, the IPA 908 may determine whether or not to send the encrypted eUICC certificate as a function of whether: (1) the IPA 908 has information regarding the availability of provisioning the subscription profile via an intermediate elM, such as elM 304, (2) the elM 304 is capable of securely providing the certificate of the eUICC 307 to the SM-DP+ 302 according to information stored in the eUICC 307 or the IPA 908, and (3) the IPA 908 is configured to avoid sending the encrypted certificate of the eUICC 307 whenever possible to reduce the number of transmitted bytes, or a combination thereof. At 938, the elM 304 derives an encryption key from the ECDH shared secret computed at 922. The elM 304 creates, using the MAC key derived at 922, a MAC on the Transaction ID, the SM-DP+ OID (obtained from SM-DP+ certificate at 922, for example), and the Matching ID obtained from the AC. The elM 304 encrypts the Matching ID, MID, using the encryption key. In some embodiments, the encrypted Matching ID may be obtained from eUICC 307 instead of the elM encrypting it. In this case, the Matching ID may be provided unencrypted from the elM 304 to the IP A 908 and further to the eUICC 307 at 926 and 928, and may be signed by the eUICC 307 at 930.

[0302] At 940, if the elM 304 did not obtain an encrypted eUICC certificate at 936, the elM 304 encrypts the eUICC certificate using the encryption key from 938.

[0303] The elM 304 calls the ES9+.AuthenticateClient function to provide 942 the following data to the SM-DP+ 302 in a package: TID, profile download flag, encrypted MID, device information, signature, encrypted eUICC certificate, eUICC ephemeral public key, and MAC. Any data not provided at 936 is known to the elM 304 and added to this package. The SM- DP+ 302 receives the package at 943.

[0304] At 944, the SM-DP+ 302 derives the encryption key from the ECDH shared secret of 918 and decrypts the encrypted Matching ID and the eUICC certificate, if the eUICC certificate was encrypted by the elM 304. The SM-DP+ 320 then verifies the received MAC using the MAC key from 918. If the eUICC 307 encrypted the eUICC certificate, the SM-DP+ 302 computes the ECDH shared secret using the SM-DP+ ephemeral private key and the eUICC ephemeral public key and derives an encryption key and a MAC key from the shared secret. The encryption key is used to decrypt the eUICC certificate. The eUICC 307 then verifies the eUICC certificate and the received signature. After successful verification, the eUICC 307 is authenticated. The SM-DP+ 302 then signs the TID and eUICC ephemeral public key using the SM-DP+ private key.

[0305] At 946, the SM-DP+ 302 checks that there is a subscription profile prepared for the given Matching ID (and / or EID). The SM-DP+ 302 may perform an eligibility check leveraging the provided device information. After a successful check, and if not already performed at 944, the SM-DP+ 302 computes the ECDH shared secret using the SM-DP+ ephemeral private key and the eUICC ephemeral public key and derives a session encryption key and a session MAC key from the shared secret. The base profile package (BPP), including profile metadata and a subscription profile, is created where the subscription profile is encrypted and integrity- protected using the session keys.

[0306] Then, the SM-DP+ 302 responds 948 to the elM 304 with a package that includes the TID, the signature from 944, and the BPP, which the elM 304 receives at 949. At 950, if not performed by the loT device 306, the elM 304 checks if the subscription profile can be installed on the eUICC 307 using the profile metadata from the BPP as well as, in some embodiments, information about the eUICC 307 (e.g., rules authorization table (RAT), information about installed profiles). Some of this information may be available to the elM 304. For example, the RAT is typically common to a batch of devices and may, as an example, have been provided by the manufacturer of the eUICC 307 to the device owner and further to the elM 304 when ordering eUICCs. Alternatively, this information may have been read out earlier from the device 306, or another device in the batch. As yet another example, the information may have been obtained from the device 306 during an earlier profile download. Information about installed profiles can be obtained by the elM 304 through earlier profile management operations (including profile provisioning).

[0307] The elM 304 then provides 952 the signature and BPP, and optionally the TID should the IPA 908 not have it, to the IPA 908, which receives it at 953.

[0308] Then, the IPA 908 sends 954 the ESI 0b. Authenticate ServerEnd function with the TID and signature to the eUICC 307, which receives it at 955.

[0309] At 956, the eUICC 307 verifies the signature over the TID and eUICC ephemeral public key to authenticate the SM-DP+ 302.

[0310] At 958, if supported by the loT device 306, the IPA 908 checks if the subscription profile can be installed using the profile metadata from the BPP as well as, in some embodiments, information about the eUICC 307 obtained by the IPA 908 from the eUICC 307 (e.g., rules authorization table (RAT), information about installed profiles).

[0311] Then, the IPA 908 calls the ESlOb.LoadBoundProfilePackage function with the BPP to send 960 the BPP to the eUICC 307, which it receives at 961.

[0312] At 962, if not already done at 932, the eUICC 307 derives the ECDH shared secret session keys using the eUICC ephemeral private key and the SM-DP+ ephemeral public key, then derives the encryption and MAC session keys. The subscription profile is decrypted and verified using the derived session keys while installing the subscription profile. A ProfilelnstallationResult notification is prepared by the eUICC 307.

[0313] Then, the ProfilelnstallationResult notification is sent 964 to the IPA 908, which receives it at 965.

[0314] The IPA 908 provides 966 the ProfilelnstallationResult notification to elM 304 by calling the ESipa.Handl eNotification function. The elM 304 receives the ProfilelnstallationResult notification at 967.

[0315] The elM 304 sends 968 an acknowledgement of successful delivery to the IPA 908, which it receives at 969. Then, the IPA 908 calls the ESlOb.RemoveNotificationFromList function to send 970 a trigger to the eUICC 307, which the eUICC 307 receives at 971. The trigger makes the eUICC 307 delete the ProfilelnstallationResult notification.

[0316] Finally, the elM 304 delivers 972 the ProfilelnstallationResult notification to the SM- DP+ 302 using the ES9+.HandleNotification function, which the SM-DP+ 302 receives at 973.

[0317] Example Provisioning Scenario

[0318] Fig. 7 depicts one example 700 of provisioning an eSIM profile according to an embodiment of the present disclosure. In this embodiment, intelligent fabric 701 comprises an eSIM device 702 and an NFC tag 710. Initially, the owner of the intelligent fabric 701 orders a subscription from an operator 704. The owner receives an activation code (AC) to be used for provisioning the subscription to the eSIM device 702 of the intelligent fabric 701. The AC contains information about the SM-DP+ 706, which in this example is at the operator 704 but may reside elsewhere, from where the eSIM profile can be provisioned. In this example, the owner uses a mobile phone as a device management entity, acting as elM 708, for eSIM provisioning. Other examples may have the elM 708 functioning as a cloud service. The elM 708 can determine the SM-DP+ 706 from the AC, allowing the user to initiate 720 the provisioning process from the elM 708. The result of 720 is a secure and authenticated connection 722 with the SM-DP+ 706, using a method such as HTTPS, to provide confidentiality and integrity protection for data to be exchanged. The connection 722 is important for not leaking privacy sensitive information such as the eUICC identity of the eSIM device 702, and for protecting against theft the Matching ID that was obtained from the AC and sent to the SM-DP+ 706 to identify the profile to be downloaded. As part of establishing the connection 722, the elM 708 may verify the TLS certificate of the SM-DP+ 706 to authenticate the SM-DP+ 706. If following the PKI from GSMA SGP.21 RSP Architecture Specification version 3.0, the TLS certificate chains back either to an eSIM- specific certificate authority (certificate issuer, CI) or to a publicly trusted certificate authority (CA).

[0319] In this example, the eSIM device 702 connects 724 to the elM 708 using NFC tag 710, though other connection methods available to the eSIM device 702 could be used, such as traditional network access (e.g., HTTPS). The connection 724 between the elM 708 and the eSIM device 702 may be secured, however in some cases the short range of access between the eSIM device 702 and the elM 708 serves as sufficient security, particularly against eavesdropping attacks. Upon provisioning the eSIM profile according to the methods disclosed herein, network access 726 is established to allow the transmission of application data over a network (e.g., 3GPP) between the eSIM device 702 via the operator 704, and a destination such as vendor 712.

[0320] Alternative Embodiments - HTTPS

[0321] In embodiments presented herein, before an elM triggers the provisioning it has established an HTTPS connection with an SM-DP+ to authenticate the SM-DP+ create a secure channel between the elM and the SM-DP+. However, in other embodiments the HTTPS connection may not be necessary because the SM-DP+ and the eUICC authenticate each other using a combination of their corresponding certificates and the ephemeral keys used as challenges. The eUICC certificate is then sent encrypted from the eUICC or elM, to the SM-DP+. In some of the embodiments where the elM shares an ephemeral key with the SM-DP+, the SM-DP+ and the elM may use the shared ephemeral keys to derive session encryption and MAC keys which can be used to encrypt and integrity-protect the communication between the elM and the SM-DP+. This could occur early in the method to ensure most of the communication is protected.

[0322] Alternative Embodiments - elM

[0323] In embodiments described herein, an elM is relied upon. However, some embodiments, such as where an elM does not actively participate other than for triggering the provisioning of the device, may not use an elM. Instead, portions of the exchange (e.g., when data is exchanged between the SM-DP+ and the eUICC) may be protected in other ways, such as by encrypting the eUICC certificate. The elM is intended to help a constrained device with eSIM provisioning, but some embodiments may utilize a more powerful device, in which case the elM is not necessary during the profile download. In these embodiments, the eSIM device would have the AC and use it to initiate the profile download. The AC may have been obtained from the elM in a profile download trigger, such as 814 of 3-round trip provisioning flow 800, which is illustrated on FIG. 8. Referring to 3-round trip provisioning flow 800 while further describing this embodiment, the checks performed by the elM at 836 and 862 are instead performed by the IP A. The eUICC certificate and MID encryption is always handled by the eUICC, regardless of an elM being present.

[0324] Alternatively, in another embodiment the eSIM device is a consumer device which does not make use of an elM at all. In this embodiment, the IPA and the elM are replaced by an LPA residing in the consumer eSIM device. The parts performed by the elM are instead performed by the LPA. For example, referring to 3-round trip provisioning flow 800 on FIG. 8, the checks performed by the elM 836 and 862 are performed by the LPA. The eUICC certificate and MID encryption is always handled by the eUICC. Alternative Embodiments - BPP Encryption

[0325] As disclosed herein, the base profile package (BPP) is encrypted using keys derived from a Diffie-Hellman key exchange (DH) performed with the ephemeral keys of the SM-DP+ and the eUICC. However, other embodiments may perform a DH with the certificates of the SM- DP+ and the eUICC.

[0326] Alternative Embodiments - eSIM Security

[0327] In embodiments where the eSIM device is in a physically secure environment (e.g., private and gated property), and the interface between it and the elM is range limited (e.g., NFC), a secure communication channel between the elM and the eSIM device is not necessary as there is not a possibility for a malicious entity to interact with the communication between the eSIM device and the elM.

[0328] Alternative Embodiments - Profile Metadata Verification

[0329] Some of the embodiments herein verify profile metadata when the profile is downloaded from the SM-DP+, instead of before the profile download starts. For non-constrained devices where large profiles are downloaded, profile metadata verification before the profile download starts may be desirable. This may still be done, for example, by adding an extra round trip to the 3 -round trip embodiment of sequence 200, after the profile eligibility check of 236 and before the profile is downloaded at 238.

[0330] Signature Verification

[0331] In various embodiments of the systems and methods described herein, certificates are verified in any suitable fashion as will occur to those skilled in the art in view of this disclosure. For example, a certificate may be cryptographically signed using other cryptographic certificates in a Web of Trust (WoT) framework, where a certificate is considered valid upon accumulation of signatures with certificates having a sufficiently high reputation. In other embodiments, a certificate may be deemed invalid unless it is signed with a known-good root certificate or with a signing certificate signed (perhaps via one or more intermediate certificates) by a known-good root certificate. In some such embodiments, both the subject certificate and the signing certificates in the chain are also compared with a certificate revocation list (e.g., in accordance with IETF RFC 5280, “Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile”), and if any of those certificates has been revoked, the verification fails.

[0332] Additional Embodiments

[0333] FIG. 10 shows a UE 2200 in accordance with some embodiments. As used herein, a UE refers to a device capable, configured, arranged and / or operable to communicate wirelessly with network nodes and / or other UEs. Examples of a UE include, but are not limited to, a smart phone, mobile phone, cell phone, voice over IP (VoIP) phone, wireless local loop phone, desktop computer, personal digital assistant (PDA), wireless cameras, gaming console or device, music storage device, playback appliance, wearable terminal device, wireless endpoint, mobile station, tablet, laptop, laptop-embedded equipment (LEE), laptop-mounted equipment (LME), smart device, wireless customer-premise equipment (CPE), vehicle-mounted or vehicle embedded / integrated wireless device, etc. Other examples include any UE identified by the 3rd Generation Partnership Project (3 GPP), including a narrow band internet of things (NB-IoT) UE, a machine type communication (MTC) UE, and / or an enhanced MTC (eMTC) UE.

[0334] A UE may support device-to-device (D2D) communication, for example by implementing a 3GPP standard for sidelink communication, Dedicated Short-Range Communication (DSRC), vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), or vehicle-to-everything (V2X). In other examples, a UE may not necessarily have a user in the sense of a human user who owns and / or operates the relevant device. Instead, a UE may represent a device that is intended for sale to, or operation by, a human user but which may not, or which may not initially, be associated with a specific human user (e.g., a smart sprinkler controller). Alternatively, a UE may represent a device that is not intended for sale to, or operation by, an end user but which may be associated with or operated for the benefit of a user (e.g., a smart power meter).

[0335] The UE 2200 includes processing circuitry 2202 that is operatively coupled via a bus 2204 to an input / output interface 2206, a power source 2208, a memory, or storage medium, 2210, a communication interface 2212, and / or any other component, or any combination thereof. Certain UEs may utilize all or a subset of the components shown in FIG. 10. The level of integration between the components may vary from one UE to another UE. Further, certain UEs may contain multiple instances of a component, such as multiple processors, memories, transceivers, transmitters, receivers, etc.

[0336] The processing circuitry 2202 is configured to process instructions and data and may be configured to implement any sequential state machine operative to execute instructions stored as machine-readable computer programs in the memory 2210. The processing circuitry 2202 may be implemented as one or more hardware-implemented state machines (e.g., in discrete logic, field- programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), etc.); programmable logic together with appropriate firmware; one or more stored computer programs, general-purpose processors, such as a microprocessor or digital signal processor (DSP), together with appropriate software; or any combination of the above. For example, the processing circuitry 2202 may include multiple central processing units (CPUs).

[0337] The memory 2210 may be or be configured to include memory such as random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic disks, optical disks, hard disks, removable cartridges, flash drives, and so forth. In one example, the memory 2210 includes one or more application programs 2214, such as an operating system, web browser application, a widget, gadget engine, or other application, and corresponding data 2216. The memory 2210 may store, for use by the UE 2200, any of a variety of various operating systems or combinations of operating systems.

[0338] The memory 2210 may be configured to include a number of physical drive units, such as redundant array of independent disks (RAID), flash memory, USB flash drive, external hard disk drive, thumb drive, pen drive, key drive, high-density digital versatile disc (HD- DVD) optical disc drive, internal hard disk drive, Blu-Ray optical disc drive, holographic digital data storage (HDDS) optical disc drive, external mini-dual in-line memory module (DIMM), synchronous dynamic random access memory (SDRAM), external micro-DIMM SDRAM, a memory comprised in a smartcard such as tamper resistant module in the form of a universal integrated circuit card (UICC) including one or more subscriber identity modules (SIMs), such as a USIM and / or ISIM, other memory, or any combination thereof. The UICC may for example be an embedded UICC (eUICC), integrated UICC (iUICC) or a removable UICC commonly known as “SIM card.” The memory 2210 may allow the UE 2200 to access instructions, application programs and the like, stored on transitory or non-transitory memory media, to off-load data, or to upload data. An article of manufacture, such as one utilizing a communication system may be tangibly embodied as or in the memory 2210, which may be or comprise a device-readable storage medium.

[0339] The processing circuitry 2202 may be configured to communicate with an access network or other network using the communication interface 2212. The communication interface 2212 may comprise one or more communication subsystems and may include or be communicatively coupled to an antenna 2222. The communication interface 2212 may include one or more transceivers used to communicate, such as by communicating with one or more remote transceivers of another device capable of wireless communication (e.g., another UE or a network node in an access network). Each transceiver may include a transmitter 2218 and / or a receiver 2220 appropriate to provide network communications (e.g., optical, electrical, frequency allocations, and so forth). Moreover, the transmitter 2218 and receiver 2220 may be coupled to one or more antennas (e.g., antenna 2222) and may share circuit components, software, or firmware, or alternatively be implemented separately.

[0340] In the illustrated embodiment, communication functions of the communication interface 2212 may include cellular communication, Wi-Fi communication, LPWAN communication, data communication, voice communication, multimedia communication, short-range communications such as Bluetooth, near-field communication, location-based communication such as the use of the global positioning system (GPS) to determine a location, another like communication function, or any combination thereof. Communications may be implemented in according to one or more communication protocols and / or standards, such as IEEE 802.11, Code Division Multiplexing Access (CDMA), Wideband Code Division Multiple Access (WCDMA), GSM, LTE, New Radio (NR), UMTS, WiMax, Ethernet, transmission control protocol / internet protocol (TCP / IP), synchronous optical networking (SONET), Asynchronous Transfer Mode (ATM), QUIC, Hypertext Transfer Protocol (HTTP), and so forth.

[0341] A UE, when in the form of an Internet of Things (loT) device, may be a device for use in one or more application domains, these domains comprising, but not limited to, city wearable technology, extended industrial application and healthcare. Non-limiting examples of such an loT device are a device which is or which is embedded in: a connected refrigerator or freezer, a TV, a connected lighting device, an electricity meter, a robot vacuum cleaner, a voice controlled smart speaker, a home security camera, a motion detector, a thermostat, a smoke detector, a door / window sensor, a flood / moisture sensor, an electrical door lock, a connected doorbell, an air conditioning system like a heat pump, an autonomous vehicle, a surveillance system, a weather monitoring device, a vehicle parking monitoring device, an electric vehicle charging station, a smart watch, a fitness tracker, a head-mounted display for Augmented Reality (AR) or Virtual Reality (VR), a wearable for tactile augmentation or sensory enhancement, a water sprinkler, an animal- or itemtracking device, a sensor for monitoring a plant or animal, an industrial robot, an Unmanned Aerial Vehicle (UAV), and any kind of medical device, like a heart rate monitor or a remote controlled surgical robot. A UE in the form of an loT device comprises circuitry and / or software in dependence of the intended application of the loT device in addition to other components as described in relation to the UE 2200 shown in FIG. 10.

[0342] As yet another specific example, in an loT scenario, a UE may represent a machine or other device that performs monitoring and / or measurements and transmits the results of such monitoring and / or measurements to another UE and / or a network node. The UE may in this case be an M2M device, which may in a 3 GPP context be referred to as an MTC device. As one particular example, the UE may implement the 3 GPP NB-IoT standard. In other scenarios, a UE may represent a vehicle, such as a car, a bus, a truck, a ship and an airplane, or other equipment that is capable of monitoring and / or reporting on its operational status or other functions associated with its operation.

[0343] FIG. 11 is a block diagram of a host, or server, 4400 in accordance with various aspects described herein. As used herein, the host 4400 may be or comprise various combinations hardware and / or software, including a standalone server, a blade server, a cloud-implemented server, a distributed server, a virtual machine, container, or processing resources in a server farm. The host 4400 may provide one or more services to one or more UEs.

[0344] The host 4400 includes processing circuitry 4402 that is operatively coupled via a bus 4404 to an input / output interface 4406, a network interface 4408, a power source 4410, and a memory 4412. Other components may be included in other embodiments. Features of these components may be substantially similar to those described with respect to the devices of previous figures, such as FIG. 10, such that the descriptions thereof are generally applicable to the corresponding components of host 4400.

[0345] The memory 4412 may comprise one or more non-transitory computer-readable storage media upon which are stored one or more computer programs including one or more host application programs 4414 and data 4416, which may include user data, e.g., data generated by a UE for the host 4400 or data generated by the host 4400 for a UE. Embodiments of the host 4400 may utilize only a subset or all of the components shown. The host application programs 4414 may be implemented in a container-based architecture and may provide support for video codecs (e.g., Versatile Video Coding (VVC), High Efficiency Video Coding (HEVC), Advanced Video Coding (AVC), MPEG, VP9) and audio codecs (e.g., FLAC, Advanced Audio Coding (AAC), MPEG, G.711), including transcoding for multiple different classes, types, or implementations of UEs (e.g., handsets, desktop computers, wearable display systems, heads-up display systems). The host application programs 4414 may also provide for user authentication and licensing checks and may periodically report health, routes, and content availability to a central node, such as a device in or on the edge of a core network. Accordingly, the host 4400 may select and / or indicate a different host for over-the- top services for a UE. The host application programs 4414 may support various protocols, such as the HTTP Live Streaming (HLS) protocol, Real-Time Messaging Protocol (RTMP), Real-Time Streaming Protocol (RTSP), Dynamic Adaptive Streaming over HTTP (MPEG- DASH), etc.

[0346] Although the computing devices described herein (e.g., UEs, network nodes, hosts) may include the illustrated combination of hardware components, other embodiments may comprise computing devices with different combinations of components. It is to be understood that these computing devices may comprise any suitable combination of hardware and / or software needed to perform the tasks, features, functions, and methods disclosed herein. Determining, calculating, obtaining or similar operations described herein may be performed by processing circuitry, which may process information by, for example, converting the obtained information into other information, comparing the obtained information or converted information to information stored in the network node, and / or performing one or more operations based on the obtained information or converted information, and as a result of said processing making a determination. Moreover, while components are depicted as single boxes located within a larger box, or nested within multiple boxes, in practice, computing devices may comprise multiple different physical components that make up a single illustrated component, and functionality may be partitioned between separate components. For example, a communication interface may be configured to include any of the components described herein, and / or the functionality of the components may be partitioned between the processing circuitry and the communication interface. In another example, non-computationally intensive functions of any of such components may be implemented in software or firmware and computationally intensive functions may be implemented in hardware.

[0347] In certain embodiments, some or all of the functionality described herein may be provided by processing circuitry executing instructions stored on in memory, which in certain embodiments may be a computer program product in the form of a non-transitory computer-readable storage medium. In alternative embodiments, some or all of the functionality may be provided by the processing circuitry without executing instructions stored on a separate or discrete device-readable storage medium, such as in a hard-wired manner. In any of those particular embodiments, whether executing instructions stored on a non-transitory computer-readable storage medium or not, the processing circuitry can be configured to perform the described functionality. The benefits provided by such functionality are not limited to the processing circuitry alone or to other components of the computing device, but are enjoyed by the computing device as a whole, and / or by end users and a wireless network generally.

[0348] It will be appreciated that computer systems are increasingly taking a wide variety of forms. In this description and in the claims, the terms “controller,” “computer system,” or “computing system” are defined broadly as including any device or system — or combination thereof — that includes at least one physical and tangible processor and a physical and tangible memory capable of having thereon computer-executable instructions that may be executed by a processor. By way of example, not limitation, the term “computer system” or “computing system,” as used herein is intended to include personal computers, desktop computers, laptop computers, tablets, hand-held devices (e.g., mobile telephones, PDAs, pagers), microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, multi-processor systems, network PCs, distributed computing systems, datacenters, message processors, routers, switches, and even devices that conventionally have not been considered a computing system, such as wearables (e.g., glasses).

[0349] The computing system also has thereon multiple structures often referred to as an “executable component.” For instance, the memory of a computing system can include an executable component. The term “executable component” is the name for a structure that is well understood to one of ordinary skill in the art in the field of computing as being a structure that can be software, hardware, or a combination thereof. For instance, when implemented in software, one of ordinary skill in the art would understand that the structure of an executable component may include software objects, routines, methods, and so forth, that may be executed by one or more processors on the computing system, whether such an executable component exists in the heap of a computing system, or whether the executable component exists on computer-readable storage media. The structure of the executable component exists on a computer-readable medium in such a form that it is operable, when executed by one or more processors of the computing system, to cause the computing system to perform one or more functions, such as the functions and methods described herein. Such a structure may be computer-readable directly by a processor — as is the case if the executable component were binary. Alternatively, the structure may be structured to be interpretable and / or compiled — whether in a single stage or in multiple stages — so as to generate such binary that is directly interpretable by a processor.

[0350] The terms “component,” “service,” “engine,” “module,” “control,” “generator,” or the like may also be used in this description. As used in this description and in this case, these terms — whether expressed with or without a modifying clause — are also intended to be synonymous with the term “executable component” and thus also have a structure that is well understood by those of ordinary skill in the art of computing.

[0351] In terms of computer implementation, a computer is generally understood to comprise one or more processors or one or more controllers, and the terms computer, processor, and controller may be employed interchangeably. When provided by a computer, processor, or controller, the functions may be provided by a single dedicated computer or processor or controller, by a single shared computer or processor or controller, or by a plurality of individual computers or processors or controllers, some of which may be shared or distributed. Moreover, the term “processor” or “controller” also refers to other hardware capable of performing such functions and / or executing software, such as the example hardware recited above.

[0352] In general, the various exemplary embodiments may be implemented in hardware or special purpose chips, circuits, software, logic, or any combination thereof. For example, some aspects may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor, or other computing device, although the disclosure is not limited thereto. While various aspects of the exemplary embodiments of this disclosure may be illustrated and described as block diagrams, flow charts, or using some other pictorial representation, it is well understood that these blocks, apparatus, systems, techniques, or methods described herein may be implemented in, as nonlimiting examples, hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof.

[0353] Abbreviations and Defined Terms

[0354] To assist in understanding the scope and content of this written description and the appended claims, a select few terms are defined directly below. Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which the present disclosure pertains.

[0355] The terms “approximately,” “about,” and “substantially,” as used herein, represent an amount or condition close to the specific stated amount or condition that still performs a desired function or achieves a desired result. For example, the terms “approximately,” “about,” and “substantially” may refer to an amount or condition that deviates by less than 10%, or by less than 5%, or by less than 1%, or by less than 0.1%, or by less than 0.01% from a specifically stated amount or condition.

[0356] Various aspects of the present disclosure, including devices, systems, and methods may be illustrated with reference to one or more embodiments or implementations, which are exemplary in nature. As used herein, the term “exemplary” means “serving as an example, instance, or illustration,” and should not necessarily be construed as preferred or advantageous over other embodiments disclosed herein. In addition, reference to an “implementation” of the present disclosure or embodiments includes a specific reference to one or more embodiments thereof, and vice versa, and is intended to provide illustrative examples without limiting the scope of the present disclosure, which is indicated by the appended claims rather than by the present description.

[0357] As used in the specification, a word appearing in the singular encompasses its plural counterpart, and a word appearing in the plural encompasses its singular counterpart, unless implicitly or explicitly understood or stated otherwise. Thus, it will be noted that, as used in this specification and the appended claims, the singular forms “a,” “an” and “the” include plural referents unless the context clearly dictates otherwise. For example, reference to a singular referent (e.g., “a widget”) includes one, two, or more referents unless implicitly or explicitly understood or stated otherwise. Similarly, reference to a plurality of referents should be interpreted as comprising a single referent and / or a plurality of referents unless the content and / or context clearly dictate otherwise. For example, reference to referents in the plural form (e.g., “widgets”) does not necessarily require a plurality of such referents. Instead, it will be appreciated that independent of the inferred number of referents, one or more referents are contemplated herein unless stated otherwise. References in the specification to "one embodiment," "an embodiment," "an example embodiment, " and the like indicate that the embodiment described may include a particular feature, structure, or characteristic, but it is not necessary that every embodiment includes the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0358] It shall be understood that although the terms "first" and "second" etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first element could be termed a second element, and similarly, a second element could be termed a first element, without departing from the scope of example embodiments. As used herein, the term "and / or" includes any and all combinations of one or more of the associated listed terms.

[0359] It will be further understood that the terms "comprises", "comprising", "has", "having", "includes" and / or "including", when used herein, specify the presence of stated features, elements, and / or components etc., but do not preclude the presence or addition of one or more other features, elements, components and / or combinations thereof.

[0360] When an act or operation is described herein as occurring “based on” or “as a function of’ a particular thing, the system is configured so that the act or operation is, according to the context, (a) either performed or not performed, or (b) performed in different ways, in either case depending on one or more characteristics of the thing.

[0361] At least some of the following abbreviations may be used in this disclosure. If there is an inconsistency between abbreviations, preference should be given to how it is used above. If listed multiple times below, the first listing should be preferred over any subsequent listing(s).

[0362] AC Activation Code

[0363] CA Certificate Authority

[0364] CoAP Constrained Application Protocol

[0365] DH Diffie-Hellmann

[0366] DTLS Datagram Transport Layer Security

[0367] ECDH Elliptic Curve DH eCO elM Configuration Operation

[0368] EID eUICC ID elM eSIM remote loT Manager eSIM Embedded SIM eUICC Embedded UICC

[0369] HTTP Hypertext Transfer Protocol

[0370] HTTPS HTTP over TLS ieUICC Integrated eUICC loT Internet of Things

[0371] IPA loT Profile Assistant iUICC Integrated UICC

[0372] M2M Machine to Machine

[0373] MAC Message Authentication Code

[0374] MNO Mobile Network Operator

[0375] OID Object Identifier

[0376] PSMO Profile State Management Operation

[0377] SIM Subscriber Identity Module

[0378] SM-DP Subscription Manager Data Preparation

[0379] TLS Transport Layer Security

[0380] UICC Universal Integrated Circuit Card

[0381] Conclusion

[0382] The present disclosure includes any novel feature or combination of features disclosed herein either explicitly or any generalization thereof. Various modifications and adaptations to the foregoing exemplary embodiments of this disclosure may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompanying drawings. However, any and all modifications will still fall within the scope of the non-limiting and exemplary embodiments of this disclosure.

[0383] It is understood that for any given component or embodiment described herein, any of the possible candidates or alternatives listed for that component may generally be used individually or in combination with one another, unless implicitly or explicitly understood or stated otherwise. Additionally, it will be understood that any list of such candidates or alternatives is merely illustrative, not limiting, unless implicitly or explicitly understood or stated otherwise.

[0384] In addition, unless otherwise indicated, numbers expressing quantities, constituents, distances, or other measurements used in the specification and claims are to be understood as being modified by the term “about,” as that term is defined herein. Accordingly, unless indicated to the contrary, the numerical parameters set forth in the specification and attached claims are approximations that may vary depending upon the desired properties sought to be obtained by the subject matter presented herein. At the very least, and not as an attempt to limit the application of the doctrine of equivalents to the scope of the claims, each numerical parameter should at least be construed in light of the number of reported significant digits and by applying ordinary rounding techniques. Notwithstanding that the numerical ranges and parameters setting forth the broad scope of the subject matter presented herein are approximations, the numerical values set forth in the specific examples are reported as precisely as possible. Any numerical values, however, inherently contain certain errors necessarily resulting from the standard deviation found in their respective testing measurements.

[0385] Any headings and subheadings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. The terms and expressions which have been employed herein are used as terms of description and not of limitation, and there is no intention in the use of such terms and expressions of excluding any equivalents of the features shown and described or portions thereof, but it is recognized that various modifications are possible within the scope of the present disclosure. Thus, it should be understood that although the present disclosure has been specifically disclosed in part by certain embodiments, and optional features, modification and variation of the concepts herein disclosed may be resorted to by those skilled in the art, and such modifications and variations are considered to be within the scope of this present description.

[0386] It will also be appreciated that systems, devices, products, kits, methods, and / or processes, according to certain embodiments of the present disclosure may include, incorporate, or otherwise comprise properties or features (e.g., components, members, elements, parts, and / or portions) described in other embodiments disclosed and / or described herein. Accordingly, the various features of certain embodiments can be compatible with, combined with, included in, and / or incorporated into other embodiments of the present disclosure. Thus, disclosure of certain features relative to a specific embodiment of the present disclosure should not be construed as limiting application or inclusion of said features to the specific embodiment. Rather, it will be appreciated that other embodiments can also include said features, members, elements, parts, and / or portions without necessarily departing from the scope of the present disclosure.

[0387] Moreover, unless a feature is described as requiring another feature in combination therewith, any feature herein may be combined with any other feature of a same or different embodiment disclosed herein. Furthermore, various well-known aspects of illustrative systems, methods, apparatus, and the like are not described herein in particular detail in order to avoid obscuring aspects of the example embodiments. Such aspects are, however, also contemplated herein.

[0388] It will be apparent to one of ordinary skill in the art that methods, devices, device elements, materials, procedures, and techniques other than those specifically described herein can be applied to the practice of the described embodiments as broadly disclosed herein without resort to undue experimentation. All art-known functional equivalents of methods, devices, device elements, materials, procedures, and techniques specifically described herein are intended to be encompassed by this present disclosure. When a group of materials, compositions, components, or compounds is disclosed herein, it is understood that all individual members of those groups and all subgroups thereof are disclosed separately. When a Markush group or other grouping is used herein, all individual members of the group and all combinations and sub-combinations possible of the group are intended to be individually included in the disclosure. The above-described embodiments are examples only. Alterations, modifications, and variations may be effected to the particular embodiments by those of skill in the art without departing from the scope of the description, which is defined solely by the appended claims.

Claims

CLAIMS1. A method (300, 900) for installing a subscription profile from a provisioning server (302), PS, to a subscriber module (307) of a communication device (306), CD, the subscriber module (307) having a CD cryptographic certificate associated with a CD public / private key pair and comprising a subscriber module identifier, and the PS (302) having a PS cryptographic certificate associated with a PS public / private key pair, the method comprising: receiving (315, 929), by the CD (306), a first message, wherein the first message includes the PS cryptographic certificate, a first PS cryptographic signature, and a PS ephemeral public key of a PS ephemeral key pair; and wherein the first PS cryptographic signature has been created using a PS private key of the PS public / private key pair and is based on at least the PS ephemeral public key; verifying (316, 930), by the subscriber module (307), the PS cryptographic certificate; verifying (318, 930), by the subscriber module (307), the first PS cryptographic signature using the PS cryptographic certificate; sending (322, 934) a second message toward the PS (302), the second message comprising a CD ephemeral public key of a CD ephemeral key pair and a first CD signature, wherein the first CD signature is generated (320, 930) by the subscriber module (307) using the CD private key and is based at least on the PS ephemeral public key and the CD ephemeral public key, and wherein the CD ephemeral key pair is generated (320, 930) at the subscriber module (307) of the CD (306) and comprises a CD ephemeral private key and the CD ephemeral public key; receiving (335, 955, 961), by the CD (306), a third message, wherein the third message contains a subscription profile; wherein the subscription profile is encrypted using a second session key; and wherein the third message includes integrity protection data; verifying (338, 956), by the subscriber module (307), the integrity of the third message as a function of the integrity protection data, wherein the PS (302) is authenticated as a result of the verification; decrypting (340, 962), by the subscriber module (307), the subscription profile using the second session key; and attempting, by the subscriber module (307), to install (342, 962) the subscription profile.

2. The method of claim 1, comprising determining, by the CD (306), whether to send or not send the CD cryptographic certificate as part of the second message, wherein the determining is based on: whether the CD (306) has information regarding availability of provisioning of the subscription profile via an intermediate entity eSIM loT remote manager (304), ERM, whether the ERM (304) is capable of securely providing the CD cryptographic certificate to the PS (302) according to information stored in the CD (306), and whether the CD (306) is configured to avoid sending the CD cryptographic certificate whenever possible to reduce the number of transmitted bytes.

3. The method of claim 1, comprising the CD (306) sending (344, 964) the PS (302) a further message indicating a result of the attempt to install the subscription profile.

4. The method of claim 1, wherein the second message comprises an encrypted portion having a payload that is encrypted, the payload comprising the CD cryptographic certificate, and wherein the encrypted portion is encrypted (932) by the subscriber module (307) using a first session key.

5. The method of claim 4, wherein the first session key is determined (320, 932) by the subscriber module (307) as a function of the CD ephemeral private key and the PS ephemeral public key.

6. The method of claim 1, wherein the second message comprises profile identifier information, and wherein the profile identifier information comprises one of a matching identifier, MID, an encrypted MID, and an indication that the MID is not used, wherein the encrypted MID is encrypted by the subscriber module (307).

7. The method of claim 1, wherein the second session key (336, 962) is determined by the subscriber module (307) as a function of the CD ephemeral private key and the PS ephemeral public key.

8. The method of claim 1, wherein the sending and receiving steps each comprise sending information via an eSIM loT remote manager (304), ERM, the method comprising: before receiving the first message: establishing (914) a secure and authenticated connection between the ERM (304) and the PS (302), and sending (310, 916) a trigger to receive the first message;wherein receiving the first message comprises receiving (921), by the ERM (304), the first message through the secure and authenticated connection, verifying (922), by the ERM (304), the PS cryptographic certificate; verifying (922), by the ERM (304), the first PS cryptographic signature using the PS cryptographic certificate; and if the two verification steps by the ERM (304) are successful, forwarding (926) the first message to the CD (306).

9. The method of claim 8, wherein the ERM (304) comprises a database that is configured to store one or more CD certificates, wherein sending the second message, when the second message does not contain an encrypted portion having a payload comprising the CD cryptographic certificate, comprises: obtaining the CD cryptographic certificate from the database; and adding the encrypted portion to the second message, the encrypted portion comprising the CD cryptographic certificate, wherein the encrypted portion is encrypted (940) using a third session key.

10. The method of claim 9, wherein the third session key is generated (922) using an ERM ephemeral private key and the PS ephemeral public key, wherein an ERM ephemeral key pair is generated (912) by the ERM and comprises the ERM ephemeral private key and an ERM ephemeral public key.

11. The method of claim 10, wherein the second message comprises the ERM ephemeral public key.

12. The method of claim 10, comprising: before receiving (921) the first message, but after establishing (914) a secure and authenticated connection between the ERM (304) and the PS (302), sending (916) the ERM ephemeral public key to the PS (302) as the trigger to receive the first message, wherein the first message comprises a second PS cryptographic signature generated by the PS (302) using the PS private key and is based on the ERM ephemeral public key; and wherein receiving (921) the first message comprises verifying (922), by the ERM (304), the second PS cryptographic signature using the PS cryptographic certificate.

13. The method of claim 12, wherein the ERM (304) has a public / private key pair, and wherein the ERM public key of the ERM public / private key pair is stored in the subscriber module (307), comprising:after establishing a secure and authenticated connection between the ERM (304) and the PS (302) and before forwarding the first message to the CD (306), adding, by the ERM (304), a first ERM signature to the first message, wherein the first ERM signature is generated by the ERM (304) using the ERM private key of the ERM public / private key pair, and said generation is based further on the PS ephemeral public key; and verifying, by the subscriber module (307), the first ERM signature using the ERM public key.

14. The method of claim 8, wherein profile identifier information comprises at least one of a matching identifier, MID, an encrypted MID, and an indication that MID is not used, and wherein the second message comprises the profile identifier information, and wherein the encrypted MID is encrypted (938) by the ERM (304).

15. The method of claim 4 or 5, wherein at least the first CD signature and the profile identifier information of the second message are within the encrypted portion.

16. The method of claim 1, wherein the integrity protection data in the third message comprises a cryptographic signature created by the PS (302) using the PS private key based on at least the CD ephemeral public key, and wherein the PS (302) is authenticated by the subscriber module (307) by verifying (956) the cryptographic signature using the PS public key.

17. The method of claim 1, wherein the integrity protection data in the third message comprises a Message Authentication Code, MAC, created using a MAC key based on at least the CD ephemeral public key, and wherein the PS (302) is authenticated by the subscriber module (307) by verifying the MAC using the MAC key, wherein the MAC key is derived by the subscriber module (307) from the CD private key and the PS public key.

18. A communication device (306) comprising a subscriber module (307), wherein the subscriber module (307) is a UICC selected from an embedded UICC, eUICC, integrated UICC, iUICC, or integrated eUICC, ieUICC, the communication device (306) being configured with programming instructions (2214) executable to implement the method of any one of claims 1- 17.

19. A method (300, 900) for sending a subscription profile from a provisioning server (302), PS, to a subscriber module (307) of a communication device (306), CD, the subscriber module (307) having a CD cryptographic certificate associated with a CD public / private key pair, and the PS (302) having a PS cryptographic certificate associated with a PS public / private key pair and comprising a PS database, the method comprising: sending (314, 920), by the PS (302), a first message toward the CD (306),wherein the first message includes the PS cryptographic certificate, a first PS cryptographic signature, and a PS ephemeral public key, where a PS ephemeral key pair comprises the PS ephemeral public key and a PS ephemeral private key; and wherein the first PS cryptographic signature is created (918) by the PS (302) using the PS private key and is based on at least the PS ephemeral public key; receiving (323, 943), by the PS (302), a second message, the second message comprising a CD ephemeral public key, a first CD signature, profile identifier information, and an encrypted portion, wherein the first CD signature is created using the CD private key and is based on at least the PS ephemeral public key and the CD ephemeral public key; wherein the encrypted portion has a payload comprising the CD cryptographic certificate, and wherein the encrypted portion is encrypted using one of a first session key and a third session key; decrypting (326, 944), by the PS (302), the encrypted portion using one of the first session key and the third session key to obtain the CD cryptographic certificate; verifying (328, 944), by the PS (302), the CD cryptographic certificate and the first CD signature to authenticate the CD, wherein the verification of the first CD signature is performed using the CD cryptographic certificate; selecting (332, 946), by the PS (302), the subscription profile to be provisioned based on the profile identifier information; and sending (334, 948), by the PS (302), a third message toward the CD (306), wherein the third message contains the selected subscription profile; wherein the subscription profile is encrypted (946) using a second session key; and wherein the third message includes integrity protection data.

20. The method of claim 19, comprising the PS (302) receiving (345, 973) from the CD (306) a further message indicating a result of the attempt to install the subscription profile.

21. The method of claim 19, wherein the first session key is determined as a function of the PS ephemeral private key and the CD ephemeral public key.

22. The method of claim 19, wherein the second session key is determined as a function of the PS ephemeral private key and the CD ephemeral public key.

23. The method of claim 19, wherein the sending and receiving steps each comprise sending information via an eSIM loT remote manager (304), ERM, and wherein an ERM ephemeral key pair is generated by the ERM (304) and comprises the ERM ephemeral private key and an ERM ephemeral public key, the method comprising: before sending (314, 920) the first message, but after establishing (914) a secure and authenticated connection between the ERM (304) and the PS (302), receiving (917) the ERM ephemeral public key at the PS (302) as a trigger to send the first message, wherein the first message comprises a second PS cryptographic signature generated by the PS (302) using the PS private key and is based on the ERM ephemeral public key.

24. The method of claim 19, wherein the sending and receiving steps each comprise sending information via an eSIM loT remote manager (304), ERM, and wherein an ERM ephemeral key pair is generated by the ERM (304) and comprises the ERM ephemeral private key and an ERM ephemeral public key, and wherein the second message comprises the ERM ephemeral public key.

25. The method of claim 23 or claim 24, wherein the third session key is determined as a function of the PS ephemeral private key and the ERM ephemeral public key.

26. The method of claim 19, wherein the profile identifier information comprises a matching identifier, MID, where the MID points to a specific subscription profile in the PS database.

27. The method of claim 26, wherein the MID is encrypted (938) using one of the first session key and the third session key, and wherein the encrypted MID is decrypted (944) by the PS (302) using one of the first session key and the third session key.

28. The method of claim 19, wherein the profile identifier information comprises an indication that the MID is not used and the subscriber module identifier of the CD cryptographic certificate is used to select a subscription profile in the PS database.

29. The method of claim 19, wherein at least the first CD signature and profile identifier information of the second message is within the encrypted portion.

30. The method of claim 19, wherein the integrity protection data in the third message comprises a cryptographic signature created (944) at the PS (302) using the PS private key and based on at least the CD ephemeral public key.

31. The method of claim 19, wherein the integrity protection data in the third message comprises a Message Authentication Code, MAC, created (944) at the PS (302) using a MAC key and based on at least the CD ephemeral public key, wherein the MAC key is derived from the PS private key and the CD public key.

32. A method (300, 900) for provisioning a subscription profile from a provisioning server (302), PS, to a subscriber module (307) of a communication device (306), CD, via an eSIM loT remote manager (304), ERM, the subscriber module (307) having a CD cryptographic certificate associated with a CD public / private key pair and comprising a subscriber module identifier, and the PS (302) having a PS cryptographic certificate associated with a PS public / private key pair, the method comprising: establishing (914) a secure and authenticated connection between the ERM (304) and the PS (302); receiving (921), by the ERM (304), a first message through the secure and authenticated connection, wherein the first message comprises the PS cryptographic certificate, a first PS cryptographic signature, and a PS ephemeral public key of a PS ephemeral key pair and wherein the first PS cryptographic signature has been created using a PS private key of the PS public / private key pair and is based on at least the PS ephemeral public key; verifying (922), by the ERM (304), the PS cryptographic certificate; verifying (922), by the ERM (304), the first PS cryptographic signature using the PS cryptographic certificate; forwarding (926), by the ERM (304), if the two verification steps by the ERM (304) are successful, the first message to the CD (306); receiving (937), by the ERM (304), a second message from the CD (306), wherein the second message comprises a CD ephemeral public key of a CD ephemeral key pair and a first CD signature, and wherein the first CD signature is generated (320, 930) by the subscriber module (307) using the CD private key and is based at least on the PS ephemeral public key and the CD ephemeral public key, sending (942), by the ERM (304), the second message to the PS (302); receiving (949), by the ERM (304), a third message from the PS (302), wherein the third message contains a subscription profile; wherein the subscription profile is encrypted using a second session key; and wherein the third message includes integrity protection data; and sending (952), by the ERM (304), the third message to the CD (306).

33. The method of claim 32, wherein the ERM (304) has storage holding one or more CD cryptographic certificates, and wherein the second message does not contain an encrypted portion having a payload comprising the CD cryptographic certificate, and the storage does contain the CD cryptographic certificate, the method comprising the ERM (304), before sending (942) the second message:obtaining the CD cryptographic certificate from the storage; and adding (940) the encrypted portion to the second message, the encrypted portion comprising the CD cryptographic certificate, wherein the encrypted portion is encrypted (940) using a third session key.

34. The method of claim 33, wherein the third session key is generated using an ERM ephemeral private key and the PS ephemeral public key, wherein an ERM ephemeral key pair is generated (912) by the ERM (304) and comprises the ERM ephemeral private key and an ERM ephemeral public key.

35. The method of claim 34, wherein sending the second message comprises adding the ERM ephemeral public key to the second message.

36. The method of claim 34, comprising, after establishing (914) a secure and authenticated connection between the ERM (304) and the PS (302), but before receiving the first message, sending (916), by the ERM (304), the ERM ephemeral public key to the PS (302) as a trigger to prompt the first message, where the first message comprises a second PS cryptographic signature generated by the PS (302) using the PS private key and is based on the ERM ephemeral public key; and wherein after receiving (921) the first message, verifying (922), by the ERM (304), the second PS cryptographic signature using the PS cryptographic certificate.

37. The method of claim 36, wherein the ERM (304) has a public / private key pair, and wherein the ERM public key of the ERM public / private key pair is stored in the subscriber module (307), the method comprising, after establishing (914) a secure and authenticated connection between the ERM (304) and the PS (302) and before forwarding (926) the first message to the CD (306), adding, by the ERM (304), a first ERM signature to the first message, wherein the first ERM signature is created by the ERM (304) using the ERM private key of the ERM public / private key pair and is based on the PS ephemeral public key.

38. The method of claim 32, wherein: a profile identifier information comprises at least one of a matching identifier, MID, an encrypted MID encrypted (938) by the ERM (304), and an indication that the MID is not used, and the second message comprises the profile identifier information.

39. A computer program (2214), comprising instructions which, when executed on a processing circuitry (2202), cause the processing circuitry (2202) to carry out the method according to any one of claims 1 to 17 and 19 to 38.

40. A computer-readable storage medium (4412) comprising instructions which, when executed on a processing circuitry (4402), cause the processing circuitry (4402) to carry out the method according to any one of the claims 1 to 17 and 19 to 38.

41. A communication device (306), CD, adapted to receive and install a subscription profile from a provisioning server (302), PS, the CD comprising: a subscriber module (307) having a CD cryptographic certificate associated with a CD public / private key pair and comprising a subscriber module identifier, and the PS (302) having a PS cryptographic certificate associated with a PS public / private key pair; processing circuitry (2202); memory (2210) encoded with programming instructions (2214) executable by the processing circuitry (2202) to: receive (315, 929) a first message, wherein the first message includes the PS cryptographic certificate, a first PS cryptographic signature, and a PS ephemeral public key of a PS ephemeral key pair, and wherein the first PS cryptographic signature has been created using a PS private key of the PS public / private key pair and is based on at least the PS ephemeral public key; verify (316, 930) the PS cryptographic certificate; verify (318, 930) the first PS cryptographic signature using the PS cryptographic certificate; generate (320, 930) a CD ephemeral key pair comprising a CD ephemeral private key and a CD ephemeral public key; generate (320, 930) a first CD signature using the CD private key and based at least on the PS ephemeral public key and the CD ephemeral public key; send (322, 934) a second message toward the PS (302), the second message comprising the CD ephemeral public key and the first CD signature; receive (335, 955, 961) a third message, wherein the third message contains a subscription profile, wherein the subscription profile is encrypted using a second session key, and wherein the third message includes integrity protection data;verify (338, 956) the integrity of the third message as a function of the integrity protection data, wherein the PS (302) is authenticated as a result of the verification; decrypt (340, 962) the subscription profile using the second session key; and attempt to install (342, 962) the subscription profile.

42. The communication device (306) of claim 41, wherein the programming instructions (2214) are executable by the processing circuitry (2202) to determine whether to send or not send the CD cryptographic certificate as part of the second message, and wherein the determining is based on whether the CD (306) is configured to avoid sending the CD cryptographic certificate whenever possible to reduce the number of transmitted bytes.

43. The communication device (306) of claim 41, wherein the programming instructions (2214) are executable by the processing circuitry (2202) to send (344, 964) the PS (302) a further message indicating a result of the attempt to install the subscription profile.

44. The communication device (306) of claim 41, wherein the second message comprises an encrypted portion having a payload that is encrypted, the payload comprising the CD cryptographic certificate, and wherein the encrypted portion is encrypted (932) by the subscriber module (307) using a first session key.

45. The communication device (306) of claim 44, wherein the first session key is determined (320, 932) by the subscriber module (307) as a function of the CD ephemeral private key and the PS ephemeral public key.

46. The communication device (306) of claim 41, wherein the second message comprises profile identifier information, and wherein the profile identifier information comprises one of a matching identifier, MID, an encrypted MID, and an indication that the MID is not used, wherein the encrypted MID is encrypted by the subscriber module (307).

47. The communication device (306) of claim 41, wherein the second session key is determined (336, 962) by the subscriber module (307) as a function of the CD ephemeral private key and the PS ephemeral public key.

48. An apparatus (305), comprising: a communication device (306) of claim 41, and an eSIM loT remote manager (304), ERM, in communication with the communication device (306); wherein the sending and receiving operations of the communication device (306) each comprise sending information via the ERM (304);wherein the programming instructions (2214) are executable by the processing circuitry (2202) to, before receiving the first message: establish (914) a secure and authenticated connection between the ERM (304) and the PS (302), and send (310, 916) a trigger to receive the first message; and wherein the operation of receiving the first message comprises: receiving (921), using the ERM (304), the first message through the secure and authenticated connection, verifying (922), using the ERM (304), the PS cryptographic certificate; verifying (922), using the ERM (304), the first PS cryptographic signature using the PS cryptographic certificate; and if the two verification steps using the ERM (304) are successful, forwarding (926) the first message to the CD (306).

49. The apparatus (305) of claim 48, wherein the ERM (304) comprises a database that is configured to store one or more CD certificates, wherein the operation of sending the second message, when the second message does not contain an encrypted portion having a payload comprising the CD cryptographic certificate, comprises: obtaining the CD cryptographic certificate from the database; and adding the encrypted portion to the second message, the encrypted portion comprising the CD cryptographic certificate, wherein the encrypted portion is encrypted (940) using a third session key.

50. The apparatus (305) of claim 49, wherein the third session key is generated (922) using an ERM ephemeral private key and the PS ephemeral public key, wherein an ERM ephemeral key pair is generated (912) using the ERM and comprises the ERM ephemeral private key and an ERM ephemeral public key.

51. The apparatus (305) of claim 50, wherein the second message comprises the ERM ephemeral public key.

52. The apparatus (305) of claim 50, wherein the programming instructions (2214) are executable by the processing circuitry (2202) to before receiving the first message, but after establishing (914) a secure and authenticated connection between the ERM (304) and the PS (302), send (916) the ERM ephemeral public key to the PS (302) as the trigger to receive the first message, wherein the firstmessage comprises a second PS cryptographic signature generated by the PS (302) using the PS private key and is based on the ERM ephemeral public key; and wherein receiving the first message comprises verifying (922), using the ERM (304), the second PS cryptographic signature using the PS cryptographic certificate.

53. The apparatus (305) of claim 52, wherein the ERM (304) has a public / private key pair, and wherein the ERM public key of the ERM public / private key pair is stored in the subscriber module (307), and wherein the programming instructions (2214) are executable by the processing circuitry (2202) to: after establishing (914) a secure and authenticated connection between the ERM (304) and the PS (302) and before forwarding the first message to the CD (306), add, using the ERM (304), a first ERM signature to the first message, wherein the first ERM signature is generated using the ERM (304) using the ERM private key of the ERM public / private key pair, and said generation is based on the PS ephemeral public key; and verify, using the subscriber module (307), the first ERM signature using the ERM public key.

54. The apparatus (305) of claim 48, wherein the profile identifier information comprises at least one of a matching identifier, MID, an encrypted MID, and an indication that MID is not used, wherein the second message comprises the profile identifier information, and wherein the encrypted MID is encrypted (938) using the ERM (304).

55. The communication device (306) of claims 44 and 45, wherein at least the first CD signature and the profile identifier information of the second message are within the encrypted portion.

56. The communication device (306) of claim 41, wherein the integrity protection data in the third message comprises a cryptographic signature created by the PS (302) using the PS private key based on at least the CD ephemeral public key, and wherein the programming instructions (2214) are executable to use the subscriber module (307) to authenticate the PS (302) by verifying (956) the cryptographic signature using the PS public key.

57. The communication device (306) of claim 41, wherein the integrity protection data in the third message comprises a Message Authentication Code, MAC, created using a MAC key based on at least the CD ephemeral public key, and wherein the programming instructions (2214) are executable to use the subscriber module (307) to authenticate the PS (302) by verifying the MAC using the MAC key, wherein the MAC key is derived by the subscriber module (307) from the CD private key and the PS public key.

58. The communication device (306) of claim 41, wherein the subscriber module (307) is a UICC selected from an embedded UICC, eUICC, integrated UICC, iUICC, or integrated eUICC, ieUICC, the communication device being configured with programming instructions (2214) executable to implement the method of claim 41.

59. A provisioning server (302), PS, adapted to send a subscription profile to a communication device (306), CD, the PS (302) having a PS cryptographic certificate associated with a PS public / private key pair and comprising a PS database, the PS comprising: processing circuitry (2202); memory (2210) encoded with programming instructions (2214) executable by the processing circuitry (2202) to: create (918) a first PS cryptographic signature using the PS private key and based on at least a PS ephemeral public key, where a PS ephemeral key pair comprises the PS ephemeral public key and a PS ephemeral private key; send (314, 920) a first message toward the CD (306), wherein the first message includes the PS cryptographic certificate, a first PS cryptographic signature, and a PS ephemeral public key; receive (323, 943) a second message, the second message comprising a CD ephemeral public key, a first CD signature, profile identifier information, and an encrypted portion, wherein the first CD signature is created using the CD private key and is based on at least the PS ephemeral public key and the CD ephemeral public key; wherein the encrypted portion has a payload comprising the CD cryptographic certificate, and wherein the encrypted portion is encrypted using one of a first session key and a third session key; decrypt (326, 944) the encrypted portion using one of the first session key and the third session key to obtain the CD cryptographic certificate; verify (328, 944) the CD cryptographic certificate and the first CD signature to authenticate the CD, wherein the verification of the first CD signature is performed using the CD cryptographic certificate; select (332, 946) the subscription profile to be provisioned based on the profile identifier information; and send (334, 948) a third message toward the CD (306), wherein the third message contains the selected subscription profile; wherein the subscription profile is encrypted (946) using a second session key; andwherein the third message includes integrity protection data.

60. The provisioning server (302) of claim 59, wherein the programming instructions (2214) are executable by the processing circuitry (2202) to receive (345, 973) from the CD (306) a further message indicating a result of the attempt to install the subscription profile.

61. The provisioning server (302) of claim 59, wherein the first session key is determined as a function of the PS ephemeral private key and the CD ephemeral public key.

62. The provisioning server (302) of claim 59, wherein the second session key is determined as a function of the PS ephemeral private key and the CD ephemeral public key.

63. The provisioning server (302) of claim 59, wherein the sending and receiving operations each comprise sending information via an eSIM loT remote manager (304), ERM, and wherein an ERM ephemeral key pair is generated (912) by the ERM (304) and comprises the ERM ephemeral private key and an ERM ephemeral public key, wherein the programming instructions (2214) are executable by the processing circuitry (2202) to: before sending (314, 920) the first message, but after establishing (914) a secure and authenticated connection between the ERM (304) and the PS (302), receive (917) the ERM ephemeral public key as a trigger to send the first message, wherein the first message comprises a second PS cryptographic signature generated by the PS (302) using the PS private key and is based on the ERM ephemeral public key.

64. The provisioning server (302) of claim 59, wherein the sending and receiving operations each comprise sending information via an eSIM loT remote manager (304), ERM, and wherein an ERM ephemeral key pair is generated (912) by the ERM (304) and comprises the ERM ephemeral private key and an ERM ephemeral public key, and wherein the second message comprises the ERM ephemeral public key.

65. The provisioning server (302) of claim 63 or claim 64, wherein the third session key is determined as a function of the PS ephemeral private key and the ERM ephemeral public key.

66. The provisioning server (302) of claim 59, wherein the profile identifier information comprises a matching identifier, MID, where the MID points to a specific subscription profile in the PS database.

67. The provisioning server (302) of claim 66, wherein the MID is encrypted using one of the first session key and the third session key, and wherein the programming instructions (2214) are executable by the processing circuitry (2202) to decrypt (944) the encrypted MID using one of the first session key and the third session key.

68. The provisioning server (302) of claim 59, wherein the profile identifier information comprises an indication that the MID is not used and the subscriber module identifier of the CD cryptographic certificate is used to select a subscription profile in the PS database.

69. The provisioning server (302) of claim 59, wherein at least the first CD signature and profile identifier information of the second message is within the encrypted portion.

70. The provisioning server (302) of claim 59, wherein the integrity protection data in the third message comprises a cryptographic signature created (944) at the PS (302) using the PS private key and based on at least the CD ephemeral public key.

71. The provisioning server (302) of claim 59, wherein the programming instructions (2214) are executable by the processing circuitry (2202) to create (944) a Message Authentication Code, MAC, using a MAC key and based on at least the CD ephemeral public key, wherein the MAC key is derived from the PS private key and the CD public key, and wherein the integrity protection data in the third message comprises the MAC.

72. An eSIM loT remote manager (304), ERM, for facilitating communication of a subscription profile from a provisioning server (302), PS, to a communication device (306), CD, the PS (302) having a PS cryptographic certificate associated with a PS public / private key pair, and the CD (306) having a subscriber module (307) and a CD cryptographic certificate associated with a CD public / private key pair and comprising a subscriber module identifier, the ERM (304) comprising: processing circuitry (2202); and memory (2210) encoded with programming instructions (2214) executable by the processing circuitry (2202) to: establish (914) a secure and authenticated connection between the ERM (304) and the PS (302); receive (921) a first message through the secure and authenticated connection, wherein the first message comprises the PS cryptographic certificate, a first PS cryptographic signature, and a PS ephemeral public key of a PS ephemeral key pair and wherein the first PS cryptographic signature has been created using a PS private key of the PS public / private key pair and is based on at least the PS ephemeral public key; verify (922) the PS cryptographic certificate; verify (922) the first PS cryptographic signature using the PS cryptographic certificate; forward (926), if the two verification steps by the ERM (304) are successful, the first message to the CD (306); receive (937) a second message from the CD (306),wherein the second message comprises a CD ephemeral public key of a CD ephemeral key pair and a first CD signature, and wherein the first CD signature is generated (320, 930) by the subscriber module (307) using the CD private key and is based at least on the PS ephemeral public key and the CD ephemeral public key, send (942) the second message to the PS (302); receive (949) a third message from the PS (302), wherein the third message contains a subscription profile; wherein the subscription profile is encrypted using a second session key; and wherein the third message includes integrity protection data; and send (952) the third message to the CD (306).

73. The ERM (304) of claim 72, wherein the memory (2210) holds one or more CD cryptographic certificates, and wherein the second message does not contain an encrypted portion having a payload comprising the CD cryptographic certificate, and wherein the memory (2210) does contain the CD cryptographic certificate, and wherein the programming instructions (2214) are executable by the processing circuitry (2202) to, before sending the second message: obtain the CD cryptographic certificate from the memory (2210); and add (940) the encrypted portion to the second message, the encrypted portion comprising the CD cryptographic certificate, wherein the encrypted portion is encrypted (940) using a third session key.

74. The ERM (304) of claim 73, wherein the third session key is generated (922) using an ERM ephemeral private key and the PS ephemeral public key, wherein an ERM ephemeral key pair is generated (912) by the ERM (304) and comprises the ERM ephemeral private key and an ERM ephemeral public key.

75. The ERM (304) of claim 74, wherein sending the second message comprises adding the ERM ephemeral public key to the second message.

76. The ERM (304) of claim 74, wherein the programming instructions (2214) are executable by the processing circuitry (2202) to, after establishing (914) a secure and authenticated connection between the ERM (304) and the PS (302), but before receiving (921) the first message, send (916) the ERM ephemeral public key to the PS (302) as a trigger to prompt the first message, where the first message comprises a second PS cryptographic signature generated by the PS (302) using the PS private key and is based on the ERM ephemeral public key; andwherein receiving (921) the first message comprises verifying (922), by the ERM (304), the second PS cryptographic signature using the PS cryptographic certificate.

77. The ERM (304) of claim 76, wherein the memory (2210) also stores a public / private key pair, and wherein the ERM public key of the ERM public / private key pair is stored in the subscriber module (307), wherein the programming instructions (2214) are executable by the processing circuitry (2202) to, after establishing (914) a secure and authenticated connection between the ERM (304) and the PS (302) and before forwarding (926) the first message to the CD (306), add a first ERM signature to the first message, wherein the first ERM signature is created by the ERM (304) using the ERM private key of the ERM public / private key pair and is based on the PS ephemeral public key.

78. The ERM (304) of claim 72, wherein: a profile identifier information comprises at least one of a matching identifier, MID, an encrypted MID encrypted (938) by the ERM (304), and an indication that the MID is not used, and the second message comprises the profile identifier information.

Images