CN104221347A - Mobile device supporting multiple access control clients and corresponding method - Google Patents

Abstract

The present invention discloses, in one aspect, a method and apparatus for large-scale distribution of electronic access control clients, and a layered security software protocol. In one exemplary embodiment, the server electronic universal integrated circuit card (eUICC) and the client eUICC software comprise a so-called "stack" of software layers. Each software layer is responsible for a set of hierarchical functions that are negotiated with its corresponding peer software layer. The layered security software protocol is configured for large-scale distribution of electronic subscriber identity modules (esims).

Description

Mobile device supporting multiple access control clients and corresponding method

priority

This patent application claims priority to U.S. Patent Application 13/767,593, entitled "METHODS AND APPARATUS FOR LARGE SCALE DISTRIBUTION OFELECTRONIC ACCESS CLIENTS," filed concurrently with this patent application on February 14, 2013, which claims February 2012 Priority to U.S. Provisional Patent Application 61/598,819, filed on the 14th, entitled "METHODS ANDAPPARATUS FOR LARGE SCALE DISTRIBUTION OF ELECTRONICACCESS CLIENTS," each of which is hereby incorporated by reference in its entirety.

Related Patent Applications

This patent application is related to commonly owned and co-pending U.S. Patent Application 13/457,333, filed April 26, 2012, entitled "ELECTRONICACCESS CLIENT DISTRIBUTION APPARATUS AND METHODS"; US Patent Application 13/464,677 for APPARATUS FOR PROVIDING MANAGEMENTCAPABILITIES FOR ACCESS CONTROL CLIENTS; US Patent Application 13/095,716 for APPARATUS ANDMETHODS FOR DISTRIBUTING AND STORING ELECTRONIC ACCESS CLIENTS, filed April 27, 2011; U.S. patent application 13/080,558 entitled "APPARATUS AND METHODS FOR CONTROLLING DISTRIBUTION OFELECTRONIC ACCESS CLIENTS" filed on November 22, 2010, entitled "WIRELESS NETWORK AUTHENTICATION APPARATUS AND METHODS"; U.S. Patent Application 12/952,089, filed on November 22, 2011, entitled "METHODS FOR PROVISIONING SUBSCRIBERIDENTITY DATA IN A WIRELESS NETWORK"; /183,023; U.S. Patent Application 12/353,227, filed January 13, 2009, entitled "POSTPONED CARRIER CONFIGURATION"; U.S. Patent Application 13/, filed April 25, 2011, entitled "APPARATUS AND METHODS FOR STORING ELECTRONICACCESS CLIENTS" 093,722; US Patent Application 13/109,851, filed May 17, 2011, entitled "METHODS AND APPARATUS FOR ACCESS CONTROL CLIENTASSISTED ROAMING"; 20 U.S. Patent Application 13/079,614, filed 4/4/11, entitled "MANAGEMENT SYSTEMS FOR MULTIPLE ACCESS CONTROL ENTITIES"; Patent Application 13/111,801; U.S. Patent Application 13/080,521, filed April 5, 2011, entitled "METHODS AND APPARATUS FOR STORAGE AND EXECUTION OFACCESS CONTROL CLIENTS"; filed April 1, 2011, entitled "ACCESS DATA PROVISIONING APPARATUS ANDMETHODS"; US Patent Application 13/287,874, filed November 2, 2011, entitled "METHODS AND APPARATUS FOR ACCESS DATA RECOVERY FROMA MALFUNCTIONING DEVICE"; filed April 5, 2011 U.S. Patent Application 13/080,533 for "SIMULACRUM OF PHYSICAL SECURITY DEVICEAND METHODS"; and U.S. Patent Application 4,13/29 for "APPARATUS AND METHODS FOR RECORDATION OF DEVICE HISTORY ACROSS MULTIPLE SOFTWARE EMULATION," filed November 11, 2011, Each of the aforementioned applications is hereby incorporated by reference in its entirety.

Background technique

1. Technical field

This disclosure relates generally to the fields of wireless communications and data networking. More particularly, the present invention relates to methods and apparatus for mass distribution of electronic access control clients.

2. Related fields

Access control is required in the latest radio communication systems to enable secure communication. For example, a simple access control scheme could include: (i) verifying the identity of communicating parties; and (ii) granting a level of access commensurate with the authenticated identity. In the context of an exemplary cellular system, such as the Universal Mobile Telecommunications System (UMTS), access control is governed by an access control client, called a Universal Subscriber Identity Module (USIM), on a physical Universal Integrated Circuit Card (USIM). UICC) (also known as "SIM card"). The USIM Access Control Client authenticates users of the UMTS cellular network. After successful authentication, the user is allowed to access the cellular network. As used hereinafter, the term "access control client" generally refers to a logical entity implemented in hardware or software and adapted to control a first device's access to a network. Common examples of access control clients include the aforementioned USIM, CDMA Subscriber Identity Module (CSIM), IP Multimedia Services Identity Module (ISIM), Subscriber Identity Module (SIM), Removable Subscriber Identity Module (RUIM), etc.

Previous SIM-based approaches suffered from several failures. For example, conventional UICCs only support a single USIM (or more generally "SIM") access control client. If a user wishes to authenticate to the cellular network with a different SIM, the user must physically swap the SIM card in the device with a different SIM card. Some devices have been designed to accommodate two SIM cards simultaneously (dual SIM phones); however, such dual SIM phones do not address the fundamental physical limitations of SIM card devices. For example, information stored within one SIM card cannot easily be merged with information stored within another SIM card. Existing dual SIM devices cannot access the contents of both SIM cards at the same time.

Furthermore, accessing the SIM cards takes a significant amount of time for the user; switching between SIM cards to transfer information is undesirable, as is the case in both legacy and dual SIM devices.

Furthermore, existing SIM card issuers and activation entities are generally network-specific and not universal to different users in different networks. Specifically, a given user within a given network must either activate his phone or obtain a replacement SIM card from a very specific entity authorized to issue SIMs. This can greatly limit a user's ability to quickly gain valid access, such as when roaming across other networks, swapping their phones, and the like.

More recently, electronic SIMs (so-called eSIMs) have been developed by, for example, its assignees. These e-SIMs offer enhanced flexibility in swapping out with another eSIM, transferring to another device, etc. However, existing network infrastructure for distributing and activating SIMs has not kept pace with these developments.

Therefore, new solutions and infrastructures are required to take advantage of the enhanced flexibility offered by electronic access clients such as eSIMs and support their secure and pervasive distribution.

Contents of the invention

In particular, the present disclosure relates to electronic access control clients for mass distribution.

First, a method for mass distribution of electronic access control clients is disclosed. In an exemplary embodiment, the method includes: establishing ownership of one or more electronic access control clients; determining whether the one or more electronic access control clients have not been previously copied; encrypted for transmission to the second device; and exchanging the encrypted one or more electronic access control clients.

Also disclosed is an apparatus for mass distribution of electronic access control clients. In one exemplary embodiment, the apparatus includes: a processor; and a non-transitory computer-readable medium comprising instructions that, when executed by the processor: establish ownership of one or more electronic access control clients; Determining whether the one or more electronic access control clients have not been previously copied; encrypting the one or more electronic access control clients for transmission to the second device; and exchanging the encrypted one or more electronic access control clients.

A mobile device for handling electronic access control clients is also disclosed. In one embodiment, the device includes: a wireless interface configured to communicate with a wireless network; a processor in data communication with the interface; and a secure element in data communication with the interface. In one variant, the secure element includes: a secure processor; secure storage in data communication with the secure processor and storing a plurality of access control clients operable to authenticate at least to the wireless network; and logic for data communication by the security processor, the logic configured to store, access, and transmit a plurality of access control clients to or from the user mobile device; and user interface logic, at least in communication with the secure element and configured to enable the user to move A user of the device can select one of the stored plurality of access control clients and authenticate the user mobile device to the network to be able to communicate with the network.

