In-factory ESIM profile provisioning using a group key

Abstract

Provisioning an embedded subscriber identity module (eSIM) profile in a user device includes receiving, at a compute subsystem, of the user device, an encrypted eSIM profile provisioned using a batch encryption key. The compute subsystem decrypts the eSIM profile and generates a symmetric key K and at least one over-the-air (OTA) key associated with the eSIM profile. The compute subsystem encrypts the symmetric key K and the at least one OTA key using a public key to generate encrypted profile information. The compute subsystem generates a profile installation report including encrypted profile information and installation status, and transmits the profile installation report to one or more subscription management entities. At least one of the mobile network operator or the subscription manager decrypts the symmetric key K and the at least one OTA key for processing the eSIM profile for network access.

Description

IN-FACTORY ESIM PROFILE PROVISIONING USING A GROUP KEYBACKGROUND

[0001] Embedded subscriber identity module (eSIM) technology represents an advancement in mobile and connected device technology, offering a more flexible and streamlined approach to cellular connectivity over traditional SIM cards. Unlike traditional SIM cards, eSIMs are built into devices on embedded universal integrated circuit cards (eUlCCs), allowing users to change their network operator via software settings rather than physically swapping out SIM cards. This technology not only facilitates greater flexibility for users but also opens up new possibilities for a wider array of devices to include cellular functionality, from smartphones to wearables and Internet of Things (loT) devices.

[0002] The integration of eSIM technology into devices involves several stages, one of which is the provisioning of eSIM profiles. These profiles include all necessary information for a device to connect to and operate on a mobile network. The provisioning process is overseen by entities, such as original equipment manufacturers (OEMs), and involves coordination with subscription management (SM) services, including data preparation (SM-DP) platforms. These platforms are tasked with the preparation, management, and secure delivery of eSIM profiles to devices, each uniquely identified by an eSIM Identifier (EID).SUMMARY OF EMBODIMENTS

[0003] In accordance with one aspect, a method for provisioning an embedded subscriber identity module (eSIM) profile in a user device includes receiving, at a compute subsystem of the user device, an encrypted eSIM profile provisioned using a batch encryption key. The eSIM profile is decrypted at the compute subsystem using a corresponding decryption key. A symmetric key K and at least one over-the- air (OTA) key associated with the eSIM profile is generated at the compute subsystem. The symmetric key K and the at least one OTA key are encrypted at the compute subsystem using a public key associated with a subscription management entity or a mobile network operator to generate encrypted profile information. Aprofile installation report is generated at the compute subsystem, including the encrypted profile information and installation status. The profile installation report is transmitted to one or more subscription management entities. The symmetric key K and the at least one OTA key are decrypted at the one or more subscription management entities for processing the eSIM profile for network access.

[0004] In at least some embodiments, the method further includes installing the eSIM profile during manufacturing of the user device.

[0005] In at least some embodiments, the method further includes installing the eSIM profile in an un-personalized and encrypted state using a group encryption key that is shared among multiple eSIM profiles.

[0006] In at least some embodiments, decrypting the eSIM profile includes decrypting, at the compute subsystem, the eSIM profile using a group decryption key corresponding to a group encryption key that is shared among multiple eSIM profiles.

[0007] In at least some embodiments, decrypting the eSIM profile includes verifying, at the compute subsystem, a project-specific SM-DPf certificate prior to decrypting the eSIM profile.

[0008] In at least some embodiments, generating the symmetric key K and the at least one OTA key includes generating, at the compute subsystem, the symmetric key K and the at least one OTA key for authentication with at least one of a Universal Mobile Telecommunications System (UMTS) or a 5G authentication and key agreement (AKA) protocol.

[0009] In at least some embodiments, encrypting the symmetric key K and the at least one OTA key includes encrypting, at the compute subsystem, the symmetric key K and the at least one OTA key using a project-specific SM-DPf public key prior to transmission.

[0010] In at least some embodiments, generating the profile installation report includes generating, at the compute subsystem, a profile installation report that is cryptographically signed using a unique key stored at the compute subsystem.

[0011] In at least some embodiments, transmitting the profile installation report includes transmitting, by a device manufacturer, the profile installation report to a subscription manager data preparation factory for verification.

[0012] In at least some embodiments, decrypting the symmetric key K and the at least one OTA key includes verifying, at the mobile network operator, that an international mobile subscriber identity (I MSI ) of the eSIM profile has not been previously installed on another computer subsystem before allowing the eSIM profile to authenticate with a network.

[0013] In at least some embodiments, encrypting the symmetric key K and the at least one OTA key includes decrypting, at the compute subsystem, the eSIM profile while maintaining the eSIM profile in an un-personalized state until assigned an international mobile subscriber identity (I MSI ) and one or more authentication keys.

[0014] In at least some embodiments, the method further includes encrypting, at a subscription manager data preparation factory, the eSIM profile using an elliptic curve cryptographic algorithm.

[0015] In at least some embodiments, the method further includes installing the eSIM profile in a factory environment without requiring real-time network connectivity to the mobile network operator.

[0016] In accordance with another aspect, a processing system includes one or more processors and at least one memory storing executable instructions, the executable instructions configured to manipulate at least one of the one or more processors to perform the methods described above and herein.

[0017] In accordance with a further aspect, a computer-readable storage medium embodies a set of executable instructions, the set of executable instructions to manipulate a user equipment device to perform the methods described above and herein.BRIEF DESCRIPTION OF THE DRAWINGS

[0018] The present disclosure may be better understood, and its numerous features and advantages made apparent to those skilled in the art, by referencing the accompanying drawings. The use of the same reference symbols in different drawings indicates similar or identical items.

[0019] FIG. 1 is a diagram illustrating an example operating environment for implementing in-factory eSIM profile provisioning (IFPP) utilizing a group key on a user device in accordance with some embodiments.

[0020] FIG. 2 is a diagram illustrating an example of a subscription manager data preparation factory in the operating environment of FIG. 1 in accordance with some embodiments.

[0021] FIG. 3 is a diagram illustrating an example of a device manufacturer in the operating environment of FIG. 1 in accordance with some embodiments.

[0022] FIG. 4 and FIG. 5 together are a sequencing diagram illustrating an example method for performing in-factory eSIM profile provisioning utilizing a group key on a user device during manufacturing in accordance with some embodiments.

