INSTALIZATION OF MULTIPLE INSTITUTIONS OF AN ELECTRONIC SUBSCRIBER IDENTITY MODULE (eSIM)

Abstract

Method, by means of a universal integrated circuit card embedded in a wireless device (220), eUICC (embedded universal integrated circuit card) (102), wherein the method comprises: at the eUICC (102): Receiving (704) an initial request to instantiate an initial electronic subscriber identity module, eSIM (402, 502); Instantiating (706) the first eSIM (402, 502) using generic data (612) from a large binary data object, data BLOB (data binary large object) (104, 602, 604); characterized by: Adapting (708) the first eSIM (402, 502) based on first data from the data BLOB (104, 602, 604) or based on second data from the eUICC (102) or based on third data from a second data BLOB (104, 602, 604).

Description

AREA

[0001] The described embodiments generally relate to wireless communications technology. More specifically, the present embodiments relate to preloading an eUICC (embedded universal integrated circuit card) with an eSIM (electronic subscriber identity module) package including a data BLOB (binary large object). Multiple eSIMs can then be instantiated from the data BLOB. BACKGROUND

[0002] Wireless communication devices, such as smartphones, have traditionally been configured to use UICCs (universal integrated circuit cards) that provide access to wireless network services. A UICC is a physically secure device. UICCs can contain one or more applications. One of the applications can be a USIM, or similarly, an eSIM. eSIMs / USIMSs allow registration with a cellular network with appropriate security. A UICC typically takes the form of a small removable card (e.g., a subscriber identity module card (SIM card)) that is inserted into a wireless communication device. In most cases, each UICC is associated with a single issuer—such as a mobile network operator (MNO)—that controls the programming and distribution of the UICC.

[0003] In more recent implementations, non-removable UICCs—referred to herein as embedded UICCs (eUICCs)—are included on the motherboards of wireless communication devices. These eUICCs differ from traditional removable UICCs in that the eUICCs are non-removable and soldered to the motherboards of wireless communication devices. In some cases, an eUICC may be programmed with one or more eSIMs, each of which can emulate and replicate the architecture of a typical SIM to enable a wireless communication device, including the eUICC, to access services provided by mobile network operators. An eSIM allows secure registration with an MNO.

[0004] The use of eUICCs and eSIMs can offer advantages over traditional UICCs. For example, the use of an eUICC can provide wireless device manufacturers with increased design flexibility because they do not need to develop a wireless device that accommodates the size and form factor of a removable SIM card.

[0005] Remote provisioning (e.g., over-the-air) of eSIMs can be used to configure a wireless device to access a mobile network operator's network. However, there are regulatory and business reasons to avoid over-the-air eSIM installation. However, if over-the-air eSIM installation is not available, the flow of wireless devices to the market may be limited because an aftermarket purchaser cannot practically obtain an eSIM for a purchased wireless device.

[0006] When the eUICC form factor is very small, such as when using WLCSP (Wafer Level Chip Scale Packaging), an eSIM provider may have difficulty physically loading operating system and personalization data into an eUICC. An eUICC chip can be programmed in a wafer context in a chip fab environment, rather than as a separate package, and rather than over-the-air when residing in a wireless device. However, the carrier or MNO contracting to manufacture the eUICC may trust the eSIM provider, but may not trust sensitive eSIM information to a contracted chip manufacturer or wireless device fab. In some embodiments, the MNO does not trust the chip manufacturer, does not trust the wireless device fab, and either does not trust or is unable to perform over-the-air eSIM provisioning.

[0007] Conventional approaches for installing eSIMs in eUICCs do not address the challenges faced by aftermarket buyers who purchase wireless devices without an eSIM. Furthermore, conventional approaches do not address the issue of eSIM provisioning for eUICCs in an untrusted factory.

[0008] The document DE 10 2015 003 977 A1 discloses a method for loading a profile for a mobile communications subscription from a data processing server into a subscriber identity module (eUICC).

[0009] The document DE 11 2013 002 437 T5 concerns the provision of an embedded subscriber identity module (eSIM) in a user equipment (UE) with personalized subscriber information.

[0010] The document US 2013 / 0227646 A1 discloses methods and devices for the large-scale distribution of electronic access control customers.

[0011] Document EP 4 037 357 A1 concerns the pre-personalization of eSIMs to support large-scale eSIM deployment. SUMMARY

[0012] One approach to solving these problems involves creating an eSIM package, including a data blob, and installing the eSIM package into an eUICC in a manufacturing environment. An eSIM package is a binary data object, not a piece of hardware. The eUICC is subsequently embedded into a wireless device by a manufacturer. The eUICC then receives a command to instantiate an eSIM. In some embodiments, the eUICC then populates a file structure in its memory with a SIM (Subscriber Identity Module) profile using the data in the data blob, thereby instantiating a minimal eSIM. In some embodiments, applets are also instantiated based on data in the data blob. In this way, an eSIM is instantiated without over-the-air provisioning. In some embodiments, the minimal eSIM is functional and contains all data required to access network services.

[0013] In some embodiments, the minimal eSIM is converted into a unique eSIM based on unique data. The unique eSIM can then be converted into a functional eSIM by communicating with an MNO. In some embodiments, the functional eSIM includes an IMSI (international mobile subscriber identity), a subscriber key, and a phone number. The user can then access MNO services using the wireless device. For example, incoming calls to the phone number are routed to the wireless device.

[0014] The user can delete the eSIM and sell the wireless device to another party. While the wireless device belongs to the second party, the eUICC can receive a command to instantiate an eSIM. The eUICC then performs steps to generate a minimal eSIM and makes the eSIM unique. The wireless device can then communicate with an MNO and receive one or more of a new IMSI, a new subscriber key, and a different phone number. Finally, the second party can use the wireless device to access MNO services. For example, incoming calls to the different phone number are routed to the wireless device.

[0015] Multiple eSIM instances can coexist in the eUICC. In some embodiments, a wireless device is shared by family members or family and friends. Each person can be assigned a unique eSIM instance. Each user of the device can select which eSIM to use when using the device.

[0016] The eSIM package installed in the manufacturing environment may be specific to an MNO, or it may be a generic package usable by a number of different MNOs. A minimal eSIM may include an OTA (over-the-air) key shared by more than one MNO. In some embodiments, an MNO uses an OTA key set that is kept secret from other MNOs. A key set includes encryption and integrity keys. After the eUICC instantiates the minimal eSIM, a specific MNO can authenticate to the eSIM using the OTA key set. The MNO can then customize the eSIM using RFM (remote file management) or RAM (remote applet management) protocols. In some embodiments, the MNO changes (ie, replaces) the key set in the eSIM after the MNO authenticates the instantiated eSIM.For example, the MNO can use a PUT-KEY provisioning command to replace the existing key set after authentication.

