BRPI1106663B1 - METHODS AND APPARATUS FOR THE STORAGE AND EXECUTION OF ACCESS CONTROL CLIENTS - Google Patents

Abstract

methods and apparatus for storing and executing access control clients. The present invention relates to methods and apparatus for the secure provision of access control entities (such as electronic or virtual subscriber identity module (ESIM) components) post-launch of the main device on which the access control entity is located. access will be used. In one embodiment, a wireless user equipment (e.g., cell phone) is given a unique device key and endorsement certificate, which can be used for provisioning updates or new esims to the user equipment in the ' 'field''. user equipment may trust esim material delivered by an unknown independent esim vendor based on a secure certificate transmission with the device key. In another aspect, an operating system(s) is partitioned into several portions or ''sandboxes''. During an operation, the user device can wake up and run the operating system in the sandbox corresponding to the current wireless network. customization packs while connected to the network only apply to that sandbox. Similarly, when loading an esim, the os only needs to load the list of software required for the current round-time environment. unused software can be subsequently activated.

Description

Priority and Related Orders

This application claims priority to US Patent Application Serial No. 13/080,521 filed April 5, 2011 entitled "METHODS AND APPARATUS FOR STORAGE AND EXECUTION OF ACCESS CONTROL CLIENTS", which claims priority to US Provisional Patent Applications Serial No. 61/407,866 filed October 28, 2010 and entitled "METHODS AND APPARATUS FOR STORAGE AND EXECUTION OF ACCESS CONTROL CLIENTS", each of the foregoing being incorporated herein by reference in its entirety.

This application is also related to co-owned Applications, co-pending US Patent Serial No. 13/080,558 filed on April 5, 2011, and entitled "APPARATUS AND METHODS FOR CONTROLLING DISTRIBUTION OF ELECTRONIC ACCESS CLIENTS", 12/952,082 filed on 22nd November 2010 and entitled "WIRELESS NETWORK AUTHENTICATION APPARATUS AND METHODS", 12/952,089 filed on November 22, 2010 and entitled "APPARATUS AND METHODS FOR PROVISIONING SUBSCRIBER IDENTITY DATA IN A WIRELESS NETWORK", 12/980,232 filed on December 28, 2010 and entitled "VIRTUAL SUBSCRIBER IDENTITY MODULE DISTRIBUTION SYSTEM", and 12/353,227 filed January 13, 2009, and entitled "POSTPONED CARRIER CONFIGURATION", and US Provisional Patent Applications Serial No. 61/472.109 filed April 5 of 2011, and entitled "APPARATUS AND METHODS FOR STORING ELECTRONIC ACCESS CLIENTS", 61/472.115 filed on April 5, 2011, and entitled "APPARATUS AND METHODS FOR DISTRIBUTING AND S TORING E-LECTRONIC ACCESS CLIENTS", 61/407,858 filed October 28, 2010 and entitled "METHODS AND APPARATUS FOR ACCESS CONTROL CLIENT ASSISTED ROAMING", 61/407,861 filed October 28, 2010 and entitled "MANAGEMENT SYSTEMS FOR MULTIPLE

ACCESS CONTROL ENTITIES" (now US Patent Application Serial No. 13/079,614 filed April 4, 2011, same title), 61/407,862 filed October 28, 2010 and entitled "METHODS AND APPARATUS FOR DELIVERING ELECTRONIC IDENTIFICATION COMPONENTS OVER A WIRELESS NETWORK", 61/408,504 filed October 29, 2010 and entitled "ACCESS DATA PROVISIONING SERVICE" (now US Patent Application Serial No. 13/078,811 filed April 1, 2011, and entitled "ACCESS DATA PROVISIONING APPARATUS AND METHODS"), 61/409,891 filed on November 3, 2010 and entitled "METHODS AND APPARATUS FOR ACCESS DATA RECOVERY FROM A MALFUNCTIONING DEVICE", 61/410.298 filed on November 4, 2010 and entitled "SIMULACRUM OF PHYSICAL SECURITY DEVICE AND METHODS" (now US Patent Application No. 13/080,533 filed on April 5, 2011, of the same title), and 61/413,317 filed on November 12, 2010 and entitled "APPARATUS AND METHODS FOR RECORDATION OF DEVICE HIS TORY ACROSS MULTIPLE SOFTWARE EMULATION", each of the foregoing being incorporated herein by reference in its entirety.

Background of the Invention Field of Invention

The present invention generally relates to the field of wireless communication and data networks. More particularly, in an exemplary aspect, the present invention is directed to methods and apparatus for securely modifying, storing and executing access control entities or clients.

Description of Related Technology