[0023] FIG. 6 and FIG. 7 together are a flow diagram illustrating a method for performing IFPP using a Group Key within a manufacturing environment in accordance with some implementations.

[0024] FIG. 8 illustrates a table including examples of fields for an elllCC certificate in accordance with some embodiments.

[0025] FIG. 9 illustrates a table describing the fields of one example of a subordinate certificate authority for the subscription manager data preparation factory of FIG. 2 in accordance with some embodiments.

[0026] FIG. 10 illustrates a table describing the fields of one example of a projectspecific SM-DPf certificate for the subscription manager data preparation factory of FIG. 2 in accordance with some embodiments.

[0027] FIG. 11 is a block diagram of an example processing system in accordance with some embodiments.

[0028] FIG. 12 is a diagram illustrating an example hardware configuration of a user device in accordance with some embodiments.DETAILED DESCRIPTION

[0029] The adoption of eSIM technology represents a shift in mobile and device connectivity, transitioning from traditional SIM cards to an integrated approach. This transition allows for seamless network operator changes directly through device settings, improving user convenience and expanding the range of devices that can offer cellular capabilities, including a variety of loT applications. One aspect of the integration process is the factory provisioning phase, where device manufacturers may decide to pre-install eSIM profiles on a select subset of devices or specific stock keeping units (SKUs) during production. This approach involves an eSIM server, such as a subscription manager data preparation factory (SM-DPf), that is designated to prepare eSIM profiles for this subset of devices. Each device within this subset is distinguishable by a globally-unique eSIM identifier, such as an embedded identity document (EID).

[0030] However, the eSIM integration process is not without its challenges. A significant hurdle arises from the offline nature of the device manufacturer’s factory lines during production. This offline status impedes the real-time transmission of El Ds from the production line to the SM-DPf servers, creating a bottleneck in the provisioning process. Moreover, device manufacturers typically do not determine which specific devices (identified by their El Ds) will require pre-installed eSIM profiles until a late stage in the manufacturing process. As a result, eSIM vendors and device manufacturers may end up creating and installing eSIM profiles for all devices within a model range, leading to unnecessary expenses. For instance, if only 300,000 devices out of a production run of 5 million require pre-installed eSIMs, the cost associated with generating and installing profiles for the entire production (much of which will not be utilized) can significantly inflate operational costs for device manufacturers. In at least some embodiments, the eSIM profile is installed in thefactory environment without requiring real-time network connectivity to the mobile network operator (MNO), enabling efficient provisioning even in an offline manufacturing setting. This ensures that devices can be pre-provisioned in a controlled environment without immediate network dependency, allowing subsequent activation and authentication to occur when the device first connects to a network.

[0031] As such, the following describes embodiments of systems and methods enabling in-factory eSIM profile provisioning (IFPP) utilizing a group key on a user device. The techniques described herein allow for, among other things, eSIM profiles to be provisioned on a subset (or a specific SKU) of devices without knowledge of both the target eSIM ID (EID) and the elllCC certificate (or comparable certificate) in advance. As described in greater detail below, during the IFPP process, the device manufacturer (or another entity / component, such as the EMU) installs eSIM profiles in an encrypted state, ensuring that they remain encrypted during installation and storage. These un-personalized (i.e., no K-value) encrypted eSIM profiles (also referred to herein as “profiles”) are installed on a compute subsystem, such as an eUlCC, of user devices with an eUlCC batch / group key that is to be shared across multiple eSIMs. In at least some embodiments, the SM-DPf encrypts each eSIM profile before installation using a group encryption key, which is a shared encryption key used to encrypt multiple eSIM profiles. The group encryption key allows secure provisioning of a batch of eSIM profiles while maintaining their encrypted state throughout storage and installation. Each eSIM profile encrypted using the batch / group encryption key is later decrypted at the compute subsystem using a corresponding group decryption key, ensuring secure profile activation. In at least some embodiments, upon decryption, the eSIM profile remains in an un-personalized state, meaning it does not yet include an assigned IMSI or authentication keys. The personalization process occurs later when, for example, the network operator provisions the profile with subscriber-specific credentials.

[0032] The compute subsystem generates and encrypts the secret symmetric keys (i.e., K) that are to be used for Universal Mobile Telecommunications System (UMTS) or 5G authentication and key agreement (AKA), and SIM over-the-air (OTA) keys with the carrier or subscription manager data preparation factory (SM-DPf) public key.The compute subsystem then returns the profile installation report to the SM-DPf, the device manufacturer, or both indicating the success or failure of the eSIM profile installation attempt. In at least some embodiments, the compute subsystem also returns the encrypted eSIM profile to the SM-DPf, the device manufacturer, or both. The SM-DPf verifies that the international mobile subscriber identity (IMSI) of the eSIM profile was not previously installed on another compute subsystem (e.g., elllCC). The SM-DPf, in at least some embodiments, also decrypts the symmetric key (K) and SIM OTA keys and provides these decrypted keys to the mobile service provider / operatorfor performing the profile provisioning. In at least some embodiments, personalization of the secret eSIM profile data is performed on the compute subsystem to be returned to the SM-DPf. In at least some embodiments, the personalized secret eSIM profile data that is returned to the SM-DPf is backed with a key derivation function (KDF).

[0033] The personalization, in at least some embodiments, includes the compute subsystem decrypting the unpersonalized profile using the decryption key corresponding to the batch encryption public key. Unique keys, such as a symmetric key K and OTA keys, are then generated on the compute subsystem. These processes personalize the eSIM profile because the symmetric key K and the OTA keys are unique secrets that are known to the compute subsystem and the network operator. These secrets are encapsulated (i.e., encrypted) with a project-specific SM-DPf public key, which means that only the carrier or its representative entity can decrypt the content. The decrypted content can then be shared with the network operator so the eSIM profile on the compute subsystem can authenticate to the network.