[0017] The manufacturing environment may include untrusted parties. For example, an MNO may contract with an eSIM provider to manufacture a large number of eSIMs, such as 1 million eSIMs. The eSIMs are defined by the MNO. The MNO trusts the eSIM provider, but it may not trust a chip manufacturer that manufactures eUICC chips programmed with the eSIM packages or similar confidential data. In some embodiments, the eSIM provider also generates eUICC operating system files and generates personalization data (sometimes referred to as "perso data"). The information encrypted at the eSIM provider may also include a set of one-time-use elements used to uniquely identify subsequently instantiated eSIMs.In some embodiments, the information to be encrypted also includes an ICCID (integrated circuit card identifier). Furthermore, the MNO may not trust a wireless device factory where the wireless devices are manufactured. To solve this problem, the eSIM data is encrypted with a KEK (key encrypted key) before being sent from the eSIM provider to the chip manufacturer. Thus, the chip manufacturer receives encrypted information from the eSIM provider in the form of encrypted eSIM packs or encrypted data BLOBs. The chip manufacturer manufactures the finished eUICCs (programmed with encrypted eSIM information) and delivers the finished eUICCs to a wireless device factory.The eSIM provider provides the KEK to an OEM (original equipment manufacturer) server at the wireless device factory.

[0018] In some embodiments, the eUICC performs a mutual authentication protocol with the OEM server to determine that the OEM server is authentic and to prove its own (eUICC) identity. The eUICC and the OEM server may establish a session key using one of a number of algorithms. In some embodiments, the OEM server encrypts the KEK with the established session key and sends it to the eUICC. The eUICC then begins, using the KEK, decrypting the encrypted information programmed into the eUICC by the chip manufacturer. In some embodiments, one or more defined eSIM profiles decrypted by the eUICC do not represent one or more functional eSIMs. Instead, they represent one or more data blobs from which eSIMs can be instantiated.

[0019] A first method performed by an eUICC embedded or housed in a wireless device is provided herein. The first method includes receiving a request to instantiate an eSIM; instantiating the first eSIM using generic data from a large binary data object (data blob); receiving, via the wireless device, an instruction to delete the first eSIM; receiving a request to instantiate a second eSIM; and instantiating the second eSIM using the generic data from the data blob.

[0020] Another method by an eUICC embedded in a wireless device is provided herein. The method includes receiving a request to instantiate a first eSIM; and instantiating the first eSIM using generic data from a data blob. In some embodiments, the method includes customizing the first eSIM based on first data from the data blob, or based on second data from the eUICC, or based on third data from a second data blob; and successfully performing an authentication and key agreement procedure with a mobile network operator after the customization. In some embodiments, the method includes customizing the first eSIM based on first data from the data blob, or based on second data from the eUICC.In some embodiments, the first data is a first element of a set of single-use elements from the data blob. In some embodiments, the second data is a value corresponding to an ICCID. In some embodiments, the method includes receiving, via the wireless device, personalization data, including a first IMSI and a first subscriber key, from a first MNO; and storing the personalization data in the first eSIM. In some embodiments, the method includes generating a first challenge value based on the first IMSI and the first subscriber key; and sending, via the wireless device, the first challenge value to a first MNO. In some embodiments, the method includes receiving, via the wireless device, an instruction to delete the first eSIM; and deleting the first eSIM.In some embodiments, the method includes receiving a request to instantiate a second eSIM; instantiating the second eSIM using the generic data from the data blob; customizing the second eSIM based on a second item from the set of single-use items or based on an incremented value of an ICCID. In some embodiments, the method includes receiving, via the wireless device, second personalization data comprising a second IMSI and a second subscriber key from a second MNO; and storing the second personalization data in the second eSIM. In some embodiments, the method includes generating a second challenge value based on the second IMSI and the second subscriber key; and sending, via the wireless device, the second challenge value to the second MNO.

[0021] This disclosure further describes an eUICC. In some embodiments, the eUICC includes a memory configured to store instructions; processing circuitry coupled to the memory; and an interface coupled to: the memory, the processing circuitry, and a processor of a wireless device, wherein the memory is configured to store instructions that, when executed by the processing circuitry, cause the processing circuitry to perform steps including: i) receiving a first request to instantiate a first eSIM, ii) instantiating the first eSIM using generic data from a data blob, and iii) customizing the first eSIM based on first data from the data blob, or based on second data from the eUICC, or based on third data from a second data blob.In some embodiments, the memory is further configured to store instructions that, when executed by the processing circuitry, cause the processing circuitry to perform steps including: i) receiving a second request to instantiate a second eSIM; ii) instantiating the second eSIM using the generic data from the data BLOB; iii) customizing the second eSIM based on fourth data from the second data BLOB, and iv) if the first eSIM is customized based on first data from the data BLOB or second data from the eUICC: a) receiving, from the processor via the interface, personalization data, including a first IMSI and a first subscriber key, from a first MNO, and b) storing the personalization data in the first eSIM.In some embodiments, the memory is further configured to store instructions that, when executed by the processing circuitry, cause the processing circuitry to perform steps including: i) receiving, via the wireless device, an instruction to delete the first eSIM; and ii) deleting the first eSIM. In some embodiments, the memory is further configured to store instructions that, when executed by the processing circuitry, cause the processing circuitry to perform steps including: authenticating the first request using an OTA key set.

[0022] This disclosure further describes a non-transitory computer-readable data storage medium configured to store instructions that, when executed by a processor in an eUICC, cause commands issued by the processor to cause the eUICC to perform steps including: Receiving a request to instantiate a first eSIM; instantiating the first eSIM using generic data from a data blob; customizing the first eSIM based on first data from the data blob or based on second data from the eUICC; receiving, via the wireless device, an instruction to delete the first eSIM; deleting the first eSIM; receiving a request to instantiate a second eSIM; instantiating the second eSIM using the generic data from the data blob; and customizing the second eSIM based on third data from the data blob or based on fourth data from the eUICC.

[0023] This disclosure further provides a method for configuring a device by a chip manufacturer, the method comprising: receiving, from an eSIM provider, a plurality of encrypted data BLOBs; fabricating a wafer, the wafer comprising a plurality of chips; programming a portion of the chip with a portion of the plurality of encrypted data BLOBs; fabricating a plurality of WLCSPs (wafer level chip scale packages) based on the wafer; and sending the plurality of WLCSPs (wafer level chip scale packages) to a wireless device factory.

[0024] This disclosure further provides a method for maintaining confidential information using a data BLOB, the method comprising: by an eSIM provider: generating one or more eSIM profiles; generating an eSIM encryption key; generating an eSIM authentication key; generating a KEK; encrypting, with the KEK, the one or more eSIM profiles, the eSIM encryption key, and the eSIM authentication key to create a data BLOB; sending the data BLOB to a chip manufacturer; and sending the KEK to a wireless device factory.