Access control is required for secure communication in most prior art wireless radio communication systems. As an example, a simple access control scheme could comprise: (i) verifying the identity of a communicating party, and (ii) granting a level of access commensurate with the verified identity. In the context of an example cellular system (eg, the Universal Mobile Telecommunications System (UMTS)), access control is governed by an access control client, referred to as a Universal Subscriber Identity Module (USIM) running on a physical universal integrated circuit card (UICC). The USIM access control client authenticates the subscriber to the UMTS cellular network. After successful authentication, the subscriber is allowed to access the cellular network. As used from this point forward, the term "access control client" generally refers to a logical entity, embodied in hardware or software, suitable for controlling the access of a first device to a network. Common examples of access control clients include the aforementioned USIM, CDMA Subscriber Identity Modules (CSIM), IP Multimedia Services Identity Module (ISIM), Subscriber Identity Modules (SIM), Removable User IDs (RUIM), etc.

Traditionally, USIM (or, more generally, "SIM") performs the well-known authentication and key agreement (AKA) procedure, which checks and decrypts applicable data and programs to ensure a secure boot. Specifically, the USIM must (i) successfully respond to a remote challenge to prove its identity to the network operator, and (ii) issue a challenge to verify the identity of the network.

However, existing solutions have multiple weaknesses or disadvantages. First, the SIM software is hard coded for physical UICC card media; subscriber needs a new UICC to change SIM operation. This can be harmful to MNOs and subscribers; for example, if authentication procedures are "broken" (eg through malicious activities of "hackers"), the subscriber must be issued a new UICC, and this process is time consuming and costly. Furthermore, for reasons described in greater detail subsequently here, the physical SIM only recognizes a single trusted entity; specifically, the Mobile Network Operator (MNO) it is configured to communicate with. Thus, there is no current method for incorporating a post-launch schedule, except through the trust relationship that exists between the device and the MNO. For example, independent SIM developers who want to provide new or updated SIM software are frustrated by the inflexibility of physical SIM card media, as well as their inability to establish a trusting relationship between themselves and the subscriber's SIM. This control "bottleneck" greatly limits the number and capabilities assured to SIM vendors.

Therefore, new solutions are needed to allow for post-release SIM distribution and modification. Ideally, these solutions should allow the mobile device to receive and implement changes to SIM operation while the device is in "the field" (post-launch). Furthermore, the improved methods and handsets must support other desirable features such as, among other things, support for multiple SIM profiles, flexible operation, updates, etc.

More generally, however, improved methods and appliances are needed for secure modification, storage and execution of access control clients. Techniques for modifying the access control client operation are necessary to support features such as multiple subscriber access profiles, secure device update, alternative methods for provisioning subscriber service, etc. Furthermore, due to the sensitive nature of access control and the possibility of surreptitious use and theft of service, secure methods for making these modifications are a major concern.

Invention Summary

The present invention satisfies the aforementioned needs by providing improved apparatus and methods for securely modifying, storing and executing access control clients.

In a first aspect of the invention, a wireless apparatus is described. In one embodiment, the apparatus includes: one or more wireless links adapted to communicate with at least one network via an access control client; a secure element configured for access control client storage; an interface to the secure element, the interface having a cryptographic key and an endorsement certificate associated with it; a processor; and a storage device in data communication with the processor, the storage device comprising computer-executable instructions. At least a subset of the computer-executable instructions is further divided into one or more segments.

In a variant, computer-executable instructions, when executed by the processor: transmit a request by one or more components to a specific access control client for at least one network through the interface, the request including the endorsement certificate and the cryptographic key; receive one or more required components, one or more components associated with a second certificate of endorsement; verify the second endorsement certificate; and, in response to a successful verification of the second endorsement certificate, load the access control client.

In a second aspect of the invention, a method for mutual authentication is described. In one embodiment, the method includes: requesting one or more components, the request being associated with a first endorsement certificate; the receipt of one or more components and a second certificate of endorsement; and loading one or more components, if the second endorsement certificate is valid, where the first and second endorsement certificates are issued by a trustee.

In a third aspect of the invention, a method of executing an access control client is described. In one embodiment, the method includes: executing a first autoloader operating system, the autoloader operating system selecting a secure partition, the secure partition being associated with only one access control client; secure partition verification, the secure partition including a common operating system and an access control client; and running the common operating system, the common operating system carrying an access control client. The access control client is configured to authenticate with a network, such as an external cellular network.

In a fourth aspect of the invention, a mobile device is described. In one embodiment, the mobile device is configured to request, receive, and use a virtual or electronic SIM data structure using an autoloader OS architecture.

In a fifth aspect of the invention, a computer readable apparatus is described. In one embodiment, the apparatus includes network access equipment with at least one computer program running on it, at least one program being configured to receive, process and provision requests for virtual or electronic SIMs using an autoloader OS.

In a sixth aspect of the invention, a system for distributing virtual or electronic SIMs to users is described. In one embodiment, the system includes an apparatus for delivering operating system components supporting an eSIM delivery over a network, such as the Internet, or a MAN or a WLAN.

Other features and advantages of the present invention will be readily recognized by persons skilled in the art with reference to the accompanying drawings and a detailed description of example embodiments, as given below.