[0034] FIG. 1 illustrates an operating environment 100 for implementing the infactory eSIM profile provisioning (IFPP) techniques described in accordance with at least some embodiments. As shown, the operating environment 100 includes a compute subsystem manufacturer, such as an embedded universal integrated circuit card (eUlCC ) manufacturer (EUM) 102, a mobile service provider and operator 104 (also referred to herein as “operator 104”), an eSIM certification authority (CA) 106, a user device 108 (also referred to herein as a “user equipment (UE) 108” or a “UEdevice 108”), a subscription manager data preparation factory (SM-DPf) 110, and a device manufacturer 112 (also referred to herein as “OEM 112”). In at least some embodiments, at least some of the components of the operating environment 100 implement one or more interfaces 114 (illustrated as interfaces 114-1 to 114-7) for communicating with each other. Examples of these interfaces include ES2F, ESbpp, ESfac, ES10f, ES8f, Esci, Eseum, ESedl , ESed2, or the like as defined in the Global System for Mobile Communications Association (GSMA) SIM Group Permanent Reference Document (SGP) GSMA SPG.21 (or later) specification. In at least some embodiments, at least some of the components transmit data structures 116 (illustrated as data structures 116-1 and 116-2) to other components of the operating environment 100. It should be understood that the operating environment 100 can include other components not illustrated in FIG. 1.

[0035] The EUM 102 is an entity that produces compute subsystems. In at least some embodiments, a compute subsystem includes one or more processors, storage configured to store executable instructions and cryptographic keys, and other components that enable functionality similar to that of a universal integrated circuit card (UICC), an embedded UICC (eUlCC) 118, or a comparable device. It should be understood that while this description references an eUlCC 118 as an example of a compute subsystem, the embodiments and techniques described herein are not limited to an eUlCC and may apply to other forms of secure computing modules or systems implementing similar functionality, regardless of the underlying standard or architecture.

[0036] The eUlCCs 118 are used to store information, such as subscriber identity information, authentication information, authorization information, identification information, an IMSI number and its related key, and the like, for accessing different networks or network services. In at least some embodiments, an eUlCC 118 stores one or more eSIMs for accessing different MNOs. The EUM 102 ensures the secure production of eUlCCs 118 to protect against tampering and unauthorized access. This involves the secure generation and provisioning of cryptographic keys and certificates that are utilized for the secure operations of the eUlCC 118. In at least some embodiments, the EUM 102 is also responsible for the initial provisioning ofelllCCs 118 with mobile operator profiles (also referred to herein as “eSIM profiles” or “profiles”) or enabling these profiles to be downloaded over-the-air (OTA).

[0037] The operator 104 is an entity that owns or controls access to the network infrastructure necessary to provide mobile services to end users, an entity that provides mobile services to users, or a combination thereof. The eSIM CA 106 is a system or entity that issues digital certificates to verify the identities within the eSIM ecosystem. The eSIM CA 106 is responsible for ensuring that all parties involved in the eSIM environment, such as user devices 108 with elllCCs 118 and the SM-DPf 110, are authenticated and can securely communicate with one another. The digital certificates issued by the eSIM CA 106 are used to authenticate the various entities, encrypt data to protect the data during transmission, and verify the integrity of data and software by confirming that they have not been tampered with. This process not only facilitates the initial provisioning of profiles to eLIICCs 118 in user devices 108 but also for ongoing management tasks, such as profile updates, swaps, or deletions.

[0038] The user device 108, in at least some embodiments, includes any of a variety of wireless communication devices capable of implementing an eUlCC or an eSIM. Examples of the user device 108 include a cellular phone, a cellular-enabled tablet computer or cellular-enabled notebook computer, a cellular-enabled wearable device, an automobile, or other vehicle employing cellular services (e.g., for navigation, provision of entertainment services, in-vehicle mobile hotspots, etc.), a cellular-enabled electronics board, and so on. In at least some embodiments, the user device 108 includes a factory profile assistant (FPA) 120. The FPA 120 sends a bound profile package (BPP) and related data to the eUlCC 118 of the user device 108 and returns a response(s) following the protocols defined for IFPP by, for example, one or more of the GMSA SGP specifications. In at least some embodiments, the FPA 120 is implemented as hardware, a low-level driver, as local profile assistant (LPA) or an loT profile assistant (IPA) running in factory mode, or the like. In other embodiments, the FPA 120 is implemented partly or entirely outside of the user device 108 and is able to communicate with the eUlCC 118 independent of the user device 108 being finished or partially finished.

[0039] The SM-DPf 110, in at least some embodiments, performs the functions of an SM-DP as defined in the Global System for Mobile Communications Association (GSMA) SIM Gateway Protocol (SGP) .01 V42 “Embedded IM Remote Provisioning Architecture”, SM-DP+ as defined in GSMA SGP.21 V2.2 or higher “RSP Architecture”, other functions, or a combination thereof. As such, the SM-DPf 110, in at least some embodiments, is configured to securely and efficiently handle eSIM profiles for connected devices, such as the user devices 108. For example, in at least some embodiments, the SM-DPf 110 receives eSIM profile data from the operator(s) 104, which it then processes and transforms in alignment with GSMA standards and the specific requirements of the operator(s) 104. This process involves, for example, encryption, formatting, and the integration of necessary security elements. Once prepared, these eSIM profiles are securely stored within the SM-DPf 110 to safeguard them from unauthorized access and potential data breaches.

[0040] FIG. 2 shows one example of the SM-DPf 110 and the various mechanisms implemented by the SM-DPf 110 to perform one or more techniques or processes described herein. In at least some embodiments, the SM-DPf 110 includes a profile package generator 202, a profile package protector 204, a profile packing binder 206, a profile package storage component 208, and a profile package delivery component for IFPP component 210. The profile package generator 202 creates profile packages (i.e. , eSIM profiles including an I MSI , a secret symmetric K, an integrated circuit card Identifier (ICCID), and the like) based on Profile Descriptions that have been established in conjunction with the operator(s) 104. These operations, in at least some embodiments, are executed as either an offline batch or a real-time process.

[0041] The profile package protector 204 safeguards each profile package through a security procedure, resulting in the creation of a protected profile package (PPP). The profile packing binder 206 binds the PPP with a designated elllCC, thereby generating a BPP. The profile package storage component 208 temporarily stores one or more of the PPPs or BPPs for subsequent dispatch / delivery to the eUlCC 118.The profile package delivery component 210 for IFPP transmits the BPP to the device manufacturer 112 for the purpose of being loaded / installed on the elllCC 118.