[0025] This disclosure further provides a method for maintaining, by an eSIM provider, confidential information using a data BLOB and a KEK, the method comprising: generating one or more eSIM profiles; generating an eSIM encryption key; generating the KEK; encrypting, with the eSIM encryption key, the one or more eSIM profiles to generate a first encryption result; encrypting, with the KEK, the first encryption result, and the eSIM encryption key to generate a second encryption result, wherein the data BLOB comprises the second encryption result; sending the data BLOB to a chip manufacturer; and sending the KEK to a wireless device factory.

[0026] This disclosure further provides a method for instantiating, by an eUICC embedded in a wireless device, multiple eSIMs, the method comprising: receiving an eSIM package including a generic data BLOB, a first personalization data BLOB, and a second personalization data BLOB; receiving a command to instantiate a first eSIM; instantiating the first eSIM from the generic data BLOB and the first personalization data BLOB; receiving a command to instantiate a second eSIM; and instantiating the second eSIM from the generic data BLOB and the second personalization data BLOB. In some embodiments, the generic data BLOB comprises an OTA key set from an MNO. In some embodiments, the first personalization data BLOB comprises a first IMSI and a first subscriber key.In some embodiments, the second personalization data BLOB comprises a second IMSI and a second subscriber key.

[0027] This summary is provided merely for the purpose of summarizing some example embodiments to provide a basic understanding of some aspects of the disclosure. Accordingly, it will be appreciated that the example embodiments described above are only examples and should not be construed as limiting the scope or spirit of the disclosure in any way. Other embodiments, aspects, and advantages will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which illustrate, by way of example, the principles of the described embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] The disclosure will be readily understood from the following detailed description taken in conjunction with the accompanying drawings, in which like reference numerals designate like structural elements. Fig. 1 illustrates an example eSIM package including a data blob installed in an eUICC, according to some embodiments. Fig. 2 illustrates an example block diagram of a wireless device setup including the data BLOB and the eUICC, according to some embodiments. Fig. 3 illustrates an example block diagram of a trusted entity in communication with the wireless device, according to some embodiments. Fig. 4 illustrates an example eSIM instantiated in the wireless device, according to some embodiments. Fig. 5 illustrates a second example eSIM instantiated in the wireless device, according to some embodiments. Fig. 6A illustrates an example eSIM package including two data blobs, according to some embodiments. Fig. 6B illustrates an example eSIM package including a generic data BLOB and two personalization data BLOBs, according to some embodiments. Fig. 7A illustrates example logic for instantiating multiple eSIM instances in a wireless device according to some embodiments. Fig. 7B illustrates example logic for instantiating multiple eSIM instances in a wireless device using multiple personalization data BLOBs, according to some embodiments. Fig. 8 illustrates example logic implemented by an eSIM provider, according to some embodiments. Fig. 9 illustrates an example manufacturing environment according to some embodiments. Fig. 10 illustrates example operations in a wireless device factory according to some embodiments. Fig. 11 illustrates an example computing device according to some embodiments. DETAILED DESCRIPTION

[0029] Reference will now be made in detail to representative embodiments illustrated in the accompanying drawings. It should be understood that the following descriptions are not intended to limit the embodiments to a single preferred embodiment. On the contrary, it is intended to cover alternatives, modifications, and equivalents as may be included within the spirit and scope of the described embodiments as defined by the appended claims. One approach to reducing problems with downloading eSIMs over-the-air involves first creating an eSIM package, including a data BLOB. The eSIM package may then be loaded into an eUICC in a manufacturing environment. The eUICC may subsequently be embedded into a wireless device by a manufacturer.In some embodiments, the eUICC in the wireless device initially does not have an eSIM but waits for an instantiation command. A user can instruct, via the wireless device's user interface, that an eSIM be instantiated in the eUICC. Alternatively, the eUICC can, via the wireless device, undergo an authentication protocol with a trusted entity, which then instructs the instantiation of an eSIM. In either case, the eUICC receives a command to instantiate an eSIM. In some embodiments, the eUICC then uses the data in the data blob to populate a file structure in its memory with a SIM profile, thereby instantiating a minimal eSIM. In some embodiments, applets are also instantiated based on data in the data blob. In this way, an eSIM is instantiated without over-the-air provisioning.In some embodiments, the minimal eSIM is functional and contains all data required to access network services.

[0030] The minimal eSIM can then be made into a unique eSIM based on unique data in the eUICC or based on unique data received in another way. For example, unique data can be received from an MNO. The unique eSIM can then be made into a functional eSIM by communicating with an MNO. In some embodiments, the functional eSIM includes an IMSI, a subscriber key, and a phone number. At this point, the user can access MNO services using the wireless device. For example, incoming calls to the phone number are routed to the wireless device.

[0031] The user can delete the eSIM and sell the wireless device to another party. The wireless device, as sold, is in a state where the eUICC does not have an eSIM. While the wireless device is owned by the second party, the eUICC can receive a command to instantiate an eSIM. The eUICC then performs the steps of populating a file structure to generate a minimal eSIM and makes the eSIM unique based on data in the data blob, data received from an MNO, or based on other unique input. Alternatively, the instantiated eSIM is unique and functional, enabling communication with an MNO and access to network services. In some embodiments, after instantiating the eSIM, the wireless device communicates with an MNO and receives one or more of a new IMSI, a new subscriber key, and a different phone number.Security elements, such as IMSIs and subscriber keys, are discussed in 3GPP TS 35.205, v12.0.0, dated September 2014, titled "Specification for the MILENAGE Algorithm Set" (hereinafter "TS 35.205"). TS 35.205 is hereby incorporated by reference. After communicating with the MNO, the second party can use the wireless device to access MNO services. For example, incoming calls to the different phone numbers are routed to the wireless device.

[0032] Multiple eSIM instances can coexist in the eUICC. In some embodiments, a wireless device is shared by family members or family and friends. Each person can be assigned a unique eSIM instance. Each user of the device can select which eSIM to use when using the device.

[0033] The eSIM package installed in the manufacturing environment can be specific to an MNO, or it can be a generic package usable by a number of different MNOs. This means that the data blob in the eSIM package can be used by an eUICC to generate the minimal eSIM. The minimal eSIM can include an OTA key common to more than one MNO. In some embodiments, an MNO uses an OTA key set that is kept secret from other MNOs. A key set includes encryption and integrity keys. After the eUICC instantiates the minimal eSIM, a specific MNO can authenticate to the eSIM using the OTA key set. The MNO can then customize the eSIM using RFM or RAM protocols. In some embodiments, the MNO changes (ie, replaces) the key set in the eSIM after the MNO authenticates the instantiated eSIM.For example, the MNO can use a PUT-KEY provisioning command to replace the existing key set after authentication. Adaptation can be performed using RFM or RAM protocols, for example, to modify file contents or load new applets onto the eSIM.