Brief Description of the Drawings Figure 1 graphically illustrates an example authentication and key agreement (AKA) procedure using a prior art USIM. Figure 2 is a logical flowchart illustrating an embodiment of a method for assigning a device key pair to a software entity (e.g., a user equipment (UE), an independent software vendor, a software vendor. YES, etc.) according to the invention. Figure 3 graphically illustrates an example transaction for secure delivery of runtime components between a UE and a software vendor in accordance with an embodiment of the invention. Figure 4 graphically illustrates an embodiment of a method for safely executing an eSIM, according to the invention. Figure 4A graphically illustrates an embodiment of an autoloader OS, eUICC, and eSIM architecture according to the invention. Figure 5 is a logical flowchart illustrating one embodiment of a generalized method for secure modification and storage of components for use with access control clients. Figure 6 is a logical flowchart illustrating an embodiment of a generalized method for securely executing components for use with access control clients in accordance with the invention. Figure 7 is a block diagram of an example apparatus useful for implementing the methods of the present invention.

All figures © Copyright 2010 Apple Inc. All rights reserved.

Detailed Description of the Invention

Reference is now made to the drawings, in which like numbers refer to like parts throughout. Overview

The present invention provides, among other things, secure methods and apparatus by which a user equipment and any trusted independent entity can mutually verify each other. It also shows a method and apparatus that allow any independent entity to become trusted, even after user equipment has been released. For example, a mobile device (eg a UMTS UE) can identify an independent eSIM vendor (eg a virtual or electronic SIM - from this point on "eSIM"), and initiate a trusting dialog for the purchase , purchase or upgrade your eSIM. Similarly, the independent eSIM vendor can verify that the UE is a trusted device, and securely encrypt their eSIM for delivery. The trust dialog is based on a unique device key and an endorsement certificate; as described hereinafter, in an example embodiment, the device key is based on a public/private key cryptography.

Various aspects of the present invention are directed towards secure reception of an access control client (in whole or in part). Due to the sensitive nature of an access control material for network operators, existing solutions favored the use of physical card form factors. However, the present invention advantageously provides for secure delivery of virtualized or electronic access control clients (eg, eSIMs), thereby eliminating the need for physical card requirements and their associated limitations.

Furthermore, unlike existing solutions, the present invention allows for the delivery of an access control client material without a pre-existing access control client, thereby greatly improving user flexibility and usage experience.

In yet another aspect of the invention, a device (eg, a mobile user device) can activate and run one or multiple stored access control clients (eg, eSIMs). In particular, when loading an eSIM, the operating system (OS) only needs to load the software list needed for the current runtime environment. This "sandbox" effect ensures that multiple eSIMs can be used on the same device, without improper access to other eSIMs.

Detailed Description of Sample Modalities

Exemplary embodiments and aspects of the present invention are now described in detail. Although these modalities and aspects are primarily discussed in the context of Subscriber Identity Modules (SIMs) of a GSM, GPRS/EDGE or UMTS cellular network, it will be recognized by those of ordinary skill in the art that the present invention is not so limited . In fact, the various aspects of the invention are useful in any wireless network (whether cellular or otherwise) that can benefit from the secure modification, storage and execution of access control entities or clients.

It will also be recognized that, although the term "subscriber identity module" is used herein (eg, eSIM), this term in no way necessarily connotes or requires (i) use by a subscriber itself (ie, the invention can be practiced by a subscriber or a non-subscriber); (ii) the identity of a single individual (that is, the invention may be practiced on behalf of a group of individuals, such as a family, or an intangible or fictitious entity, such as a corporation); or (iii) any tangible "module" equipment or hardware.

Prior Art Subscriber Identity Module (SIM) Operation - In the context of prior art UMTS cellular networks, a user equipment (UE) includes a mobile device and a Universal Subscriber Identity Module (USIM). The USIM is a logical software entity that is stored and executed from a physical universal integrated circuit (UICC) card. A variety of information is stored in the USIM, such as subscriber information, as well as the keys and algorithms used to authenticate with the network operator in order to obtain wireless network services. U-SIM software is based on Java Card® programming language. The Java Card is a subset of the Java® programming language that has been modified for built-in "card" type devices (such as the UICC mentioned earlier).

Generally, UICCs are programmed with a USIM, prior to distribution to the subscriber; pre-programming or "customization" is specific to each network operator. For example, prior to launch, the USIM is associated with an International Mobile Subscriber Identity (IMSI), a unique integrated circuit card identifier (ICC-ID), and a specific authentication key (K). The network operator stores the membership in a record contained in the network authentication center (AuC). After customization, the UICC can be distributed to subscribers. Referring to Figure 1, an Authentication and