A wireless system is also disclosed.

Additionally, a computer readable device is disclosed. In one embodiment, the apparatus comprises a storage medium having stored thereon a computer program configured, when executed, to: distribute the electronic access control client.

Additionally, a network architecture for providing wireless mobile devices with electronic access clients is disclosed. In one embodiment, the architecture includes: a plurality of agents; and a plurality of manufacturers in data communication with the plurality of agents. In one variation, a given user mobile device can be serviced by more than one of the agents; and any of the agents can order electronic access clients from one or more manufacturers.

Apparatus for providing an electronic access client to one or more mobile devices is also disclosed. In one embodiment, the device includes: at least one processor; and first logic in data communication with the at least one processor, the first logic is configured to cause the device to perform encryption and decryption of the access client; and at least one processing second logic in data communication with the at least one processor, the second logic configured to cause the device to ensure that the access client is not duplicated; and third logic in data communication with at least one processor, the third logic configured to cause the device to establish the access client at least one of trust, ownership and/or verification of the end user.

An electronic access control client revocation procedure is also disclosed. In one embodiment, the process includes: determining whether a signing certificate authority that issued a certificate is affected, the certificate is associated with one or more devices storing the certificate; The created certificate service request is determined at; a new certificate is requested using the determined certificate service request; and a new certificate is issued based on the request. In one variant, one or more devices can issue a new certificate containing a previous public key corresponding to the previous private key, using the previously used private key as part of the request.

Other features and advantages of the present disclosure will be immediately appreciated by those of ordinary skill in the art with reference to the following drawings and detailed description of the exemplary embodiments.

Description of drawings

FIG. 1 is a logical block diagram of an exemplary electronic universal integrated circuit card (eUICC) that may be used in conjunction with aspects of the present disclosure.

2 is a logical block diagram of an exemplary electronic subscriber identity module (eSIM) directory structure that may be used in conjunction with aspects of the present disclosure.

3 is a logical block diagram representing an exemplary state machine for a subscriber identity module (SIM) specific file (SDF) that may be used in conjunction with aspects of the present disclosure.

4 is a logical block diagram representing an exemplary state machine for eSIM operation that may be used in conjunction with aspects of the present disclosure.

5 is an illustration of an exemplary eSIM proxy network that may be used in conjunction with various embodiments of the present disclosure.

Figure 6 is a logic block diagram of an exemplary layered security protocol that may be used in conjunction with various embodiments of the present disclosure.

FIG. 7 is a diagram of an exemplary data structure comprising three (3) parts that may be used in conjunction with aspects of the present disclosure.

8 is an illustration of an exemplary OEM certificate hierarchy that may be used in conjunction with aspects of the present disclosure.

9 is a logic flow diagram illustrating one example logical sequence for transferring an eSIM to an unpersonalized device.

10 is a logic flow diagram illustrating one example logical sequence for transferring an eSIM to a pre-personalized device.

11 is a logic flow diagram illustrating one example logical sequence for transferring a batch of eSIMs to a device.

Figure 12 is a logical representation of an Electronic Universal Integrated Circuit Card (eUICC) device.

Figure 13 is a logical representation of an Electronic Subscriber Identity Module (eSIM) repository device.

Figure 14 is a logic flow diagram illustrating an exemplary user device.

Figure 15 is a logic flow diagram illustrating one embodiment of a method for mass distribution of electronic access control clients.

all pictures Copyright 2012-2013 Apple Inc. All rights reserved.

Detailed ways

Referring now to the drawings, like numerals refer to like parts throughout.

Description of Exemplary Embodiments

Exemplary embodiments and aspects of the present disclosure are now described in detail. Although these embodiments and aspects are primarily discussed in the context of a Subscriber Identity Module (SIM) of a GSM, GPRS/EDGE or UMTS cellular network, those of ordinary skill will appreciate that the present disclosure is not so limited. In fact, the various features of the present disclosure can be used with any network (whether wireless cellular or otherwise) that might benefit from storing and distributing access control clients to devices.

As used herein, the terms "client" and "UE" include, but are not limited to, wireless-enabled cellular phones, smart phones (such as iPhone ^™ ), wireless-enabled personal computers (PCs), mobile devices such as handheld computers , PDAs, Personal Media Devices (PMDs), wireless tablet computers (such as iPad ^(TM ), so-called "phablets", or any combination of the above.

As used hereinafter, the terms "subscriber identity module (SIM)", "electronic SIM (eSIM)", "profile" and "access control client" generally refer to an A logical entity that accesses the network. Common examples of access control clients include the aforementioned USIM, CDMA Subscriber Identity Module (CSIM), IP Multimedia Services Identity Module (ISIM), Subscriber Identity Module (SIM), Removable User Identity Module (RUIM), etc. or any combination of the above.

It can also be appreciated that although the term "subscriber identity module" (e.g., eSIM) is used herein, this term does not necessarily include or require (i) use by the user himself (i.e., the various aspects of the present disclosure may be practiced by the user or non-user). characteristics); (ii) the identity of a single individual (i.e., the various characteristics of the disclosure may be practiced on behalf of a group of individuals, such as a family, or an intangible or imaginary entity such as a business); or (iii) any tangible "module" device or hardware.

Exemplary eUICC and eSIM operation -

Various features and functions of the present disclosure are now discussed in connection with an exemplary implementation. In the context of the exemplary embodiments of the present disclosure, rather than using a physical UICC as in the prior art, the UICC is simulated as a virtual or electronic entity, such as a software application, hereinafter referred to as an electronic universal integrated circuit card (eUICC). ), which is contained within a secure element (such as a secure microprocessor or storage device) in the UE. The EUICC is capable of storing and managing multiple SIM elements, hereinafter referred to as Electronic Subscriber Identity Modules (eSIMs). Each eSIM is a software emulation of a typical USIM and contains similar programming and user data associated with it. The EUICC selects an eSIM based on its ICC-ID. Once the eUICC selects the desired eSIM, the UE can initiate an authentication procedure to obtain wireless network services from the eSIM's corresponding network operator.

EUICC Software Architecture -

Referring now to FIG. 1 , there is shown an exemplary electronic universal integrated circuit card (eUICC) that may be used in connection with the present disclosure. An example of an exemplary eUICC is described in commonly owned and co-pending U.S. Patent Application 13/093,722, entitled "APPARATUS ANDMETHODS FOR STORING ELECTRONIC ACCESS CLIENTS," filed April 25, 2011, which is incorporated herein by reference in its entirety. input, but it is recognized that other examples may be used in accordance with the present disclosure.

Figure 1 shows an exemplary Java Card ^(TM) eUICC architecture. Other examples of operating systems (OS) for use on smart card applications include, but are not limited to, MULTOS and proprietary OSs, Java Card is merely exemplary. OS provides the interface between application software and hardware. Typically, an OS includes services and functions configured for: Input Output (I/O), Random Access Memory (RAM), Read Only Memory (ROM), Non-Volatile Memory (NV) ( EEPROM, flash memory) etc. The OS may also provide cryptographic services, memory and file management, and communication protocols used by higher layers.

The exemplary Java implementation consists of three parts: the Java Card Virtual Machine (JCVM) (a byte code interpreter); the Java Card Runtime Environment (JCRE) (which manages card resources, execution of applets, and other runtime features) ; and the Java Application Programming Interface (API) (a set of custom classes for programming smart card applications).