[0042] Referring back to FIG. 1 , the device manufacturer 112 is an entity that produces the user devices 108. The device manufacturer 112 also receives protected profiles from one or more SM-DPfs 110 and provisions these profiles into the elllCC 118 during production via the FPA 120 at the user device 108. FIG. 3 shows one example of a device manufacturer 112 and the various mechanisms implemented by the device manufacturer 112 to perform one or more techniques or processes described herein. In at least some embodiments, the device manufacturer 112 includes a profile package requestor 302, a profile package storage component 304, and a profile provisioner 306. The profile package requestor 302 obtains BPPs from the SM-DPf 110 and forwards profile loading reports back to the SM-DPf 110. The profile package storage component 304 maintains / stores BPPs temporarily for later dispatch to the elllCC 118. The profile provisioner 306 sends the BPP to the FPA 120 to be installed on the eLIICC 118 as part of the device manufacturing process.

[0043] FIG. 4 and FIG. 5 together are a sequencing diagram illustrating an example method 400 for performing in-factory eSIM profile provisioning utilizing a group key on a user device 108 in a device factory environment. It should be understood that the method 400 is not limited to the sequence of operations shown in FIG. 4 and FIG. 5, as at least some of the sequences / operations can be performed in parallel or in a different sequence. Also, in at least some embodiments, the method 400 can include one or more different sequences or operations other than those shown in FIG. 4 and FIG. 5. Moreover, although FIG. 4 and FIG. 5 are discussed with respect to a single eSIM profile, the techniques described herein are also applicable to multiple eSIM profiles and multiple iterations of the sequences illustrated in FIG. 4 and FIG. 5.

[0044] As shown in FIG. 4 and FIG. 5, the EUM 102 generates 402 eUlCC data, such as an EID, an eUlCC unique certificate, a eUlCC batch public key for profile encryption and installation, and the like. In at least some embodiments, as part of or separate from the eUlCC data generation, the EUM 102 generates and installs one or more elliptic curve (EC) public key and EC private key pairs into the eUlCC 118.The elllCC 118, in at least some embodiments, supports one or more elliptic curves for signing, verification, and key agreement, such as the National Institute of Standards and Technology (NIST) P-256 with namedCurve secp256r1 (Request For Comments (RFC) 8422), NIST P-384 with namedCurve secp384r1 (RFC 8422), or another elliptic curve. FIG. 8 illustrates a table 800 including examples of fields for an elllCC certificate.

[0045] The EUM 102 sends 404 the eUlCC data to the SM-DPf 110 at the request of the device manufacturer 112 (identified in FIG. 4 and FIG. 5 as “OEM 112”). The SM-DPf 110 (or SM-DP+), in at least some embodiments, has a subordinate certificate authority (SubCA) signed by the GSMA that asserts its management of a specific mobile country code(s) (MCCs) and mobile network code(s) (MNCs) on behalf of the operator 104. In at least some embodiments, the SM-DPf 110 supports one or more elliptic curves for signing, verification, and key agreement, such as NIST P-256 with namedCurve secp256r1 (RFC 8422), NIST P-384 with namedCurve secp384r1 (RFC 8422), or another elliptic curve. FIG. 9 illustrates a table 900 describing the fields of one example of the SubCA for the SM-DPf 110 (or SM-DP+).

[0046] The SM-DPf 110 generates 406 un-personalized profiles (e.g., no K value) that include information or data such as an I MSI , an operator parameter (OP), an authentication management field (AMF), a generic SIM profile(s), and the like. At this stage, the un-personalized profile does not include subscriber-specific authentication keys, which are later generated and assigned during the provisioning process. In at least some embodiments, IMSI is not associated with subscriber-specific information at this point since the profile is un-personalized. The OP, in at least some embodiments, is a cryptographic key used in the authentication process between the SIM / eSIM and the mobile network’s authentication center. One example OP is defined in the Third Generation Partnership Project (3GPP) standard TS.35205 as a 128-bit Operator Variant Algorithm Configuration Field that is a component of the functions f 1 , f1*, f2, f3, f4, f5 and f5. The AMF, in at least some embodiments, is part of the authentication parameters used in the security algorithms of mobile networks. The AMF is a field used alongside the IMSI and other keys during the authentication process to ensure that the user device 108 and the network can establish a secureand trusted connection. The generic SIM profile(s), in at least some embodiments, is a set of information and settings on a SIM or eSIM that is not personalized for a specific subscriber. The generic SIM profile includes information necessary for the SIM or eSIM to connect to a network, such as operator identifiers and security parameters, but does not include personal subscriber information like the I MSI and MSISDN (phone number) until the profile is personalized.

[0047] An eSIM ordering or pre-ordering process 408 occurs between the device manufacturer 112 and the operator 104. A project-specific SM-DPf certificate is generated 410 and obtained by, for example, the SM-DPf 110. The project-specific SM-DPf certificate is signed by the SubCA SM-DPf (or another entity / component) that proves the SM-DPf (or another component) owns the MCC and MNC values of the IMSI of a profile. FIG. 10 illustrates a table 1000 describing the fields of one example of the project-specific SM-DPf for the SM-DPf 110 (or SM-DP+).

[0048] The SM-DPf 110 then encrypts 412 the un-personalized eSIM profile (elllCC batch encryption key => (IMSI, OP, SIM files, project-specific SM-DPf certificate)). In at least some embodiments, the SM-DPf 110 generates the elllCC batch encryption key by generating an EC public key - EC private key pair with a security strength of at least 128 bits, although other security strengths are applicable as well. The SM-DPf 110 generates a project-specific SM-DPf certificate that includes the generated EC public key and EC Private key and is signed by its SubCA asserting ownership of the MCC and MNC. In at least some embodiments, the SM- DPf 110 generates the elllCC batch encryption key for profile encryption and installation using, for example, anonymous elliptic curve Diffie-Hellman (ECDH) key agreement, namedCurve secp256r1 , the generated project-specific SM-DPf EC private key, and the eUlCC EC public key (provided by the EUM 102), although other parameters are applicable as well. The key length output, in at least some embodiments, has a length of 256 bits, although other lengths are applicable as well. In at least some embodiments, the SM-DPf 110 and the eUlCC each have a trust public key. For example, for the public key from SM-DPf 110, the eUlCC batch public key already present on eUlCC 118 is used and, for the eUlCC 118, the public key corresponding to the eUlCC unique certificate is used. However, other trusted publickeys are applicable as well.