Example Key Agreement (AKA) using prior art USIM previously mentioned USIM is illustrated in detail. During normal authentication procedures, the UE acquires the International Mobile Subscriber Identity (IMSI) from the USIM. The UE passes the IMSI to the Service Network (SN) of the network operator or the visited core network. The SN forwards the authentication request to the Home Network (HN) AuC. The HN compares the received IMSI with the AuC record and gets the appropriate K. HN generates a random number (RAND) and signs it with L using an algorithm for creating the expected response (XRES). The HN further generates a Cipher Key (CK) and an Integrity Key (IK) for use in encryption and integrity protection, as well as an authentication token (AUTN) using various algorithms. The HN sends an authentication vector consisting of RAND, XRES, CK and AUTN to the SN. The SN stores the authentication vector only for use in a disposable authentication process. The SN passes the RAND and AUTN to the UE.

Once the UE receives the RAND and the AUTN, the USIM checks whether the received AUTN is valid. If so, the UE will use the received RAND to compute its own response (RES) using the stored K and the same algorithm that generated the XRES. The UE passes the RES back to the SN. 20 The SN compares the XRES with the received RES and, if they match, the SN will authorize the UE to use the operator's wireless network services. Example Operation -

Various aspects of the present invention are now discussed with respect to an example implementation. In the context of the example embodiment 25 of the present invention, instead of using a physical UICC as in the prior art, the UICC is emulated as a virtual or electronic entity, such as, for example, a software application, from this point on referred to as an electronic Universal Integrated Circuit Card (eUICC), which is contained in a secure element (eg, a secure microprocessor or storage device) in the UE. The eUICC is capable of storing and managing multiple SIM elements, referred to from this point on as Electronic Subscriber Identity Modules (eSIM). Each eSIM is a software emulation of a typical USIM, and contains analog programming and user data associated with it. eUICC selects an eSIM based on the eSIM ICC-ID. Once the eUICC selects the desired eSIM(s), the UE can initiate an authentication procedure for obtaining wireless network services from the corresponding network operator of the eSIM. Furthermore, each eSIM application usually involves access control clients such as USIM, CSIM, ISIM, SIM, BAD, etc. previously mentioned. It is understood that each eSIM is associated with a user account, thus an "eSIM" can broadly encompass multiple access control clients (for example, a user can have a USIM, and a SIM associated with the same eSIM account).

As alluded to previously, the prior art USIM procedure described above uses a pre-shared key for authentication to the Core Network (eg, Home Network (HN), Service Network (SN) and Authentication Center (AuC), etc. mentioned above). Therefore, the USIM procedure is necessarily a "closed" system for the network operator, as the pre-shared key must be kept closely. In contrast, the present invention provides secure methods for the eUICC and any independent entity to mutually trust each other; and allows any independent entity to become trusted, even after user equipment has been released.

Therefore, the present invention has in some respects significantly more complex security requirements, but it also advantageously offers much more flexibility. Furthermore, it will be recognized by those of ordinary skill in the art that while various aspects of the present invention benefit from use with "virtual" software constructs (e.g., eUICC, eSIM), the benefits are not limited to these virtual embodiments. In fact, the principles discussed here are equally applicable to secure modification, storage and execution of an access control client embodied, among other things, on physical card media, dedicated security hardware, etc.

Establishing Trusted Communication - Figure 2 illustrates an example method for assigning a device key pair to a software entity (eg, an eUICC, an independent software vendor, a SIM vendor, etc.) . In step 202, a public/private cryptographic key pair (e.g., the Rivest, Shamir, and Adleman (RSA) algorithm) is assigned to the software entity, and stored in a physically protected secure element of the software entity; for example, the eUICC in the UE, a secure database at the independent software vendor. For example, the eUICC is programmed by a trusted entity; or, alternatively, it can internally generate the public/private key pair when first manufactured/activated.

As a brief aside, a public/private key pair is based on a secret private key and a publishable public key. Public/private key schemes are considered "asymmetric" as the key used for encryption and decryption are different and thus the encoder and decoder do not share the same key. In contrast, "symmetric" key schemes use the same key (or trivially transformed keys) for encryption and decryption. The Rivest, Shamir, and Adleman (RSA) algorithm is a type of public/private key pair cryptography that is commonly used in related techniques, but it will be recognized that the present invention is in no way limited to the RSA algorithm.

Public/private encryption schemes can be used to encode a message and/or generate signatures. Specifically, a message can be encrypted with a private key and decrypted with the public key, thereby ensuring that the message has not been altered in transit. Similarly, a signature generated with the private key can be verified with the public key, ensuring that the entity generating the signature is legitimate. In both uses, the private key is kept hidden, and the public key is freely distributed.

In step 204, an endorsement certificate is issued for the public/private key pair. For example, the trustee attests to the authenticity of the eUICC and the secret of the private key by issuing an "endorsement" certificate for the eUICC key pair. This public/private key pair is now the device key pair for eUICC.