The JCVM has an on-card component (byte code interpreter) and an off-card counterpart (converter). Due to card resource limitations, some compilation tasks may be performed by the converter. In the beginning, the Java compiler creates class files from source code. The converter preprocesses the class files and creates CAP files. The converter verifies that the load image of Java classes is well-formed, checks for Java card language subset violations, and performs a number of other tasks as well. CAP files contain executable binary representations of classes in a Java package. The converter also generates an export file, which contains public API information. Only load the CAP file into the card. Another common format is IJC, which can be converted from a CAP file. IJC files can be slightly smaller in size than CAP files.

Typically, downloading an applet to the card requires an exchange of Application Protocol Data Units (APDUs) to load the contents of the CAP file into the card's persistent memory. The on-card installer also links the classes in the CAP file with other classes on the card. Then, the installation process creates an instance of the applet and registers the instance with the JCRE. The applet remains suspended until selected.

The above process may additionally implement one or more layers of security. In one exemplary embodiment, a global platform (GP) provides security protocols to manage applications. The GP works within the security issuer security domain, which is the on-card representation of the card issuer. The card can also implement other security domains for eg application providers.

In one exemplary embodiment, the EUICC is a non-removable part of the device. During operation, the eUICC executes a secure bootstrap OS. The boot OS ensures that the eUICC is secure and manages the execution of security protocols within it. An example of a secure bootstrap OS is described in commonly owned and co-pending U.S. Patent Application 13/080,521, entitled "METHODS ANDAPPARATUS FOR STORAGE AND EXECUTION OF ACCESS CONTROLCLIENTS," filed April 5, 2011, previously incorporated by reference It is incorporated in its entirety. It should also be understood that different Mobile Network Operators (MNOs) may customize eSIMs to support various degrees of service differentiation. Common examples of customization include, but are not limited to, having proprietary file structures and/or software applications. Due to the configurability of the eSIM, the size of the eSIM may vary significantly.

Unlike existing technology SIM cards, eSIMs can be freely swapped between devices based on secure transactions. Users don't need a "physical card" to move a SIM between devices; however, the actual transaction with the eSIM must be securely secured, e.g. through specific security protocols. In one exemplary embodiment, the eSIM is encrypted for a particular receiver prior to transmission. In some variants, each eSIM may include, in addition to the encrypted content, a metadata portion, ie in plaintext. Cryptographic signatures can be further used to ensure the integrity of plaintext content. This metadata section can be freely provided (even to insecure entities) to aid insecure storage etc.

eSIM software architecture-

Referring now to FIG. 2 , an exemplary Electronic Subscriber Identity Module (eSIM) directory structure implemented in an exemplary eUICC is disclosed. As shown, the eSIM directory structure has been modified to support the flexibility provided by eSIM. For example, the eSIM directory structure includes, inter alia: (i) EFeSimDir, which contains a list of installed eSIMs; (ii) EFcsn, which contains a card serial number that globally uniquely identifies eUECC; (iii) DFsecurity, which stores security-related data and corresponding Private keys for one or more eUICC certificates. In one such variant, the DFsecurity information includes: (i) DFepcf, which contains the eUICC platform-level PCF; (ii) EFoemcert, which contains the root certificate and the OEM's common name (OEM certificates can be used for special operations such as factory refurbishment ); (iii) EfeUICCcert, which is the eUICC certificate; (iv) EFsL1cert, which is the root certificate of the server L1 device; (v) EFsL2cert, which is the root certificate of the server L2 device; and (vi) EFsL3cert, which is the root certificate of the server L3 device Certificate.

In an exemplary embodiment, the directory structure also includes a SIM Specific File (SDF) containing an eSIM-specific file structure. Each SDF is located directly below the MF. Each SDF has a name attribute and a SID (eSIM ID), such as an Integrated Circuit Card Identifier (ICCID). As shown, each SDF also contains DFprofiles and DFcodes. Furthermore, in a variant, all EFs related to the profile PCF are stored under DFppcf, which is stored under DFprofile.

In an exemplary embodiment, the DFprofile information includes: (i) EFname, which is the description of the eSIM (such as the name and version of the eSIM); (ii) EFtype, which describes the type of the eSIM (such as normal, bootstrap and test). Software applications can use this information, such as displaying icons when using a bootstrapped eSIM; (iii) EFsys_ver, which is the minimum version number of eUICC software required to support eSIM; (iv) EFnv_min, which indicates the non-volatile The minimum amount of volatile memory; (v) EFram_min, which represents the minimum amount of volatile memory required; (vi) EFnv_rsvd, which represents the amount of non-volatile memory reserved for over-the-air transactions (OTA); and (vii ) EFram_rsvd, indicating the amount of volatile memory reserved for OTA.

In an exemplary embodiment, the DFcode information contains a set of keys for each eSIM. In most circumstances these values cannot be read from the eUICC. An exceptional use case is the export operation, which encrypts and exports the entire eSIM. Since the entire eSIM is encrypted, the key value remains secure. In an exemplary embodiment, the DFcode information includes: (i) ExEFgPinx/gPukx, which contains a global PIN (Personal Identification Number) and PUK (PIN Unlock Key); (ii) EFuPin/uPuk, which contains a universal PIN and PUK; ( iii) EFadminx, which contains the ADMIN code; and (iv) EFotax, which contains the OTA code. In some variants, there can also be ADFusim containing additional elements, such as: (i) EFk, which stores K, the 128-bit shared authentication key; (ii) EFopc, which stores OPc, which is derived from the user key and the operator variant algorithm configuration field OP (some variants may store OP instead of OPc); (iii) EFauthpar, which specifies the length of the RES; (iv) EFalgid, which specifies the network authentication algorithm (eg Milenage); ( v) EFsan, which stores the SQN; and (vi) EFlpinx/lpukx, which stores the PIN and PUK code for the local PIN.

Those of ordinary skill in the art who read this disclosure should understand that the above-mentioned documents, structures or elements are only exemplary, and can be replaced by other documents, structures or elements having desired functions or structures.

Referring now to FIG. 3, an exemplary state machine for SDF operation is shown. As shown in the figure, the SDF state machine includes the following states: CREATION (creation), INITIALISATION (initialization), OPERATIONAL (ACTIVATED) (operation (activation)), OPERATIONAL (DEACTIVATED) (operation (deactivation)) and TERMINATION (termination ).

When installing eSIM for the first time, create SDF (CREATION), and then use the file structure data included in eSIM to initialize (INITIALISATION). Once the eSIM is installed, the SDF transitions to the DEACTIVATED state. During the deactivated state, no files are available. Once the eSIM is selected, the SDF transitions from the DEACTIVATED state to the ACTIVATED state; the ACTIVATED state enables access to the SDF's files. Upon deselection of the eSIM (implicitly or explicitly), the SDF transitions from the ACTIVATED state back to the DEACTIVATED state.

Referring now to FIG. 4, an exemplary state machine for eSIM operation is shown. As shown in the figure, the eSIM state machine includes the following states: INSTALLED (installed), SELECTED (selected), LOCKED (locked), DEACTIVATED (deactivated), EXPORTED (exported) and DELETED (deleted).

During installation of an eSIM (INSTALLED), an entry is created for the eSIM in the eUICC registry; this entry represents one or more associated SDFs and applications. During the INSTALLED state, set the SDF to the DEACTIVATED state and the application to the INSTALLED state.

Once an eSIM is selected, the eSIM transitions to the SELECTED state. During the selected state, the SDF transitions to the ACTIVATED state and the application transitions to the SELECTABLE (selectable) state. If the eSIM is deselected, the eSIM transitions back to the INSTALLED state.