[0049] In one example, The Secure Hash Algorithm (SHA)-256 with an X9.63 key derivation is used to generate the encryption key and mac key, and the sharedlnfo is set as the length and value of the HostID and the length and value of the EID. In another example, a different Sharedlnfo value is used that aligns with the batch key approach, i.e., where the EID is not available. The SM-DPf 110, in at least some embodiments, uses the Advanced Encryption Standard algorithm with a 256-bit key size algorithm to encrypt the un-personalized profile package with the elllCC batch encryption key. In at least some embodiments, the SM-DPf 110 uses the projectspecific SM-DPf EC private key elliptic curve digital signature algorithm (ECDSA) signature of the hash of the encrypted un-personalized profile blob with the SM-DPf SubCA certificate.

[0050] The SM-DPf 110 sends 414 the encrypted un-personalized profile batch to the device manufacturer 112. The device manufacturer 112 (or its contracting party) then selects 416 and installs an un-personalized eSIM profile on the eUlCC 118 of the user device 108. In at least some embodiments, the eUlCC 118 verifies that the project-specific SM-DPf certificate chains to the GSMA Root certificate. Using the anonymous Diffie-Hellman algorithm and other key derivation steps (e.g. SHA256 with X9.63 key derivation function), the eUlCC 118, in at least some embodiments, generates the eUlCC batch decryption key using the stored eUlCC batch private key and the SM-DPf public key, which was included in the metadata (in plain text) of the encrypted un-personalized profile.

[0051] The eUlCC 118 verifies 418 the project-specific SM-DPf certificate chain using the GSMA root certificate. The eUlCC 118 then generates an eUlCC decryption key using the eUlCC batch private key and the project-specific SM-DPf public key. Using the generated eUlCC decryption key, the eUlCC 118 decrypts 420 the partially-personalized eSIM profile, extracting provisioning data used for activation. The eUlCC decryption key corresponds to the encryption key used by the subscription management entity, ensuring that only authorized compute subsystems can decrypt the profile. For example, the eUlCC 118 obtains an IMSI, one or more OPs, one or more cryptographic keys used in mobile network authentication, one ormore SIM files, one or more carrier certificates, a combination thereof, and the like. The elllCC 118 further verifies that the MCC and MNC values in the project-specific SM-DPf certificate chain match the corresponding values in the decrypted I MS I . The elllCC 118 then generates a secret symmetric key (K) and OTA keys and encapsulates them using the project-specific SM-DPf public key. The eUlCC 118 generates 422 the secret symmetric key (K) and OTA keys, and encapsulates K and the OTA keys with the project-specific SM-DPf public key.

[0052] The elllCC 118 generates 424 a profile installation report that is signed with the elllCC unique key. In at least some embodiments, the elllCC 118 generates the profile installation report based on, for example, the encapsulated K and OTA keys, the EID, and IMSI The elllCC 1 18 sends 426 the signed profile installation report to the device manufacturer 112. The device manufacturer 1 12 sends 428 the signed profile installation report to the SM-DPf 110. The SM-DPf 110 verifies 430 the profile installation report signature. The SM-DPf 110 also verifies 432 that the IMSI was not already installed on another elllCC. In at least some implementations, the SM-DPf maintains or receives a track record of profile installation reports.

[0053] FIG. 6 and FIG. 7 together illustrate a flow diagram of a method 600 for performing IFPP using a Group Key within a manufacturing environment. The processes described below with respect to method 600 are further detailed in reference to FIGs. 1 through 5 above. For purposes of description, method 500 is described within an example implementation involving an embedded universal integrated circuit card (elJICC) manufacturer (EUM), a subscription manager data preparation factory (SM-DPf), a device manufacturer (OEM), and a mobile network operator (MNO). However, in other implementations, method 600 may be executed within alternative system architectures or applied to different provisioning frameworks. Furthermore, method 600 is not limited to the sequence of operations shown in FIG. 6 and FIG. 7, as certain operations may occur in parallel or in a different order depending on system design and implementation constraints. Additionally, in some embodiments, method 600 may include additional operations beyond those explicitly depicted in FIG. 6 and FIG. 7, such as enhanced cryptographic key management or additional verification steps performed by the SM-DPf and the OEM.

[0054] At block 602, the EUM 102 generates eUlCC data, including an EID, a unique eUlCC certificate, and an eUlCC batch public key for profile encryption and installation. Additionally, at this stage, the EUM 102 may generate and install EC public key-private key pairs within the eUlCC to enable secure cryptographic operations. These keys ensure secure communication and profile management within the eSIM ecosystem.

[0055] At block 604, the EUM 102 transmits the generated eUlCC data to the SM- DPf 110 upon request from the OEM 112. This data transfer ensures that the SM- DPf 110 has access to the necessary credentials and cryptographic keys required for profile provisioning and encryption. At block 606, the SM-DPf 110 generates unpersonalized eSIM profiles. These profiles include generic network parameters, such as the I MSI , OP, AMP, and a generic SIM profile. At this stage, the IMSI remains unlinked to any specific subscriber, ensuring flexibility in future provisioning. At block 608, the OEM 112 initiates the eSIM profile pre-ordering process with the network operator 104. This step involves, for example, coordination between the OEM 112 and the operator 104 to determine the number of eSIM profiles required for provisioning during production.

[0056] At block 610, the SM-DPf 110 generates a project-specific certificate that verifies its management of the MOO and MNC associated with the eSIM profile. This certificate is signed by the SubCA and serves as proof that the SM-DPf 110 is authorized to provision profiles for the specified mobile network. At block 612, the SM-DPf 110 encrypts the un-personalized eSIM profiles using an eUlCC batch encryption key. In one example, the encryption process employs Advanced Encryption Standard (AES-256) and ECDH key exchange to ensure the confidentiality of the profile data. The encryption key is derived using, for example, cryptographic techniques that allow the profile to be securely stored and installed without requiring individual device-specific encryption keys in advance.