In one embodiment, the endorsement certificate comprises a collection of data which may include, but is not limited to: (i) an identity information for the certification authority, (ii) an identification information for the device, (iii ) metadata describing certification algorithms, and/or (iv) the appropriate public keys. These components can be additionally signed with the endorser's private key. In one modality, during normal operation, this digital signature is checked by the receiver to verify that the contents are secure and not tampered with.

Since device key pairs are asymmetric, public keys can be distributed without compromising the integrity of private keys. Therefore, the device key and certificate can be used for protection and verification of communication between previously unknown parties (eg eUICC and independent party). Consider the following example transaction for an assured delivery of runtime components between an eUICC and a software vendor (shown in Figure 3).

In step 302 of Figure 3, an eUICC requests an eSIM from an independent eSIM vendor. While the following example describes a secure transfer of an eSIM application, other common examples of runtime environment applications could include patches, fully featured operating systems, etc.

In step 304, the independent eSIM vendor retrieves the device public key corresponding to the eUICC from the endorsement certificate, for example, the endorsement certificate can be obtained from a database by querying the eUICC, etc. . It is of particular interest to note that the eUICC counterparty private key is advantageously never exposed to the independent eSIM vendor during this process.

In step 305, the independent eSIM vendor verifies the endorsement certificate. In an example modality, the endorsement certificate is uniquely assigned by a trustee (such as its assignee, Apple®). Once the third-party eSIM vendor has verified the endorsement certificate, then the third-party eSIM vendor can be assured that the eUICC is trusted by the trusting entity (eg Apple®) and by association is secure.

In step 306, the eSIM runtime environment is encoded and then signed by the independent software vendor by the particular eUICC corresponding to the UE. In alternative modalities, the eSIM runtime environment is first signed and then encoded. In an example case, the vendor uses its own vendor asymmetric signing key and an RSA public/private key and certificate chain to sign the eSIM, and uses an ephemeral or temporary symmetric key to encode the eSIM. The temporary symmetric key is generated randomly while preparing the package for eUICC.

In step 308, the signed and encoded eSIM runtime environment is split into multiple packets for delivery (eg, over a wireless interface, etc.) by the independent eSIM vendor. For example, the signed and encoded eSIM is divided and sized into packets that are appropriate for the quality of the communication link (packet delivery supports several desirable error correction schemes well-known in the related arts).

In step 310, the ephemeral symmetric key is transmitted securely to the eUICC, such as by encrypting it with the appropriate eUICC public key. The seller certificate can be transferred as plain text, or alternatively it can be encoded. Generally, the seller certificate is not encoded to reduce the processing load on the recipient (this is not a system requirement, however, and an encoding can be used in all cases or alternatively can be applied selectively) .

In step 312, eUICC verifies the seller certificate. It should be noted that a successful verification of the seller's certificate with the seller's public signature key provides the eUICC with proof that the signature is not forged.

In some cases, the seller certificate may still include signatures by an external trustee (eg an MNO, etc.). If the seller certificate is valid, then the UE will decode the ephemeral symmetric key, with its private key (that of the eUICC). A successful completion of the preceding exchange ensures that the path between the eUICC and the independent entity is secured, and encoded with a common ephemeral symmetric key for an additional data transaction.

Thus, in step 314, the bulk encoded packets can be securely received, reassembled and decoded by the eUICC. In this particular example, eUICC transfers (via download) packages to eSlM.

In one embodiment, the seller certificate, key, and encrypted packets are transmitted together. Alternative modalities use other paradigms; for example, they transmit the certificate and key, establish a secure connection first, and then start transmitting the packets encrypted by the secure connection.

The exemplary embodiment of the present invention treats the eSlM as a separate entity from the eUICC. As such, the eUICC can establish a secure connection with an independent entity, without the benefit of an existing eSlM, and even after the user equipment is launched. The example eUICC allows for the secure delivery of an eSlM, thus directly allowing an independent eSlM vendor to distribute eSIMs to a mobile device, without prior reliance on the existing SIM AKA procedure.

More directly, the device has a pair of distinct symmetric device keys, which is separate from the symmetric key associated with any single eSlM (and the MNO issuing the eSlM). This distinction between e-SIM and eUICC has significant implications for the complexity of the device's operating system. Secure Partition Execution - As alluded to previously, existing solutions for physical UICCs contain a single USIM entity; however, those skilled in the related art will recognize that various aspects of the present invention are readily suitable for storing and executing multiple access control client profiles. Therefore, in another embodiment of the present invention, the eUICC must determine the validity of the network and the eSIM. Due to the complexity of the preceding tasks, the prior art SIM architecture is no longer sufficient for a boot. Instead, in an exemplary embodiment of the invention, the autoloader operating system (OS) loads a "common" or "resident" operating system; the common OS loads an appropriate eSIM, and the loaded e-SIM can perform the Authentication and Key Agreement (AKA) procedure.