Under certain circumstances, eSIM can enter the LOCKED state. For example, if the eUICC PCF is changed such that the installed eSIM is no longer usable, the eSIM will transition to the LOCKED state. In the LOCKED state, set the SDF to the DEACTIVATED state, and set the application to the LOCKED state. Other miscellaneous states include the EXPORTED state (ie, the eSIM is exported and is no longer selected), and the DELETED state (ie, the eSIM is deleted).

Network Authentication Algorithm -

A Network Authentication Algorithm (NAA) is generally mandatory for the operation of a Mobile Network Operator (MNO). Although there are different NAA implementations, the functions are not significantly different. In some embodiments, the EUICC may include a general package for NAA. During eSIM installation, an instance of each NAA application can be created for each eSIM from a preloaded package to reduce the overall eSIM loading time as well as unnecessary memory consumption on the eUICC.

Common examples of NAA include, but are not limited to: Milenage, COMP128V1, COMP128V2, COMP128V3, and COMP128V4, as well as specific proprietary algorithms. There are a larger number of proprietary algorithms still in use (due to known attacks on COMP128VI). In one embodiment, network authentication is based on the well-known Authentication and Key Agreement (AKA) protocol.

In different events where NAA is affected, a software update may be required to replace the NAA scheme. During such an event, the eSIM may come with a replacement algorithm, such as via a secure software update. The MNO can then implement the replacement algorithm via existing OTA mechanisms.

Exemplary eSIM Proxy Network -

Figure 5 shows a schematic view of an exemplary eSIM proxy network that may be used in conjunction with various embodiments of the present disclosure. In one exemplary embodiment, the agent network includes a distributed network of agents and manufacturers such that a device can be serviced by multiple agents and an agent can order eSIMs from multiple eSIM manufacturers. In some embodiments, there may be an eUICC and/or eSIM profile policy that restricts the set of proxies that a device can communicate with for a particular eSIM operation. For example, the MNO may require that MNO-sponsored devices communicate only with MNO-owned proxies.

In one such variation, the primary agent provides a discovery service to the device, enabling the device to identify an appropriate agent. The device is then able to communicate directly with the identified agent for eSIM operations such as purchase, install, export and import.

Those of ordinary skill in the relevant networking arts will recognize that many practical problems arise during the operation of large-scale distribution networks, such as those illustrated in FIG. 5 . In particular, large-scale distribution networks must be scalable to handle large bursts of provisioning traffic (such as may occur on so-called "start-up days" for a given mobile user device). One approach suggested to reduce overall network traffic requires pre-personalization of the eSIM (where possible) prior to launch day. For example, a so-called "SIM-in" unit has already been assigned an eSIM at the time of shipment; this pre-assigned eSIM can be assigned to a unit, for example, by encrypting the corresponding eSIM profile with a key specific to the eUICC of the unit. Do pre-personalization.

Other considerations include system reliability, e.g. the agent network must be able to recover from various equipment failures. One solution is geographic redundancy, where multiple data centers across different locations have replicated content; however, the network of data centers can be actively synchronized with each other to avoid eSIM cloning. Such network synchronization can require a very large amount of network bandwidth. In an alternative solution, each data center could have an independent set of eSIMs; however, this requires significant eSIM overhead.

Ideally, a proxy network would be flexible enough to accommodate various business models. In particular, various components of the agent network described above may be handled by different parties for various legal and antitrust reasons. Therefore, the security aspects of eSIM traffic need to be carefully monitored and evaluated. Each eSIM contains valuable user and MNO information. For example, an eSIM can include a shared authentication key (K for USIM and Ki for SIM) that can be used for SIM cloning if compromised. Similarly, an eSIM can also contain apps that may have sensitive user data such as bank account information.

Furthermore, it should also be understood that eUICC software also requires other countermeasures for recovery of the device. Unlike a physical SIM, if the eUICC software goes into an unrecoverable state, the entire device will need to be swapped (which is much more costly than swapping a SIM card). Therefore, an exemplary solution should be able to handle device recovery in order to eliminate such drastic measures.

Finally, network operations should provide a "good" user experience. Excessive response times, unreliable operation, excessive software crashes, etc., can significantly degrade the overall user experience.

Exemplary Security Protocol -

Therefore, this paper discloses a layered security software protocol to solve the various problems mentioned above. In an exemplary embodiment, the server eUICC and client eUICC software comprise a so-called "stack" of software layers. Each software layer is responsible for a set of hierarchical functions that it negotiates with its corresponding peer software layer. In addition, each software layer also communicates with its own layer. It should also be understood that in some cases, the device Application Processor (AP) may be affected (eg "jailbroken", etc.); thus, it should be recognized that between the client eUICC and the corresponding server eUICC (or other security entity) A trust relationship exists; that is, the AP is not trusted.

In one exemplary embodiment, a three (3) layer system is disclosed. As shown in FIG. 6, the security software protocol includes Layer 1 (L1), Layer 2 (L2) and Layer 3 (L3). L1 security performs encryption and decryption of eSIM data. L1 operations are restricted to secure execution environments (such as eUICCs or hardware security modules (HSMs)). Within L1, eSIM data can be stored in clear text (ie, unencrypted) within the logical L1 boundary; outside the L1 boundary, eSIM data is always securely encrypted. L2 security ensures that the eSIM cannot be duplicated. The L2 boundary ensures that there is only one copy of the eSIM. Within an L2 boundary, multiple replicas can exist. In addition, L2 security can also embed a challenge into the encrypted eSIM payload; the recipient of the eSIM will compare the received challenge with an earlier stored challenge before installing the eSIM to ensure that their eSIM has not expired (i.e. is currently the only one) eSIM). L3 security is responsible for establishing trust, ownership and verification of users. For each eSIM, the eUICC may store information to represent the ownership associated with the eSIM.

In one exemplary implementation, a so-called "challenge" is a key resource for associating a particular eSIM instance with an eUICC. Specifically, each eUICC maintains a specific number of challenges for each profile agent, which is a logical entity to maintain L2 security. By verifying that the challenge is valid, the eUICC can ensure that the eSIM is not a stale eSIM (ie, an invalid replica). Create multiple challenges for each eSIM to be personalized. On receipt of a matching eSIM, the eUICC deletes the challenge.

Consider the following pre-personalization scenario, the eUICC creates (or is given) multiple challenges, the challenges are provided to the network; the challenges are also saved in the eUICC's non-volatile memory. Then next, the network can generate an eSIM for the eUICC bound to the pre-generated challenge. When the eUICC receives the eSIM later during device activation, the eUICC is able to verify that the received eSIM contains the appropriate challenge.

However, one disadvantage of the above scheme is that the fixed number of challenges may be vulnerable to denial of service (DOS) attacks. In a DOS attack, the eUICC is continuously triggered to generate challenges until all its challenge resources are exhausted. Therefore, in one such variant, the eUICC additionally performs a session handshake to authenticate the profile server/proxy before processing the request that would trigger the eUICC to create a challenge. Furthermore, in different situations where resources are exhausted and the eUICC is unable to create new challenges, the eUICC can store a separate set of reserved challenges, specifically designated to release another set of challenges. In some cases, the EUICC may additionally include original equipment manufacturer (OEM) credentials, which the OEM may use to further control challenge operations.

Referring now to FIG. 7, an exemplary data structure for an eSIM is shown. As shown, the exemplary data structure includes three (3) sections, one for each of L1, L2, and L3 security levels. By decoupling security components into different layers, overall network operations can be distributed over multiple entities according to a variety of options. For example, various network entities may implement only one or two of the security layers (e.g. eSIM providers may only handle L2, etc.); this flexibility easily and advantageously adapts to almost any business arrangement.