[0057] At block 614, the SM-DPf 110 transmits the encrypted profile batch to the OEM 112. The encrypted profiles are prepared for installation on user devices 108as part of the manufacturing process. At block 616, the OEM 112 installs an unpersonalized eSIM profile onto the elllCC of the user device 108. The installation process involves, for example, selecting an appropriate profile from the batch and securely writing it onto the elllCC without exposing sensitive key material. In at least some embodiments, the elllCC 118 verifies that the project-specific SM-DPf certificate chains to the GSMA Root certificate. Using the anonymous Diffie-Hellman algorithm and other key derivation steps (e.g. SHA256 with X9.63 key derivation function), the eUlCC 118, in at least some embodiments, generates the eUlCC batch decryption key using the stored eUlCC batch private key and the SM-DPf public key, which was included in the metadata (in plain text) of the encrypted un-personalized profile. At block 618, the eUlCC 118 decrypts the encrypted un-personalized profile using the eUlCC batch decryption key. This decryption process allows the device to access the stored profile information while maintaining security. The eUlCC 118 then verifies the project-specific SM-DPf certificate using the GSMA root certificate and checks that the MCC and MNC values within the certificate match the corresponding values in the IMSI.

[0058] At block 620, the eUlCC 118 generates a secret symmetric key (K) and Over-the-Air (OTA) keys for secure authentication. These keys are unique to each eUlCC and are for enabling secure network access and profile management. The generated keys are provisioned on the newly installed profile within the eUlCC 118 and are also encapsulated using, for example, a dedicated project-specific SM-DPf public key. This encapsulation ensures that only the authorized SM-DPf 110, possessing the corresponding private key, can decrypt and access them for secure provisioning. In at least some embodiments, the encapsulation of K and OTA keys is performed using a separate project-specific SM-DPf public key, which is distinct from the one used for creating the eUlCC batch decryption key. This second public key, in at least some embodiments, is only available after the decryption of the un- personalized profile and is exclusively used for securing the symmetric key exchange. At block 622, the eUlCC 118 creates a profile installation report. This report includes data, such as the encapsulated symmetric key (K) and OTA keys, the EID, and the IMSI. To ensure authenticity and integrity, the report is signed using, for example, the eUlCC’s unique cryptographic key.

[0059] At block 624, the elllCC 118 transmits the signed profile installation report to the OEM 112. This allows the OEM 112 to track the status of profile installations and ensure that devices are correctly provisioned. The profile installation report is then sent to one or more subscription management entities, such as the SM-DPf 110 or the mobile network operator 104. For example, at block 626, the OEM 112 forwards the profile installation report to the SM-DPf 110. This report submission allows the SM-DPf 110 to verify successful provisioning and prepare for further network activation steps. At block 628, the SM-DPf 110 verifies the authenticity of the profile installation report. This verification includes, for example, checking the digital signature to confirm that the report was generated by a legitimate elllCC 118 and ensuring that the installation process was completed without errors.

[0060] At block 630, the SM-DPf 110 performs a final validation to ensure that the IMSI assigned to the provisioned profile has not been previously installed on another elllCC. This check prevents duplicate IMSI allocations and ensures that each provisioned eSIM profile remains unique. Upon successful verification at block 630, the process concludes, and the eSIM profiles are considered ready for activation by the network operator 104.

[0061] FIG. 11 illustrates a block diagram of an example processing system 1100 in which the techniques described herein can be implemented. It should be understood that the techniques described herein are not limited to the processing system 1100 shown in FIG. 11 . In at least some embodiments, the processing system 1100 includes, for example, a server, a desktop computer, a laptop / notebook, a mobile device, a tablet computing device, a wearable computing device, or the like. The processing system 1100, in at least some embodiments, comprises a processor 1102, memory 1104, storage 1106, one or more input devices 1108, and one or more output devices 1110. The processing system 1100, in at least some embodiments, also comprises one or more of an input driver 1112 or an output driver 1114. In some embodiments, the processing system 1100 includes one or more software, hardware, circuitry, and firmware components in addition to or different from those shown in FIG. 1.

[0062] In at least some embodiments, the processor 1102 comprises a central processing unit (CPU), an accelerator processor (e.g., a graphics processing unit (GPU)), a CPU and an accelerator processor located on the same die or multiple dies (e.g., using a multi-chip-module (MCM)), or one or more processor cores, wherein each processor core is a CPU or an accelerator processor. The memory 1104, in at least some embodiments, is located on the same die as the processor 1102 or is located separately from the processor 1102. The memory 1104 includes a volatile or non-volatile memory, such as random-access memory (RAM), dynamic RAM, cache, and so on.

[0063] The storage 1106, in at least some embodiments, comprises a fixed or removable storage, such as a hard disk drive, a solid-state drive, an optical disk, a flash drive, and so on. In at least some embodiments, the input devices 1108 comprise, for example, one or more of a keyboard, a keypad, a touch screen, a touchpad, a detector, a microphone, an accelerometer, a gyroscope, a biometric scanner, a network connection (e.g., a wireless local area network card for transmission / reception of wireless signals), and so on. The output devices 1110, in at least some embodiments, comprise, for example, one or more of a display, a speaker, a printer, a haptic feedback device, one or more lights, an antenna, or a network connection (e.g., a wireless local area network card for transmission / reception of wireless signals), and so on.

[0064] In at least some embodiments, the input driver 1112 communicates with the processor 1102 and the input devices 1108 and allows the processor 1102 to receive input from the input devices 1108. The output driver 1114, in at least some embodiments, communicates with the processor 1102 and the output devices 1110 and allows the processor 1102 to send output to the output devices 1110. It is noted that the processing system 1100 operates in the same manner if the input driver 1112 and the output driver 1114 are not present. The output driver 1114, in at least some embodiments, includes an accelerated processing device (APD) 1116 that is coupled to a display device 1118. The APD 1116 accepts compute commands and graphics rendering commands from processor 1102, processes those compute and graphics rendering commands, and provides pixel output to display device 1118 fordisplay. The APD 1116, in at least some embodiments, includes one or more parallel processing units that perform computations in accordance with a single-instruction- multiple-data (SIMD) paradigm.