Specifically, the autoloader OS of the present invention in one implementation is responsible for cryptographic verification, decoding and loading of the common OS, and all patches associated with an activated eSIM. The autoloader OS runs on a virtualized software eUICC; hence, the eSIM and the associated common OS are "sandboxed"; they can only access the appropriate patches made available through eUICC. For example, in an example modality, eUICC only allows patches that share the same signer as eSIM.

Referring now to Figure 4, an example method for safely performing partitioning in an eSIM is described.

In step 402, eUICC opens the autoloader OS on chip reset. In step 404, the autoloader OS parses the authorized list of patches opening for the runtime environment. For example, the autoloader OS can identify a default network and its associated patches. At least one of these patches is the regular OS, the other patches include an active eSIM, and any patches associated with the e-SIM.

At step 406, the autoloader OS checks the integrity of patches, for example, by reviewing a certificate or other means. For example, in one modality, a trusting entity (eg, Assignee of the Registry) could issue certificates or otherwise act as a root of trust for signature chains. If the patches are properly signed, then the autoloader OS can run the patches. Only checked patches matching the appropriate eSIM are loaded (other patches can be stored but are not played in the "sandbox").

In step 408, the autoloader OS opens the common OS. The common OS provides the interface between the eSIM and the remaining hardware. The common OS usually provides input and output functions that emulate the specific UICC for a particular eSIM. Generally, this includes functions such as file input and output (IO) etc.

After that, in step 410, the common OS can run the appropriate eSIM. Figure 4A illustrates the software relationship between the autoloader OS 452, the common OS 454, and the eSIMs 456. Most notably, in the example modality (as described in Figures 4 and 4A), different eSIM profiles operate on their common OSs . By separating the runtime environments by different eSIM profiles in different sandboxes, the preceding modality advantageously remains compatible with legacy SIM architectures, but leverages the benefits of the present invention. Generally, by ensuring that each eSIM runs in its own environment, existing SIM software can be directly virtualized. Furthermore, sandboxes ensure that the existence of other eSIMs does not cause an adverse interaction, which is a necessary requirement to support a large population of independent eSIM vendors (eg, which may have proprietary protocols and capabilities, etc. .). As noted previously, the preceding discussion is based primarily on SIM-based networking technologies and resources. Accordingly, a description of exemplary embodiments of generalized methods and apparatus for implementing one or more aspects of the invention is now presented. Methods -

Referring now to Figure 5, an embodiment of a generalized method 500 for securely modifying and storing components for use with access control clients is illustrated.

At step 502, one or more components for use with an access control client are ordered or offered. In an exemplary embodiment, one or more components include, in whole or in part, (i) a common operating system, (ii) at least one eSlM, and/or (iii) one or more customization patches associated with the eSlM. In other technology implementations, packets can be associated with CDMA Subscriber Identification Modules (CSIM), IP Multimedia Services Identity Module (ISIM), Subscriber Identity Modules (SIM), Removable User Identity Modules (RUIM), etc. Nearly limitless permutations of various analogous structures will be recognized by those skilled in the art, given the present description, the modification of the methods and apparatus presented here for the accommodation of these analogous structures and permutations is well within the ability of a common scholar, given this description.

In one embodiment, one or more components are requested or "pulled" by a device, or a subscriber associated with the device; that is, by the device/user issuing an affirmative communication or request. In alternative embodiments, one or more components are assigned or "pushed" into the device; that is, without the communication or request mentioned above, but rather according to some other criteria or a scheme, such as, for example, periodically, based on the occurrence of an event, etc. The existence of one or more components may be advertised or otherwise broadcast, or stored in a repository that can be accessed or searched.

In other embodiments, one or more components are queried or otherwise triggered by one or more contextual events, eg, a device entering a specified area, exceeding a specific usage, etc.

The requisition or offer may also include a signature or certificate which originated from a trusting party. In other alternative implementations, the request or offer comprises a cryptographic challenge. In still other variants, the request or offer includes a means for determining authenticity (eg, a password authentication based on a user interface, etc.).

The requisition or offer may also include a transaction key. In such a variant, the transaction key is an ephemeral key. Still other persistent transaction keys can also be implemented; for example, the key can be the same for multiple transaction sessions, multiple users, etc. In other variants, the transaction key is a symmetric key or, alternatively, an asymmetric key.

At step 504, the requisition or offer is checked for authenticity. In one embodiment, the signature or certificate which originated from a relying party is checked for validity. In some cases, this may require external contact with the trusted party. Alternatively, the validity of the signature or certificate may be self-evident or otherwise discoverable by a verifier, without resorting to the relying party. Still other schemes can be based on a subscriber input; for example, a username and password entry, or simple recognition schemes, etc.

A successful check can also be configured to require one or more challenge response exchanges. In some variants, verification can be one-way (for example, only one of the negotiators must succeed). In still other schemes, a check is performed out-of-band (eg via another communication path), or via subscriber assistance, etc.

A successful verification results in agreement on one or more parameters required for a secure transaction. For example, in an modality, one or more transaction keys are established. In some variants, a transaction key is generated after a check. In alternative variants, the transaction key is proposed or generated before verification and used conditionally thereafter.