As shown in FIG. 7, each eSIM profile section 702 utilizes symmetric encryption because asymmetric encryption (i.e., each entity has a different and unique key) is much slower than a symmetric operation (where entities share a key). The key is encrypted and the symmetric key is encrypted with the intended eSIM receiver's L1 public key. The ESIM may also include a plaintext portion (such as a text string of the ICCID) for metadata. The encrypted symmetric key, metadata, and encrypted eSIM content are hashed and signed with the public key of the "donating" L1 entity. For example, append the associated L1 certificate at the end for verification.

Batch descriptor section 704 of FIG. 7 contains L2 information for eSIM. It has a plaintext portion that includes a Globally Unique Identifier (GUID), a challenge to the intended eSIM receiver, the unique ID of the eSIM receiver, a URL to retrieve the configuration file, and a URL to post the installation results. The batch descriptor also includes a plaintext part of a series of elements consisting of the ICCID for each profile and the hashed part of the profile (metadata part and encrypted eSIM content). In one embodiment, the hash does not include a symmetric key so that batch descriptors can be created without waiting for the actual configuration file to be generated. For device-side operations, the batch descriptor contains only an ICCID and profile hash. Larger arrays are desirable for server-to-server batch transfers. The data content of the batch descriptor is hashed and signed with the L2 public key, and the associated L2 certificate is appended at the end.

The L3 owner section 706 contains L3 information for the eSIM. The main field identifies the user account associated with the eSIM (such as abcme.com ), and the service name identifies the service provider that the user account is to authenticate. Include hashes of batch descriptors to associate L2 and L3 data structures. This data can be stored in clear text, hashed and signed with an L3 public key. Append the L3 certificate at the end.

As used herein, there are three (3) types of certificates: eUICC certificates, server device certificates, and OEM certificates. In one embodiment, a trusted third party issues a certificate for a verified eUICC. Each eUICC contains a private key and an associated certificate issued by this entity or its subordinate key management authority. In some embodiments, a trusted third party may issue certificates for certified L1, L2, and L3 devices; alternatively, an independent third party entity may issue certificates for L1, L2, or L3 devices. When multiple third parties are present, the eUICC has preloaded (or is provided OTA from a trusted entity) root certificate authority (CA) of the third party and can validate messages received from the server device based on the appropriate CA.

Referring now to FIG. 8, an exemplary OEM certificate hierarchy is shown. A Root Certificate Authority (CA) has a set of intermediate CAs that perform a subset of tasks (such as issuing e.g. iOS or equivalent device certificates). As shown in the figure, eUICC CA is responsible for the specific operation of eSIM. The EUICC CA can issue certificates for a group of servers; as shown in the figure, the certificates include, for example, factory refurbished servers for eUICC maintenance and activation servers for signing eUICC PCF. OEM-signed messages are verified by the client eUICC using the root CA together with the common name of the eUICC CA.

Based on the above, in an exemplary embodiment, each client eUICC stores the following security-related data: (i) eUICC certificates for eUICC L1, L2 and L3 operations (each eUICC stores for L1, L2 and certificate for L3 security-related operations); (ii) the eUICC private key associated with the eUICC certificate; (iii) the OEM certificate, including the OEM's root certificate and the common name of the OEMeUICC CA; (iv) the third party's certificate that can certify the server device root certificate. In some variants, if the signing CA is affected, for example, if the eUICC CA or the server CA is affected (e.g. private key is affected/lost), the certificate in the eUICC may need to be replaced, two (2) revocation procedures are described below.

According to a first exemplary revocation procedure, if the signing CA that issued the eUICC certificates is affected, the eUICC certificates stored in the affected eUICCs should be exchanged. Specifically, when creating the initial certificate request for the eUICC, save the Certificate Signing Request (CSR). If the signing CA is affected, a new certificate can be requested for the eUICC using the initial CSR. By keeping the same CSR, the eUICC is able to use the same private key and new certificates containing the same eUICC public key will be issued. OEMs are able to sign new certificates using the OEM's private key. When the eUICC sends a request to the server proxy, the proxy is able to check the revocation list of the bad eUICC CA and reject the request with a specific error indicating that the certificate needs to be exchanged. The AP can retrieve the new eUICC certificate through the existing OEM service and send the new certificate to the eUICC (in this case the AP does not need to be trusted).

The eUICC then verifies the OEM signature and ensures that the received public key matches a previously stored public key in the eUICC. In some variants, to prevent denial of service (DOS) attacks or replay attacks, the eUICC also includes an eUICC certificate. In a variant, this period is increased when a new certificate is issued. The EUICC is able to verify that the eUICC period in the received certificate is higher than that of the current certificate before storing the new certificate.

Unfortunately, revoking server certificates in the eUICC may be difficult due to various eUICC resource constraints; i.e., it may be untenable for the eUICC to handle large revocation lists. To avoid maintaining a revocation list, in a second revocation scheme, each server certificate is additionally associated with a period. If the CA is compromised, the root CA reissues certificates for all legitimate entities and increases the time period for each new certificate. Since the number of server certificates will not be large, certificate reissuance can be performed in the existing system. At the client eUICC, the eUICC saves the server L1, L2 and L3 certificates in non-volatile memory for the expected period. When a received certificate contains a higher period, the eUICC must update the corresponding NV period and reject any future certificates with a lower period; ie, the eUICC will reject rogue servers that have not been signed since the CA was affected. In some variants, the server may also maintain an eUICC blacklist for affected eUICCs. In one embodiment, requests from blacklisted eUICCs are rejected by the server.

Policy Control Functions -

Within the context of the above security solutions, there are two (2) levels of Policy Control Functions (PCFs): (i) eUICC platform level; and (ii) configuration file level. In an exemplary embodiment, the EUICC PCF may only be updated by the OEM, while the Profile PCF is controlled by the MNO and is part of the eSIM. In one such variant, when importing and/or exporting the eSIM, the configuration file PCF is included as part of the import/export package.

Referring now to the eUICC PCF, the eUICC PCF may include: (i) a SIM lock policy, which specifies the type of eSIM that the eUICC can activate; (ii) a security code that can be used to authorize the deletion of all eSIMs in the eUICC; (iii) a server (L1, L2 and L3) that specify clusters of server devices with which the eUICC can communicate (e.g., based on business considerations or methods) (i.e., an inclusive list); (iv) lists of common names for servers (L1, L2, and L3) that specify A cluster of server devices with which the eUICC may not communicate (ie, an exclusionary list).

Similarly, a configuration file PCF may include: (i) a list of common names of servers (L1, L2, and L3) specifying warehouse clusters (inclusive) from which eUICCs can export eSIMs; (ii) servers (L1, L2, and L3 ) which specifies the repository clusters from which the eUICC cannot export eSIMs (exclusive); (iii) notification URL and operation type, which specifies the URL to be notified upon completion of the specified eSIM operation; (iv) automatic expiration parameters, where the AP can delete the eSIM once the profile expires; (v) server device (L1, L2, and L3) classes, which can be assigned different classes, denoting the security level implemented (profiles can be selected to be associated only with specific levels server part communication above); (vi) period of server certificate (L1, L2 and L3), which is checked during installation (e.g. eUICC only installs configuration file if period of eUICC server certificate is equal to or higher than specified period); (vii) L3 service names that can be used for L3 authentication, and/or a list of service names that cannot be used for L3 authentication; (viii) the minimum version of the eUICC system (where eSIM can only be installed on eUICC systems higher than the specified minimum version); (ix) Minimum RAM size required by eSIM (excluding OTA operations); (x) Minimum RAM size reserved for OTA; (xi) Minimum non-volatile (NV) memory size required by eSIM (excluding space reserved for OTA ); (xii) Minimum NV size reserved for OTA.

Exemplary operation -