[0065] FIG. 12 illustrates an example device diagram 1200 of a user device 108 capable of implementing the elllCC 118 and eSIM profiles described herein. It should be noted that other user devices are applicable as well. The user device 108 may include additional functions and interfaces that are omitted from FIG. 12 for the sake of clarity. The user device 108, in at least some embodiments, includes antennas 1202, a radio frequency (RF) front end 1204, and one or more RF transceivers 1206 (e.g., a 3GPP 4G LTE transceiver 1206-1 and a 5G NR transceiver 1206-2) for communicating with one or more base stations in a RAN, such as a 5G RAN, an E-UTRAN, a combination thereof, and so on. The RF front end 1204, in at least some embodiments, includes a transmitting (Tx) front end 1204-1 and a receiving (Rx) front end 1204-2. The Tx front end 1204-1 includes components such as one or more power amplifiers (PA), drivers, mixers, filters, and so on. The Rx front end 1204-2 includes components such as low-noise amplifiers (LNAs), mixers, filters, and so on. The RF front end 1204, in at least some embodiments, couples or connects the one or more transceivers 1206, such as the LTE transceiver 1206-1 and the 5G NR transceiver 1206-2, to the antennas 1202 to facilitate various types of wireless communication.

[0066] In at least some embodiments, the antennas 1202 of the user device 108 include an array of multiple antennas configured similarly to or different from each other. The antennas 1202 and the RF front end 1204, in at least some embodiments, are tuned to or are tunable to one or more frequency bands, such as those defined by the 3GPP LTE, 3GPP 5G NR, IEEE wireless local area network (WLAN), IEEE wireless metropolitan area network (WMAN), or other communication standards. In at least some embodiments, the antennas 1202, the RF front end 1204, the LTE transceiver 1206-1 , and the 5G NR transceiver 1206-2 are configured to support beamforming (e.g., analog, digital, or hybrid) or in-phase and quadrature (l / Q) operations (e.g., I / Q modulation or demodulation operations) for the transmission and reception of communications with one or more base stations. By way of example, theantennas 1202 and the RF front end 1204 operate in sub-gigahertz bands, sub-6 GHz bands, above 6 GHz bands, or a combination of these bands defined by the 3GPP LTE, 3GPP 5G NR, or other communication standards.

[0067] In at least some embodiments, the antennas 1202 include one or more receiving antennas positioned in a one-dimensional shape (e.g., a line) or a two- dimensional shape (e.g., a triangle, a rectangle, or an L-shape) for implementations that include three or more receiving antenna elements. While the one-dimensional shape enables the measurement of one angular dimension (e.g., an azimuth or an elevation), the two-dimensional shape enables two angular dimensions to be measured (e.g., both azimuth and elevation). Using at least a portion of the antennas 1202, the user device 108 can form beams that are steered or un-steered, wide or narrow, or shaped (e.g., as a hemisphere, cube, fan, cone, or cylinder). The one or more transmitting antennas may have an un-steered omnidirectional radiation pattern or may produce a wide steerable beam. Either of these techniques enables the user device 108 to transmit a radio signal to illuminate a large volume of space. In some embodiments, the receiving antennas generate thousands of narrow steered beams (e.g., 2000 beams, 4000 beams, or 6000 beams) with digital beamforming to achieve desired levels of angular accuracy and angular resolution.

[0068] The user device 108, in at least some embodiments, includes one or more sensors 1208 implemented to detect various properties such as one or more of temperature, supplied power, power usage, battery state, or the like. Examples of sensors include a thermal sensor, a battery sensor, a power usage sensor, and so on.

[0069] The user device 108 also includes at least one processor 1210. The processor 1210, in at least some embodiments, is a single-core processor or a multiple-core processor composed of a variety of materials, such as silicon, polysilicon, high-K dielectric, copper, and so on. In at least some embodiments, the processor 1210 is implemented at least partially in hardware, including, for example, components of an integrated circuit or a system-on-a-chip (SoC), a digital-signal- processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a complex programmable logic device (CPLD), other implementations in silicon or other hardware, or a combination thereof.

[0070] Examples of the processor(s) 1210 include a communication processor, an application processor, microprocessors, DSPs, controllers, and so on. A communication processor, in at least some embodiments, is implemented as a modem baseband processor, software-defined radio module, configurable modem (e.g., multi-mode, multi-band modem), wireless data interface, wireless modem, or so on. In at least some embodiments, a communication processor supports one or more of data access, messaging, or data-based services of a wireless network, as well as various audio-based communication (e.g., voice calls). An application processor, in at least some embodiments, provides computing resources to applications executing on the user device 108. For example, an application provides a self-contained operating environment that delivers system capabilities (e.g., graphics processing, memory management, and multimedia processing) to support applications executing on the user device 108.

[0071] The user device 108 further includes at least one non-transitory computer- readable storage medium 1212 (CRM 1212). The computer-readable storage media described herein excludes propagating signals. The CRM 1212, in at least some embodiments, includes any suitable memory or storage device such as randomaccess memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), non-volatile RAM (NVRAM), read-only memory (ROM), or Flash memory useable to store device data 1214 of the user device 108. In at least some embodiments, the device data 1214 includes user data, multimedia data, beamforming codebooks, applications 1216, a user interface(s) 1218, an operating system of the user device 108, and so on, which are executable by the processor(s) 1210 to enable user-plane communication, control-plane signaling, and user interaction with the user device 108. The user interface 1218, in at least one embodiment, is configured to receive inputs from a user of the user device 108. In at least some embodiments, the user interface 1218 includes a graphical user interface (GUI) that receives the input information via a touch input. In other instances, the user interface 1218 includes an intelligent assistant that receives the input information via an audible input or speech.Alternatively, or additionally, the operating system of the user device 108 is maintained as firmware or an application on the CRM 1212 and executed by the processor(s) 1210.

[0072] The CRM 1212, in at least some embodiments, the CRM 1212 further includes a communication manager 1220. Alternatively, or additionally, the communication manager 1220, in at least some embodiments, are implemented in whole or part as hardware logic or circuitry integrated with or separate from other components of the user device 108. In at least some embodiments, the communication manager 1220 configures the RF front end 1204, the LTE transceiver (RF modem) 1206-1 , the 5G NR transceiver (RF modem) 1206-2, or a combination thereof, to perform one or more wireless communication operations.