Thereafter, in step 506, a device receives one or more packets associated with an access control client. Packets can be additionally encoded with the transaction key to ensure secure transmission. In one variant, packets can be encoded asymmetrically; that is, the packets are encrypted with a public key. In other variants, packets are symmetrically encoded using a previously agreed shared key. Alternatively, packages are signed with an identifiable signature. A myriad of other solutions for verifiable packet delivery known in the related arts can be used, consistent with the present invention.

At step 508, the device assembles the packets, and decodes one or more components. In an example embodiment, one or more components are associated with the appropriate common operating system. For example, as described previously, patches can include at least one eSIM, and/or one or more personalization patches associated with the eSIM, as described previously. At the completion of step 508, one or more components have been successfully or securely transferred to the target device.

Referring now to Fig. 6, an exemplary embodiment of a generalized method 600 for securely executing components for use with access control clients is illustrated.

At step 602, an access control client and one or more associated patches are identified. In an example modality, the access control client and one or more associated patches are selected by an operating system. In one implementation, the operating system is additionally booted from a simple autoloader operating system.

In one configuration, the autoloader operating system maintains multiple partitions secure, where each partition is distinct from other partitions, and software running from one memory partition cannot be accessed or accessed by other unrelated partitions. For example, an example device runs a simple autoloader OS; the simple autoloader OS loads and runs a regular OS, and its associated eSlM, and patches, on a single "sandbox" partition.

Various embodiments of the present invention separate the entire manifest from available components, and patches, according to one or more categorizations. In such a variant, components and patches are associated according to a common signer or source of trust. For example, in one scenario, the simple autoloader OS might just allow the regular OS, and eSIMs signed by the same eSlM vendor to run. In other variants, components and patches can be associated using a user selection, or multiple trust levels. For example, multiple components may be dispersed from different cooperative entities (eg a trusted eSlM vendor, and a trusted network customization, etc.).

In step 604 of method 600, the access control client and associated patches are checked for an operation. In one modality, the access control client and associated patches are checked for integrity; that is, if they have not been violated or otherwise altered. Common methods for these integrity checks include checksums, cryptographic evidence or residuals, etc. Other solutions for checking the authenticity of patches might include a certificate check, a status check, and so on.

In step 606, the verified access control client is executed. Upon successful loading and execution, the access control client will perform the initial access control procedures for an associated network. For example, a verified eSIM can perform the Authentication and Key Agreement procedure. Example Mobile Apparatus - Referring now to Figure 7, example apparatus 700 useful for implementing the methods of the present invention is illustrated.

The example UE apparatus of Fig. 7 is a wireless device with a processor subsystem 702, such as a digital signal processor, a microprocessor, a field programmable gate array, or a plurality of processing components mounted in a or more substrates. The processing subsystem can also comprise an internal cache memory. The processing subsystem is connected to a memory subsystem 704 comprising memory which may comprise, for example, SRAM, flash and SDRAM components. The memory subsystem may implement one or more of a DMA type hardware in order to facilitate data accesses, as is well known in the art. The memory subsystem contains computer-executable instructions which are executable by the processor subsystem.

In an exemplary embodiment of the present invention, the device may comprise one or more wireless interfaces (706) adapted for connection to one or more wireless networks. The multiple wireless interfaces can support different radio technologies such as GSM, CDMA, UMTS, LTE/LTE-A, WiMAX, WLAN, Bluetooth, etc. by implementing the appropriate antenna and modem subsystems.

The 708 user interface subsystem includes any number of well-known I/O, including, without limitation: a keyboard, a touch screen (eg a multi-touch interface), an LCD display, a backlight, a speaker and/or a microphone. However, it is recognized that, in certain applications, one or more of these components can be eliminated. For example, PCMCIA card-type client modalities may lack a user interface (as they could concatenate into the user interface of the main device to which they are physically and/or electrically coupled).

In the illustrated embodiment, the device comprises a secure element 710 which contains and operates the eUICC application. eUICC is capable of storing and accessing a plurality of access control clients to be used for authentication with a network operator. The secure element is accessible by the memory subsystem upon request from the processor subsystem.

In one embodiment, the secure element comprises at least one partitionable memory, wherein the partitionable memory is adapted to contain one or more access control clients and associated patches. Each partition is kept separate from other partitions, and software running from the memory partition cannot access or be accessed by other unrelated partitions.

The secure element may also comprise a so-called "secure microprocessor" or SM of the type well-known in the security arts.

Furthermore, various embodiments of the example modality include instructions which, when executed, open a simple autoloader operating system (OS). The autoloader operating system is further configured to select at least one partition from the secure element, and load the appropriate access control client loaded with it. In many implementations, access control clients may still be provided with one or more certificates associated with a trusted signatory. The autoloader OS can verify certificates before running the access control client.