[0034] Some issues related to the manufacturing environment are addressed as follows. The MNO's confidential information is encrypted before being sent from the eSIM provider to the chip manufacturer. The key used for encryption, the KEK, is sent to an OEM server at the wireless device factory. The chip manufacturer produces a wafer containing a plurality of eUICC devices. Each device is programmed with encrypted data. Some of the data is unique to a particular device. For example, in some embodiments, a chip serial number is uniquely assigned to each device. After the devices are programmed, in some embodiments, the wafer is sliced, and the devices are mounted in WLCSPs (Wafer Level Chip Scale Packages). The finished chips are sent to the wireless device factory.At the wireless device factory, a specific eUICC receives the KEK corresponding to it and decrypts the encrypted information within the eUICC itself. In some embodiments, the MNO's confidential information is encrypted twice before being sent from the eSIM provider to the chip manufacturer. The first encryption is performed using a first encryption key and produces a first encryption result. The second encryption is performed using a KEK that accepts the first encryption result and the first encryption key as its argument. The key used for the second encryption, the KEK, is sent to an OEM server at the wireless device factory. The chip manufacturer cannot determine the contents of the MNO's confidential information (eSIM data) because the chip manufacturer does not have access to any of the KEKs.As with single encryption, the chip manufacturer produces a wafer with a plurality of eUICC components and sends the resulting chips to the wireless device factory. The wireless device factory cannot obtain the MNO's confidential information (eSIM data) because the wireless device factory does not have access to the internal data of any of the eUICCs. At the wireless device factory, a specific eUICC receives the KEK corresponding to it and performs decryption to recover the first encryption key and a remaining encrypted portion. The eUICC then uses the recovered first encryption key to decrypt the remaining encrypted portion.

[0035] In some embodiments, the eSIM creates a plurality of eSIM profiles. A specific eSIM profile is encrypted with a specific eSIM encryption key. In some embodiments, the eSIM encryption key is unique to the eUICC in which the eSIM profile is to be programmed. The eSIM encryption key, along with other sensitive data (e.g., other keys associated with the intended eUICC), is encrypted with the KEK. In some embodiments, multiple KEKs are used for a single intended eUICC. For example, in some embodiments, there is a second KEK specifically dedicated to encrypting the eSIM encryption key.

[0036] In some embodiments, the data sent to the chip manufacturer includes the result of encryption with the KEK, the eSIM encryption key, and sensitive data. In some embodiments, the eSIMs encrypted with the eSIM encryption key are also sent to the chip manufacturer. The KEK (or KEKs) of the intended eUICC and a chip serial number of the intended eUICC are sent to the OEM server at the wireless device factory. The OEM server can use the chip serial number to identify the eUICC when the KEK is deployed to the eUICC.

[0037] After decryption at the eUICC is complete, in some embodiments, the eUICC possesses an unencrypted data BLOB and other information. The (unencrypted) data BLOB may contain one or more eSIM profiles representing functional eSIMs. For example, an eSIM pack from the eSIM provider may include a common data BLOB and a set of unique data BLOBs. Each unique data BLOB may contain a set of unique data based on the requirements of an MNO. For example, each unique data BLOB may include one or more of an ICCID, an IMSI, an OTA key set, a subscriber key, or an integrity key. In such an embodiment, each member of the set of unique data BLOBs may correspond to a unique eSIM instance. The set of unique data BLOBs may include a first unique data BLOB and a second unique data BLOB.At a first instantiation time, the eUICC may be instructed to use the shared data blob and either the first unique data blob or the second unique data blob to instantiate a first eSIM. At another time, the eUICC 102 may be instructed to instantiate a second eSIM using the shared data blob and a unique data blob that has not yet been used for eSIM instantiation.

[0038] In some embodiments, the data blob contains files or additional information that the eUICC can use to instantiate a minimal eSIM. The minimal eSIM can be unique and functional, enabling access to network services. Alternatively, the minimal eSIM can be made unique using a single-use element or a value corresponding to an ICCID retrieved from the data blob. The single-use element is a binary string placed in the eSIM package by the eSIM provider. The unique eSIM can then, in some embodiments, be made functional by communicating with an MNO. The MNO can authenticate the eUICC using an OTA key or OTA key set, or using a public key associated with the eUICC for which the eUICC possesses the corresponding private key.The MNO can then provide information, such as an IMSI and a subscriber key, to make the eUICC functional. After the eUICC is functional, additional components, such as applets and files, can be added to an instantiated eSIM. The applets and files can be specific to the user of the wireless device. Example key sets, a key hierarchy, and USIM security (associated with the eSIM) are described in 3GPP TS 33.401, v12.15.0, dated September 2015, titled "Security Architecture" (hereinafter "TS 33.401"). TS 33.401 is hereby incorporated by reference.

[0039] According to various embodiments described herein, the terms "wireless communication device," "wireless device," "mobile device," "mobile station," and "user equipment" (UE) may be used interchangeably herein to describe one or more common consumer electronic devices that may be capable of performing procedures associated with various embodiments of the disclosure. According to various implementations, any of these consumer electronic devices may refer to: a mobile phone or smartphone, a tablet computer, a laptop computer, a notebook computer, a personal computer, a netbook computer, a media player, an electronic book device, a MiFi® device, a wearable computing device, as well as any other type of electronic computing device.that has a wireless communication capability that includes communication over one or more wireless communication protocols, such as used for communication on: a wireless wide area network (WWAN), a wireless metro area network (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN), a near field communication (NFC), a cellular wireless network, a Long Term Evolution (LTE), fourth generation (4G) and / or 5G LTE Advanced (LTE-A) or other enhanced cellular network present or developed in the future.

[0040] The wireless communication device may, in some embodiments, also operate as part of a wireless communication system, which may include a set of client devices, which may also be referred to as stations, wireless client devices, or wireless client communication devices, connected to an access point (AP), e.g., as part of a WLAN, and / or to each other, e.g., as part of a WPAN and / or a wireless ad hoc network. In some embodiments, the client device may be any wireless communication device capable of communicating via WLAN technology, e.g., according to a wireless communication protocol for local area networks.In some embodiments, the WLAN technology may be a WiFi (or more generally, a WLAN) wireless communications subsystem or radio, where the WiFi radio may implement an Institute of Electrical and Electronics Engineers (IEEE) 802.11 technology, such as one or more of: IEEE 802.11a; IEEE 802.11b; IEEE 802.11g; IEEE 802.11-2007; IEEE 802.11n; IEEE 802.11-2012; IEEE 802.11ac; or other existing or future developed IEEE 802.11 technologies.

[0041] Additionally, it should be understood that the UEs described herein may be configured as multi-mode wireless communication devices that are also capable of communicating over various third-generation (3G) and / or second-generation (2G) radio access technologies (RATs). In these scenarios, a multi-mode UE may be configured to preferentially connect to LTE networks that offer faster data rate throughput compared to other legacy 3G networks that offer lower data rate throughput. For example, in some implementations, a multi-mode UE may be configured to fallback to a legacy 3G network, such as an Evolved High Speed ​​Packet Access (HSPA+) network or a Code Division Multiple Access (CDMA) 2000 Evolution-Data Only (EV-DO) network, when LTE and LTE-A networks are otherwise unavailable. eUICC operation