[0073] In some embodiments, certain aspects of the techniques described above may be implemented by one or more processors of a processing system executing software. The software comprises one or more sets of executable instructions stored or otherwise tangibly embodied on a non-transitory computer-readable storage medium. The software can include the instructions and certain data that, when executed by the one or more processors, manipulate the one or more processors to perform one or more aspects of the techniques described above. The non-transitory computer-readable storage medium can include, for example, a magnetic or optical disk storage device, solid-state storage devices such as Flash memory, a cache, random access memory (RAM) or other non-volatile memory device or devices, and the like. The executable instructions stored on the non-transitory computer-readable storage medium may be in source code, assembly language code, object code, or other instruction format that is interpreted or otherwise executable by one or more processors.

[0074] A computer-readable storage medium may include any storage medium, or combination of storage media, accessible by a computer system during use to provide instructions and / or data to the computer system. Such storage media can include, but is not limited to, optical media (e.g., compact disc (CD), digital versatile disc (DVD), Blu-Ray disc), magnetic media (e.g., floppy disc , magnetic tape, or magnetic hard drive), volatile memory (e.g., random access memory (RAM) orcache), non-volatile memory (e.g., read-only memory (ROM) or Flash memory), or microelectromechanical systems (MEMS)-based storage media. The computer- readable storage medium may be embedded in the computing system (e.g., system RAM or ROM), fixedly attached to the computing system (e.g., a magnetic hard drive), removably attached to the computing system (e.g., an optical disc or Universal Serial Bus (USB)-based Flash memory), or coupled to the computer system via a wired or wireless network (e.g., network accessible storage (NAS)).

[0075] Note that not all of the activities or elements described above in the general description are required, that a portion of a specific activity or device may not be required, and that one or more further activities may be performed, or elements included, in addition to those described. Still further, the order in which activities are listed are not necessarily the order in which they are performed. Also, the concepts have been described with reference to specific embodiments. However, one of ordinary skill in the art appreciates that various modifications and changes can be made without departing from the scope of the present disclosure as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of the present disclosure.

[0076] Benefits, other advantages, and solutions to problems have been described above with regard to specific embodiments. However, the benefits, advantages, solutions to problems, and any feature(s) that may cause any benefit, advantage, or solution to occur or become more pronounced are not to be construed as a critical, required, or essential feature of any or all the claims. Moreover, the particular embodiments disclosed above are illustrative only, as the disclosed subject matter may be modified and practiced in different but equivalent manners apparent to those skilled in the art having the benefit of the teachings herein. No limitations are intended to the details of construction or design herein shown, other than as described in the claims below. It is, therefore, evident that the particular embodiments disclosed above may be altered or modified, and all such variations are considered within the scope of the disclosed subject matter. Accordingly, the protection sought herein is as set forth in the claims below.

Claims

WHAT IS CLAIMED IS:1 . A method for provisioning an embedded subscriber identity module (eSI ) profile in a user device, the method comprising: receiving, at a compute subsystem (118) of the user device (108), an encrypted eSIM profile provisioned using a batch encryption key; decrypting (420), at the compute subsystem, the eSIM profile using a corresponding decryption key; generating (422), at the compute subsystem, a symmetric key K and at least one over-the-air (OTA) key associated with the eSIM profile; encrypting (422), at the compute subsystem, the symmetric key K and the at least one OTA key using a public key associated with a subscription management entity or a mobile network operator to generate encrypted profile information; generating (424), by the compute subsystem, a profile installation report including the encrypted profile information and installation status; transmitting (426) the profile installation report to one or more subscription management entities (104, 110); and decrypting (430), at the one or more subscription management entities, the symmetric key K and the at least one OTA key for processing the eSIM profile for network access.

2. The method of claim 1 , further comprising: installing (416) the eSIM profile during manufacturing of the user device.

3. The method of claim 1 , further comprising: installing (416) the eSIM profile in an un-personalized and encrypted state using a group encryption key that is shared among multiple eSIM profiles.

4. The method of claim 1 , wherein decrypting the eSIM profile comprises:decrypting, at the compute subsystem, the eSIM profile using a group decryption key corresponding to a group encryption key that is shared among multiple eSIM profiles.

5. The method of claim 1 , wherein decrypting the eSIM profile comprises: verifying, at the compute subsystem, a project-specific SM-DPf certificate prior to decrypting the eSIM profile.

6. The method of claim 1 , wherein generating the symmetric key K and the at least one OTA key comprises: generating, at the compute subsystem, the symmetric key K and the at least one OTA key for authentication with at least one of a Universal Mobile Telecommunications System (UMTS) or a 5G authentication and key agreement (AKA) protocol.

7. The method of claim 1 , wherein encrypting the symmetric key K and the at least one OTA key comprises: encrypting, at the compute subsystem, the symmetric key K and the at least one OTA key using a project-specific SM-DPf public key prior to transmission.

8. The method of claim 1 , wherein generating the profile installation report comprises: generating, at the compute subsystem, a profile installation report that is cryptographically signed using a unique key stored at the compute subsystem.

9. The method of claim 1 , wherein transmitting the profile installation report comprises: transmitting, by a device manufacturer, the profile installation report to a subscription manager data preparation factory for verification.

10. The method of claim 1 , wherein decrypting the symmetric key K and the at least one OTA key comprises: verifying, at the mobile network operator, that an international mobile subscriber identity (I MS I) of the eSIM profile has not been previously installed on another computer subsystem before allowing the eSIM profile to authenticate with a network.11 . The method of claim 1 , wherein encrypting the symmetric key K and the at least one OTA key comprises: decrypting, at the compute subsystem, the eSIM profile while maintaining the eSIM profile in an un-personalized state until assigned an international mobile subscriber identity (I M S I) and one or more authentication keys.

12. The method of claim 1 , further comprising: encrypting (411 ), at a subscription manager data preparation factory (110), the eSIM profile using an elliptic curve cryptographic algorithm.

13. The method of claim 1 , further comprising: installing (416) the eSIM profile in a factory environment without requiring realtime network connectivity to the mobile network operator.

14. A processing system (1100), comprising: one or more processors (1102); and at least one memory (1104) storing executable instructions, the executable instructions configured to manipulate at least one of the one or more processors to perform the method of any one of claims 1-13.

15. A non-transitory computer readable storage medium (1104) storing one or more programs, the one or more programs comprising instructions, which, when executed by a processing system (1100) with one or more processors (1102), cause the processing system to perform the method of any one of claims 1-13.

Images