Within the context of the above-mentioned parts (eg, eUICC, eSIM, proxy network, security protocols, etc.), the following exemplary message sequence is disclosed. In the following sequence diagram, three entities are given: agent, configuration file proxy and configuration file lock, representing entities responsible for L3, L2 and L1 security respectively. However, it should be understood that these are logical entities and that different network topologies may include or further differentiate the above functions.

In the illustrated embodiment, the client eUICC is responsible for all three levels of security; however, for clarity, the client eUICC is divided into three logical entities to gather functional requirements within the eUICC. Furthermore, although there may be separate sets of credentials for L1, L2 and L3 within the client eUICC, it should be understood that the same (ie one credential) credential may be used since the client device is a single device.

eSIM delivered, not personalized -

Figure 9 illustrates an example logical sequence for delivering an unpersonalized eSIM to a device. First, the device identifies a server proxy via a discovery process (not shown). Once the device attempts to communicate with the server agent, there are three main actions: (i) the device queries the server backend for available eSIM options; (ii) if the requested eSIM has not been pre-personalized, the device requests the server to personalize the eSIM personalization; and (iii) the device downloads the actual eSIM and installs it.

In the first phase, the device queries the server backend for available eSIM options using getProfileOptions. The eUICC associated with the device is identified by its UniqueId, which may for example be a card serial number. The sales information is used by the agent to determine one or more eSIM options available for the device. For unlocked devices, there may be a very large set of available eSIMs; thus, in some embodiments, generic options (eg, based on location, cost, etc.) that may be selected by the user are displayed. The server returns an array of profile providers (MNOs) and profile types (eg prepaid/postpaid) valid for the device.

In some cases, the eSIM type available to the user may be considered confidential information, so in some variants, the getProfileOptions API also requires the device eUICC L3 to sign the unique identifier of the eUICC and include the signing identifier in the API. The server proxy (or proxy server) is able to verify the signature before processing the request. This prevents malicious parties from retrieving a user's profile options by sending a spoofed request. In some variants, the communication between the device proxy and the server proxy uses a secure protocol such as Transport Security (TLS) to prevent capture and replay attacks.