[0042] Fig. 1 illustrates an example system 100 for installing an eSIM package 106 into an eUICC 102 in a manufacturing environment 108. In some embodiments, the manufacturing environment 108 corresponds to a chip factory. The eSIM package 106 includes a data blob 104. In some embodiments, the data blob 104 includes data for instantiating a generic eSIM, which is then made unique by the eUICC. In some embodiments, the data blob 104 includes an ICCID (integrated circuit card identifier) ​​stored in the eUICC 102, which is incremented each time the eUICC 102 instantiates a new eSIM based on the data blob 104. eUICCs are installed in wireless devices as part of a manufacturing process. Fig. 2 illustrates an example system in which the eUICC 102 configured with the data blob 104 is installed in a wireless device 220. The wireless device 220 includes a memory 212, a processor 210, a baseband component 214, and the eUICC 102. The eUICC 102 also includes a memory 206 and a processor 208. The memory 206, in the example configuration of Fig. 2, the data blob 104 includes a public key 202, a private key 203, and an eUICC operating system 204. In some embodiments, the eUICC 102 includes an OTA key (not shown).

[0043] Fig. 3 illustrates an exemplary embodiment in which a trusted entity 302 communicates with the wireless device 220 over a network 304. The network 304 can be either a wired or a wireless network (or a combination thereof). In some embodiments, the trusted entity 302 and the eUICC 102 authenticate each other. For example, the trusted entity 302 can issue a challenge message encrypted with the public key 202 of the eUICC 102. The eUICC 102 can then decrypt the challenge message using its private key 203. The eUICC 102 can similarly authenticate the identity of the trusted entity 302 by requesting a correct response to a message encrypted using a public key of the trusted entity 302 (not shown).In some embodiments, the challenge is based on the OTA key. After authentication is complete, in some embodiments, the trusted entity 302 instructs the wireless device 220 to instantiate an eSIM.

[0044] Fig. 4 illustrates an example system 400 with an eSIM 402 in the eUICC 102. The eSIM 402 is instantiated by the eUICC 102 in response to a command from the trusted entity 302. Alternatively, a command may be received by the eUICC 102 from a user of the wireless device 220. The eUICC 102 responds to the command, regardless of the source, by instantiating the eSIM 402 based on generic data from the data blob 104 in the memory 206. It is a system limitation of the eSIM design that no two eSIMs recognized by an MNO can be identical. In some embodiments, the first eSIM instantiated in the eUICC 102 (i.e., the eSIM 402) is unique based on the data blob 104 uniquely generated for use by the eUICC 102. In some embodiments, the eSIM 402 is functional and contains all data required to access network services from an MNO.In some embodiments, the data blob 104 is created for use by a number of different eUICCs and is granted uniqueness after instantiation. In some embodiments, the eUICC 102 uniques the eSIM 402 using an ICCID present in the data blob 104. After uniquely unique the eSIM 402 using the ICCID, the eUICC 102 increments the ICCID value to generate a new ICCID value and stores the new ICCID value in the memory 206. In some embodiments, applets are also instantiated based on data in the data blob 104.

[0045] In some embodiments, the data BLOB 104 includes a number of different elements to be used for only a single eSIM instantiation. These single-use elements are binary strings that the eUICC 102 uses to uniquely identify a newly instantiated eSIM. After a particular single-use element has been used, the eUICC 102 stores a record in the memory 206 indicating that the particular single-use element is no longer valid. In some embodiments, the data BLOB 104 has a size of 50 to 70 kBytes, and a particular single-use element has a size of 2 to 5 bytes (where a byte consists of 8 bits).

[0046] In some embodiments, when the wireless device 220 of Fig. 4 is deployed on a cellular radio network operated by an MNO, the MNO provides additional SIM profile data to the eSIM 402 using OTA (over-the-air), HTTPS (Hypertext Transport Protocol Secure), or SMS (Short Message Service) methods. In some embodiments, the over-the-air provisioning is performed using an OTA key associated with a specific MNO. In some embodiments, the OTA provisioning is performed using an OTA key that is the same for a number of different MNOs.

[0047] In some embodiments, after instantiating the eSIM 402, an MNO modifies files of the eSIM 402 or loads new applets using RFM or RAM protocols.

[0048] The eSIM 402 has a unique identity obtained through one of the above methods. Associated with the eSIM 402 are an IMSI, a subscriber key, and a device telephone number. The user can then access an MNO for services using the wireless device 220. When access is attempted, the eSIM 402 participates in an AKA (authentication and key agreement) using the IMSI and subscriber key. In some embodiments, the AKA is performed with a HLR (home location register), a VLR (visitor location register), or a MME (mobility management entity). In an example scenario, an MNO network on which the wireless device 220 is deployed includes an MME.After the user's wireless device 220 successfully completes the AKA, incoming voice calls to the user's telephone number are routed through the MME to the wireless device 220.

[0049] The user can sell their wireless device 220 to a second party. Before the sale, in some embodiments, the user instructs the wireless device 220 to delete the eSIM 402. The sale is then completed, and the second party possesses and owns the wireless device 220. However, the wireless device 220 cannot take a first step to access MNO services because there is no eSIM to perform the AKA. In some embodiments, this is not a sale; rather, a second eSIM must be instantiated, and the eSIM 402 is not deleted.

[0050] A trusted entity (such as the trusted entity 302 or another trusted entity) instructs, in some embodiments, the eUICC 102 to create a second eSIM, for example, a Fig. 5. In some embodiments, the eUICC 102 receives the command to instantiate from the second party. The eUICC 102 has retained the data blob 104 in the memory 206. The eUICC 102 then instantiates the eSIM 502 using the data blob 104. In some embodiments, the eSIM 502 is initially identical to the eSIM 402 after the eSIM 402 is first instantiated. In some embodiments, the eSIM 502 is unique after instantiation with the uniqueness based on the eUICC 102 using the stored incremented ICCID value, based on the eUICC 102 using a new one-time-use element, or based on another unique input.In some embodiments, the eSIM 502 is provided with data to make it unique after the wireless device 220 is deployed on a cellular radio network of an MNO that provides customization data. This data obtained from the MNO may be provided to the eSIM 502 using OTA-HTTPS or SMS, as noted above. In some embodiments, there is no sale involved, and the eSIM 502 remains stored or present in the eUICC 102 after the eSIM 502 is instantiated (not shown in FIG. Fig. 5).