Furthermore, in one embodiment, the secure element maintains a listing or manifest of stored access control clients. The manifest may include information as to the current status of stored access control clients; such information may include availability, completeness, validity, previously experienced errors, etc. The manifest can still be linked or docked in the UI to allow a user selection from an available access control client.

Referring back to Figure 7, secure element 710 is capable of receiving and storing components for use with one or more access control clients for authentication with a network operator. In an exemplary embodiment, the secure element has an associated device key and an endorsement certificate. This device key is used for protection and verification of communication between previously unknown parties (eg UE and independent party).

In such a variant, the device key is a private key from an asymmetric public/private key pair. The counterparty public key can be freely distributed, without compromising the integrity of the private keys. For example, the device may be assigned (or it may internally generate) an RSA public/private key; the public key is made available for post-release communication.

Furthermore, in some variants, the endorsement certificate is a uniquely signed digital signature associated with a trustee. In an example scenario, the endorsement certificate is verifiable by independent entities, and provides proof of the integrity of the example device.

Although the foregoing methods and apparatus for programming the secure element are illustrated with respect to an RSA keypair, it is readily appreciated by those skilled in the art that other authentication schemes can be similarly substituted. For example, in other variants, the device key can be a shared key, where the distribution of the shared key is highly guarded. Still other modalities can be certificate-based rather than cryptographic exchanges.

It will be recognized that while certain aspects of the invention are described in terms of a specific sequence of steps in a method, these descriptions are only illustrative of the broader methods of the invention, and may be modified as required for application in

private. Certain steps may be made unnecessary or optional under certain circumstances. Additionally, certain steps or functionality can be added to the modalities shown, or the order of execution of two or more steps swapped. All such variations are considered to be encompassed by the invention shown and claimed herein.

Although the detailed description above has shown, described and highlighted new features of the invention as applied to various embodiments, it will be understood that various omissions, substitutions and changes in the form and details of the device illustrated process can be made by those skilled in the art , without deviating from the invention. The foregoing description is that of the presently best contemplated mode of carrying out the invention. This description is not meant to be limiting in any way, but rather is to be taken as illustrative of the 15 general principles of the invention. The scope of the invention is to be determined with reference to the claims.

Claims (15)

1. Method to securely manage access control clients, the method characterized by comprising, on an electronic Universal Integra-ted Circuit Card, eUICC, embedded in a mobile device and in response to an eUICC boot: selecting a secure partition from a plurality of secure partitions managed by eUICC, where the secure partition includes a respective access control client; authenticate the access control client; and after access control client authentication: causing an operating system, OS, associated with the access control client to run within a limited scope that corresponds to the secure partition, where the OS runs the client of access control. 2. Method according to claim 1, characterized in that the access control client comprises an electronic Subscriber Identity Module, eSIM. 3. Method according to claim 2, characterized in that the eSIM is a virtualization of a physical SIM card. 4. Method according to claim 1, characterized in that the authentication of the access control client comprises the validation of a first certificate associated with the access control client against a second certificate associated with the eUICC. 5. Method according to claim 1, characterized in that the mobile device receives identifies the initialization of the eUICC after a reset of the eUICC. 6. Method according to claim 1, characterized in that the access control client corresponds to a standard mobile network operator, MNO, associated with the mobile device. 7. Method according to claim 1, characterized in that the secure partition stores at least one additional access control client. 8. Method according to claim 1, characterized in that the activation of the access control client allows the mobile device to register with a Mobile Network Operator, MNO, which corresponds to the control client of access. 9. Mobile device configured to securely manage a plurality of access control clients, the mobile device characterized by comprising: at least one wireless interface; an electronic universal integrated circuit board, eUICC, comprising: a memory that includes a plurality of secure partitions and a processor is configured to cause the mobile device to perform steps that include, in response to an eUICC initialization: selecting a secure partition of the plurality of secure partitions managed by eUICC, where the secure partition includes a respective access control client; authenticate the access control client; and after access control client authentication: causing an OS associated with the access control client to run within a limited scope corresponding to the secure partition, where the OS runs the access control client. 10. Mobile device, according to claim 9, characterized in that the access control client comprises an electronic Subscriber Identity Module, eSIM. 11. Mobile device, according to claim 10, characterized by the fact that the eSIM is a virtualization of a physical SIM card. 12. Mobile device, according to claim 9, characterized in that the authentication of the access control client comprises the validation of a first certificate associated with the access control client against a second certificate associated with the eUICC. 13. Mobile device, according to claim 9, characterized in that the processor initializes the eUICC together with a reset of the eUICC. 14. Mobile device, according to claim 9, characterized in that the access control client corresponds to a standard mobile network operator, MNO, associated with the mobile device (700). 15. Mobile device, according to claim 9, characterized in that the activation of the access control client allows the mobile device, using at least one wireless interface (706), to register with an Operator. Mobile Network, MNO, which corresponds to the access control client.

Images