In one embodiment, getProfileOptions contains two L3 tokens to verify current and new ownership of the eSIM. Current L3 tokens can be unique identifiers or so-called "fake card" scratch codes. A new L3 token could be information used to associate a user account with an eSIM, for example, a signing token for an iCloud account (as the device has logged into the user account to retrieve the token). Both L3 tokens are signed by eUICC L3. The server proxy validates the L3 token with the associated authentication service. For example, it may communicate with a web server (such as the assignee's iCloud server) or a third-party service to verify signed tokens.

To optimize performance and avoid repeated authentications, after authenticating the token passed by the device, the server agent generates a one-time code (OTC) and passes the OTC back to the device. The device can use the OTC as evidence that the server has performed L3 authentication. A complete data binary large object (BLOB) may include the generated OTC, a unique device identifier such as a card serial number (CSN), principal, service provider, and a timestamp indicating the validity of the OTC. The BLOB is hashed and signed by a proxy. In a variant, the hashing is performed with a symmetric key to improve overall performance. If getProfileOptions returns an array of eSIMs, the user is prompted to make a selection.

In the second stage, the device calls personalizeProfile to request the server backend to personalize the eSIM. There is a session handshake for authentication between the eUICC Profile Proxy and the Server Profile Proxy before the device sends a personalization request to the server. The device agent and eUICC create a session based on the profile options selected by the user and the current L3 code and the new L3 code sent by the server agent. The EUICC is able to save this information to populate subsequent subsequent profile requests. The EUICC profile proxy generates a session id which will be returned by the server proxy for subsequent authentication.

The device agent can now pass eUICC generated session requests to the server agent. The server proxy can inspect the request. For example, the server agent determines whether the requested eUICC represented by the unique ID is useful. Because the unique identifier is included in clear text, server proxies are able to retrieve this information even if more thorough request validation is performed by the server profile proxy.

If the request is appropriate, the server agent passes the request to the profile agent. The profile agent cryptographically validates the request by validating the eUICC L2 certificate and validating the L2 signature with the eUICC L2 public key. Once authenticated, the Server Profile Agent creates a SessionResponse that includes a plaintext portion including: the received session identifier and unique identifier, an L2 signature (by hashing the plaintext portion and using the Server Profile Agent's generated by private key signature).

Sends a session response from the server profile proxy to the server proxy, which then forwards the session response to the device proxy. The device agent delivers the response to the eUICC in the prepareProfileRequest message. EUICC L2 verifies the sessionReponse by verifying the server profile proxy's certificate and L2 signature. EUICC L2 also verifies that the session identifier and unique identifier match the information in the eUICC. Once authenticated, the eUICC creates a challenge for the personalized profile request. The challenge is submitted to non-volatile memory. The EUICC then creates a configuration file request BLOB, including L1, L2 and L3 related information. The detailed structure is listed in Appendix A, which is incorporated herein by reference.

Then, send the profile request BLOB to the server backend. The server agent performs L3 verification and includes the L3 owner information (such as principal and service provider) to be associated with the eSIM; the server profile agent creates a batch descriptor, and the server profile lock personalizes the eSIM for the eUICC. Personalized eSIMs can be distributed to content delivery networks (CDNs) for performance optimization.

After the device agent receives the profile descriptor and associated L3 owner information, it retrieves the associated profile via getProfile by providing the received GUID (Globally Unique Identifier).

Once the device agent has retrieved the profile descriptor and profile, it instructs the client eUICC to install the eSIM. The call flow shows three separate calls, processL3Owner, processProfileDescriptor, and installProfile, however it should be understood that in actual implementations these three logical calls could be combined within a single transaction. The EUICC performs L3, L2 and L1 verification; once verified, the eSIM is installed. The associated challenge is deleted. Save L3 owner information with eSIM to indicate proper ownership. L3 owner information can be provided at a later point if the user exports the eSIM.

Once the configuration file is installed, the eUICC returns the installation result to the server. Server infrastructure can use notifications to trigger purge of cached content in a content delivery network (CDN). In some cases, this information can also be used for notification services, for example, to indicate successful installation, partial installation, unsuccessful installation, etc.

ESIM delivery, pre-personalized -

Figure 10 illustrates an exemplary logical sequence for delivering an eSIM to a pre-personalized device. Similar to the scheme of Figure 9, three (3) phases are required to deliver a pre-personalized eSIM.

Initially, during the manufacture of the client device, the factory agent instructs the eUICC to create a challenge for later eSIM pre-personalization. However, unlike the scheme of Figure 9, the device is not yet associated with an MNO or eSIM type; instead, these fields are filled with special values to indicate that a selection will be made later. Save the full contents of the Profile Request BLOB for later personalization use.

For example, the second phase is automatically triggered by shipping notifications, equipment sales, etc. The L2 (client profile proxy) in the distribution center acts as a proxy for the client eUICC L2. Although the eUICC profile request BLOB does not contain the MNO and eSIM type, the client profile agent is able to regenerate the BLOB by replacing these fields with updated information. The Client Profile Proxy can create its own challenges and replace the eUICC challenges. The Client Profile Proxy will sign the content with its own private key (otherwise, all L2s will require a unique challenge). The BLOB will contain the L1 signature of the eUICC, which still needs to decrypt the personalized eSIM. Send a new profile request BLOB to the server agent using an existing personalizeProfile request. Hereinafter, the process is not different from that of FIG. 9 .

Furthermore, it should also be understood that the published pre-personalization process can use the same interface even if the MNO wants to support its own proxy system. The server agent will return the batch descriptor to the client and personalize the eSIM. The Client Profile Agent will create a new batch descriptor with the challenge of the eUICC to be used when the eUICC requests the profile later.

Finally, in the final phase, when the user powers up the device, the device executes getProfileOptions to check for available eSIM options. Since the eSIM is already pre-personalized, the response will include a valid batch descriptor and the device no longer needs to call personalizeProfile. It will use the information in the descriptor to retrieve the eSIM directly via the getProfile request.

eSIM delivery, batch delivery -

Figure 11 shows an exemplary logical sequence for delivering a large number (batch) of eSIMs, eg, between two entities. In one embodiment, the client proxy and server proxy are secure entities with secure communication via, for example, a virtual private network (VPN). Support for "batching" allows clients to order large numbers of eSIMs.

In this case, when a request to personalize a profile is received by the profile proxy, if a batch descriptor is returned, the profile does not need to be personalized; instead, the client can Request the actual configuration file. In a batch descriptor operation, a hash of the profile content is computed over the encrypted profile (wrapped with a symmetric key) and the profile metadata, neither of which require personalization of the profile. This also does not require the L1 to store the symmetric key for each eUICC, which would otherwise burden the L1 with difficult to meet additional storage requirements. In one embodiment, an encrypted eSIM (wrapped with a symmetric key) may be stored off-storage. The symmetric key is wrapped with an L1RFS (Remote File System) key, and the wrapped key can be kept outside the storage device with the encrypted eSIM.

eSIM export -

Finally, once the eSIM is stored on the client device, the user can choose to export the eSIM from the device and later import the eSIM to the same or a different device. One purpose is to support eSIM swapping. Another purpose is to free up eUICC memory to store additional eSIMs. On export, there are three possible scenarios: (i) export to cloud; (ii) export to AP (for off-board storage); and (iii) device-to-device eSIM transfer. Similarly, users can be imported from the cloud, AP, or another device.

During eSIM installation, associate user account information to the eSIM (unless the user opts out). Account information includes sufficient information for L3 authentication. For example, it can include principals (such as x2zyahoo.com) and associated service providers for authentication. If no account information is associated with the eSIM, the user can utilize other authentication methods to export the eSIM. One such embodiment includes a physical button that is securely connected to the eUICC to prove physical possession of the device. In another embodiment, each eSIM includes a unique passcode that users must have to prove their ownership. Utilizing OEM credentials is another option.

When a user exports an eSIM, the AP retrieves a list of installed profiles from the eUICC; for each profile, the eUICC also returns the associated principal and non-heavyness to combat replay. When the user chooses to export the configuration file, the AP uses the information contained in the principal to obtain a Single Signature (SSO) token from the service provider, where the user is prompted for a username and password for this purpose. Pass the SSO token to the server's proxy in the export request, along with the principal and non-heavyness. The server proxy can handle authentication to the service provider using the SSO token provided by the device. Once authenticated, the process mirrors the delivery of the eSIM to the device, except that the roles of client and server are reversed. At a high level, the server agent initiates a session with the eUICC, creating a request BLOB for export. In this request, it includes the non-heavyness generated by the eUICC, indicating that the operation has passed L3 authentication. The EUICC validates the request BLOB. Encrypt eSIM with server agent's public key, create batch descriptor and L3 owner information for eSIM. The eSIM can be sent to the server along with the L3 and L2 information.

Once the eUICC encrypts the eSIM for export, the eUICC relinquishes ownership of the eSIM and no longer uses the eSIM or exports the eSIM to any other entity. In some cases, the EUICC may keep an encrypted copy to help recover from connection loss (i.e. if the encrypted eSIM never reaches the server). Alternatively, the AP could save a copy of the encrypted eSIM for retransmission if the connection fails. The server can return an acknowledgment, triggering the AP to clean up the stored copy.

In some embodiments, the export can also be initiated from the portal. If a user loses his device, he can export eSIM from his device using the web portal. In this case, the portal communicates with the device to initiate the export. The process is similar except that the user will use the portal instead of the AP to obtain an SSO token for ownership verification.

device-

Various devices that may be used in conjunction with the methods described above are now described in more detail.

eUICC device-

FIG. 12 shows an exemplary embodiment of an eUICC device 1200 according to the present disclosure. EUICC devices may comprise stand-alone entities, or incorporate other network entities, such as servers. As shown, the eUICC device 1200 generally includes a network interface 1202 for interfacing with a communication network, a processor 1204 and one or more storage devices 1206 . The network interface is shown connected to the MNO infrastructure in order to provide access to other eUICC devices, as well as direct or indirect access to one or more mobile devices, but may be substituted with other configurations and functions.

In one configuration, an eUICC device is capable of: (i) establishing communication with another eUICC (eUICC device or client device); (ii) securely storing an eSIM; (iii) retrieving a securely stored eSIM; Delivering an eSIM to another specific eUICC; and (v) sending multiple eSIMs to/from the eSIM depot.

eSIM Warehouse -

FIG. 13 illustrates an exemplary embodiment of an eSIM repository 1300 according to the present disclosure. The eSIM repository 1300 may be implemented as an independent entity, or merged with other network entities (such as the eUICC device 1200, etc.). As shown, the eSIM repository 1300 generally includes a network interface 1302, a processor 1304, and a storage device 1306 for interfacing with a communication network.

In the embodiment illustrated by diagram 1300, eSIM repository 304 is capable of: (i) inventorying eSIMs (eg, through associated metadata); (ii) encrypting eSIMs (eg, from other eSIM repositories and/or eUICC devices 1200) (iii) manage user requests for eSIM.

For example, when a user stores an eSIM at the eSIM vault 1300, the eSIM may be stored with a desired destination (eg, to facilitate transfer to another device) or may be parked indefinitely. In either case, the eSIM repository can provide the eSIM to the eUICC device for secure storage and for subsequent encryption to the destination device.

user device-

Referring now to FIG. 14 , an example user device 1400 is shown in accordance with aspects of the present disclosure.

The exemplary UE device of FIG. 14 is a wireless device having a processor subsystem 1402, such as a digital signal processor, microprocessor, field programmable gate array, or multiple Handling parts. The processing subsystem may also include internal cache memory. The processing subsystem is in communication with the memory subsystem 1404, which includes memory, which may include, for example, SRAM, flash memory, and/or SDRAM components. The memory subsystem may implement one or more DMA-type hardware to facilitate data access as is well known in the art. The memory subsystem contains computer-executable instructions that can be executed by the processor subsystem.

In an exemplary embodiment, the device includes one or more wireless interfaces 1406 adapted to connect to one or more wireless networks. The multiple radio interfaces can support different radio technologies such as GSM, CDMA, UMTS, LTE/LTE-A, WiMAX, WLAN, Bluetooth, etc. by implementing appropriate antenna and modem subsystems of the type known in the wireless arts.

User interface subsystem 1408 includes any number of well-known I/Os, including but not limited to: keypad, touch screen (eg, multi-touch interface), LCD display, backlight, speaker, and/or microphone. However, it should be appreciated that in some applications one or more of these components may be excluded. For example, PCMCIA card-type client embodiments may lack a user interface (as they may piggyback on the user interface of the host device to which they are physically and/or electrically coupled).

In the illustrated embodiment, the device includes a secure element 1410 that contains and operates an eUICC application. The EUICC is capable of storing and accessing multiple access control clients to be used to authenticate network operator authentication. The secure element includes a secure processor that executes software stored in the secure medium. The secure medium is inaccessible to all other components (except the secure processor). In addition, exemplary security elements may be further reinforced to prevent damage as previously described (eg, encased in resin). The example secure element 1410 is capable of receiving and storing one or more access control clients. In one embodiment, the secure element stores an array or multiple eSIMs (e.g., one for work, one for personal, several for roaming access, etc.) Scheme or relationship (such as one for each of multiple members of a household or business entity, one for each of household members' personal and work use, etc.). Each eSIM includes a small file system, including computer-readable instructions (eSIM program) and associated data (such as encryption keys, integrity keys, etc.).

The secure element is also adapted to enable eSIM transfer to and/or from the mobile device. In one implementation, the mobile device provides a GUI-based confirmation to initiate the transfer of the eSIM.

Once the user of the mobile device chooses to activate the eSIM, the mobile device sends an activation request to the activation service. Mobile devices are able to use eSIM for standard authentication and key agreement (AKA) exchanges.

method-

Various methods that can be used in conjunction with the methods described above are now described in more detail.

Figure 15 illustrates one embodiment of a method for mass distribution of electronic access control clients.

At step 1502, the first device establishes ownership of one or more electronic access control clients.

At step 1504, the first device determines whether the one or more electronic access control clients have not been previously copied.

At step 1506, the first device encrypts the one or more electronic access control clients for transmission to the second device.

At step 1508, the first device and the second device exchange or transmit encrypted one or more electronic access control clients.

Those of ordinary skill in the art, given the present disclosure, will recognize many other schemes for mass distribution of electronic access control clients.

It should be appreciated that when certain aspects of the disclosure are described in terms of a particular sequence of steps of a method, these descriptions are merely illustrative of the broader method of the disclosure and may be modified as desired for a particular application. In some cases, certain steps may become unnecessary or optional. In addition, certain steps or functionality may be added to the disclosed embodiments, or the order of performance of two or more steps may be permuted. All such variations are deemed to be encompassed within the disclosure disclosed and claimed herein.

While the foregoing detailed description has shown, described, and pointed out the novel features of the disclosure applied to various embodiments, it should be understood that one skilled in the art can vary in the form and detail of devices or processes without departing from the disclosure. Various omissions, substitutions and changes may be made from the foregoing description to be of the best mode presently contemplated for carrying out the present disclosure. This description is in no way intended to be limiting, but rather should be considered as an illustration of the general principles of the disclosure. The scope of the present disclosure should be determined in conjunction with the claims.

Claims (24)

1. User mobile devices, including: a wireless interface configured to communicate with a wireless network; a processor in data communication with the wireless interface; a secure element in data communication with the wireless interface, the secure element comprising: security processor; a secure storage device in data communication with the secure processor and storing a plurality of access control clients operable to authenticate at least to the wireless network; and computerized logic in data communication with the security processor, the logic configured to store, access, and transmit the plurality of access control clients to or from the user mobile device; and user interface logic in communication with at least the secure element and configured to enable a user of the user mobile device to select one of the stored plurality of access control clients and to authenticate the user mobile device to the network for able to communicate with the network. 2. The user mobile device of claim 1, wherein the secure storage is inaccessible to all components in the user mobile device except the secure processor. 3. The user mobile device of claim 2, wherein the secure element is configured to receive and store the one or more access control clients as distinct electronic subscriber identity modules (eSIMs) associated with public users, Each of the different eSIMs includes a different user context. 4. The user mobile device of claim 1, wherein each access control client includes a limited capability file system including computer readable instructions and associated cryptographic data. 5. The user mobile device of claim 1 , wherein the secure element includes a limited capability file system including computer readable instructions, and each access control client includes a Unique password data. 6. The user mobile device of claim 1, wherein the secure element further comprises logic configured to cause the user mobile device to send an activation request to an activation service of the network. 7. The user mobile device of claim 1 , wherein the secure element further comprises logic configured to enable the user mobile device to communicate with a plurality of electronic access control client proxy entities, the proxy entities is each part of the agent and manufacturer network, the communication is configured to enable the user mobile device to obtain one or more encrypted access control clients. 8. A method for distributing a plurality of electronic access control clients for use on a mobile wireless device, the method comprising: Establish ownership of one or more electronic access control clients; determining whether the one or more electronic access control clients have not been previously copied; encrypting the one or more electronic access control clients for transmission to one of the mobile wireless devices when not previously copied; and Exchange encrypted one or more electronic access control clients. 9. The method of claim 8, wherein said establishing ownership includes evaluating level 3 (L3) security credentials. 10. The method of claim 8, wherein said determining previous replication includes at least one of: (i) evaluating; (ii) responding to challenge questions; and/or (iii) Prompt from circuit card (eUICC). 11. The method of claim 10, wherein the encrypting comprises encrypting with a key specific to the eUICC. 12. The method of claim 10, wherein said exchanging encrypted one or more electronic access control clients comprises exchanging an encrypted one or more clients disposed on said one mobile wireless device. or multiple clients. 13. An apparatus for mass distribution of electronic access control clients comprising: processor; and A non-transitory computer readable medium in data communication with the processor and including instructions configured to, when executed by the processor, cause the apparatus to: Establish ownership of one or more electronic access control clients; determining whether the one or more electronic access control clients have been previously copied; encrypting the one or more electronic access control clients for transmission to the second device when it is determined that they have not been previously copied; and The encrypted one or more electronic access control clients are transmitted to the second device. 14. The apparatus of claim 13, wherein the apparatus comprises a networked server accessible by a plurality of similar apparatuses, the apparatus communicating with a plurality of user mobile devices via a wireless network. 15. A network architecture for providing wireless mobile devices with electronic access clients, the network architecture comprising: multiple agents; and a plurality of manufacturers in data communication with the plurality of agents; wherein a given user mobile device can be serviced by a plurality of the agents; and Wherein any of said agents can order electronic access clients from one or more of said manufacturers. 16. The network architecture of claim 15, wherein the plurality of agents includes a primary agent that provides at least a discovery service to the mobile device, enabling the mobile device to identify an appropriate agent prior to communicating therewith. 17. Means for providing an electronic access client to one or more mobile devices, the means comprising: at least one processor; and first logic in data communication with the at least one processor, the first logic configured to cause the apparatus to perform encryption and decryption of access clients; second logic in data communication with the at least one processor, the second logic configured to cause the apparatus to ensure that the accessing client is not duplicated; and Third logic in data communication with the at least one processor, the third logic configured to cause the apparatus to establish at least one of trust, ownership, and/or authentication of a user of the access client. 18. The apparatus of claim 17, wherein the first logic comprises logic within an electronic universal integrated circuit card (eUICC) or hardware security module (HSM) in L1. 19. The apparatus of claim 18, wherein the second logic is configured to embed a challenge into an encrypted payload encrypted by the first logic. 20. An electronic access control client revocation process comprising: determining whether a signing certificate authority issuing a certificate associated with one or more devices storing the certificate is affected; determining, at the one or more devices, a created credential service request when creating the initial request for the credential; request a new certificate using the identified certificate service request; and issuing a new certificate based on said request; Wherein said one or more devices are able to use a previously used private key as part of said request, and issue said new certificate containing a previous public key corresponding to said previous private key. 21. An apparatus for distributing a plurality of electronic access control clients for use on a mobile wireless device, the apparatus comprising: means for establishing ownership of one or more electronic access control clients; means for determining whether the one or more electronic access control clients have not been previously copied; means for encrypting the one or more electronic access control clients for transmission to one of the mobile wireless devices when it is determined that the one or more electronic access control clients have not been previously copied; as well as Means for exchanging one or more clients disposed on said one mobile wireless device with encrypted one or more clients. 22. The apparatus of claim 21, wherein the establishing ownership comprises evaluating a level 3 (L3) security credential. 23. The apparatus of claim 21 , wherein said determining whether said one or more electronic access control clients have not been previously copied comprises at least one of: (i) evaluating; (ii) responding to a challenge responses to questions; and/or (iii) prompts issued by the eUICC. 24. The apparatus of claim 23, wherein the encryption uses at least one key specific to the eUICC.