[0051] The eSIM 502 has a unique identity obtained through one of the above methods. Associated with the eSIM 502 are a new IMSI, a new subscriber key, and, in some embodiments, a different device phone number. The second party can then access an MNO for services using the wireless device 220. During the access attempt, the eSIM 502 participates in an AKA using the new IMSI and the new subscriber key. After the second party's wireless device 220 successfully completes the AKA, incoming voice calls to the different phone number are routed to the wireless device 220.

[0052] In some embodiments, the eSIM package 106 includes a plurality of data BLOBs. Fig. 6A illustrates an example embodiment in which the eSIM package 106 includes a data blob 602 and a data blob 604. At a time of eSIM instantiation, the trusted entity 302 may instruct the eUICC 102 to use a particular one of the plurality of data blobs. For example, for a first and a second eSIM instantiation, the eUICC 102 may be instructed to use the data blob 602 and to increment the ICCID value found in the data blob 602 (thus achieving uniqueness of the second eSIM relative to the first). For a third eSIM instantiation, the eUICC 102 may be instructed to use the data blob 604. The first and second eSIMs may be initiated in response to commands from a trusted entity associated with a first MNO, and the third eSIM may be instantiated in response to a command from a trusted entity associated with a second, different MNO.In exemplary embodiments, the data blob 602 is configured for the first MNO and the data blob 604 is configured for the second MNO.

[0053] In some embodiments, the eSIM package 106 includes a common data blob and a set of unique data blobs. In such an embodiment, each member of the set of unique data blobs may correspond to a unique eSIM instance. The set of unique data blobs may include a first unique data blob and a second unique data blob. The unique data blobs provide unique personalization information for each instantiated unique eSIM. Therefore, these data blobs are also referred to herein as personalization data blobs. In contrast, the common data blob common to the multiple instantiations of unique eSIMs is also referred to herein as a generic data blob. Fig. 6B illustrates an exemplary embodiment of the eSIM package 106 with a generic data BLOB 612, a personalization data BLOB 614, and a personalization data BLOB 616. At a first instantiation time, the eUICC 102 may be instructed by the trusted entity 302 or by the user of the wireless device 220 to use the generic data BLOB 612 and either the personalization data BLOB 614 or the personalization data BLOB 616 to instantiate a first eSIM. At another time, the eUICC 102 may be instructed to instantiate a second eSIM using the generic data BLOB 612 and a (unique) personalization data BLOB that has not yet been used for eSIM instantiation.

[0054] Fig. 7A illustrates example logic 700 for instantiating first and second eSIMs from a data blob. At 702, an eUICC, in a manufacturing environment, receives an eSIM package including a data blob. At 704, the eUICC receives a command to instantiate a first eSIM. At 706, the eUICC instantiates the first eSIM. At 708, the eUICC customizes the first eSIM to make it unique. This may be accomplished through a one-time use element with a counter that is incremented, for example, an incremented ICCID value, or with another unique input. In some embodiments, the customization is performed by a first mobile network operator using OTA-HTTPS or SMS programming techniques. At 710, the eSIM receives a command to delete the first eSIM, and deletes the first eSIM at 712. At 714, the eUICC receives a command to instantiate a second eSIM. At 716, the eUICC instantiates the second eSIM.The second eSIM can be instantiated from the data blob or from a second data blob in the eSIM package. At 718, the eUICC adapts the second eSIM. The adaptation of the second eSIM can be done in communication with an MNO.

[0055] Fig. 7B illustrates example logic 720 for instantiating first and second eSIMs from an eSIM pack, including a generic data blob and two personalization data blobs. At 722, an eUICC, in a manufacturing environment, receives an eSIM pack including a generic data blob, a first personalization data blob, and a second personalization data blob. At 724, the eUICC receives a command to instantiate a first eSIM using the first personalization data blob. At 726, the eUICC instantiates the first eSIM using the generic data blob and the first personalization data blob. At 728, the eUICC receives a command to instantiate a second eSIM using the second personalization data blob. At 730, the eUICC instantiates the second eSIM using the generic data blob and the second personalization data blob. eUICC manufacturing logic

[0056] Fig. 8 illustrates exemplary logic 800 for manufacturing the eUICC 102. Participants include an eSIM provider that provides encrypted information to a chip manufacturer. The eSIM provider also provides associated encryption information to a wireless device factory. The chip manufacturer uses the encrypted information to program a wafer. The wafer includes a number of chips or components that are packaged after programming. At 802, the eSIM provider generates eSIM profiles. At 804, the eSIM generates an eSIM encryption key. At 806, the eSIM provider encrypts the eSIM profiles using the encryption key to generate a first encryption result. At 808, the eSIM provider generates a KEK (key encryption key).At 810, the eSIM provider encrypts the first encryption result using the KEK to generate a second encryption result. At 812, the eSIM provider sends the second encryption result to the chip manufacturer, and at 814, the eSIM provider sends the KEK to the wireless device factory. eSIM provider and wireless device factory

[0057] Fig. 9 illustrates an exemplary system 900 for manufacturing the eUICC 102 using the logic of Fig. 8. Overall, Fig. 9 illustrates an eSIM provider 904 providing encrypted information 912 to a chip manufacturer 902. The eSIM provider 904 also provides associated encryption information 914 to a wireless device factory 906. The chip manufacturer 902 uses the encrypted information 912 to program the wafer 908, as indicated by arrow 910. The wafer 908 includes a number of chips or components that are packaged after programming. The encrypted information 912 is located at the chip level. That is, the eSIM provider 904 generates records per chip. The eUICC 102 (although not embedded at this point) is illustrated by arrow 916 as being based on the wafer 908. The eUICC 102 is provided to the wireless device factory 906 as indicated by arrow 918.

[0058] In one exemplary embodiment, a particular MNO defines an eSIM profile. The eSIM provider 904 generates a plurality of eSIMs based on the defined eSIM profile. The number of generated eSIMs is, for example, on the order of 1 million per defined profile. The eSIM provider 904 then forms data BLOBs for inclusion in eUICCs to be manufactured by the chip manufacturer 902. The eUICC 102 is, for example, one of the eUICCs to be manufactured. The eSIM provider 904 also generates key data, including, for example, an eSIM encryption key and a KEK. The key data, in some embodiments, also includes an authentication key. In some embodiments, the key data includes a public key 202 and a private key 203. The associated encryption information 914 includes a plurality of KEKs.In some embodiments, a KEK is located in the associated encryption information 914 for each data blob encrypted in the encrypted information 912.

[0059] The eSIM provider 904 also generates an eUICC operating system file according to the defined eSIM profile. In some embodiments, the eUICC operating system file includes the eUICC operating system 204. The eSIM provider 904 also generates personalization data.

[0060] In an exemplary embodiment, the data to be encrypted includes one or more of: the eUICC operating system file, the public key 202, the private key 203, an OTA key set, one or more defined eSIM profiles, a chip serial number, or the personalization data. A set of data to be encrypted is dedicated to a single chip in exemplary embodiments. For example, in some embodiments, the public key 202 and the private key 203 are unique, and a particular pair of the public key 202 and the private key 203 is not programmed into more than one chip.

[0061] The chip manufacturer 902 is not a trusted entity. The eSIM provider 904 uses a portion of the key data to maintain the confidentiality of the MNO, thereby providing only the encrypted information 912 to the chip manufacturer 902. In some embodiments, the eSIM encryption key is used to encrypt the data to be encrypted to generate a first encryption result. The KEK is then used to encrypt the eSIM encryption key and the first encryption result to generate the encrypted information 912. The encrypted information 912 is sent to the chip manufacturer 902 as an encrypted data BLOB or an encrypted eSIM package. The encrypted information 912, in some embodiments, also includes a set of one-time-use elements, as described above.In some embodiments, each data blob in the encrypted information 912 includes an ICCID.

[0062] Chip manufacturer 902 uses encrypted information 912 to program the chips or components of wafer 908. Thus, the defined eSIM profile is programmed without using over-the-air programming. Confidentiality is maintained using encryption. Chip manufacturer 902 is unable to read or analyze encrypted information 912 because chip manufacturer 902 does not possess the KEK.

[0063] A plurality of eUICC devices are manufactured in WLCSPs (Wafer Level Chip Scale Packages) by the chip manufacturer 902. After the wafer 908 is manufactured, including programming with the encrypted information 912 at the chip level, the plurality of WLCSPs are manufactured from the wafer 908. For example, the eUICC 102 may be one of the packaged devices resulting from the work of the chip manufacturer 902. The eUICC 102 then includes a chip-scale version of the encrypted information 912. For example, in some embodiments, the eUICC 102 has its own security features, such as a pair of the public key 202 and the private key 203, its own OTA key, its own key set including multiple private / public keys, symmetric keys, and / or its own chip serial number.Some or all of these security features are encrypted with a KEK to maintain confidentiality. At this point, no functional eSIM is instantiated in the eUICC 102 because the encrypted information 912 has not been decrypted.

[0064] After the eUICC 102 is manufactured in the WLCSP form factor, it is sent to the wireless device factory 906 along with a plurality of eUICCs.

[0065] Fig. 10 illustrates an exemplary process 1000 for applying a KEK 1006 corresponding to an encrypted data BLOB 1002 programmed into the eUICC 102. In some embodiments, the encrypted data BLOB 1002 is Fig. 10 an encrypted version of the data blob 104 of Fig. 1. The wireless device factory 906 has received the KEK 1006 for the eUICC 102 in the associated encryption information 914. The wireless device factory 906 includes a wireless device 1010, other wireless devices indicated by ellipsis ("..."), and the wireless device 220. The wireless device 220, as depicted within the wireless device factory 906, is awaiting installation of the eUICC 102. In some embodiments, the eSIM provider 904 sends the associated information 914 to a central OEM data center, and the associated information 914 is later provided to an OEM server (not shown) at the wireless device factory 906.In the wireless device factory 906, the eUICC 102 provided by the chip manufacturer 902 is installed in the wireless device 220 (shown by the arrow 1004 as emerging from the wireless device manufacturing factory 906).

[0066] In some embodiments, the eUICC 102 performs a mutual authentication protocol with the OEM server to determine that the OEM server is authentic and to prove its own identity. The public key 202 and private key 203 pair can be used for this purpose. That is, the OEM server can encrypt a challenge with the public key 202 and send it to the eUICC 102. The eUICC can prove possession of the private key 203 (and thus its authenticity, its identity) by successfully decrypting the challenge and responding to the OEM server with the decrypted challenge. In some embodiments, the chip serial number of the eUICC 102 is used by the OEM server to address the eUICC 102.

[0067] In some embodiments, the eUICC 102 and the OEM server may establish a session key using one of a number of algorithms, for example, a Diffie-Hellman algorithm. In some embodiments, the OEM server encrypts the KEK 1006 with the established session key and sends it to the eUICC 102. The eUICC 102 may then retrieve the KEK 1006 using the established session key and decrypt the encrypted data blob 1002 to generate a first decryption result, including an encryption key and remaining encrypted information. The eUICC 102 may use the eSIM encryption key to decrypt the remaining encrypted information to generate a second decrypted result.The second decryption result may include the eUICC operating system file, the public key 202, the private key 203, the OTA key, the one or more defined eSIM profiles, and the personalization data originally encrypted by the eSIM provider 904 as described above.

[0068] In some embodiments, the underlying data has undergone a single encryption process at the eSIM provider 906. After decryption, for example, with the KEK 1006, the underlying data is in plaintext, and no further decryption is required. This means that the UICC can directly read the data encrypted by the eSIM provider 906 due to file size definitions, data field delimiters, or file markers. Examples of data in plaintext after decryption using the KEK 1006 include the eUICC operating system file, the public key 202, the private key 203, the OTA key, the one or more defined eSIM profiles, or the personalization data.

[0069] In some embodiments, the one or more defined eSIM profiles of the second decryption result are not instantiated, that is, the one or more defined eSIM profiles do not represent one or more functional eSIMs. Instead, the one or more defined eSIM profiles of the second decryption result are data, represented as data BLOB 1008 in Fig. 10 and as data BLOB 104 in Fig. 1, from which one or more eSIMs can be instantiated.

[0070] In some embodiments, the one or more defined eSIM profiles of the second decryption result are instantiated by the decryption process of the eUICC 102. That is, the one or more defined eSIM profiles represent one or more functional eSIMs. Representative exemplary institution

[0071] Fig. Figure 11 illustrates, in block diagram format, an example computing device 1100 that may be used to implement the various components and techniques described herein, according to some embodiments. In particular, the detailed view of the example computing device 1100 illustrates various components used in the eUICC 102 of Fig. 1, Fig. 4, Fig. 5, Fig. 9 and Fig. 10 and / or the Fig. 2 to 5 and 10. As shown in Fig.As shown in Figure 11, the computing device 1100 may include a processor 1102, which represents a microprocessor or control unit for controlling the overall operation of the computing device 1100. The computing device 1100 may also include a user input device 1108 that allows a user of the computing device 1100 to interact with the computing device 1100. For example, the user input device 1108 may take a variety of forms, such as a button or key, a keypad, a touchpad or dial, a touch-sensitive screen, an audio input interface, a visual / image capture input interface, input in the form of sensor data, etc.Additionally, computing device 1100 may include a display 1110 (screen display) that may be controlled by processor 1102 to display information to the user (e.g., information regarding an incoming, outgoing, or active communication session). A data bus 1116 may enable data transfer between at least one data storage device 1140, processor 1102, and a control unit 1113. Control unit 1113 may be used to interface with and control other equipment through an equipment control bus 1114. Computing device 1100 may also include a network / bus interface 1111 coupled to a data link 1112. In the case of a wireless link, network / bus interface 1111 may include wireless circuitry, such as a wireless transceiver and / or a baseband processor.The computing device 1100 may also include a secure element 1150. The secure element 1150 may include an eUICC or a UICC.

[0072] Computing device 1100 also includes a data storage device 1140, which may comprise a single data store or a plurality of data stores (e.g., hard disk drives), and includes a data storage management module that manages one or more partitions within data storage device 1140. In some embodiments, data storage device 1140 may include flash memory, solid-state memory, or the like. Computing device 1100 may also include random access memory (“RAM”) 1120 and read-only memory (“ROM”) 1122. ROM 1122 may store programs, utilities, or processes to be executed in a non-volatile manner. RAM 1120 may provide volatile data storage and stores instructions related to the operation of computing device 1100.

[0073] The various aspects, embodiments, implementations, or features of the described embodiments may be used separately or in any combination. Various aspects of the described embodiments may be implemented by software, hardware, or a combination of hardware and software. The described embodiments may also be embodied as computer-readable code on a computer-readable medium. The computer-readable medium is any data storage device capable of storing data that can subsequently be read by a computer system. Examples of the computer-readable medium include read-only memory, random access memory, CD-ROMs, DVDs, magnetic tape, hard disk data storage drives, solid-state drives, and optical data storage devices.The computer-readable medium may also be distributed across network-coupled computer systems so that the computer-readable code is stored and executed in a distributed manner.

[0074] The foregoing description utilized specific nomenclature for purposes of explanation in order to provide a thorough understanding of the described embodiments. However, it will be apparent to those skilled in the art that the specific details are not required to practice the described embodiments. Thus, the foregoing descriptions of specific embodiments are presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the described embodiments to the precise forms disclosed. It will be apparent to those skilled in the art that many modifications and variations are possible in light of the above teachings.

Claims

[1] A method by means of an eUICC (embedded universal integrated circuit card) (102) embedded in a wireless device (220), the method comprising: at the eUICC (102): Receiving (704) a first request to instantiate a first electronic subscriber identity module, eSIM (electronic subscriber identity module) (402, 502); Instantiating (706) the first eSIM (402, 502) using generic data (612) from a large binary data object, data BLOB (data binary large object) (104, 602, 604); characterized by : Adapting (708) the first eSIM (402, 502) based on first data from the data BLOB (104, 602, 604) or based on second data from the eUICC (102) or based on third data from a second data BLOB (104, 602, 604). [2] The method of claim 1, further comprising: Successfully completing an authentication and key agreement procedure, AKA (authentication and key agreement) with a mobile network operator after customization. [3] The method of claim 1, wherein the first data comprises a first element of a set of single-use elements of the data BLOB (104, 602, 604). [4] The method of claim 1, wherein the second data comprises a value corresponding to an integrated circuit card identifier (ICCID). [5] The method of claim 1, further comprising: Receiving personalization data, including a first international mobile subscriber identity (IMSI) and a first subscriber key from a first mobile network operator (MNO) via the wireless device (220); and Storing the personalization data in the first eSIM (402, 502). [6] The method of claim 5, further comprising: Generating a first challenge value based on the first IMSI and the first subscriber key; and Sending the first query value to a first MNO via the wireless device (220). [7] The method of claim 6, further comprising: Receiving an instruction to delete the first eSIM (402, 502) via the wireless device (220); and Deleting the first eSIM (402, 502). [8] The method of claim 6, further comprising: Receiving (714) a second request to instantiate a second eSIM (402, 502); Instantiating (716) the second eSIM (402, 502) using the generic data (612) from the data BLOB (104, 602, 604); and Adapting (718) the second eSIM (402, 502) based on an element of a set of single-use elements or based on an incremented value of an integrated circuit card identifier, ICCID (integrated circuit card identifier). [9] The method of claim 8, further comprising: Receiving second personalization data comprising a second IMSI and a second subscriber key from a second MNO via the wireless device (220); and Storing the second personalization data in the second eSIM (402, 502). [10] The method of claim 9, further comprising: Generating a second challenge value based on the second IMSI and the second subscriber key; and Sending the second query value to the second MNO via the wireless device (220). [11] Embedded universal integrated circuit card, eUICC (embedded universal integrated circuit card) (102), comprising: a memory (206); and processing circuitry (208, 210, 214) coupled to the memory (206), wherein the memory (206) is configured to store instructions that, when executed by the processing logic (208, 210, 214), cause the eUICC (102) to: Receiving (704) a first request to instantiate a first electronic subscriber identity module, eSIM (electronic subscriber identity module) (402, 502), Instantiating (706) the first eSIM (402, 502) using generic data (612) from a large binary data object, data BLOB (data binary large object) (104, 602, 604), characterized by that the instructions also require the eUICC (102) to: Adapting the first eSIM (402, 502) based on first data from the data BLOB (104, 602, 604) or based on second data from the eUICC (102) or based on third data from a second data BLOB (104, 602, 604). [12] The eUICC (102) of claim 11, wherein the eUICC (102) is housed in a wireless device, the eUICC (102) further comprising: an interface coupled to a processor of the wireless device, wherein the memory (206) is further configured to store instructions that, when executed by the processing circuitry (208, 210, 214), further cause the eUICC (102) to: Receiving a second request to instantiate a second eSIM (402, 502), Instantiating the second eSIM (402, 502) using the generic data (612) from the data BLOB (104, 602, 604), Adapting the second eSIM (402, 502) based on fourth data from the second data blob (104, 602, 604), and if the first eSIM is customized based on first data from the data blob (104, 602, 604) or second data from the eUICC (102): i) receiving, by the processor via the interface, personalisation data, including a first international mobile subscriber identity (IMSI) and a first subscriber key from a first mobile network operator (MNO), and ii) storing the personalization data in the first eSIM (402, 502). [13] The eUICC (102) of claim 11, wherein the memory (206) is further configured to store instructions that, when executed by the processing circuitry (208, 210, 214), cause the eUICC (102) to: Authenticate the first request using an over-the-air, OTA key set. [14] The eUICC (102) of claim 11, wherein the memory (206) is further configured to store instructions that, when executed by the processing circuitry (208, 210, 214), cause the eUICC (102) to: Receiving a second request to instantiate a second eSIM (402, 502); Instantiating the second eSIM (402, 502) using the generic data (612) from the data BLOB (104, 602, 604); and Adapting the second eSIM (402, 502) based on an element of a set of single-use elements or based on an incremented value of an integrated circuit card identifier (ICCID). [15] The eUICC (102) of claim 14, wherein the memory (206) is further configured to store instructions that, when executed by the processing circuitry (208, 210, 214), cause the eUICC (102) to: Receiving second personalization data comprising a second IMSI and a second subscriber key from a second MNO via the wireless device (220); and Storing the second personalization data in the second eSIM (402, 502).

Images