WO2017082966A1

WO2017082966A1 - Integrated universal integrated circuit card on mobile computing environments

Info

Publication number: WO2017082966A1
Application number: PCT/US2016/037634
Authority: WO
Inventors: Farid Adrangi; Muthaiah Venkatachalam; Sanjay Bakshi; Carlos V. Rozas
Original assignee: Intel IP Corporation
Priority date: 2015-11-09
Filing date: 2016-06-15
Publication date: 2017-05-18

Abstract

Methods, systems, and storage media are described for implementing an integrated universal integrated circuit card iUICC module (120) that may perform various UICC functions. The iUICC module (120) may be implemented in modem circuitry (305) of a computing platform or the iUICC module (120) may be implemented in a secure execution environment (115) of a host architecture coupled with the modem circuitry (305). Program code of the iUICC module may be executed by an application processor of the host architecture when the iUICC module (120) is implemented within the secure execution environment of the host architecture. Program code of the iUICC module (120) may be executed by a baseband processor of the modem circuitry when the iUICC module (120) is implemented within the modem circuitry (200). Other embodiments may be described and/or claimed.

Description

INTEGRATED UNIVERSAL INTEGRATED CIRCUIT CARD ON MOBILE COMPUTING ENVIRONMENTS

RELATED APPLICATIONS

The present application claims priority under 35 U.S.C. § 1 19 to U.S. Provisional Application No. 62/253,048 filed on November 9, 2015, which is hereby incorporated by reference in its entirety.

FIELD

The present disclosure relates to the technical field of wireless communications, and in particular, to apparatuses, methods and storage media for providing integrated Universal Integrated Circuit Cards (iUICCs) on or in mobile computing environments.

BACKGROUND

A Universal Integrated Circuit Card (UICC) is a smart card used by computing platforms, such as user equipment (UE) or mobile equipment that ensures integrity and security of personal data and cellular communications. To ensure integrity and security, UICCs typically contain a mobile network operator (MNO) profile, which includes information and applications to identify and authenticate a computing platform with the MNO, and upon authentication, to access an MNO network associated with the MNO. These MNO profiles may contain a Subscriber Identity Module (SIM) or Network Access Application (NAA), an international mobile subscriber identity (IMSI) number, an authentication key, personal identification numbers (PINs), PIN Unblocking Keys (PUKs), and a network access policy. The SIM or NAA is the application that uses the stored IMSI, authentication key, PINs, and/or PUKs to authenticate the computing platform and access the MNO network in accordance with the stored network access policy. In some cases, a UICC may include multiple MNO profiles for accessing multiple MNO networks. For example, a UICC may operate an application and/or profile for Universal Mobile Telecommunications System (UMTS) SIM (USIM) for authenticating a device to access a UMTS network. Furthermore, UICCs must be provisioned with an MNO profile by an associated MNO before being provided to a customer.

One drawback is that mobile devices usually need a smart card reader to use the UICCs since UICCs are physical smart cards that were designed to be transferable between different mobile devices and/or replaceable (for example, when a user wishes to switch MNOs). These smart card readers take up space inside an already crowded mobile device platform. Additionally, with the proliferation of machine-type communications (MTC) devices and other like autonomous network-enabled devices, switching out UICCs may become logistically complicated and burdensome, especially in situations where MTC devices are deployed in remote or difficult to reach locations. Furthermore, because UICCs must be provisioned by an MNO before being provided to a customer, the deployment of MTC devices may become more complicated and delayed.

To solve such drawbacks, embedded UICCs (eUICCs) have been developed, particularly for MTC devices. eUICCs are UICCs that are embedded in computer devices by soldering the eUICC to a circuit board. In some cases, eUICCs are not provisioned with any MNO profiles when the device is acquired by a customer or service provider. In other cases, eUICCs are pre-provisioned with a "provisioning profile," which includes an NAA and credentials used to access a network for provisioning the eUICC with an MNO profile upon powering up the eUICC for the first time. The Groupe Speciale Mobile Association (GSMA), "Remote Provisioning Architecture for Embedded UICC," Technical Specification version 3.0, 30 September 2015 describes a secure end-to-end architecture and protocols through which an MNO application and profile may be created and assigned to an eUICC. The remote provisioning of eUICCs eliminates the need for distribution of specific UICCs to end-users. Additionally, remote provisioning of eUICCs allows end- users to maintain a subscription with multiple MNOs without removing/inserting a new UICC for each MNO. Furthermore, remote provisioning of eUICCs allows eUICC manufacturers to "rent space" on the eUI CC to other non-MNO service providers so that end-users may maintain subscription-based services with the non-MNO service providers with levels of security that were previously only afforded to MNOs.

However, eUICCs create manufacturing overhead for original equipment manufacturers (OEMs) in terms of additional manufacturing costs and processes for embedding the eUICCs, requiring space on the circuit board for the eUICCs, and stock keeping unit (SKU) proliferation. Furthermore, eUICCs are limited to the clock rate and memory capacity of the onboard eUICC microprocessor and memory. Limited clock rate and memory size can prevent UICC vendors and MNOs from employing state of the art cryptographic algorithms, which could make the eUICC and its applications vulnerable to malicious attacks. Limited memory capacity may negatively impact user experience because the limited memory size of eUICCs can only store a small number of MNO profiles and does not allow for storage of other secure information, such as payment information, web application login information, and the like. BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. To facilitate this description, like reference numerals designate like structural elements. Embodiments are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings.

FIG. 1 illustrates an arrangement in which an iUICC module may be implanented in accordance with various example embodiments;

FIG. 2 illustrates example logical components and interaction points between components of profiles, components of an iUICC module, and an iUICC proxy, in accordance with various example embodiments;

FIG. 3 illustrates example components of a computing platform according to various example embodiments;

FIG. 4 illustrates the components of a first implementation of the computing platform, in accordance with various example embodiments;

FIG. 5 illustrates the components of a second implementation of the computing platform, in accordance with various example embodiments;

FIG. 6 illustrates the components of a third implementation of the computing platform, in accordance with various example embodiments;

FIG. 7 illustrates a first example implementation of modem circuitry, in accordance with other various example embodiments;

FIG. 8 illustrates a second example implementation of modem circuitry, in accordance with other various example embodiments;

FIG. 9 illustrates an example process for remote provisioning an iUICC module in accordance with various embodiments;

FIG. 10 illustrates an example process for establishing an iUICC enclave in accordance with various embodiments;

FIG. 1 1 illustrates an example process for provisioning the iUICC proxy within the management engine circuitry;

FIG. 12 illustrates an example process for operating the iUICC module within the iUICC enclave, in accordance with various embodiments;

FIG. 13 illustrates an example process for remote attestation of a secure execution environment, in accordance with various embodiments;

FIG. 14 illustrates an example process for local attestation of a secure execution environment, in accordance with various embodiments; FIG. 15 illustrates an example process for creating a security domain within an iUICC enclave, in accordance with various embodiments;

FIG. 16 illustrates an example process for establishing one or more keys for authenticating a computing platform, in accordance with various embodiments;

FIG. 17 illustrates an example process for downloading a profile, in accordance with various embodiments;

FIG. 18 illustrates an example process for enabling a downloaded profile, in accordance with various embodiments;

FIG. 19 illustrates an example process for attaching to a network using an enabled profile, in accordance with various embodiments;

FIG. 20 illustrates an example process for accessing services using an enabled profile, in accordance with various embodiments; and

FIG. 21 illustrates an example process for intra-enclave access, in accordance with various embodiments.

DETAILED DESCRIPTION

In the following detailed description, reference is made to the accompanying drawings that form a part hereof wherein like numerals designate like parts throughout, and in which is shown by way of illustrated embodiments that may be practiced. It is to be understood that other embodiments may be utilized and structural and/or logical changes may be made without departing from the scope of the present disclosure. Therefore, the following detailed description is not to be taken in a limiting sense, and the scope of embodiments is defined by the appended claims and their equivalents.

Various operations may be described as multiple discrete actions and/or operations in turn, in a manner that is most helpful in understanding the claimed subject matter. However, the order of description should not be construed to imply that the various operations are necessarily order dependent. In particular, these operations may not be performed in the order of presentation. Operations described may be performed in a different order than the described embodiments. Various additional operations may be perfonned and/or described operations may be omitted in additional embodiments.

For the purposes of the present disclosure, the phrase "A and/or B" means (A), (B), or (A and B). For the purposes of the present disclosure, the phrase "A, B, and/or C" means (A), (B), (C), (A and B), (A and C), (B and C), or (A, B and C). For the purposes of the present disclosure, the phrase "at least one of A and B" means (A), (B), or (A and B).

The description may use the phrases "in an embodiment," or "in embodiments," which may each refer to one or more of the same or different embodiments . Furthermore, the terms "comprising," "including," "having," and the like, as used with respect to embodiments of the present disclosure, are synonymous.

Also, it is noted that example embodiments may be described as a process depicted as a flowchart, a flow diagram, a dataflow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations may be performed in parallel, concurrently, or simultaneously. In addition, the order of the operations may be re-arranged. A process may be terminated when its operations are completed, but may also have additional steps not included in the figure(s). A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, and the like. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function and/or the main function. Furthermore, a process may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perfonn the necessary tasks may be stored in a machine or computer readable medium. A code segment may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, program code, a software package, a class, or any combination of instructions, data structures, program statements, and the like.

As used herein, the term "circuitry" may refer to, be part of, or include an Application Specific Integrated Circuit (ASIC), an electronic circuit, a processor (shared, dedicated, or group), and/or memory (shared, dedicated, or group) that execute one or more software or firmware programs, a combinational logic circuit, and/or other suitable hardware components that provide the described functionality. In some embodiments, the circuitry may implement, or functions associated with the circuitry may be implemented by, one or more software or firmware modules.

As used herein, the term "module" may include logic (including operating systems or application instructions , data, etc.) at least partially operable in circuitry. The circuitry may implement the module to cause the module to perform operations described herein.

As used herein, the term "memory" may represent one or more hardware devices for storing data, including random access memory (RAM), magnetic RAM, core memory, read only memory (ROM), magnetic disk storage mediums, optical storage mediums, flash memory devices and/or other machine readable mediums for storing data. The term "computer-readable medium" may include, but is not limited to, memory, portable or fixed storage devices, optical storage devices, wireless channels, and various other mediums capable of storing, containing or carrying instruction(s) and/or data.

As used herein, the term "computing platform" may be considered synonymous to, and may hereafter be occasionally referred to, as a computer device, computing device, client device or client, mobile, mobile unit, mobile terminal, mobile station, mobile user, mobile equipment, user equipment (UE), user terminal, machine-type communication (MTC) device, machine-to-machine (M2M) device, M2M equipment (M2ME), Internet of Things (IoT) device, subscriber, user, receiver, etc., and may describe any physical hardware device capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, equipped to record/store data on a machine readable medium, and transmit and receive data from one or more other devices in a communications network. Furthermore, the term "computing platform" may include any type of electronic devices, such as a cellular phone or smartphone, a tablet personal computer, a wearable computing device, an autonomous sensor, personal digital assistants (PDAs), a laptop computer, a desktop personal computer, a video game console, a digital media player, an in-vehicle infotainment (IVI) and/or an in-car entertainment (ICE) device, a vehicle-to-vehicle (V2V) communication system, a vehicle-to-everything (V2X) communication system, a handheld messaging device, a personal data assistant, an electronic book reader, an augmented reality device, and/or any other like electronic device.

As used herein, the term "network element" may be considered synonymous to and/or referred to as a networked computer, networking hardware, network equipment, router, switch, hub, bridge, gateway, and/or other like device. The term "network element" may describe a physical hardware device of a wired or wireless communication network that is configured to host a client device and the like. Furthermore, the term "network element" may describe equipment that provides radio baseband functions for data and/or voice connectivity between a network element and one or more users.

As used herein, the term "network operator" may be considered synonymous to and/or referred to as a mobile network operator (MNO), cellular network operator, wireless service provider, wireless carrier, mobile network carrier, virtual MNO, and/or the like. The term "network operator" may describe any provider of services related to a communications network including wired and wireless communications networks. Furthermore, the term "network operator" may describe an entity that owns or controls elements necessary to provide communications network-related services, including radio spectrum allocation including one or more radio spectrum licenses from a regulatory agency, wireless network infrastructure and/or back haul infrastructure, billing and subscription-related services, provisioning computer systems, and/or other like services.

Example embodiments disclosed herein provide devices and systems that integrate Universal Integrated Circuit Card (UICC) technology with a host platform (also referred to as "integrated UICCs" or "iUICCs"), which ensures integrity and security of personal data for cellular communications while providing greater processing power and greater memory storage capabilities than traditional UICCs, embedded UICCs (eUICCs), Subscriber Identity Module (SIM) cards, or other like integrated circuitry cards (ICCs). Example embodiments provide methods for provisioning iUICCs by remote provisioning services, cellular network operators, and/or other vendors or application developers, and also provide methods for utilizing the iUICCs once provisioned. Because the iUICC of the example embodiments provide greater processing power and greater memory storage capabilities than traditional UICCs and eUICCs, the example embodiments may allow network operators to develop more robust security and authentication applications and processes. Currently, application developers and/or service providers are separate entities than smart card issuers and may "rent" card memory space from card issuers. Card issuers allow applications to be loaded onto UICCs or provisioned in eUICCs over the air (OTA). Because the iUICCs of the example embodiments provide greater processing power and greater memory storage capabilities than traditional UICCs and eUICCs, the example embodiments allow more application developers and service providers to rent space and/or develop more robust applications and services.

The example embodiments provide a trusted execution environment (also referred to as a "secure execution environment"), which includes an iUICC module instead of requiring a separate stand-alone UICC to be inserted into a card slot of the computing device or embedding an eUICC on a motherboard of the computing device. In various embodiments, the secure execution environment may be provided as a new mode of execution on an existing processor, such as an application processor, an embedded trusted platform module, or a baseband processor of a cellular modem. The iUICC module may perform various UICC functions, such as those defined by ISO/IEC 7816, European Telecommunications Standards Institute (ETSI) technical standard (TS) 102 221, ETSI TS 102 225, ETSI TS 102 226, ETSI TS 102 241, ETSI TS 102 600, 3rd Generation Partnership Project (3 GPP) TS 31.101, 3 GPP TS 31.116, 3 GPP TS 31.121, 3 GPP TS 31.220, 3 GPP TS 31.828, Groupe Speciale Mobile Association (GSMA), "Remote Provisioning Architecture for Embedded UICC," TS version 3.0, 30 September 2015, and/ or any other like standards.

Referring now to the figures, FIG. 1 shows an arrangement 100 in which an iUICC module 120 may be implemented in accordance with various example embodiments. As shown in FIG. 1, arrangement 100 may include computing platform 200, network 135, a remote provisioning service 140, a service provider 145, a network operator 150, and a certificate issuer (CI) 155. Additionally, computing platform 200 may include communications circuitry 105, iUICC proxy 110, iUICC storage 125, and secure execution environment 115. The secure execution environment 115 may include iUICC module 120. Furthermore, the remote provisioning service 140 may include a Subscription Manager Data Preparation (SM-DP) entity 160 and a Subscription Manager Secure Routing (SM-SR) entity 165.

Computing platform 200 may be a physical hardware device capable of sequentially and automatically carrying out a sequence of arithmetic or logical operations, recording, storing, and/or transferring digital data via a wired or wireless connection with one or more network elements and/or one or more client computing devices. In this regard, computing platform 200 is capable of transmitting and receiving signals and/or data streams from the network element(s) or other client computing device(s). To carry out such functions, the computing platform 200 may include one or more memory devices, one or more processors, and communications circuitry 105. The communications circuitry 105 may be one or more hardware devices that allow the computing platform 200 to communicate with other devices. Such hardware devices may include, for example, modem circuitry 305, near field communication (NFC) circuitry 310, and network interface (NI) circuitry 315, which are shown and described with regard to FIGS. 4-8.

Computing platform 200 may be configured to run, execute, or otherwise operate one or more applications. According to various example embodiments, the one or more applications may include the iUICC proxy 110, the iUICC module within the secure execution environment 115, and the secure execution environment 115 itself.

The iUICC proxy 1 10 may be one or more software modules that operate in conjunction with one or more hardware devices to provide access to the iUICC module 120 within the secure execution environment 1 15. The iUICC proxy 110 may be implemented in a physical hardware device that is separate from other components of the computing platform 200 (for example, the embodiments shown and described with regard to FIGS. 4 and 6-7), may be implemented in application circuitry (for example, the embodiment shown and described with regard to FIG. 5), or may be implemented in baseband circuitry (for example, the embodiment shown and described with regard to FIG. 7). In either embodiment, the iUICC proxy 1 10 may be a security application or application programming interface (API) allowing untrusted applications and components of the computing platform 200 to interact with the iUICC module 120 within the secure execution environment 1 15. In some embodiments, the iUICC proxy 110 may be implemented as middleware or "software glue," which is used to connect two or more separate applications or connect applications with underlying hardware components beyond those available from an operating system and/or drivers. The iUICC proxy 110 may be the only element that is outside of the secure execution environment 115 that is capable of communicating with the iUICC module 120 within the secure execution environment 115. For example, the iUICC proxy 110 may communicate with the iUICC module 120 as described with regard to FIG. 12, and various untrusted applications or components may communicate with the iUICC module 120 via the iUICC proxy 1 10 as described with regard to FIGS. 13-21.

Secure execution environment 1 15 may be one or more hardware devices and/or one or more software modules that carry out secure operations and/or control the storage and use of personal and/or confidential data. The one or more software modules may include one or more "enclaves" (also referred to as "secure enclaves"), which may be isolated regions of code and/or data within the memory of the computing platform 200. In embodiments where the secure execution environment 1 15 comprises one or more enclaves, the enclave including the iUICC module 120 may be referred to as an "iUICC enclave." In most embodiments, only code executed within a secure enclave may access data within the same secure enclave, and the secure enclave may only be accessible using the secure application (for example, the iUICC proxy 110 described previously). The secure application may be implemented by an application processor or a tamper-resistant microcontroller. The one or more secure enclaves may be defined using the Intel® Software Guard Extensions (SGX). Examples of such embodiments are shown and described with regard to FIGS. 4-5 and 7-8.

In other embodiments, secure execution environment 115 may be implemented as a physical hardware device that is separate from other components of the computing platform 200. In such embodiments, secure execution environment 1 15 may be a tamper- resistant microcontroller with embedded processors and memory devices that communicate with an application processor and/or baseband processor of the computing platform 200. The tamper -resistant microcontroller may be referred to as a management engine (ME) or ME circuitry. In such embodiments, applications that are not within the secure execution environment 115 may communicate with ME circuitry via secure application (for example, the iUICC proxy 110 described previously) that may also be implemented by the ME circuitry. The ME circuitry may include a secure cryptoprocessor, which is a dedicated system on chip (SoC) or microprocessor designed to secure hardware by carrying out cryptographic operations. An example of such embodiments is shown and described with regard to FIG. 6. In some embodiments, the ME circuitry may operate in accordance with the International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) specification ISO/IEC 11889:2009, which defines standards for trusted computing platforms. In embodiments, the ME circuitry may be a management engine provided by Intel®, a Converged Security Engine (CSE) or a Converged Security Management/Manageability Engine (CSME) provided by Intel®; Trusted Execution Technology (TXT) provided by Intel®; and/or the like. In some embodiments, the ME circuitry may operate in conjunction with Active Management Technology (AMT) provided by Intel® and/or Intel® vPro™ Technology (vPro). The Intel® AMT and/or Intel® vPro™ may allow for remote provisioning of the ME circuitry, and remote management of the ME circuitry once the ME circuitry has been successfully provisioned.

As shown, the secure execution environment 115 may include iUICC module 120.

The iUICC module 120 may be one or more software modules that operate in conjunction with one or more hardware devices to perform various functions that would be performed by a physical UICC or eUICC. This may include performing various authentication operations, implementing or executing applications associated with one or more profiles 375, and generating messages or commands in accordance with ISO/IEC 7816 and/or other suitable standards that define UICC characteristics and transmission protocols. Because the iUICC module 120 is implemented using the application circuitry of the host architecture in some embodiments, the iUICC module 120 may operate more robust and/or computationally intensive authentication procedures than traditional UICCs or eUICCs. These messages/commands/data may be communicated to the iUICC proxy 110 in encrypted form, wherein the iUICC proxy 110 may decrypt the messages/commands/data, and provide the decrypted messages/commands to other components of the computing platform 200. This may include providing the messages/commands to the communications circuitry 105 to send/receive data to/from various network elements, including network elements within network 135, remote provisioning service 140, and the service provider 145. The iUICC module 120 may also receive data in encrypted form from the iUICC proxy 110, and decrypt the encrypted data for use with one or more applications within the secure execution environment 1 15. In this regard, the iUICC enclave may include an iUICC bridge application (such as iUICC bridge 210 shown and described with regard to FIG. 2) that may interact with components of the iUICC module 120 within the iUICC enclave and receive/provide messages/commands/data from/to the iUICC proxy 1 10.

The aforementioned operations may include communicating data with the communications circuitry 105 in compliance with GSMA specifications, GlobalPlatform Card specifications, ETSI standards, or other like UlCC-based specifications. The aforementioned operations may include communicating data with one or more network elements through GSMA-specified interfaces, GlobalPlatform Card-specified interfaces, or other like UlCC-based interfaces. For example, in the arrangement 100, the SM-SR 165 may use short message service (SMS) to establish an SMS channel between the iUICC module 120 and an entity in the arrangement 100, a Card Application Toolkit Transport Protocol (CAT TP) channel for communicating with Card Application Toolkit (CAT) applications, and hypertext transfer protocol secure (HTTPS) session for remote over-the- air (OTA) communications with the iUI CC module 120 via the communications circuitry 105 and the iUICC proxy 110. The SMS protocol may be used for HTTPS session triggering, CAT TP session triggering, providing Remote File Management (RFM) commands (for example, SELECT, UPDATE RECORD, DEACTIVATE FILE, ACTIVATE FILE, VERIFY PIN, and other RFM commands as defined by ETSI TS 102 226), providing Remote Application/Applet Management (RAM) commands (for example, LOAD, INSTALL, DELETE, GET STATUS, and other RAM commands as defined by ETSI TS 102 226), and providing Proof of Receipt (PoR) messages. The SMS protocol may also be used for providing Application Protocol Data Units (APDUs) to an entity in the arrangement 100 based on a received RFM command or RAM command. The RFM and RAM commands may be in the form of Command APDUs (C-APDUs), and the responses from the iUICC module 120 may be in the form of Response APDUs (R- APDUs). In some embodiments, an established HTTPS or CAT TP session may be used to communicate RFM commands, RAM commands, or PoRs. Furthermore, the various entities in arrangement 100 may establish secure channels with the components of the iUICC module 120 or applications within a profile 375 as discussed with regard to FIG. 2. Additionally, the iUICC module 120 may include one or more security domains and operate in conjunction with one or more security domains within each of the profiles 375. Security domains are packages that support various security services, such as key handling, encryption, decryption, digital signature generation and verification for associated applications. Additionally, each of the entities in the arrangement 100 may have a corresponding security domain within the iUICC module 120 or within an associated profile 375. For example, remote provisioning service 140 may have an Issuer Security Domain Root (ISD-R) within the iUICC module 120 and an Issuer Security Domain Profile (ISD-P) within each of the profiles 375; CI 155 may have a Controlling Authority Security Domain (CASD) within the iUICC module 120; and service provider 145 and network operator 150 may have an Owner Security Domain (OSD) within their corresponding profiles 375. An example arrangement of the aforementioned security domains is shown by FIG. 2. For most eUICCs, the ISD-R and the CASD are installed and personalized by an eUICC manufacturer at the time of manufacture. However, in various embodiments, the ISD-R and the CASD may be provisioned within the iUICC module 120 at the time of provisioning the iUICC module 120, which may reduce production overhead costs.

Additionally, the secure execution environment 115 may include the iUICC storage 125, which may include one or more databases (DBs) implemented by one or more computer-readable media of the computing platform 200. The one or more DBs may include one or more relational database management systems (RDBMS) one or more object database management systems (ODBMS), a column-oriented DBMS, correlation database DBMS, an extensible markup language (XML) format database, and the like. The one or more DBs may be associated with one or more applications that enable querying of the databases and/or store information in the databases. Any suitable database query language may be used to store and obtain information from iUICC storage 125. The iUICC storage 125 may be implemented in one or more data storage devices. These data storage devices may include at least one of a non-volatile random access memory (NVRAM) device, a read-only memory (ROM) device, a flash memory device, a solid state drive (SSD), and/or other like data storage devices. In various embodiments, iUICC storage 125 may be accessed by the iUICC module 120 such that the iUICC module 120 may query the iUICC storage 125 to retrieve and control storage of profile data. In some embodiments, iUICC storage 125 may be physically and/or logically divided into multiple DBs, while in other embodiments, the iUICC storage 125 may be a single DB that resides on one physical hardware data storage device. In embodiments, where the secure execution environment 115 is implemented using secure enclaves, each of the profiles 375 and/ or other data in the iUICC storage 125 may be stored in their own enclaves, which are accessible by the iUICC module 120. In embodiments where the secure execution environment 1 15 is implemented using ME circuitry, the iUICC storage 125 (including the profiles 375 and/or other sensitive data) may be implemented in one or more memory devices embedded in the ME circuitry.

As shown, the iUICC storage 125 may store profiles 375 (individual ones of the profiles 375 may be referred to as a "profile 375" or "N profile 375" where N is a name of the profile). Each of the profiles 375 may be a combination of a file structure, data, and applications, which when enabled allows the computing platform 200 to access a specific network infrastructure of the network 135 or specific services provided by service provider 145. The service provider 145 and the network operator 150 may each have a corresponding profile 375 within the secure execution environment 1 15. An example arrangement of the profiles 375 is shown by FIG. 2.

Referring now to FIG. 2, FIG. 2 shows example logical components and interaction points between components of profiles 375A-B, components of the iUICC module 120, and the iUICC proxy 1 10. In the example embodiment shown by FIG. 2, the profile 375A may be owned by or otherwise associated with the network operator 150, and the profile 375B may be owned by or otherwise associated with the service provider 145. Profile 375A may comprise an ISD-P 243A, an owner security domain (OSD) 250, a file system element 215A, an NAA (or SIM) 220A, one or more applications 225A, user data 230A, credentials 235A, and a policy 260A. Profile 375B may comprise an ISD-P 243B, an OSD 245, a file system element 215B, an NAA (or SIM) 220B, one or more applications 225B, user data 230A, credentials 235B, and a policy 260B. One or more of the listed elements, for example, the credentials 23 A or 235B, may be optional and may not be included in other embodiments. Although not shown by FIG. 2, each of the profiles 375A-B may include one or more other elements as defined by the GlobalPlatform Card specifications, GSMA standards, and/or any other like standard. The iUICC module 120 may comprise an iUICC bridge 210, an ISD-R 240, and a CASD 255.

As mentioned previously, the iUICC proxy 1 10 may provide messages/commands/data from the iUICC module 120 to untrusted applications or components, and provide messages/commands/data to the iUICC module 120 from untrusted applications or components. To perform these functions, the iUICC proxy may interact with iUICC bridge 210 within the iUICC enclave. The iUICC bridge 210 may receive messages/commands/data from the iUICC module 120 and transmit the messages/commands/data to the iUICC proxy 1 10. The iUICC bridge 210 may also receive other messages/commands/data from the iUICC proxy 110 and provide the other messages/commands/data to the iUICC module 120. The iUICC bridge 210 may communicate messages/commands/data with the ISD-R 240.

The ISD-R 240 may be an entity that represents the remote provisioning service 140 and may perform platform management functions with the ISD-Ps 243A-B. The platform management functions may include ISD-P creation, wherein an association between the ISD-R 240 and an ISD-P 243 is created; ISD-P deletion functions; profile enabling and disabling; fallback attribute setting; transport functions, such as creating secure channels between the entities of the remote provisioning service 140 and one of ISD-Ps 243A-B. For example, a secure channel may be established between ISD-R 240 and the SM-SR 165 over an ESS interface (not shown). This secure channel may be established according to secure channel protocol (SCP) 80 and/or SCP81 as defined in ETSI standards or other like specifications. To establish the secure channel, the ISD-R 240 may have a key set used to encrypt/decrypt messages sent to/from the SM-SR 165, for example. The ISD-R 240 and its associated key sets may be provisioned within the iUICC module 120 during provisioning of the iUICC module 120. Additionally, the ISD-R 240 may provide certificates received from the entities of arrangement 100 for verification, and may receive signed messages from the CASD 255 to be provided to the entities in the arrangement 100.

The CASD 255 may be an entity that represents the CI 155, and which performs various security related functions including signing messages, verifying received certificates, and the like. The CASD 255 may be provisioned within the iUICC module 120 during provisioning of the iUICC module 120. The CASD 255 may be personalized by the iUICC module developer/owner or the remote provisioning service 140 during the construction or provisioning of the iUICC module 120. The term "personalization" may refer to provisioning the CASD 255 with certificates that are unique to the iUICC module 120 prior to provisioning the iUICC module 120 in the computing platform 200. In embodiments, the personalization may include provisioning the CASD 255 with a public key (P .CI.ECDSA) part of a Root Certificate used on the iUICC module 120 to verify certificates issued by the CI 155; a secret key for the CASD (S .ECASD.EC A), which may be used to sign messages; a CASD Elliptic Curve cryptography Key Agreement algorithm (ECKA) key certificate (CERT.ECASD.ECKA) to be used for iUICC module authentication and key establishment; a remote provisioning key set for key renewal; and an iUICC identifier (ID) that is unique to the iUICC module 120. In addition, in some embodiments only the ISD-R 240 and ISD-Ps 243A-B may be able to use the CASD services via the ISD-R 240.

The ISD-Ps 243A-B may be security domains that represent the remote provisioning service 140 while being unique to the profile in which they are established. The ISD-Ps 243A-B may be installed by the ISD-R 240 and then personalized by SM-DP 160. In some embodiments, at least one ISD-P 243 and another profile 375 (not shown by FIG. 2) may be installed and first personalized by the iUICC module developer/owner to allow for future iUICC connectivity. This other profile 375 may be a "provisioning profile," which is used solely for the purpose of connecting to a network and provisioning the computing platform 200 with one or more other profiles 375, such as the profiles 375A-B. The provisioning profile 375 may have at least an OSD, at least one NAA, a policy, and a file system that are the same or similar to those included in profiles 375A-B.

Components outside the ISD-Ps 243A-B may not have visibility or access to any profile components with the exception of the ISD-R 240, which may have read access to the policy 260A-B. Additionally, profile components may not have any visibility of, or access to, components outside their corresponding ISD-P 243A-B, and each ISD-P 243A- B may not have any visibility of, or access to, any other ISD-Ps. The ISD-Ps 243A-B may remain associated to the ISD-R 240 during their entire existence in order for the ISD-R 240 to be able to perform the platform management functions. Furthermore, a secure channel may be established between the SM-DP 160 and the ISD-Ps 243 A-B over an ES8 interface, which may overlap or tunnel through the ES5 interface. This secure channel may be established using SCP03 or SCP03t as defined in GlobalPlatform Card specifications or other like specifications.

The OSD-A 250 is a security domain owned by network operator 150 and is used for providing a secured channel to the network operator's network infrastructure (for example, one or more network elements within network 135). The secure channel may be established between the network operator 150 and OSD-A 250 over an ES6 interface, and may be established using SCP80 and/or SCP81 as defined by GlobalPlatform Card or ETSI specifications. The OSD-B 245 is a security domain owned by the service provider 145, which is used for providing a secured channel to one or more services provided by the service provider 145. The secure channel may be established between the service provider 145 and OSD-B 245 over the ES6 interface or another like interface using SCP80, SCP81 , or some other SCP. For establishment of the secure channels, the OSD-A 250 may include key information and certificates used to access the network operator 150's infrastructure, and the OSD-B 245 may include key information and certificates used to access the services of the service provider 145. The key information may include a secret key ( i), an authentication key, and other keys for encrypting/decrypting communications with the network operator 150 or service provider 145. The certificates may be data required within a secure execution space of the iUICC module 120 so that a profile downloaded from an external entity (for example, remote provisioning service 140) can be decrypted and installed in the secure execution environment 115, or used to attest to the ownership of one or more keys. The certificates may include the various certificates issued by the CI 155 as delineated by the relevant GSMA standards, ETSI standards, GlobalPlatform standards, or any other like standards. In some embodiments, the OSD-A 250 and/or OSD-B 245 may optionally include one or more PINs and one or more PU s.

The file systems 215A-B may a hierarchically organized structure that controls how data is to be stored within the profiles 375A-B. The file systems 215A-B may comprise three types of files, a master file (MF), dedicated files (DFs), and elementary files (EFs). The MF is the root of the file system. DFs may be subordinate directories of the MF, and EFs may include various types of data, structured as either a sequence of data bytes, a sequence of fixed-size records, or a fixed set of fixed-size records used cyclically.

The NAAs (or SIMS) 220A-B may be an application that is used to access the network 135 or one or more servers of service provider 145. The NAAs 220A-B may use stored user data and keys to authenticate the computing platform 200 and access network 135 and/or services of service provider 145 in accordance with the stored policy 260A-B. In one example, NAA 220A may use a stored IMSI and Ki to authenticate the computing platform 200 and access network 135 when the network 135 is an LTE or UMTS network. In another example, NAA 220B may use a stored subscription information and a secret key to authenticate the computing platform 200 to access the services provided by the service provider 145. In embodiments, the profiles 375 may include multiple MNO profiles for accessing a corresponding MNO network. For example, a first NAA 220A or profile 375 A may be a Universal Mobile Telecommunications System (UMTS) SIM (USIM) when a network operator 150 owns or controls a UMTS or LTE network; a second NAA 220A or profile 375 A may be a Global System for Mobile Communications (GSM) SIM (GSIM) when a network operator 150 owns or controls a GSM network; a third NAA 220A or profile 375A may be a an IP Multimedia Services (IMS) SIM (ISIM) when a network operator 150 owns or con!rols IMS services/applications; a fourth NAA 220A or profile 375A may be a CDMA SIM (CSIM) when a network operator 150 owns or controls a CDMA network; a fifth NAA 220A or profile 375 A may be a Worldwide Interoperability for Microwave Access (WiMAX) SIM (WiSIM) when the network operator 150 owns or controls a WiMAX network; and the like. Furthermore, the secure execution environment 1 15 may include different profiles 375 for accessing a network of a same type (not shown). For example, a first NAA 220A of a first profile 375A may correspond to a first USIM for accessing a first UMTS or LTE network provided by a first MNO, and a second NAA 220A of a second profile 375A may correspond to a second USIM for accessing a second UMTS or LTE network provided by a second MNO.

The one or more applications 225A-B may be applications that run inside secure execution environment 115 and may provide access to sensitive data stored in the profiles 375A-B (for example, user data 230A-B or credentials 235A-B) to one or more client applications outside of the profiles 375A-B or outside secure execution environment 115. For example, an application 225B may provide credentials 235B to a client application (for example, a banking application) implemented by a host architecture of the computing platform 200. Such an application 225B may interface with a GUI of the client application to receive a PIN or password, verify the PIN or password based on keys or credentials stored in the user data 230B or OSD-B 245, and provide credentials 235B to the client application upon proper verification of the PIN or password.

The user data 230A-B may be used to access network 135 or services provided by service provider 145. For example, the user data 230A may include an IMSI and (optionally) a phone number associated with the IMSI (for example, a Mobile Station International Subscriber Directory Number (MSISDN). The IMSI may be used to identify a user of the network 135 and may be used to obtain subscription information from a Home Location Register (HLR) or Visitor Location Register (VLR) within a core network of network 135. A phone number or MSISDN acts as an address for the computing platform 200 so that other devices may connect with the computing platform 200 for data transfers and/or voice communications. In another example, the user data 230B may include subscription information associated with service provider 145, such as name, address, phone number, account number or ID, and/or other like data.

Credentials 235A-B may be any sensitive data issued to the computing platform by a third party. In various embodiments, the credentials 235A-B may be associated with a payment card issued to consumers to pay for goods and services (for example, a credit card, charge card, debit card, electronic benefits transfer (EBT) cards, and the like). These credentials 235A-B may be a digital/electronic version of a physical payment card, or the credentials 235A-B may be digital/electronic payment credentials. The credentials 235A-B may also be stored in association with user data 230A-B, which may include a cardholder name, billing address, shipping address, payment card number, PIN and/or PU , verification codes, security questions and answers (e.g., cardholder birthdate, mother's maiden name, etc.), and the like. Turthermore, the credentials 235A-B and/or user data 230A-B may include authorization information in accordance with EMV (Europay, MasterCard, and Visa) standards, which define worldwide interoperability and acceptance standards for secure card-present and card-not-present transactions. Moreover, in some embodiments, the credential 235A-B may include virtual currency information (for example, Amazon Coins®, Nintendo Points®, Facebook® Credits, frequent flyer miles associated with one or more airlines, brick- and-mortar store rewards points, Linden Dollars traded in the virtual online community Second Life®, one or more currencies exchanged in World of Warcraft®, and/or the like), cryptocurrency information (for example, bitcoins, litecoins, and the like) and/or other like information used as a medium of exchange. In such embodiments, the credentials 235A-B may be stored within one or more digital wallets (for example, a bitcoin wallet and the like) and/or any other like mechanism for storing information necessary to account for digital currency transactions. These digital wallets may be implemented using the file systems 215A-B.

The policies 260A-B may define a set of rules that govern the behavior of the iUICC module 120 and/or entities involved in the remote management of the iUICC module 120. The rules may define one or more actions and the conditions under which the actions are executed. For example, policy 260A may define actions to take when the profile 375 A cannot be properly enabled or is unable to access or attach to network 135, and policy 260B may define actions to take when the profile 375B cannot be properly enabled or is unable to access network elements associated with the service provider 145. In another example, policies 260A-B may define actions to take when an incorrect password or PIN is obtained via an application 225A-B.

The arrangement shown by FIG. 2 may be implemented according to one or more of the following non-limiting use cases.

In a first use case, service provider 145 may be a bank or other like financial institution and the computing platform 200 may be implemented in a smartphone. In this case, profile 375B may be associated with the bank. The credentials 235B may be credit card information, debit card information, checking account information, and the like. NAA 220B may use stored user data 230B (for example, name address, phone number, and the like), a i, and payment credential information to authenticate the computing platform 200 to access the bank's banking infrastructure in accordance with policy 260B. Access to the bank's banking infrastructure may allow the user to deposit electronic checks and/or pay for goods and services using funds from the user's account(s). Furthermore, profile 375B may include one or more other applications 225B that allow untrusted applications (for example, mobile payment applications or money transfer applications operated by a host application processor) to access the payment credentials 235B, which could be used to pay for products and services.

In a second use case, service provider 145 may be a security firm and the computing platform 200 may be implemented in a security camera or in a home server associated with one or more security cameras. The security cameras may be purchased by a consumer and installed in the consumer's residence. In this case, the profile 375B associated with the security firm may include an NAA 220B that uses stored subscription information and a first Ki to create a secure channel with the security firm's servers in accordance with the policy 260B. The secure channel may be used to send video data streams from the security cameras to the security firm's servers. Furthermore, the security firm could select a network operator 150 to provide communications services for receiving the video data streams or setting up the secure channel, and the network operator 150 may be different than a network operator used by the consumer for his own telephone and data services. In this case, the NAA 220A of profile 375A may use a stored IMSI and a second Ki to attach to network 135 in accordance with the policy 260A. Furthermore, the profile 375B may include credentials 235B that may be used to charge the consumer for the security services, while the profile 375A may include credentials 235A that may be used to charge the security firm for communication services.

In a third use case, a consumer may purchase a new vehicle and the vehicle may include a number of vehicle-based services delivered over network 135 to the vehicle and its occupants. In this case, the computing platform 200 may be implemented in an I VI device, an ICE device, a V2V system, or V2X system. The services may be delivered whether the vehicle is mobile or stationary, and whether or not the vehicle is in the country in which the vehicle was purchased. The NAA 220A of the profile 375A may be used to access the network 135 in a similar manner as discussed previously. The vehicle manufacturer or a subcontractor may act as the service provider 145, providing vehicle related services (such as engine and/or vehicle component monitoring) and/or act as a broker for services supplied by other service providers (such as infotainment or roadside assistance). The NAA 220B of the profile 375B may be used to access the vehicle manufacturer's servers in a similar manner as discussed previously. Another NAA 220 of another profile 375 (not shown by FIG. 2) may be used to access the servers of another service provider (such as the infotainment provider or roadside assistance provider) in a similar manner as discussed previously. The subscriptions for these services may begin at the time the vehicle is purchased, and may be operational as the customer drives the vehicle away. The credentials 235A may be used for charging the service provider 145 for network access, the credentials 235B may be used for charging the consumer for the vehicle related services, and credentials in the other profile 375 may be used for charging the consumer for the other services (such as the infotainment or roadside assistance). In this way, the subscription management may be automated for a contracted number of subscriptions between the service provider 145 and the network operator 150. Furthermore, the consumer may not know which network operator 150 is providing communication services, and may have a contract for cellular communications services with a different network operator 150.

In a fourth use case, service provider 145 may contract with multiple property management companies (PMCs) to provide utility meter reading and energy saving optimization services for various buildings. The service provider 145 may have commercial contracts with each PMC to supply/install meters in the various buildings, provide regular meter readings to a utility company once the meters have been installed, and make payments to the utility company on behalf of each PMC. In this case, the computing platform 200 may be implemented in one or more meters or sensors. Additionally, each PMC may be responsible for selecting and contracting with a network operator 150 to provide communication services for the meters in their buildings. Prior to installation of the meters, service provider 145 may have arranged for the computing platforms 200 to be provisioned with multiple profiles 375A, each of which corresponds to a different network operator 150. When a desired network operator 150 is selected, the service provider 145 may arrange for the meters to be installed and to begin the meter reading services. To begin the communication services once the meters are installed, the service provider 145 or the PMC may utilize the remote provisioning service 140 to enable a profile 375A associated with the desired network operator 150 and/or disable other profiles 375A associated with the undesired network operators 150. In the event that the PMC wishes to switch cellular providers, the service provider 145 or the PMC may utilize the remote provisioning service 140 to enable a different profile 375 A and disable the profile 375A of the previous network operator 150. The credentials 235A in the enabled profile 375 A may be used to charge the PMC for the communications services of the meters. Furthermore, NAA 220B of a profile 375B may be used to provide meter readings to servers of the service provider 145, and credentials 235B may be used to charge the PMC for these services.

Referring back to FIG. 1 , the remote provisioning service 140 may be a collection of devices and/or systems that are utilized to provision the iUICC module 120 and one or more profiles 375 within the secure execution environment 1 15. The terms "to provision" or "provisioning" may refer to the downloading and storing of the iUICC module 120, one or more profiles, and/or one or more applications. The remote provisioning service 140 may provision profiles or applications in a secure memory space associated with the iUICC module 120 using OTA interfaces. Traditional UICCs are provisioned during manufacture of the UICC with a network provider profile, which is used for accessing a single network. In order to access a different network, a UICC must be physically replaced with a new UICC. eUICCs were developed to contain multiple profiles or "eSIMS," each of which is associated with a different service provider. eUICCs are capable of being remotely provisioned with new profiles OTA and can be programmed OTA to use a specific profile or change profile at any time without the need for physically replacing the eUICC. However, the number and types of profiles provisioned on the eUICCs may be limited since eUICCs have relatively little storage space and relatively slow processor speeds as compared to storage space and processor speeds of application processors and associated storage devices.

The remote provisioning service 140 may generate profiles 375 on behalf of network operator 150 and/or service provider 145, manage and execute policies associated with the profiles 375, and securely route profiles 375 to the secure execution environment 1 15. In order to provision the iUICC module 120 with a profile 375, the remote provisioning service 140 may communicate data OTA with communications circuitry 105, and such data may be provided to the iUICC module 120 via the iUICC proxy 1 10. In embodiments where the secure execution environment 115 is implemented using secure enclaves, the remote provisioning service 140 may establish the iUICC enclave, cause the iUICC module 120 to be loaded into the iUICC enclave, initialize the iUICC enclave, and provision the iUICC proxy 110 in the application circuitry or ME circuitry of the computing platform 200. In other embodiments, separate entities may be responsible for establishing/loading/initializing the iUICC enclave and provisioning the iUICC proxy 110. For example, the EAES 175 may be involved with the establishment and verification of the iUICC enclave, as well as the loading of the iUICC module 120 into the iUICC enclave; SAS 170 may be involved with the provisioning and verification of the iUICC proxy 1 10 within ME circuitry of the computing platform 200; and the SM-DP 160 and SM-SR 165 of the remote provisioning service 140 may be involved with the provisioning of profiles 375 within the secure execution environment 1 15.

For purposes of provisioning the iUICC proxy 110 within ME circuitry of the computing platform 200, the remote provisioning service 140 may include a security assist server (SAS) 170, which is a platform that creates authenticated certificates to be used by ME circuitry. The SAS 170 may have secure access to the ME circuitry via an end-to-end encrypted tunnel between the ME circuitry and the SAS 170. The SAS 170 may have access to a cryptographic private key, whose public component is embedded in ME circuitry firmware. In some embodiments, the SAS 170 may create and/or sign certificates that the ME circuitry can authenticate as having originated from the SAS 170. The SAS 170 may provide the ME circuitry with a signed certificate that includes hardware override information, which may instruct the ME circuitry to override any embedded tamper- resistant hardware devices. The hardware override information may allow the ME circuitry to download and install program code for the iUICC proxy 110. The signed certificate may also include information pertaining to a certificate chain of the SAS 170.

For purposes of establishing the iUICC enclave, the remote provisioning service may include an enclave attestation and enrollment server (EAES) 175. The EAES 175 may provide enclave development tools/code for enclave developers and may also provide enclave-based attestation services. The enrollment portion of the EAES 175 may allow enclave developers to enroll or register their enclaves and/or modules for attestation purposes. For example, an iUICC enclave/module developer may register their iUICC enclave with the EAES 175. For registration, the iUICC enclave developer may generate an asymmetric key pair. The private key portion of the key pair may be used to sign the iUICC enclave binary while the corresponding public key portion of the key pair may be provided to the EAES 175 for addition to a registered enclave whitelist. This whitelist may be stored securely in the EAES 175. Whenever an untrusted application or component tries to launch or execute the iUICC module 120 inside the iUICC enclave, the iUICC enclave may perform an attestation procedure with the attestation portion of the EAES 175 using keys and credentials provisioned in the host architecture during manufacture of the computing platform 200 or shortly thereafter.

The attestation portion of the EAES 175 may perform the attestation procedure in response to activation of the iUICC enclave by untrusted applications or untrusted components of the computing platform 200. Attestation is a processor-based mechanism of demonstrating that an enclave (for example, the iUICC enclave) has been properly instantiated or activated on a computing platform (for example, computing platform 200) and is securely running within an enclave (for example, the iUICC enclave). An example of the attestation process is shown and described with regard to FIG. 13. In other embodiments, the iUICC enclave may include the iUICC module 120 and a separate iUICC loader. The iUICC loader may attest to the EAES 175 and receive the whitelist of approved enclaves, keys and credentials. When loading the iUICC module 120, the iUICC loader may verify the iUICC module 120 by referencing the whitelist. In various embodiments, the iUICC module 120 may also be encrypted, in which case the iUICC loader may use keys provisioned by the EAES 175 to decrypt the iUICC module 120.

For purposes of provisioning the iUICC module 120 within the iUICC enclave, the remote provisioning service 140 may include SM-DP 160 and SM-SR 165. The SM-DP 160 may be an entity that generates, prepares and packages the profiles 375 for provisioning, and manages the download and installation of the profiles 375 into the secure execution environment 115 of the iUICC module 120. The SM-SR 165 may be an entity that securely performs the functions of enabling, disabling, and deleting profiles from the secure execution environment 1 15 of the iUICC module 120. The functions may be performed according to instructions or commands from the SM-DP 160. The SM-SR 165 may also establish a secure channel to the iUICC enclave in order to carry out these functions.

Once the attestation process for the iUICC module 120 and the iUICC proxy 110 has been successfully completed, and the iUICC module 120 has been properly provisioned with profiles 375, the iUICC module 120 may send a message to the communications circuitry 105 indicating that the iUICC module 120 is initialized and ready to establish a trusted channel with one or more network elements.

In some embodiments, one or more servers may perform the operations described herein relating to the SAS 170, the EAES 175, the SM-DP 160, and/or the SM-SR 165 depending upon implementation and deployment of infrastructure and/or any other requirements or considerations. For instance, the SAS 170, the EAES 175, the SM-DP 160, and/or the SM-SR 165 may be implemented in a single server, or the SAS 170, the EAES 175, the SM-DP 160, and the SM-SR 165 may be implemented in their own separate servers, each of which may be operated or controlled by separate entities. In an example, the SAS 170 may be combined with (or perform the functions of) the EAES 175. In this example, a first end-to-end encrypted tunnel may be established between the iUICC enclave and an SAS 170 for provisioning the iUICC module 120 and/or profiles 375, and a second end-to-end encrypted tunnel may be established between the ME circuitry and the SAS 170 to facilitate a provisioning of the iUICC proxy 1 10, wherein the first end-to-end encrypted tunnel is independent from the second end-to-end encrypted tunnel. Furthermore, in FIG. 1 the remote provisioning service 140 is shown as being a standalone entity that is separate from the other entities of the arrangement 100. However, in some embodiments the functions and operations of the remote provisioning service 140 may be executed by or incorporated into any other suitable device. For example, the remote provisioning service 140 may be incorporated into one or more core network elements associated with network 135.

The CI 155 (also referred to as a "certificate authority" or "CA") is an entity that issues digital certificates to the remote provisioning service 140, the service provider 145, the network operator 150, and the iUICC module 120 and acts as a trusted root for the purpose of authentication of the entities of the arrangement 100. The CI 155 is responsible for securely obtaining the public keys of each party, and for issuing a certificate that binds each entity's identity to their public keys. In embodiments, the CI 155 may issue certificates to each of the entities /components in the FIGS. 1-2 and to the various components of the computing platform 200 as shown and described with regard to FIGS. 3-8. These certificates may include one or more of the following: a subject of the certificate, which is the party to which the certificate is issued and the owner of the public key; an issuer ID, which identifies the entity that has signed and issued the certificate (for example, a CI 155); a validity period, which is a time limit for the validity of the message; subject public key information, which includes the public owned by a subject of the certificate and the algorithm with which the key is used; a usage identifier that indicates the intended use or purpose of the certificate; a certificate issuer (CI 155) signature; a public key owned by the CI 155; a random value or nonce; and/or other like information. The certificate issuer signature may be a hash encrypted using a private key owned by the CI 155, which indicates that the public key in the certificate belongs to the CI 155. The certificate message may also include an identifier for the certification policy of the CI 155, which summarizes the means taken by the CI 155 to ensure the authenticity of the subject's public key. In various embodiments, the digital certificates discussed herein may be signed using an Elliptic Curve cryptography Digital Signature Algorithm (ECDSA), and the various key pairs discussed herein may be generated using an Elliptic Curve cryptography Key Agreement algorithm (ECKA).

In embodiments, the CI 155 may issue or install a package of keys and certificates within the iUICC module 120 during provisioning of the iUICC module 120. This package may be the CASD 255 shown by FIG. 2. The digital certificates issued by the CI 155 may certify the ownership of a public key owned by the entities in arrangement 100. The digital certificates issued by the CI 155 may include a self-signed Root Certificate used to verify certificates issued and signed by the CI 155; the PK. CI. ECDSA part of the Root Certificate used on the iUICC module 120 to verify certificates issued by the CI 155; an SM-DP certificate (CERT.DP.ECDSA), which is signed by the CI 155 and used to authenticate the SM-DP 160 such as during a "Load and Install Profile" procedure; an SM-SR certificate (CERT.SR.ECDSA), which is signed by the CI 155 to authenticate the SM-SR 165; and a remote provisioning certificate (also referred to as a manufacturer certificate) signed by the CI 155 to authenticate the remote provisioning service 140 and/ or a developer of the iUI CC module 120, and which may be used in the "Download and Install Profile" procedure (see, for example, the example embodiment described with regard to FIG. 17). Using the remote provisioning certificate, the remote provisioning service 140 and/or the iUICC module developer may issue an iUICC certificate, which is specific to the iUICC module 120 and signed by the remote provisioning service 140 and/or the iUICC module developer. The iUICC certificate may include a CASD public key (PK.ECASD.ECKA), which may be used for an ECKA; the iUICC ID; and other like information. As mentioned previously, the CASD 255 may also include the SK.ECASD.ECKA, the PK.CI.ECDSA, the CERT.ECASD.ECKA, the remote provisioning key set, and the iUICC ID.

Referring back to FIG. 1 , service provider 145 may be one or more hardware computing devices that may include one or more servers or other like network elements for providing one or more services for the computing platform 200. In this regard, service provider 145 may communicate (for example, transmit and receive) data with iUICC proxy 1 10, and thus, may communicate with iUICC module 120 securely and indirectly through the iUICC proxy 1 10. The services provided by the service provider 145 may include banking or financial services; ticketing/transportation services; security/safety services (for example, video surveillance, burglary monitoring, fire/smoke monitoring, and the like); multimedia services (for example, mobile TV or music streaming services); energy usage analytics and automation services (for example, utility meter reading, analysis, and reporting); medical and/or athletic performance analytics and analysis; and/or any other like services. To provide the one or more services, the service provider 145 may generate subscription information and a key pair for subscribers (for example, a user of the computing platform 200). The public key portion of the key pair, a key generation algorithm, and the subscription information may be loaded or placed into a service-provider profile 375 by the service provider 145 and/ or the remote provisioning service 140. The service-provider profile 375 may then be provisioned in the secure execution environment 115 according to the example embodiments discussed herein. The corresponding private key portion of the key pair may be stored locally in association with the subscriber information by the service provider, or provided to the remote provisioning service 140 for addition to a registered subscriber list. When the computing platform 200 attempts to access the one or more services, the service provider may use the information loaded into the service provider profile 375 to authenticate the computing platform 200.

Remote provisioning service 140, service provider 145, network operator 150, CI 155, SM-DP 160, SM-SR 165, SAS 170, and EAES 175 may each employ one or more servers and/or one or more associated data storage devices (not shown). The servers may include one or more systems and/or applications for providing one or more services for a client device (for example, the computing platform 200) or devices. In providing the one or more services, the servers may be able to generate content such as text, graphics, audio, and/ or video to be transferred to a computing device, such as computing platform 200. The content may be served to the devices by a web server in the form of HTML, XML, ASP, MPEG-DASH, Java™, JSP, PHP, and/or any other appropriate structured language or server-side scripting language. The servers may include an operating system that may provide executable program instructions for the general administration and operation of servers, and may include a computer-readable medium storing instructions that, when executed by a processor of the servers, may allow the servers to perform their intended functions. Suitable implementations for the operating system and general functionality of servers are known or commercially available, and are readily implemented by persons having ordinary skill in the art. Additionally, each of the servers may be a single physical hardware device, or may be physically or logically connected with other network devices, such that the servers may reside on one or more physical hardware devices. Moreover, each of the servers may be connected to, or otherwise associated with, one or more data storage devices (not shown).

Network 135 may be any network that allows computers to exchange data. Network 135 may include one or more network elements (not shown) capable of physically or logically connecting computers. The network 135 may include any appropriate network, including an intranet, the Internet, a cellular network, a local area network (LAN), a wide area network (WAN), a personal network or any other such network or combination thereof. Components used for such a system can depend at least in part upon the type of network and/or environment selected. Protocols and components for communicating via such a network are well known and will not be discussed herein in detail. Communication over the network 135 may be enabled by wired or wireless connections, and combinations thereof. Network 135 may be associated with network operator 150 who owns or controls equipment and other elements necessary to provide network-related services, such as one or more base stations or access points, and one or more servers for routing digital data or telephone calls (for example, a core network or backbone network).

FIG. 3 illustrates example components of a computing platform 200. In embodiments, the computing platform 200 may be, implement, be incorporated into, or otherwise be a part of a computer device having an architecture similar to any of the architectures described herein such as, for example, those described in FIGS. 4-8. In some embodiments, the computing platform 200 may include application circuitry 302, modem circuitry 305, and one or more antennas 310 coupled together at least as shown. The modem circuitry 305 may include baseband circuitry 304, radio frequency (RF) circuitry 306, and front-end module (FEM) circuitry 308 coupled together at least as shown.

The application circuitry 302 may include one or more application processors. For example, the application circuitry 302 may include circuitry such as, but not limited to, one or more single-core or multi-core processors 302a. The processors) 302a may include any combination of general-purpose processors and dedicated processors (e.g., graphics processors such as a graphics processing unit (GPU) or a mobile video card, application processors, management engines, etc.). The processors 302a may be coupled with and/or may include one or more memory/storage devices 302b (also referred to as "memory 302b" or "computer-readable medium 302b") and may be configured to execute instructions or program code stored in the memory/storage 302b to enable various applications and/or operating systems to run on the system. In such embodiments, the processors may be configured to operate a secure execution environment and/or one or more secure enclaves as described herein.

The modem circuitry 305 may be any hardware device that modulates carrier wave signals to include digital data for transmission and demodulates modulated carrier wave signals to obtain digital data. According to various embodiments, the modem circuitry 305 may be a mobile broadband modem, which modulates/demodulates signals in accordance with one or more mobile communications standards, such as Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), Universal Mobile Telecommunications System (UMTS), Long Term Evolution (LTE) and LTE Advanced (LTE-A), Evolution-Data Optimized (EVDO), Wi-Fi including one or more Institute of Electrical and Electronics Engineers (IEEE) 802.1 1 and 802.15 protocols, Worldwide Interoperability for Microwave Access (WiMAX), code division multiple access (CDMA), Bluetooth or Bluetooth low energy (BLE), and/or any other wireless communication protocols, including RF-based, optical, and so forth.

The baseband circuitry 304 may include circuitry such as, but not limited to, one or more single-core or multi-core processors. The baseband circuitry 304 may include one or more baseband processors and/or control logic to process baseband signals received from a receive signal path of the RF circuitry 306 and to generate baseband signals for a transmit signal path of the RF circuitry 306. Baseband circuitry 304 may interface with the application circuitry 302 for generation and processing of the baseband signals and for controlling operations of the RF circuitry 306. For example, in some embodiments, the baseband circuitry 304 may include a second generation (2G) baseband processor 304a, third generation (3G) baseband processor 304b, fourth generation (4G) baseband processor 304c, and/or other baseband processors ) 304d for other existing generations, generations in development or to be developed in the future (e.g., fifth generation (5G), 6G, etc.). The baseband circuitry 304 (e.g., one or more of baseband processors 304a-e) may handle various radio control functions that enable communication with one or more radio networks via the RF circuitry 306. The radio control functions may include, but are not limited to, signal modulation/demodulation, encoding/decoding, radio frequency shifting, and the like. In some embodiments, modulation/ demodulation circuitry of the baseband circuitry 304 may include Fast-Fourier Transform (FFT), precoding, and/or constellation mapping/demapping functionality. In some embodiments, encoding/decoding circuitry of the baseband circuitry 304 may include convolution, tail-biting convolution, turbo, Viterbi, and/or Low Density Parity Check (LDPC) encoder/decoder functionality. Embodiments of modulation/demodulation and encoder/decoder functionality are not limited to these examples and may include other suitable functionality in other embodiments.

In some embodiments, the baseband circuitry 304 may include elements of a protocol stack such as, for example, elements of an evolved universal terrestrial radio access network (EUTRAN) protocol including, for example, physical (PHY), media access control (MAC), radio link control (RLC), packet data convergence protocol (PDCP), and/or radio resource control (RRC) elements. A central processing unit (CPU) 304e of the baseband circuitry 304 may be configured to run elements of the protocol stack for signaling of the PHY, MAC, RLC, PDCP and/or RRC layers. In some embodiments, the baseband circuitry 304 may include one or more audio digital signal processor(s) (DSP) 304f. The audio DSP(s) 304f may be include elements for compression/decompression and echo cancellation and may include other suitable processing elements in other embodiments.

The baseband circuitry 304 may further include memory/storage 304g (also referred to as "memory 304g" or "computer-readable media 304g"). The memory /storage 304g may be used to load and store data and/or instructions for operations performed by the processors of the baseband circuitry 304. Memory/storage for one embodiment may include any combination of suitable volatile memory and/or non-volatile memory. The memory/storage 304g may include any combination of various levels of memory/storage including, but not limited to, read-only memory (ROM) having embedded software instructions (e.g., firmware), random access memory (e.g., dynamic random access memory (DRAM)), cache, buffers, etc. The memory /storage 304g may be shared among the various processors or dedicated to particular processors.

Components of the baseband circuitry 304 may be suitably combined in a single chip or a single chipset, or disposed on a same circuit board in some embodiments. In some embodiments, some or all of the constituent components of the baseband circuitry 304 and the application circuitry 302 may be implemented together such as, for example, on a system on a chip (SoC).

In some embodiments, the baseband circuitry 304 may provide for communication compatible with one or more radio technologies. For example, in some embodiments, the baseband circuitry 304 may support communication with an evolved universal terrestrial radio access network (EUTRAN) and/or other wireless metropolitan area networks (WMAN), a wireless local area network (WLAN), a wireless personal area network (WPAN). Embodiments in which the baseband circuitry 304 is configured to support radio communications of more than one wireless protocol may be referred to as multi-mode baseband circuitry.

RF circuitry 306 may enable communication with wireless networks using modulated electromagnetic radiation through a non-solid medium. In various embodiments, the RF circuitry 306 may include switches, filters, amplifiers, etc. to facilitate the communication with the wireless network. RF circuitry 306 may include a receive signal path that may include circuitry to down-convert RF signals received from the FEM circuitry 308 and provide baseband signals to the baseband circuitry 304. RF circuitry 306 may also include a transmit signal path that may include circuitry to up- convert baseband signals provided by the baseband circuitry 304 and provide RF output signals to the FEM circuitry 308 for transmission.

In some embodiments, the RF circuitry 306 may include a receive signal path and a transmit signal path. The receive signal path of the RF circuitry 306 may include mixer circuitry 306a, amplifier circuitry 306b and filter circuitry 306c. The transmit signal path of the RF circuitry 306 may include filter circuitry 306c and mixer circuitry 306a. RF circuitry 306 may also include synthesizer circuitry 306d for synthesizing a frequency for use by the mixer circuitry 306a of the receive signal path and the transmit signal path. In some embodiments, the mixer circuitry 306a of the receive signal path may be configured to down-convert RF signals received from the FEM circuitry 308 based on the synthesized frequency provided by synthesizer circuitry 306d. The amplifier circuitry 306b may be configured to amplify the down-converted signals, and the filter circuitry 306c may be a low-pass filter (LPF) or band-pass filter (BPF) configured to remove unwanted signals from the down-converted signals to generate output baseband signals. Output baseband signals may be provided to the baseband circuitry 304 for further processing. In some embodiments, the output baseband signals may be zero-frequency baseband signals, although this is not a requirement. In some embodiments, mixer circuitry 306a of the receive signal path may comprise passive mixers, although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 306a of the transmit signal path may be configured to up-convert input baseband signals based on the synthesized frequency provided by the synthesizer circuitry 306d to generate RF output signals for the FEM circuitry 308. The baseband signals may be provided by the baseband circuitry 304 and may be filtered by filter circuitry 306c. The filter circuitry 306c may include a low-pass filter (LPF), although the scope of the embodiments is not limited in this respect.

In some embodiments, the mixer circuitry 306a of the receive signal path and the mixer circuitry 306a of the transmit signal path may include two or more mixers and may be arranged for quadrature downconversion and/or upconversion respectively. In some embodiments, the mixer circuitry 306a of the receive signal path and the mixer circuitry 306a of the transmit signal path may include two or more mixers and may be arranged for image rejection (e.g., Hartley image rejection). In some embodiments, the mixer circuitry 306a of the receive signal path and the mixer circuitry 306a of the transmit signal path may be arranged for direct downconversion and/or direct upconversion, respectively. In some embodiments, the mixer circuitry 306a of the receive signal path and the mixer circuitry 306a of the transmit signal path may be configured for super-heterodyne operation.

In some embodiments, the output baseband signals and the input baseband signals may be analog baseband signals, although the scope of the embodiments is not limited in this respect. In some alternate embodiments, the output baseband signals and the input baseband signals may be digital baseband signals. In these alternate embodiments, the RF circuitry 306 may include analog-to-digital converter (ADC) and digital-to-analog converter (DAC) circuitry and the baseband circuitry 304 may include a digital baseband interface to communicate with the RF circuitry 306.

In some dual-mode embodiments, a separate radio IC circuitry may be provided for processing signals for each spectrum, although the scope of the embodiments is not limited in this respect.

In some embodiments, the synthesizer circuitry 306d may be a fractional-N synthesizer or a fractional N/N+l synthesizer, although the scope of the embodiments is not limited in this respect as other types of frequency synthesizers may be suitable. For example, synthesizer circuitry 306d may be a delta-sigma synthesizer, a frequency multiplier, or a synthesizer comprising a phase-locked loop with a frequency divider.

The synthesizer circuitry 306d may be configured to synthesize an output frequency for use by the mixer circuitry 306a of the RF circuitry 306 based on a frequency input and a divider control input. In some embodiments, the synthesizer circuitry 306d may be a fractional N/N+l synthesizer.

In some embodiments, frequency input may be provided by a voltage controlled oscillator (VCO), although that is not a requirement. Divider control input may be provided by either the baseband circuitry 304 or the application processor 302 depending on the desired output frequency. In some embodiments, a divider control input (e.g., N) may be determined from a look-up table based on a channel indicated by the application processor 302.

Synthesizer circuitry 306d of the RF circuitry 306 may include a divider, a delay- locked loop (DLL), a multiplexer and a phase accumulator. In some embodiments, the divider may be a dual modulus divider (DMD) and the phase accumulator may be a digital phase accumulator (DPA). In some embodiments, the DMD may be configured to divide the input signal by either N or N+l (e.g., based on a carry out) to provide a fractional division ratio. In some example embodiments, the DLL may include a set of cascaded, tunable, delay elements, a phase detector, a charge pump and a D-type flip-flop. In these embodiments, the delay elements may be configured to break a VCO period up into Nd equal packets of phase, where Nd is the number of delay elements in the delay line. In this way, the DLL provides negative feedback to help ensure that the total delay through the delay line is one VCO cycle.

In some embodiments, synthesizer circuitry 306d may be configured to generate a carrier frequency as the output frequency, while in other embodiments, the output frequency may be a multiple of the carrier frequency (e.g., twice the carrier frequency, four times the carrier frequency) and used in conjunction with quadrature generator and divider circuitry to generate multiple signals at the carrier frequency with multiple different phases with respect to each other. In some embodiments, the output frequency may be a LO frequency (fLO). In some embodiments, the RF circuitry 306 may include an IQ/polar converter.

FEM circuitry 308 may include a receive signal path that may include circuitry configured to operate on RF signals received from one or more antennas 310, amplify the received signals and provide the amplified versions of the received signals to the RF circuitry 306 for further processing. FEM circuitry 308 may also include a transmit signal path which may include circuitry configured to amplify signals for transmission provided by the RF circuitry 306 for transmission by one or more of the one or more antennas 310. In some embodiments, the FEM circuitry 308 may include a TX/RX switch to switch between transmit mode and receive mode operation. The FEM circuitry 308 may include a receive signal path and a transmit signal path. The receive signal path of the FEM circuitry 308 may include a low-noise amplifier (LNA) to amplify received RF signals and provide the amplified received RF signals as an output (e.g., to the RF circuitry 306). The transmit signal path of the FEM circuitry 308 may include a power amplifier (PA) to amplify input RF signals (e.g., provided by RF circuitry 306), and one or more filters to generate RF signals for subsequent transmission (e.g., by one or more of the one or more antennas 310).

In some embodiments, the computing platform 200 may include additional elements such as, for example, memory/storage, display or touchscreen device, near field communications (NFC) circuitry, network interface (NI) circuitry, an image capture device, one or more sensors (for example, an accelerometer, gyroscope, gravimeter, magnetometer, one or more biometric sensors, and/or another like devices), input/output (I/O) interface circuitry, and/or ME circuitry. The ME circuitry may be a dedicated microcontroller including a processor (for example, a cryptoprocessor), memory (for example, RAM and/or ROM), and an I/O interface. In some embodiments, the application circuitry 302 may include ME circuitry (for example, ME circuitry 302z shown and described with regard to FIGS. 4 and 6). In other embodiments, the modem circuitry 305 may include ME circuitry as described herein (for example, ME circuitry 304z shown and described with regard to FIG. 7).

FIG. 4 illustrates the components of a first implementation of the computing platform 200. As shown, the computing platform 200 includes application circuitry 302, modem circuitry 305, NFC circuitry 313, NI circuitry 315, I/O interface circuitry 345, and bus 320. Additionally, the application circuitry 302 may include processor 302a, bus 325, computer-readable media 302b (including both volatile memory 302b- 1 and non-volatile memory 302b-2), and ME circuitry 302z.

Computer-readable media 302b may be one or more hardware devices configured to store program code for one or more software components or modules. Memory 302b may be a computer-readable storage medium that generally includes a volatile memory 302b-l (for example, RAM, synchronous dynamic random access memory devices (SDRAM), double-data rate synchronous dynamic random access memory device (DDR SDRAM), flash memory, and the like), non-volatile memory 302b-2 (for example, ROM, solid state storage (SSS), NVRAM, and the like), and/or other like storage media capable of storing and recording data. Instructions, program code and/or software components may be loaded into memory 302b by one or more network elements (for example, remote provisioning service 140 and/or service provider 145) via network 135. In some embodiments, the software components may also be loaded from a separate computer- readable storage medium into memory 302b using a drive mechanism (not shown). Such separate computer-readable storage medium may include a memory card, memory stick, removable flash drive, memory card or secure digital (SD) card, and/or other like removable computer -readable storage medium (not shown).

During operation, memory 302b (volatile memory 302b- 1 and/or non-volatile memory 302b-2) may include instructions, program code, or modules for applications 350, host operating system (OS) 360, and secure execution environment 115. OS 360 may manage computer hardware and software resources and provide common services for various applications. OS 360 may include one or more drivers, such as display drivers, sensor drivers, audio drivers, USB drivers, modem circuitry drivers, NFC circuitry drivers, and NI circuitry drivers, a connection manager driver, and/or any other like drivers that provide an interface to hardware devices without needing to know the details of the hardware itself. The OS 360 may also include one or more libraries, which provide program code and/or software components for one or more applications to obtain and use the data from the secure execution environment 115 and/ or the ME circuitry 302z. In various embodiments, these libraries may be implemented as application programming interfaces (APIs), which allow application developers to use desired ones of the various software modules and/or software components of the libraries such that their applications may interact with the secure execution environment 1 15 and/or the ME circuitry 302z to obtain iUICC related data. The OS 360 may be a general purpose operating system or an operating system specifically written for and tailored to the computing platform 200.

In various embodiments, the memory 302b may be divided into one or more trusted memory regions for storing applications or software modules of the secure execution environment 115. These trusted memory regions may be hardware enforceable containers called enclaves, secure enclaves, and the like. The enclaves may be one or more isolated regions of memory 302b that are encrypted within the memory 302b, and only decrypted inside the processor. The secure enclaves may be used to store security critical code and/or data, such as iUICC module 120, profiles 375, and/or an iUICC OS 355. The memory 302b may be divided into multiple enclaves, wherein an iUICC enclave includes the iUICC module and other enclaves may include each of the profiles 375. From a physical point of view, enclave data is resident within registers, caches, and/or other logic blocks inside the application circuitry 302. Unauthorized access via untrusted software is prevented by processor logic. Whenever enclave data leaves the on-package caches to be written to memory 302b, the data is automatically encrypted and integrity protected, which reduces the likelihood enclave data will be viewed, modified, or replayed. In some embodiments, the enclaves may be defined and managed by a virtual machine monitor (VMM) of a virtual machine running as a guest OS. Any suitable VMM may be used to define the secure enclaves. In various embodiments, the secure execution environment 1 15 may be one or more secure enclaves defined using the Intel® SGX instructions.

The memory region for the iUICC enclave may be defined using the SGX instructions. Once the iUICC enclave is built, the iUICC module 120 and associated code may be loaded into the iUICC enclave. Code that is initially loaded into an enclave may be referred to as an "enclave binary," and the iUICC module 120 initially loaded into the iUICC enclave may be referred to as an "iUICC binary." After the iUICC module 120 and associated code is loaded into the iUICC enclave, the iUICC module 120 and associated code may be crypto graphic ally hashed by the processor 302a. The hashed iUICC module 120 is used to uniquely identify the iUICC module 120 inside the iUICC enclave. The hashed iUICC module 120 may be referred to as a "measurement hash." This measurement hash may then be included in an attestation message, which is sent to a remote platform (for example, EAES 175) for verification of the iUICC enclave. The attestation message may include an attestation signature that is generated by a quoting enclave. The quoting enclave may be an enclave that is provisioned specifically to produce attestation signatures and/or other types of digital signatures or certificates for remote verification of enclaves in secure execution environment 115. The EAES 175 may use the attestation message to verify the attestation signature using its own attestation key and comparing an expected value. Once verified, the EAES 175 may generate an ephemeral key, establish a secure channel with the iUICC enclave using the ephemeral key, and provision sensitive data to the iUICC enclave using the secure channel. After the sensitive data is provisioned to the iUICC enclave, the iUICC enclave may be initialized, which in some embodiments seals the iUICC enclave from being loaded with additional code or data. When the iUICC module 120 is initialized, the iUICC module 120 may perform the various UICC functions as described herein. In embodiments, the remote attestation process may be part of the remote provisioning process for provisioning the computing platform 200 with the iUICC module 120 and/or one or more profiles 375. An example of a remote attestation process is shown and described with regard to FIG. 13. In other embodiments, a local attestation process may be used to verify the iUICC module 120, such as the process shown and described with regard to FIG. 14.

Once the attestation process is complete, the memory location of the iUICC enclave may be protected from access by all hardware components and/or software components of computing platform 200 (for example, applications 350) regardless of a privilege level assigned to the hardware components and/or software components. In such embodiments, only a processor executing a secure application (for example, IUICC proxy 1 10 being implemented by ME processor 335 of the ME circuitry 302z) may access the iUICC enclave. In embodiments, the OS 360 may include a secure driver that provides an interface for hardware devices and/or software components to create secure applications; access enclaves created by the secure applications; create secure application certificates that allow one or more software components; hardware devices; or external computing devices to attest to validate their identity; create secure channels between multiple enclaves; and/or other like secure operations. In embodiments where the processor 302a is a multi-core processor, the processor 302a may execute program code from an enclave (for example, iUICC module 120) in parallel with unsecured program code (for example, one of the applications 350).

As mentioned previously, the iUICC module 120 may perform various functions in accordance with ISO/IEC 7816 and/or other suitable UICC or eUICC standards. These functions may be performed within the iUICC enclave after the iUICC enclave has been established, verified, and initialized. These functions may include operating one or more NAAs 220 and/or one or more applications 225 included with the profiles 375, and securely providing sensitive user data 230 and/or credentials 235 associated with the profiles 375 to other applications or components. In order to operate these applications and to access the sensitive data associated with the profiles 375, the iUICC module 120 may be capable of accessing other enclaves where the profiles 375 are stored.

In some embodiments, the iUICC enclave may also include applications for validating and/or decrypting user inputs (such as an input PIN number and the like) to authenticate a user of the computing platform 200. In some embodiments, the iUICC enclave may also include applications for encrypting payment credential information and/or transaction signatures for subsequent transmission to an upstream payment processor. In other embodiments, different enclaves within the secure execution environment 1 15 may include applications for user authentication and payment transaction processing. In such embodiments, these applications may include instructions for establishing intra-enclave communication paths and perform enclave attestation procedures to communicate data with the iUICC module 120 and/or with one another.

The iUICC OS 355 may be software module or program code that controls and manages access to the iUICC enclave and the iUICC module 120. Any suitable OS may be used as the iUICC OS 355 , and any suitable VMM may be implemented by the iUICC OS 355. In some embodiments, the iUICC OS 355 may be the Java Card™ OpenPlatform (JCOP), which is a standardized smart card OS. The JCOP may include a Java Card™ Virtual Machine (JCVM) and/or implement a Java Card™ Runtime Environment (JCRE), which allow Java applets to run on UICCs. In other embodiments, the iUICC OS 355 may be a native OS, which is a proprietary vendor-specific OS. Regardless of the specific OS used, the iUICC OS 355 may implement a profile loader (also referred to as a "profile installer" and/or a "profile manager") for installing and managing provisioned profiles 375 and/ or applets.

The iUICC OS 355 may include one or more drivers to provide an interface between the processor 302a and the ME circuitry 302z, which may allow the iUICC proxy 110 and the iUICC module 120 to access one another. The iUICC OS 355 may include one or more libraries or APIs, which provide program code and/or software components for the iUICC module 120 to interface with iUICC proxy 110 and/or to implement the various functions defined by the profiles 375. Although not shown by FIG. 4, these libraries or APIs may include a cryptographic library, a digital random number generator (DRNG) library, a trusted I/O library, and/or other like libraries.

The trusted I/O library may include instructions for sending/receiving information to/from the iUICC module 120 and the iUICC proxy 110. The cryptographic library may be a collection of cryptographic algorithms needed to implement a particular security service. The cryptographic algorithms may include digital signature algorithms, key agreement algorithms, key generation and exchange algorithms, and the like. The aforementioned algorithms may be implemented using elliptic curve cryptographic (ECC), ECDSA, Rivest-Shamir-Adleman (RSA) cryptography, advanced encryption system (AES) algorithm, a triple data encryption algorithm (3DES), a secure hash algorithm (SHA), and the like. The cryptographic library may also include instructions for performing various cryptographic operations, such as generating nonces and keys including generating or obtaining random numbers, encrypting/decrypting data, and digitally signing data. The cryptographic operations may include the various operations for encrypting/decrypting data in accordance with a UICC or eUICC standard, and various operations for encrypting/decrypting data for communication with the iUICC proxy 1 10. The DRNG library may provide instructions that allow the iUICC module 120 to access underlying DRNG circuitry of the application circuitry 302 (not shown). The DRNG circuitry may use a hardware entropy source of the processor 302a to repeatedly seed a hardware-implemented cryptographically secure pseudo-random number generator (CSPRNG). The CSPRNG may produce random numbers suitable for cryptographic purposes, such as key generation. In other embodiments, any suitable pseudo-random number generator (PR G), true random number generator (TRNG), or CSPRNG implementation may be used to generate random numbers. The DRNG library may also provide instructions for obtaining a generated random number for use with various cryptographic operations discussed previously.

Processor 302a may be configured to carry out instructions of a computer program by performing the basic arithmetical, logical, and input/output operations of the system. The term "processor" as used herein may refer to a physical central processing unit (CPU), a single-core processor, a dual-core processor, a triple-core processor, a quad- core processor, and the like. The processor 302a may perform a variety of functions for the computing platform 200 and may process data by executing program code, one or more software modules, firmware, middleware, microcode, hardware description languages, and/ or any other like set of instructions stored in the memory 302b. The program code may be provided to processor 302a by memory 302b via bus 325, one or more drive mechanisms (not shown), and/or via modem circuitry 305 and/or NI circuitry 315. In order to perform the variety of functions and data processing operations, the program code and/or software components may be executed by the processor 302a. On execution by the processor 302a, the processor 302a may cause computing platform 200 to perform the various operations and functions delineated by the program code.

For example, in various embodiments, the iUICC module 120 may include various modules and/or program code configured to operate (using hardware and/or software components) to validate/authenticate the computing platform 200 and communicate various remote provisioning and/or network access -related data with the remote provisioning service 140 and/or the service provider 145 as described herein. Once the various modules and/or program code of the iUICC module 120 are loaded into memory 302b and executed by the processor 302a, the processor 302a may be configured to cause computing platform 200 to perform the various processes, methods, or functions as claimed, and/or perform various other functions or combinations of functions as disclosed herein.

ME circuitry 302z may be an isolated and tamper-resistant chipset, which is distinct from and generally operates independently of the processor 302a. The ME circuitry 302z may be embodied as any number of hardware, firmware, and/or software modules configured to perform security, encryption, and/or authentication functions, as described herein. In some embodiments the ME circuitry 302z may be included in a graphics controller or graphics processing unit (GPU). Although the ME circuitry 302z is illustratively shown in FIG. 4 as being integrated into the application circuitry 302, the ME circuitry 302z may additionally or alternatively include separate circuitry disposed on another circuit board or SoC that is communicatively coupled to the application circuitry 302 via a signal path, such as bus 320 and/ or bus 325. The ME circuitry 302z may be communicatively coupled to other components of the application circuitry 302 (for example, memory 302b and processor 302a) via bus 325 and communicatively coupled to the communications circuitry of the computing platform 200 (for example, modem circuitry 305, NFC circuitry 313, and NI circuitry 315) via bus 320. In some embodiments, the ME circuitry 302z may also include additional built-in components, such as dedicated communication circuitry and the like. In some embodiments, the ME circuitry 302z may be associated with a MAC address and/or IP address, which is different than a MAC address and/or IP address associated with the computing platform 200. This may allow portions of communications traffic to be diverted to the ME circuitry 302z before reaching the host OS 360. In some embodiments, a remote platform (for example, the remote provisioning service 140) may use the MAC address and/or IP address of the ME circuitry 302z for provisioning the ME circuitry 302z with the iUICC proxy 110. Furthermore, ME circuitry 302z may include ME processor 335 and ME memory 340.

ME memory 340 may store crypto operations 380, which is a set of cryptographic algorithms or operations used for generating keys 370 and encrypting/decrypting data. The keys 370 may be used to encrypt/decrypt data being communicated through the ME circuitry 302z. In some embodiments, the keys 370 may be generated based on one or more measurements of the application circuitry 302. However, any suitable algorithm or operations may be used for key generation and/or encrypting/decrypting data. ME processor 335 may be any processing device capable of executing software modules or program code independently of the other processors of the application circuitry 302 and may include tamper-resistant characteristics. ME processor 335 may include one or more microprocessors, DSPs, cryptoprocessors, secure cryptoprocessors, cryptographic accelerators, secure controllers, and/or any other suitable device. The ME memory 340 may be embodied as one or more volatile and/or non-volatile memory devices. The ME memory 340 may store various data, including software/ firm ware executable by the ME processor 335 and data used for the various cryptographic operations, such as program code for iUICC proxy 1 10, as program code for ME OS 365, keys 370, and crypto operations 380, and/or the like.

ME processor 335 may implement the ME OS 365, which may be a framework that provides OS like functionality to trusted applications (for example, iUICC proxy 1 10), and provides an API for client applications (for example, iUICC module 120 or applications of the communications circuitry 105) to access trusted applications. The ME OS 365 may also include internal ME APIs or libraries, such as a cryptographic operations API to provide cryptographic capabilities (for example, the cryptographic algorithms/operations of crypto operations 380) to trusted applications, a trusted storage API to provide trusted storage for keys 370 and other data, and a secure element API that provides mechanisms for an application to open a connection with a secure element, such as the iUICC module 120, and to open a logical channel with a card or profile application in order to send application data protocol units (APDUs) to the card or profile application. In some embodiments, the ME OS 365 may also include firmware or drivers that provide override mechanisms for tamper-resistant hardware devices, and firmware or drivers for verifying certificates from SAS 170. These firmware modules may ensure that various conditions are met before any new applications are provisioned within the ME circuitry 302z (for example, the iUICC proxy 110). In some embodiments, the ME OS 365 may include firmware modules for signing and verifying certificates using a certificate signing key pair. The firmware modules may verify a digital signature of certificates using a public key of the certificate signing key pair, and the private key of the certificate signing key pair is used by the security assist server to sign the certificates. The private key of this key pair may be stored in a secure data store associated with the SAS 170, and the public key of the key pair may be maintained in memory 340 as a firmware image that cannot be changed or altered (for example, as one of the keys 370). In some embodiments, the ME OS 365 may be any suitable OS or firmware, such as a real-time OS (RTOS) and the like.

ME processor 335 may also implement the iUICC proxy 1 10. The iUICC proxy 1 10 may be a collection of software modules and/or program code (for example, an applet) that enables components of the computing platform 200 to access data from the iUICC enclave. The iUICC proxy 1 10 may be a trusted application from the perspective of the ME circuitry 302z. Trusted applications are applications that run inside the ME circuitry 302z and provide security related functionality to one or more client applications outside of the ME circuitry 302z. For example, iUICC module 120 and one or more applications operated by the communications circuitry may be considered untrusted applications from the perspective of the ME circuitry 302z (by contrast, from the perspective of the iUICC enclave the iUICC module 120 may be considered a trusted application and the iUICC proxy 1 10 may be considered an untrusted application). The iUICC proxy 110 may present itself as a UICC end-point to the communications circuitry 105 (for example, the modem circuitry 305, the NFC circuitry 313, and the NI circuitry 315) in accordance with ISO 7816 protocols, GSMA protocols, GlobalPlatform protocols, and/or other like protocols. The iUICC proxy 1 10 may provide access to the iUICC module 120 by performing the crypto operations 380 and creating a secure channel between the communications circuitry 105 and the iUICC enclave. The secure channel may also include an end-to-end encrypted tunnel between the iUICC enclave and one or more network elements, such as the remote provisioning service 140 (including SAS 170 and/or EAES 175), the service provider 145, one or more network elements associated with the network 135, and the like.

Bus 325 may be configured to enable the communication and data transfer between the processor 302a, memory 302b, ME circuitry 302z, and modem circuitry 305 at least as shown. Bus 325 may comprise a high-speed serial bus, parallel bus, internal universal serial bus (USB), Front-Side-Bus (FSB), and or other suitable communication technology for transferring data between components within computing platform 200 and other like devices. In some embodiments, bus 325 may comprise a PCI bus, a PCI-Express (PCI-e) bus, a host embedded controller interface (HECI), a Small Computer System Interface (SCSI) bus, and the like.

Private bus 320 may be configured to enable the communication and data transfer between the components of the computing platform 200, such as between the ME circuitry 302z and the communications circuitry of the computing platform 200. In embodiments, private bus 320 may be any computer bus that is not exposed to the application circuitry 302. The private bus 320 may be the same or similar as bus 325, while in some embodiments, private bus 320 may comprise a private low pin count (LPC) serial bus. In embodiments, the LPC serial bus is not exposed to a host OS 360 of the application circuitry 302.

NI circuitry 315 may be a computer hardware component that connects computing platform 200 to a computer network, for example, network 135, via a wired connection. To this end, the NI circuitry 315 may include one or more dedicated processors and/or field-programmable gate arrays (FPGAs) to communicate using one or more wired communications protocols. The wired communications protocols may include a serial communications protocol (e.g., the Universal Serial Bus (USB), FireWire, Serial Digital Interface (SDI), and/or other like serial communications protocols), a parallel communications protocol (e.g., IEEE 1284, Computer Automated Measurement And Control (CAMAC), and/or other like parallel communications protocols), and/or a network communications protocol (e.g., Ethernet, token ring, Fiber Distributed Data Interface (FDDI), and/or other like network communications protocols). The NI circuitry 315 may also include one or more virtual network interfaces configured to operate with iUICC proxy 110 and/or other like applications.

NFC circuitry 313 may be one or more hardware devices and software modules configured to read electronic tags and/or connect with another NFC-enabled device (also referred to as an "NFC touchpoint"). NFC is commonly used for contactless, short-range communications based on radio frequency identification (RFID) standards, wherein magnetic field induction is used to enable communication between NFC-enabled devices. In some embodiments, the one or more hardware devices may include an NFC controller coupled with an antenna element and a processor coupled with the NFC controller. The NFC controller may be a chip providing NFC functionalities to the NFC circuitry 313. The software modules may include NFC controller firmware and an NFC stack. The NFC stack may be executed by the processor to control the NFC controller, and the NFC controller firmware may be executed by the NFC controller to control the antenna element to emit an RF signal. The RF signal may power a passive NFC tag (for example, a microchip embedded in a sticker or wristband) to transmit stored data to the NFC circuitry 313, or initiate data transfer between the NFC circuitry 313 and another active NFC device (for example, a smartphone or an NFC-enabled POS terminal) that is proximate to the computing platform 200.

Conventional NFC devices require a dedicated antenna, a controller, and a secure element. The secure element could be a separate UICC coupled with the NFC controller and/or an IC embedded in the NFC controller. Typically, the secure element stores payment credentials and performs cryptographic operations. Furthermore, an applet residing in the secure element usually receives NFC event notifications from the NFC controller and provides the NFC event notifications to authorized applications operated by the host architecture (for example, a point of sale (POS) application, a banking application, a mobile wallet application, and the like). The applet (or another applet residing in the secure element) may also emulate a passive smart card, for example, a credit card with an EMV chip. This emulation of a passive smart card may enable a user to perform transactions as if the computing device were a contactless card. In various embodiments, the NFC circuitry 313 may include a dedicated processor or microcontroller that interfaces with the iUICC module 120 via the iUICC proxy 1 10 implemented by the ME circuitry 302z. In such embodiments, the iUICC module 120 may access an NFC profile 375 that includes one or more NFC applications 225. The NFC applications 225 may receive NFC event notifications from the NFC controller and provide the NFC event notifications to authorized applications 350, and emulate an NFC card and provide NFC card information to the NFC controller. The NFC card information may be included in the user data 230 and/or credentials 235 of the profile 375.

Other NFC systems provide services that emulate the physical secure element

(referred to as "Host Card Emulation" or "HCE"). In most HCE systems, the secure element functions (for example, payment credential storage and cryptographic operations) are implemented by a cloud service separate from the NFC-enabled device. When an NFC transaction is to take place, an OS of an NFC-enabled device must route NFC commands from the NFC device to an HCE client application without accessing a secure element. The HCE client application performs verification and authorization operations and connects to the cloud service to obtain the payment credentials for carrying out the NFC transaction. Therefore, most HCE systems require almost constant signaling with the cloud service, which may require more computational and network resources than conventional NFC devices. In some embodiments, instead of having a dedicated processor, the NFC circuitry 313 may comprise the NFC controller, and one or more software modules operated by the processor 302a may access the iUICC module 120 via the iUICC proxy 1 10. In such embodiments, the iUICC module 120 may access an NFC profile 375 that includes one or more NFC applications 225, which operate in a same or similar manner as discussed previously. These embodiments may provide similar functionality as typical HCE systems without requiring constant communication with a cloud service, thereby using less computational and network resources than typical HCE systems.

I/O interface 345 may be a computer hardware component that provides communication between the computing platform 200 and one or more other devices. The I/O interface 345 may include one or more user interfaces designed to enable user interaction with the computing platform 200 and/or peripheral component interfaces designed to provide interaction between the computing platform 200 and one or more peripheral components. User interfaces may include, but are not limited to, a physical keyboard or keypad, a touchpad, speakers, a microphone, and the like. Peripheral component interfaces may include, but are not limited to, a non-volatile memory port, a universal serial bus (USB) port, an audio jack, and a power supply interface.

Although not shown by FIG. 4, in some embodiments computing platform 200 may also include one or more sensors, such as an accelerometer, gyroscope, gravimeter, magnetometer, biometric sensors, and/or another like devices.

FIG. 5 illustrates the components of a second implementation of the computing platform 200. As shown by FIG. 5, computing platform 200 may include similar components as shown by FIG. 3, such as processor 302a, computer-readable media 302b, bus 325, modem circuitry 305, NFC circuitry 313, NI circuitry 315, and input/output (I/O) interface 345, each of which may operate in a same or similar manner as discussed with regard to FIG. 4. However, according to the example embodiment shown by FIG. 5, the iUICC proxy 110 may be implemented by the processor 302a instead of ME circuitry 302z. In such embodiments, the iUICC proxy 1 10 may still act as a secure application for providing access to the iUICC enclave within the secure execution environment 1 15. In this way, the iUICC proxy 1 10 may provide a secure channel for forwarding commands or instructions from the modem circuitry 305, NFC circuitry 313, or NI circuitry 315 to the iUICC module 120 in accordance with relevant specifications, such as ISO 7816 protocols, GSMA protocols, GlobalPlatform protocols, and/or other like protocols.

FIG. 6 illustrates the components of a third implementation of the computing platform 200. As shown by FIG. 6, computing platform 200 may include similar components as shown by FIG. 4, such as processor 302a, computer-readable media 302b, ME circuitry 302z, bus 320, bus 325, modem circuitry 305, NFC circuitry 313, NI circuitry 315, and input/output (I/O) interface 345, each of which may operate in a same or similar manner as discussed with regard to FIG. 4. However, according to the example embodiment shown by FIG. 6, the iUICC proxy 110 and the iUICC module 120 may be implemented by the ME processor 335 of the ME circuitry 302z. In such embodiments, the ME circuitry 302z may act as the secure execution environment without the need to implement secure enclaves. In some embodiments, the iUICC proxy 110 may forward commands or instructions from the modem circuitry 305, NFC circuitry 313, or NI circuitry 315 to the iUICC module 120 in accordance with relevant specifications, such as ISO 7816 protocols, GSMA protocols, GlobalPlatform protocols, and/or other like protocols. In other embodiments, the iUICC proxy 1 10 may be omitted, and the iUICC module 120 may communicate with the modem circuitry 305, NFC circuitry 313, or NI circuitry 315 to the iUICC module 120 in accordance with one or more relevant standards. FIG. 7 illustrates a first example implementation of the modem circuitry 305, in accordance with other various example embodiments. As shown by FIG. 7, the baseband circuitry 304 of the modem circuitry 305 may include baseband CPU 304e, the computer- readable media 304g (including volatile memory 304g-l and non-volatile memory 304g- 2), ME circuitry 304z, bus 725, baseband processors 304a-e, and audio DSP(s) 304f.

Each of the baseband processors 304a-e and the audio DSP(s) 304f may operate in a same or similar manner as discussed with regard to FIG. 3. Baseband CPU 304e may be configured to run elements of a protocol stack for signaling various air interface layers in accordance with various air interface protocols 760. In addition to running elements of the protocol stack for signaling, in the embodiment shown by FIG. 7 the baseband CPU 304e may also implement the secure execution environment 115 in a same or similar manner as discussed previously with regard to FIGS. 1-4.

The computer -readable media 304g may be used to load and store data and/or instructions for operations performed by the baseband processors 304a-e. During operation, memory 304g (volatile memory 304g-l and/or non-volatile memory 304g-2) may include instructions, program code, or modules for air interface protocols 760, baseband OS 770, and secure execution environment 115. As shown, the secure execution environment 1 15 includes the iUICC module 120 and the iUICC OS 355, which may operate in a same or similar manner as discussed previously with regard to FIG. 4. Furthermore, the baseband OS 770 may be any suitable OS or firmware, such as an RTOS. In some embodiments, the baseband OS 770 may be a proprietary OS specifically tailored for the modem circuitry 305.

Bus 725 may be configured to enable the communication and data transfer between the baseband processors 304a-e, memory 304g, and ME circuitry 304z, at least as shown. In various embodiments, bus 725 may comprise a proprietary or an industry- standard bus that connects the components of the baseband circuitry 304. In other embodiments, the bus 725 may be the same or similar to bus 325 or bus 320 discussed previously.

ME circuitry 304z may be a tamper-resistant chip that is the same or similar to ME circuitry 302z. In the embodiment shown by FIG. 7, the iUICC proxy 1 10 implemented by the ME processor 335 may communicate commands or instructions with the iUICC module 120 implemented by the baseband processor 304e in a same or similar fashion as discussed previously with regard to FIGS. 1-4. Furthermore, the iUICC proxy 110 may also communicate commands/instructions between the iUICC module 120 and the NFC circuitry 313 and/or NI circuitry 315 in accordance with one or more relevant specifications. In such embodiments, ME circuitry 304z may be coupled with the NFC circuitry 313 and the NI circuitry 315 via a bus, such as bus 320 (not shown by FIG. 7). Although the ME circuitry 304z is illustratively shown in FIG. 7 as being integrated into the baseband circuitry 304, the ME circuitry 304z may additionally or alternatively include separate circuitry disposed on another circuit board or SoC that is communicatively coupled to baseband circuitry 304 via a signal path, such as bus 320 and/or bus 325.

FIG. 8 illustrates a second example implementation of modem circuitry 305, in accordance with other various example embodiments. As shown by FIG. 8, the baseband circuitry 304 may include similar components as shown by FIG. 7, such as baseband processors 304a-e, computer-readable media 304g (including volatile memory 304g-l and non-volatile memory 304g-2), and bus 725, each of which may operate in a same or similar manner as discussed with regard to FIGS. 1-4. However, according to the example embodiment shown by FIG. 8, the iUICC proxy 110 may be implemented by the baseband processor 304e instead of ME circuitry 304z. In such embodiments, the iUICC proxy 110 may still act as a secure application for providing access to the iUICC enclave within the secure execution environment 1 15. In this way, the iUICC proxy 110 may provide a secure channel communicating commands or instructions between the iUICC module 120 and untrusted applications of the baseband circuitry 304, a remote device (not shown by FIG. 8), NFC circuitry 313 (not shown by FIG. 8), or NI circuitry 315 (not shown by FIG. 8) in accordance with one or more relevant specifications, such as ISO 7816 protocols, GSMA protocols, GlobalPlatform protocols, and/or other like protocols.

FIGS. 9-21 illustrate processes 900-2100 for provisioning and implementing the iUICC module 120 in accordance with various example embodiments. For illustrative purposes, the operations of processes 900-2100 will be described as being performed by the various elements as described with respect to FIGS. 1-8. However, other similar devices may operate these processes. Additionally, some of the operations in processes 900-2100 are described as being performed using Intel® SGX instructions. However, the various example embodiments described herein may use any other suitable methods or processes for establishing enclaves or similar trusted execution environments. Furthermore, some of the operations in processes 900-2100 are described as being between iUICC module 120 and a remote platform, such as remote provisioning service 140 or service provider 145. It should be understood that such communications may be facilitated by the communications circuitry 105 and the iUICC proxy 1 10 as described with regard to FIGS. 1-4. Moreover, while particular examples and orders of operations are illustrated in FIGS. 9-21 , the depicted orders of operations should not be construed to limit the scope of the example embodiments in any way. Rather, the depicted operations may be re-ordered, broken into additional operations, combined, and/or omitted altogether while remaining within the spirit and scope of the present disclosure.

Referring to the figures, FIG. 9 is a flowchart illustrating an example process 900 for remote provisioning an iUICC module 120 in accordance with various embodiments. Process 900 may be used for the remote provisioning of the iUICC module 120 in computing platform 200 or other suitable devices. Process 900 may be advantageous for provisioning devices, such as M2M or MTC devices, which are not easily reachable. However, process 900 may also be used for provisioning any device over the air (OTA). Furthermore, although process 900 describes provisioning computing platform 200 with an iUICC module 120, process 900 may also be used for provisioning devices with other enclaves to ensure secure execution and integrity of other applications or to ensure secure storage and integrity of sensitive data.

Referring to FIG. 9, at operation 905 the computing platform 200 may establish an iUICC enclave and the iUICC proxy 110. An example process for establishing an iUICC enclave is shown and described with regard to FIG. 10. An example process for provisioning the iUICC proxy 1 10 is shown and described with regard to FIG. 11. Once the iUICC enclave and iUICC proxy 1 10 are established/provisioned, the iUICC module 120 may be loaded into the iUI CC enclave and activated.

At operation 910, the computing platform 200 may create a profile security domain (ISD-P) for a profile to be provisioned within the iUICC enclave. An example process for creating a security domain is shown and described with regard to FIG. 15. At operation 915, the computing platform 200 may establish one or more keys associated with a profile 375 to be provisioned. An example process for establishing keys is shown and described with regard to FIG. 16. At operation 920, the computing platform 200 may download the profile 375 from the remote provisioning service 140. In embodiments, an enclave may be established for the profile 375 and the profile may then be loaded into the enclave. This enclave may be associated with the iUICC storage 125 discussed with regard to FIG. 1. The enclave may be established in a same or similar manner as discussed with regard to operation 905 or process 1000 of FIG. 10. An example process for downloading a profile is shown and described with regard to FIG. 17. At operation 925, the computing platform 200 may enable the profile. An example process for enabling a profile is shown and described with regard to FIG. 18. Operations 910-925 may be the four main operations for remote provisioning of the iUICC module 120.

The computing platform 200 may then (optionally) proceed to operation 930 to attach to the network 135 according to the information stored in the profile and the NAA 220 of the profile 375 enabled at operation 925. An example process for attaching to a network using an enabled profile is shown and described with regard to FIG. 19. The computing platform 200 may then (optionally) proceed to operation 935 to enable another profile and access one or more services provided by the service provider 145 according to the information stored in the other profile and the NAA 220 of such a profile 375. An example process for switching profiles and obtaining services is shown and described with regard to FIG. 19.

FIG. 10 is a flowchart illustrating an example process 1000 for establishing an iUICC enclave in accordance with various embodiments. Establishing the iUICC enclave may provide for secure execution and integrity of the iUICC module 120 and any associated data and/or profiles 375. Furthermore, although process 1000 describes establishing and initializing an iUICC enclave within the application circuitry 302 of computing platform 200, process 1000 may also be used for establishing and initializing an iUICC enclave within the modem circuitry 305. Furthermore, process 1000 may also be used for establishing and initializing other enclaves (such as enclaves for profiles 375) within application circuitry 302 and/or modem circuitry 305 to ensure secure execution and integrity of other applications or to ensure secure storage and integrity of sensitive data.

Referring to FIG. 10, at operation 1005, the computing platform 200 may obtain the program code for implementing the iUICC module 120. In some embodiments, the program code for the iUICC module 120 may be loaded into memory /storage via the communications circuitry 105, for example, via the modem circuitry 305, the NI circuitry 315, or the NFC circuitry 313. In other embodiments, the program code for the iUICC module 120 may be loaded into memory/storage 302b via a separate removable computer- readable media, for example, using a memory stick, thumb drive, CD-ROM, and the like. The mechanism or circuitry through which the program code for the iUICC module is obtained may depend on the type of device in which the computing platform 200 is implemented and/or the circuitry in which the iUICC module 120 is to be implemented. For example, when the computing platform 200 is implemented in an MTC device, the program code for the iUICC module 120 may be loaded into memory/storage 302b via the modem circuitry 305. In another example, a thumb drive or the NI circuitry 315 may be used to load the program code for the iUICC module 120 into memory 302b when the computing platform 200 is implemented in a laptop PC or desktop PC. In another example, the NFC circuitry 313 or the modem circuitry 305 may be used to load the program code for the iUICC module 120 into memory 302b when the computing platform 200 is implemented in a smartphone.

At operation 1010, the computing platform 200 may receive a command to establish the iUICC enclave. In some embodiments, the command may be received from a user input, the remote provisioning service 140, or an iUICC developer. For example, when the computing platform 200 is implemented in an MFC device, the command may be received from the remote provisioning service 140 or the iUICC developer, whereas when the computing platform 200 is implemented in a smartphone or laptop PC, the command may be received from a user input.

At operation 1015, the computing platform 200 may initialize an enclave control structure for the iUICC enclave. In embodiments, the ECREAFE instruction may be used to create an SGX Enclave Control Structure (SECS) for the iUICC enclave (referred to herein as an "iUICC SECS"). Fhe iUICC SECS may contain metadata about the iUICC enclave, such as a measurement value of the iUICC enclave and/or other like sensitive information about the iUICC enclave. Fhe ECREAFE instruction may also allocate an unused Enclave Page Cache (EPC) page for the iUI CC SECS, wherein the iUI CC SECS may be stored in the allocated EPC. Fhe EPC is a protected memory store that is used to store enclave pages and SGX structures, such as the iUICC SECS. Fhe EPC is divided into chunks or portions, each of which is called an EPC page. Fhe EPC pages include portions of the enclave program code and a thread control structure (FCS). Fhe FCS may include fields that indicate context switches to be performed by a processor as it transitions between executing enclave code and non-enclave code. Fhe ECREAFE instruction may be used to specify a base address and a size of the iUICC enclave within the EPC.

Once the iUICC SECS has been created, at operation 1020 the computing platform 200 may load the program code and associated data for iUICC module 120 into the iUICC enclave. Fhis may include loading the iUICC module 120, the CASD, ISD-R, and/or any pre-provisioned profiles 375 (for example, a provisioning profile or one or more MNO profiles). As mentioned previously, a portion of the EPC may be allocated to the iUICC enclave. Fhe program code and data for the iUICC module 120 may be allocated to a plurality of EPC pages making up the iUICC enclave using the EADD instruction. Fypically, the EPC is managed by the same system software that manages the rest of the physical memory of the computing platform 200, such as a VMM or an OS kernel implemented by the application circuitry 302. Therefore, in some embodiments, the EADD instruction may cause the application circuitry 302 to load the program code and associated data for iUICC module 120 from the memory 302b into the iUICC enclave. In other embodiments, such as the example embodiment shown by FIGS. 7-8, the EADD instruction may cause the baseband circuitry 304 to load the program code and associated data for iUICC module 120 from the memory 304g into the iUICC enclave implemented by the baseband circuitry 304.

Furthermore, the EADD instruction may initialize Enclave Page Cache Map (EPCM) entries to indicate a page type for each EPC page, a linear address that the enclave will access the EPC pages, the enclave permissions for the EPC pages (such as read/write/execute permissions), and an association to the iUICC SECS. The EPCM entry information may be used by the system hardware to provide access control to the EPC pages comprising the iUICC enclave. The EADD instruction may then record EPCM information in a cryptographic log stored in the iUICC SECS and copy the program code for the iUICC module 120 from unprotected memory to the allocated EPC pages. The EPCM may be comprised of a series of entries with one entry for each EPC page. The EPCM is usually managed by an SGX-enabled processor as part of various SGX instructions and is never directly accessible by system software or other devices. The format of the EPCM may be implementation dependent; however, each EPCM entry may include some or all of the following information: whether the EPC page is valid or invalid; the enclave instance that owns the page; the type of page (regular (REG), TCS, version array (VA), or SECS); the virtual address through which the enclave is allowed to access the page; the enclave specified read/write/execute permissions on that page; and/or whether the page is accessible or not (blocked or unblocked).

Referring back to FIG. 10, after the program code and associated data for iUICC module 120 is loaded into the iUICC enclave, at operation 1025 the computing platform 200 may measure the iUICC enclave. An enclave's measurement may be computed by hashing inputs to the ECREATE, EADD, and EEXTEND instructions. The E EXTEND instruction may be used to measure a region of an added EPC page, and thus, a desired amount of an EPC page or enclave may be measured by invoking the EEXTEND instruction a specified number of times. By computing the measurements using the inputs to the ECREATE, EADD, and EEXTEND instructions, ihe enclave may only be constructed in a way that matches an expected measurement by following the exact sequence of instructions specified by the enclave owner/ creator/developer (for example, the iUICC module developer).

Each invocation of EEXTEND adds a header to a cryptographic log. Each header may indicate which region is being measured and the measurement of the region. Entries in the cryptographic log may define the measurement of the enclave and are used for attesting that the enclave was correctly constructed by the untrusted system software. In some embodiments, only a cryptographic hash of the log is actually stored in the iUICC SECS due to the potential size of the log. Correct construction results in the cryptographic log matching the one built by the enclave owner/creator/developer, which can be verified by a remote party (for example, the remote provisioning service 140).

At operation 1030, the computing platform 200 may initialize the iUICC enclave. The initialization process may be invoked using an Enclave Initialization (EINIT) instruction. After the EINIT instruction is invoked, the enclave's contents are "sealed." Once an enclave is sealed, the system software cannot add or load additional data or program code into the enclave, and additional enclave measurements may not occur. Furthermore, once the iUICC enclave is sealed using the EINIT instruction, the final enclave measurement may be hashed, which may be used in an attestation signature during an attestation procedure. The initialization process may also finalize the cryptographic log and establish the enclave identity and sealing identity of the iUICC enclave. The enclave identity and sealing identity of the iUICC enclave may be written to the iUICC SECS.

The enclave identity is a cryptographic hash that reflects the content of the enclave, the order in which it was built, the addresses it occupies in memory, and the security attributes of each page. The sealing identity (also referred to as a "signature structure") is managed by a sealing authority represented by the hash of a public key used to sign a structure by the enclave owner/creator/developer. The sealing authority assigns a product ID and security version number to an enclave identity comprising known attributes of the enclave and the measurement of the enclave. The EINIT instruction may verify the signature inside the signature structure and may use information in the signature structure to assign an enclave identity to an enclave. In some embodiments, the signature structure may include the iUICC certificate signed by the remote provisioning service 140 and/or the iUICC module developer, and the enclave identity may be based on the signature of the remote provisioning service 140 and/or the iUICC module developer. Additionally, the enclave identity may also be used to transfer data between enclaves that contain different versions of the same software module. Thus, in some embodiments the enclave identity of the iUICC enclave may be used to update the iUICC module 120 with new applications or components. In some embodiments, the iUICC enclave identity may be used to update the iUICC enclave to include newly provisioned profiles 375 within the iUICC enclave with or without updating the program code of the iUICC module 120. Once the iUICC enclave is initialized, the iUICC module 120 may be operated inside the iUICC enclave.

FIG. 1 1 is a dataflow diagram illustrating an example process 1 100 for provisioning the iUICC proxy 110 within the ME circuitry 302z. As discussed previously, the iUICC proxy 110 may be used for communicating with the iUICC module 120 within the iUICC enclave, in accordance with various embodiments. Provisioning the iUICC proxy 110 within the ME circuitry 302z may provide security and integrity of the communications between the iUICC module 120 and other untrusted applications or components of the computing platform 200. Furthermore, although process 1 100 describes provisioning the iUICC proxy 1 10 within the ME circuitry 302z, process 1100 may also be used for provisioning iUICC proxy 110 within the ME circuitry 304z of the modem circuitry 305. Furthermore, in some embodiments, process 1100 may also be used for provisioning iUICC module 120 within the ME circuitry 302z/304z, such as the embodiment shown and described with regard to FIG. 6.

At operation 1102, iUICC module 120 may transmit a message to the ME circuitry 302z to determine if the iUI CC proxy 110 has been provisioned. The message may be transmitted in response to the establishment and/or initialization of the iUI CC enclave as discussed with regard to FIG. 10. In response to the message, at operation 1 104 the ME circuitry 302z may determine whether the iUICC proxy 1 10 has been provisioned. If the ME circuitry 302z determines that the iUICC proxy 110 has been provisioned, at operation 1006 the ME circuitry 302z may transmit another message back to the iUICC module 120 to indicate that the iUICC module 120 has been provisioned. At this point, the process 1 100 may end.

If the ME circuitry 302z determines that the iUICC proxy 110 has not been provisioned, at operation 1 108 the ME circuitry 302z may transmit an iUICC proxy establishment request to the remote provisioning service 140 (or the SAS 170). The iUICC proxy establishment request may include an ME circuitry certificate that is signed using a private key of a certificate signing key pair stored in the ME memory 340. At operation 1 1 10, the remote provisioning service 140 (or the SAS 170) may verify the ME circuitry 302z using the ME circuitry certificate and a private key of a certificate signing key pair stored in an associated secure memory/storage. Upon proper verification of the ME circuitry 302z, at operation 1112 the remote provisioning service 140 (or the SAS 170) may generate an installation certificate, and at operation 1 1 14, the remote provisioning service 140 (or the SAS 170) may transmit the installation certificate with program code for the iUICC proxy 1 10. Then at operation 1 1 16, the ME circuitry 302z may verify the installation certificate. Upon proper verification of the installation certificate, at operation 1118, the ME circuitry 302z may override any tamper -resistant components of the ME circuitry 302z, and at operation 1 120, the ME circuitry 302z may install the program code for the iUICC proxy 1 10.

In some embodiments, the installation certificate may include an override module that is capable of interacting with the ME circuitry 302z firmware to override or disable tamper -resistant technology, including tamper-resistant hardware devices such as e- fuses. In some embodiments, the override module may override boot/initialization control mechanisms. In embodiments where the ME circuitry 302z operates in conjunction with Intel® AMT and/or Intel® vPro™ technology, the installation certificate may include or be sent with program code that instructs the ME circuitry 302z to enter a "provisioning mode," which allows an administrator or operator of the remote provisioning service 140 (or the SAS 170) to set up or configure the ME circuitry 302z.

Upon properly installing the program code for the iUICC proxy 1 10, at operation 1 122, the ME circuitry 302z may transmit a message to the iUICC module 120 to indicate that the iUICC proxy 1 10 has been installed or provisioned. Additionally, at operation 1 124, the ME circuitry 302z may transmit a message to the remote provisioning service 140 (or the SAS 170) to indicate that the iUICC proxy 110 has been installed or provisioned.

FIG. 12 is a dataflow diagram illustrating an example process 1200 for operating the iUICC module 120 within the iUICC enclave, in accordance with various embodiments. In embodiments, the process 1 100 may be operated by iUICC proxy 110 to provide communications between the iUICC module 120 and the communications circuitry 105. Process 1200 may be invoked during the other processes described herein, such as processes 1300-2100 that are shown and described with regard to FIGS. 13-21.

Referring to FIG. 12, at operation 1205, the iUICC proxy 110 may receive a request from an untrusted application or component of the computing platform 200. As an example, the modem circuitry 305 may wish to activate the iUICC module 120 in order to attach to network 135. In this case, the modem circuitry 305 may transmit an iUICC activation command to the iUICC proxy 110 to be delivered to the iUICC module 120. At operation 1210, the iUICC proxy 110 may enter the iUICC enclave with the request information as one or more inputs. The iUICC proxy 110 may use the iUICC enclave using the EENTER instruction to transfer control to the iUICC module 120 residing in EPC of the iUICC enclave. Upon enclave entry, control is transferred by hardware to the iUICC module 120 inside the iUICC enclave. This may be accomplished by setting an instruction pointer to a value indicated by one or more fields in a TCS of the iUICC enclave EPC. In some embodiments, the value in the TCS may point to a location of the iUICC module 120. In other embodiments, the iUICC proxy 110 may pass the requests to iUICC bridge 210 within the iUICC module 120, which hands off the requests to other components of the iUICC module 120.

At operation 1215, the iUICC module 120 may be executed within the iUICC enclave, and at operation 1220, the iUICC proxy 1 10 may obtain one or more outputs based on the execution of the iUICC module 120. The iUICC module 120 may return to the caller (iUICC proxy 110) via an Enclave Exit (EEXIT) instruction, which is called by the iUICC module 120. When returning back from the enclave, the iUICC module 120 may set the instruction pointer to another value indicated by another field in the TCS, and then execute the EEXIT instruction. Continuing with the previous example, the iUICC proxy 1 10 may enter the iUI CC enclave with the iUICC activation command at operation 1210, and in response, the iUICC proxy may receive an Answer-to-Reset (ATR) message at operation 1220.

At operation 1225, the iUICC proxy 1 10 may provide the outputs from the iUICC module 120 to the requesting untrusted application or component. Continuing with the previous example, the iUICC proxy 1 10 may provide the ATR message to the modem circuitry 305.

FIG. 13 is a dataflow diagram illustrating an example remote attestation process 1300 for a secure execution environment, in accordance with various embodiments. Process 1300 may be used to validate the integrity of the iUICC module 120 and/or the iUICC enclave using a remote entity, such as the remote provisioning service 140 and/or EAES 175. The process 1300 may be invoked when an untrusted application or component of the computing platform 200 attempts to activate the iUICC module 120 within the iUICC enclave.

Referring to FIG. 13, at operation 1302, the communications circuitry 105 may transmit an iUICC activation command to the iUICC module 120 via the iUICC proxy 1 10. The iUICC activation command may be sent to the iUICC module 120 in order to access a network profile 375 A for attaching to the network 135, or the iUICC activation command may be sent to the iUICC module 120 in order to access a service-provider profile 375B for accessing one or more services provided by the service provider 145.

At operation 1304, the iUICC module 120 may transmit an attestation request to the remote provisioning service 140 (or EAES 175) via the iUICC proxy 110 and communications circuitry 105. When the iUICC module 120 is undergoing an initial or first attestation procedure, such as when the iUICC module 120 is activated after being provisioned in the computing platform 200, the communications circuitry 105 may attach or otherwise communicate over the network 135 according to a provisioning profile 375. In such embodiments, the attestation request (and other transmissions in process 1300) may be transmitted to the remote provisioning service 140 while the communications circuitry 105 is attached or otherwise capable of communicating over the network 135 utilizing an NAA 220 of the provisioning profile 375. When the iUICC module 120 is activated to access one or more services, the attestation request (and other transmissions in process 1300) may be transmitted to the remote provisioning service 140 during an ongoing communications session.

At operation 1306, the remote provisioning service 140 (or EAES 175) may transmit a challenge to the iUICC module 120 via the communications circuitry 105 and the iUICC proxy 110. The challenge may be a request for attestation information from the iUICC enclave. In embodiments, the remote provisioning service 140 (or EAES 175) may generate a cryptographic nonce (or initialization vector) using a random number generator and embed the nonce in the challenge message. The challenge response at operation 1314 may include an acknowledgement of the embedded nonce.

In response to the challenge, at operation 1308 the iUICC module 120 may generate a report. In embodiments , a report may be used to verify the correctness of the iUICC enclave. The report may be generated by the iUICC module 120 or iUICC enclave using an Enclave Report (EREPORT) instruction. The EREPORT instruction reads the iUICC enclave identity information and iUICC enclave measurement from the iUICC SECS, and populates a report structure. The report structure may also be populated with the nonce embedded in the challenge message and/or a security version number (SVN), which may indicate a version of the iUICC enclave or iUICC module 120.

At operation 1310, the iUICC module 120 may obtain an attestation signature. In embodiments, iUICC module 120 may provide the report to a quoting enclave (not shown) to obtain the attestation signature. The quoting enclave may derive a report key using an Enclave Get Key (EGETKEY) instruction, and use the report key to verify the report. The report key returned by EGETKEY is derived from a secret key embedded in the application circuitry 302. The quoting enclave may then obtain a pre-provisioned seal key using the EGETKEY instruction and uses the seal key to decrypt a pre-provisioned attestation key. The seal key and the attestation key may be provided to the quoting enclave from a provisioning enclave that is provisioned into tamper-resistant hardware components of the application circuitry 302 during manufacture. The quoting enclave may then derive the attestation signature using the attestation key, and place the attestation signature into the report. In various embodiments, the quoting enclave may use Enhanced Privacy ID (EPID) cryptosystem provided by Intel®, which is a group signature scheme that allows a platform to sign objects while preserving the anonymity of the signing platform. In EPID cryptosys terns, the remote provisioning service 140 (or EAES 175) may provide the computing platform 200 with an EPID group public key, while securely storing an EPID master issuing key. After the provisioning enclave authenticates itself to the remote provisioning service 140 (or EAES 175) during a separate enclave provisioning process, the provisioning enclave may generate an EPID member private key, which serves as the attestation key. In such embodiments, the quoting enclave may use the EPID member private key to produce the attestation signature.

The quoting enclave may then provide the report with attestation signature to the iUICC module 120, and at operation 1312, the iUICC module 120 may generate a challenge response. The challenge response may include the report and attestation signature, as well as other information, such as the nonce received with the challenge message, an ephemeral public key to be used by the remote provisioning service 140 (or EAES 175) or other network elements for communicating with the iUICC enclave, and/or other like information. In some embodiments, the challenge response may include a public key of a key pair associated with the iUICC module. In such embodiments, the public key may have been registered with the remote provisioning service 140 (or EAES 175) prior to provisioning the iUICC module 120. Once registered, the public key may be placed in a whitelist stored by the remote provisioning service 140 (or EAES 175). At operation 1314, the iUICC module 120 may transmit the challenge response to the remote provisioning service 140 (or EAES 175) via the iUICC proxy 110 and communications circuitry 105.

At operation 1316, the remote provisioning service 140 (or EAES 175) may verify the attestation signature and the challenge response. In embodiments, the remote provisioning service 140 (or EAES 175) may use the EPID group public key to validate the attestation signature, and may determine whether the nonce is included in the report portion of the challenge response. In other embodiments, the remote provisioning service 140 (or EAES 175) may use the public key included in the challenge response, and compare the public key against the whitelist of public keys.

Based on the verification, at operation 1318 the remote provisioning service 140 (or EAES 175) may transmit an attestation response to the iUICC module 120 via the communications circuitry 105 and the iUICC proxy 1 10. If the iUICC enclave was properly verified at operation 1316, then the attestation response may indicate that the iUICC enclave is a trusted application, which may be accessed by communications circuitry 105 to attach or otherwise communicate over network 135. Once the attestation has been successfully completed, a trusted channel can be established, and at operation 1320, a trusted communications session with the network 135 may be established and/or services can be securely accessed from the service provider 145.

FIG. 14 is a dataflow diagram illustrating an example local attestation process 1400 for a secure execution environment, in accordance with various embodiments. Process 1400 may be used to validate the integrity of the iUICC module 120 and/or the iUICC enclave using local entities, such as an iUICC loader 121. The process 1400 may be invoked when an untrusted application or component of the computing platform 200 attempts to activate the iUI CC module 120 within the iUI CC enclave.

Referring to FIG. 14, at operation 1402, the iUICC loader 121 may receive an enclave whitelist from the remote provisioning service 140 (or EAES 175). The whitelist may be a list of approved iUICC modules with associated keys and/or credentials, which is used to verify that the iUICC module 120 is an authentic iUICC module 120 and not an untrusted application and/or malicious code. In some embodiments, the list of approved iUICC modules may comprise a set of enclave identities, while in other embodiments, the list of approved iUICC modules may comprise a set of enclave measurements. The iUICC loader 121 may be a software module within the iUICC enclave that prepares the iUICC module 120 for execution, including performing attestation procedures, and starts the execution of the iUICC module 120 within the iUICC enclave.

Later, at operation 1404, the communications circuitry 105 may transmit an iUICC activation command to the iUICC module 120 via the iUICC proxy 1 10. The iUICC activation command may be sent to the iUICC module 120 in order to access a network profile for attaching to the network 135, or the iUICC activation command may be sent to the iUICC module 120 in order to access a service-provider profile for accessing one or more services provided by the service provider 145.

In a first embodiment, at operation 1406, the iUICC module 120 may obtain a measurement of the iUICC enclave. In embodiments, the iUICC module 120 may obtain the measurement value from the iUICC SECS. At operation 1408, the iUICC module 120 may provide the measurement of the iUICC enclave to the iUICC loader 121. At operation 1410 the iUICC loader 121 may compare the iUICC enclave measurement with measurements contained in the whitelist.

In a second embodiment, operations 1406 and 1408 may be the same as in the first embodiment. However, at operation 1410 the iUICC loader 121 may use the iUICC enclave measurement to obtain a report for the iUICC enclave. The report may be generated by the iUICC loader 121 using the EREPORT instruction with the iUICC enclave measurement as an input value. The EREPORT instruction may copy fields from the iUICC SECS to populate a report structure with the iUICC enclave measurement, the enclave identity of the iUICC enclave, and/or an SVN of the iUICC module 120. In such embodiments, iUICC loader 121 may then extract the iUICC enclave identity from the generated report and compare the iUICC enclave identity with enclave identities listed in the whitelist.

In a third embodiment, at operation 1406, the iUICC module 120 may generate a report for the iUICC enclave using the EREPORT instruction, and at operation 1408 the iUICC module 120 may provide the report to the iUICC loader 121. At operation 1410, the iUICC loader 121 may then extract the iUICC enclave identity from the report and compare the iUICC enclave identity with enclave identities listed in the whitelist.

In a fourth embodiment, at operation 1406, the iUICC module 120 may generate a report for the iUICC enclave using the EREPORT instruction, and at operation 1408 the iUICC module 120 may provide the report to the iUICC loader 121. At operation 1410, the iUICC loader 121 may obtain a report key using the EREPORT instructions, and compare the obtained report key with keys listed in the whitelist.

At operation 1412, the iUICC loader 121 may load (or not load) the iUICC module 120. Assuming that the iUICC enclave identity was properly verified against the whitelist at operation 1410, then the iUICC loader 121 may load the iUICC module 120 by reading the contents of the iUICC enclave (for example, the EPC pages including the iUICC module) into memory, and then carrying out other required preparatory tasks to prepare the iUICC module for execution. Once loading is complete, the iUICC loader 121 may pass control to the iUICC module 120. Once the attestation has been successfully completed, a trusted channel can be established, and at operation 1414, a trusted communications session with the network 135 may be established and/or services can be securely accessed from the service provider 145. If the iUICC enclave identity was not listed in the whitelist at operation 1410, then the iUICC loader 121 may simply not load the iUICC module 120 or take some other action.

FIG. 15 is a dataflow diagram illustrating an example process 1500 for creating a security domain within an iUICC enclave, in accordance with various embodiments. Process 1500 is the first part of the iUICC remote provisioning procedure discussed with regard to FIG. 9. Although process 1500 is described as creating a security domain of a profile 375 associated with the network operator 150, process 1500 may also be used for creating a security domain for other profiles 375, for example, a profile associated with the service provider 145.

Referring to FIG. 15, at operation 1502, the network operator 150 transmits a profile 375 to the remote provisioning service 140. In embodiments, the network operator 150 may transmit the profile 375 to the SM-SR 165 using an SM-SR address. In some embodiments, the network operation 150 may call a download profile function, which may instruct the SM-DP 160 to enable or disable the newly downloaded profile 375 at the end of the provisioning procedure. Absent such an instruction, the SM-DP 160 may disable the newly downloaded profile 375 at the end of the provisioning procedure by default.

At operation 1504, the remote provisioning service 140 may determine an information set (IS) associated with the iUICC module 120 based on the received profile 375. The IS may include the iUICC ID and the iUICC certificate discussed previously, as well as a production date of the iUICC module 120, a platform type and version of the computing platform 200, a platform type and version of the iUICC module 120 and the iUICC loader, a total memory availability or remaining memory of the iUICC storage, an amount of memory availability or remaining memory of the iUICC storage 125 for profile 375 storage, an SM-SR ID that indicates an identity of the SM-SR 165 in charge of the iUICC module 120, a list of currently installed profiles 375, information related to the ISD-R, information related to the CASD, a signature algorithm used by the iUICC developer or remote provisioning service 140 to sign relevant parts of the IS, and a signature value of the iUICC signature. In some embodiments, the IS may be stored in the SM-SR 165. In such embodiments, the SM-DP 160 may retrieve the IS from the SM-SR 165 using the iUICC ID.

At operation 1506, the remote provisioning service 140 (or SM-DP 160) may determine whether the iUICC module 120 is eligible based on characteristics of the profile 375 to be downloaded. This may include determining whether the profile 375 to be downloaded is compatible with the platform and version of the iUICC module 120 and/or the platform and version of the computing platform 200; determining whether the iUICC storage 125 has enough available memory for the profile 375; and/or determining whether the iUICC module 120 is certified or not by verifying the CASD certificate. The SM-DP 160 may verify the CASD certificate, which was received as part of the IS, using the remote provisioning certificate and a Root Certificate of the CI 155. If any of these conditions is not satisfied or if the verification fails, the SM-DP 160 may end the process 1500. Additionally, SM-DP 160 may extract the CASD public key (P .ECASD.EC A) from the CASD certificate, which may be used for an ECKA during a key establishment procedure (see for example, process 1600 shown and described with regard to FIG. 16).

At operation 1508, when the remote provisioning service 140 determines that the iUICC module 120 is eligible, the remote provisioning service 140 may create a network- side ISD-P for the iUI CC module 120. The ISD-P may include relevant information from the IS.

At operation 1510, the remote provisioning service 140 may establish a communications session with the iUICC module 120. If there is no existing communications session with the iUICC module 120, the SM-SR 165 may trigger a communications session as discussed previously. Additionally, operation 1510 may include invoking an enclave attestation procedure, such as the remote attestation process 1300 shown and described with regard to FIG. 13 or the local attestation process 1400 shown and described with regard to FIG. 14.

After the communications session is established, at operation 1512 the remote provisioning service 140 may transmit an ISD-P command to the iUICC module 120, and at operation 1514 the iUICC module 120 may create the ISD-P based on the ISD-P command. The ISD-P command may instruct the iUICC module 120 to create the ISD-P with relevant information from the IS. In embodiments, the ISD-P created at operation 1514 may be the same or similar to the network-side ISD-P created at operation 1508. In some embodiments, the ISD-P may be loaded into a separate enclave that may be established for the profile 375 to be downloaded. In such embodiments, the iUICC module 120 may establish the separate enclave for the profile 375. This enclave may be established in a similar manner as discussed with regard to FIG. 10. In other embodiments, the iUICC enclave may be updated to include the profile 375 and the ISD-P for the profile 375. After the ISD-P is created within the iUICC enclave or a separate profile enclave, at operation 1516 the iUICC module 120 may transmit an ISD-P response to the remote provisioning service 140 to indicate whether the ISD-P was successfully created or not. At operation 1518, the remote provisioning service 140 may update the IS based on the received ISD-P response.

FIG. 16 is a dataflow diagram illustrating an example process 1600 for establishing one or more keys for authenticating a computing platform 200, in accordance with various embodiments. Process 1600 is the second part of the iUICC remote provisioning procedure discussed with regard to FIG. 9. Although process 1600 illustrates the establishment of one or more keys for a profile 375 associated with the network operator 150, process 1600 may also be used for establishing keys for other profiles 375, for example, a profile associated with the service provider 145.

Referring to FIG. 16, at operation 1602, the remote provisioning service 140 may obtain a remote provisioning service certificate. The remote provisioning service certificate may be the SM-DP certificate (CERT .DP.ECD S A) signed by the CI 155, which may include an SM-DP public key (P .DP.ECDSA).

At operation 1604, the remote provisioning service 140 may establish a communications session with the iUICC module 120 if a communications session has not already been established. Operation 1604 may be the same or similar to operation 1510 discussed previously with regard to FIG. 15 (including an enclave attestation procedure such as process 1200 or process 1300 discussed with regard to FIGS. 12-13). After the communications session is established, at operation 1606 the remote provisioning service 140 may transmit an "establish key command" to the iUICC module 120. In embodiments, the SM-DP 160 may specify the targeted iUICC module 120 and an associated ISD-P, and instruct the SM-SR 165 to transmit the establish key command to the iUICC module 120. The establish key command may include the remote provisioning service certificate obtained at operation 1602. Upon receipt, the ISD-R within the iUICC enclave may forward the establish key command to the ISD-P, which may have been previously created according to the example embodiment depicted by FIG. 15. The ISD-P may verify that the CERT .DP.ECD SA is an SM-DP certificate and may forward the CERT.DP.ECDSA to the CASD or the OSD. The CASD (or OSD) may then verify the CERT.DP.ECDSA with its provisioned public key (P .CI.ECDSA). If the CASD (or OSD) properly verifies the CERT.DP.ECDSA, then the CASD (or OSD) may store the PK.DP.ECDSA from the CERT.DP.ECDSA and generate a random challenge (RC). The CASD (or OSD) may then provide the RC to the ISD-P, and the ISD-P may then provide the RC to the ISD-R. At operation 1608, the iUICC module 120 (or the ISD-R) may transmit the RC to the remote provisioning service 140.

At operation 1610, the remote provisioning service 140 may generate one or more keys and generate a random challenge response (RCR). In embodiments, the SM-DP 160 may generate an ephemeral key pair including an SM-DP ephemeral private /secret key (eSKDP.ECKA) and an SM-DP ephemeral public key (eP .DP.EC A). The SM-DP 160 may generate the RCR by signing the received RC and the generated ePK.DP.ECKA with the SK.DP.ECDSA. At operation 1612, the remote provisioning service 140 (or SM-SR 165) may transmit the RCR to the iUICC module 120.

At operation 1614, the iUICC module 120 may determine a shared secret (ShS) based on the RCR and derive a key set from the ShS. In embodiments, the ISD-P may forward the RCR to the CASD (or OSD) for verification using the previously stored PK.DP.ECDSA, and the CASD (or OSD) may calculate the ShS using the ePK.DP.ECKA and the SK.ECASD.ECKA. In some embodiments, the CASD (or OSD) may derive a key set and (optionally) a derivation random (DR) using the ShS. The CASD (or OSD) may then generate a key response that (optionally) includes the DR. The DR may be derived and placed in the key response based on a request by the SM-DP 160.

At operation 1616, the iUICC module 120 (or ISD-R) may transmit the key response to the remote provisioning service 140 (or SM-SR 165). At operation 1618, the remote provisioning service 140 (or SM-DP 160) may verify the key response, derive the ShS from information contained in the key response, and derive the key set from the ShS. In embodiments, the SM-DP 160 may derive the ShS using the eSK.DP.ECKA and the PK.ECASD.ECKA, and derive the key set using the ShS and (optionally) the DR. In some embodiments, the SM-DP 160 may store the key set and ShS in the IS associated with the iUICC module 120. Additionally, when the profile 375 is to be provisioned for a service provider 145, the SM-DP 160 may provide, via the SM-SR 165, the key set to the service provider 145.

FIG. 17 is a dataflow diagram illustrating an example process 1700 for downloading a profile 375 in accordance with various embodiments. Process 1700 is the third part of the iUICC remote provisioning procedure discussed with regard to FIG. 9. Although process 1700 illustrates how a profile 375 associated with the network operator 150 may be downloaded and installed, process 1700 may also be used for downloading and installing other profiles 375 into the iUICC storage 125, for example, a profile associated with the service provider 145.

Referring to FIG. 17, at operation 1702, the remote provisioning service 140 (or the SM-DP 160) may obtain a profile 375 to be installed in the secure execution environment 115 and an ISD-P ID. The profile 375 may have been received previously, such as during the ISD-P creation procedure (see for example, operation 1502 discussed previously with regard to FIG. 15). At operation 1704, the remote provisionmg service 140 may establish a communications session with the iUICC module 120, if a communications session has not already been established. Operation 1704 may be the same or similar to operation 1510 discussed previously with regard to FIG. 15 and may include enclave attestation.

After the communications session is established, at operation 1706 the remote provisioning service 140 (or SM-SR 165) may transmit the profile 375 and ISD-P ID to the iUICC module 120. At operation 1708, the iUICC module 120 (or ISD-P) may decrypt and install the profile 375. In embodiments, the profile 375 may be loaded into a separate enclave that is established for the profile 375. The profile 375 may be loaded into such an enclave in a similar manner as discussed with regard to FIG. 10. In other embodiments, the iUICC enclave may be updated to include the profile 375.

At operation 1710, the iUICC module 120 (or ISD-R) may transmit an execution response to the remote provisioning service 140 (or SM-SR 165). The execution response may indicate whether the profile 375 was properly downloaded and installed. If the profile 375 was not properly downloaded and installed, the execution response may include a reason or cause of the failure. At operation 1712, the remote provisionmg service 140 (or SM-DP 160) may determine whether the profile 375 download is complete or not based on the received execution response, and at operation 1714, the remote provisioning service 140 (or SM-DP 160) may update the IS accordingly.

At operation 1716, the remote provisioning service 140 may initiate a process to enable the profile 375. An example of an enable profile process is shown and described with regard to FIG. 18. Once enabled, at operation 1718 the remote provisioning service 140 may transmit a profile installation complete message to the network operator 150. The profile installation complete message may indicate whether the profile 375 was properly installed and enabled or not, and if the profile 375 was not properly installed and enabled, the profile installation complete message may indicate a reason or cause of the failure. In some embodiments, the profile installation complete message may also include the derived key set derived at operation 1614 shown and described with regard to FIG. 16. FIG. 18 is a dataflow diagram illustrating an example process 1800 for enabling a provisioned profile 375 in accordance with various embodiments. Process 1800 is the fourth part of the iUICC remote provisioning procedure discussed with regard to FIG. 9. Although process 1800 illustrates how a profile 375 associated with the network operator 150 may be enabled, process 1700 may also be used for enabling other profiles 375, for example, a profile associated with the service provider 145.

Referring to FIG. 18, at operation 1802 the network operator 150 may transmit an enable profile command to the remote provisioning service 140 (or SM-SR 165). In alternative embodiments, the enable profile command may be included with original profile 375 transmission (see operation 1502 in FIG. 15). In such embodiments, operation 1802 may be omitted. At operation 1804, the remote provisioning service 140 (or SM-SR 165) may transmit the enable profile command to the iUICC module 120. In embodiments, the enable profile command sent by the remote provisioning service 140 may include the profile 375 to be enabled (also referred to as a "target profile 375").

In embodiments, the remote provisioning service 140 (or SM-SR 165) may simply relay or forward the enable profile command received from the network operator 150 to the iUICC module 120. In other embodiments, the remote provisioning service 140 (or SM-DP 160) may formulate its own enable profile command based on the enable profile command received from the network operator 150. For example, in some embodiments the SM-SR 165 may include the enable profile command and any other relevant data in a mobile terminated (MF) SMS message. If the network operator 150 sends its enable profile command in an MF-SMS message, then the SM-SR 165 may simply relay that MF-SMS message to the communications circuitry 105. However, if the enable profile command from the network operation 1 0 is included in a Simple Object Access Protocol (SOAP) message, then the SM-SR 165 may extract the header and body of the SOAP message and place that information into an MF-SMS message.

At operation 1806, the iUICC module 120 (or ISD-R) may enforce a profile policy of a currently enabled profile 375. In embodiments, the ISD-R may check the profile policy, and if the profile policy rejects enabling of the target profile 375, the ISD-R may transmit a mobile originated (MO)-SMS message containing a response indicating failure to enable the target profile 375 and a reason for the failure (not shown in FIG. 18). At this point, the process 1800 end.

Assuming that the currently enabled profile policy does not reject enabling the target profile 375, at operation 1808 the iUICC module 120 (or ISD-R) may disable the currently enabled profile 375 and enable the target profile 375 in accordance with the enable profile command received at operation 1804. This profile change may include changing an IMSI that is used to attach to the network 135. In this circumstance, the enable profile command may be accompanied by a refresh command to avoid inconsistent information being read by the communications circuitry 105. So while the targeted profile 375 may be considered enabled at this point in the process 1800, the target profile 375 may actually become effective after the iUICC module 120 executes the refresh command. The refresh command may be executed at operation 1812.

At operation 1810, the iUICC module 120 may transmit a command response to the remote provisioning service 140 indicating whether the profile was successfully enabled or not, and if failed, a reason for the failure. The command response may be included in an MO-SMS message.

At operation 1812, the iUICC module 120 may reset the iUICC module to initiate an attachment procedure with the network 135. Operation 1812 may include executing a refresh command included with the enable profile command. In other embodiments, the iUICC module 120 may reset itself without receiving a refresh command.

At operation 1814, the iUICC module 120 may perform an attachment procedure with the network 135 using the enabled profile 375. In various embodiments, the network attachment procedure may be an attachment procedure defined by a wireless communications protocol, for example, a Radio Resource Control (RRC) connection (or reconnection) establishment procedure and/or a Non-Access Stratum (NAS) attach procedure in LTE networks. An example attachment procedure is shown and described with regard to TIG. 19.

At operation 1816, the iUICC module 120 may transmit a network attachment notification to the remote provisioning service 140 (or SM-SR 165), which may indicate whether the iUICC module 120 and/or the communications circuitry 105 were successful in attaching to the network 135 or not. In some embodiments, the network attachment notification may include a reason for the success or failure to attach to the network 135. This message may be transmitted by one or more SMS messages or one or more HTTPS commands. At operation 1818, the remote provisioning service 140 (or SM-SR 165) may transmit a notification confirmation to the iUICC module 120 confirming receipt of the network attachment notification. If the attachment procedure is successful and or the network attachment notification is successfully received by the remote provisioning service 140, then the process 1800 may proceed to operation 1830 wherein the remote provisioning service 140 may update the IS associated with the iUICC module 120. At operation 1832 the remote provisioning service 140 may transmit an enable profile result to the network operator 150 to indicate that the profile was properly enabled.

However, if a network attachment failure occurs, then the iUICC module 120 (or ISD-R) may disable the current profile 375, and re-enable the previously enabled profile 375 to re-establish network connectivity. The network attachment failure may indicate that the enabled profile 375 cannot provide connectivity; the iUICC module 120 did not succeed in sending the network attachment notification (after having exhausted all possible retries); or the iUICC module 120 did not receive the notification confirmation. The attachment procedure with the re-enabled profile 375 may be attempted using the NAA and IMSI of the previously enabled profile 375. The attachment procedure of the re- enabled profile 375 may be the same or similar to the operations 1802-1818 as discussed previously. The operations between the dashed lines in TIG. 18 may also be performed when a network attachment failure occurs.

At operation 1820, the remote provisioning service 140 (or SM-DP 160) checks and enforces the policy of the now disabled profile (previously the target profile 375) to determine whether the profile should be deleted, and if so, at operation 1822 the remote provisioning service 140 (or SM-SR 165) transmits a delete profile command. The delete profile command may be sent in an MT-SMS message.

At operation 1824, the iUICC module 120 (or ISD-R) checks and enforces the disabled profile's policy to determine whether the disabled profile should be deleted or not. If the disabled profile's policy indicates that the disabled profile should be deleted, then at operation 1826, the iUICC module 120 (or ISD-R) may delete the disabled profile and the associated ISD-P in accordance with the delete profile command. Once the profile and associated ISD-P are deleted from the iUICC enclave, at operation 1828 the iUICC module 120 (or ISD-R) may transmit a profile delete response to the remote provisioning service 140 indicating that the disabled profile 375 and ISD-P were deleted. If the disabled profile's policy indicates that the disabled profile should not be deleted, then the iUICC module 120 (or ISD-R) may proceed to operation 1828 without deleting the disabled profile and associated ISD-P. In this case, at operation 1828 the profile delete response sent to the remote provisioning service 140 (or SM-SR 165) may indicate a failure to delete the disabled profile 375 and ISD-P and may indicate a cause or reason for the failure.

Upon receipt of the profile delete response, at operation 1830 the remote provisioning service 140 (or SM-DP 160) may update the IS, and at operation 1832 the remote provisioning service 140 (or SM-SR 165) may transmit an enable profile result to the network operator 150 based on whether the profile was properly enabled or not.

FIG. 19 is a dataflow diagram illustrating an example process 1900 for attaching to a network 135 using an enabled profile 375 in accordance with various embodiments. For illustrative purposes, the operations of process 1900 are described for attaching to an LTE network. However, process 1900 may be used for attaching to other networks using an enabled profile 375.

Referring the FIG 19, at operation 1902, the communications circuitry 105 may transmit an iUICC activation command to the iUICC module 120. In response to receiving the iUICC activation command, at operation 1903 the iUICC module 120 may perform an iUICC enclave attestation procedure, such as the remote attestation process 1300 shown and described with regard to FIG. 13 or the local attestation process 1400 shown and described with regard to FIG. 14.

In response to the iUI CC activation command, at operation 1904 the iUICC module 120 may transmit an ATR sequence and a Protocol and Parameter Selection (PPS) message to the communications circuitry 105. The communications circuitry 105 may then communicate data with the iUICC module 120 by way of the iUICC proxy 1 10 using information contained in the ATR and the PPS. The ATR may include a sequence of characters (each, one byte of data), that inform the communications circuitry 105 about various characteristics of the iUICC module 120. The various characteristics may include a transport protocol to be used for transmitting/receiving data to/from the iUICC module 120, transmission rate, serial number, mask version number, and/or other like information. The PPS may be used to negotiate or select different communications parameters than those specified by the ATR. The specific PPS procedure used may be based on whether the iUICC module 120 is initialized upon powering up the computing platform 200 (referred to as a "cold reset") or initialized to select a different communications protocol for the communications circuitry 105 (referred to as a "warm reset"), for example, switching from using LTE protocols to WiMAX protocols or vice versa.

Once the communications parameters are negotiated and selected, at operation 1906, the iUICC module 120 may select a profile 375 for communicating over the network 135. For example, a first profile may be a Universal Mobile Telecommunications System (UMTS) Subscriber Identity Module (SIM) (also referred to as a "Universal SIM" or "USIM") for authentication of the computing platform 200 to access a UMTS or an LTE network; a second profile may be a GSM SIM for authentication of the computing platform 200 to access a GSM network; a third profile may be a Code Division Multiple Access (CDMA) SIM (CSIM) for authentication of the computing platform 200 to access a CDMA network; a fourth profile may be an IP Multimedia Services SIM (ISIM) for authentication of the computing platform 200 to access an IP multimedia subsystem (IMS) applications; and a fifth profile may be a iMAX SIM (WiSIM) for authenticating the computing platform 200 to access a WiMAX network. Each of the profiles 375 may be associated with their own NAA, IMSI, and secret key (Ki), such that an NAA, an IMSI, and a Ki associated with a first profile 375 may be different than the NAA, IMSI, and Ki associated with a second profile 375.

At operation 1908, the iUICC module 120 may provide the IMSI and/or NAA information to the communications circuitry 105, which may be used to establish a connection with the network 135. At operation 1910, the communications circuitry 105 may perform a connection setup procedure with the network 135 using the IMSI and/or NAA information. For example, in embodiments where the network 135 is an LTE network and the selected profile 375 is a USIM profile, operation 1910 may include establishing an R C connection with an evolved nodeB (eNB) associated with the network 135 according the LTE standards. In such embodiments, the communications circuitry 105 may transmit an Attach Request message to the eNB, which may be used to establish a non-access stratum (NAS) connection with a core network element (for example, a mobility management entity (MME) within the network 135. The Attach Request message may include the IMSI and/or NAA information, such as security capability information. The IMSI and/or security capability information may be used to authenticate the computing platform 200 and perform a key agreement (AKA) procedure.

At operation 1914, the network 135 derives or obtains authentication mformation (AI) based on the IMSI and/or NAA information. The Ki associated with the selected profile 375 should be known by the network 135 associated with the selected profile 375. The network 135 may use the received IMSI to determine the Ki on the network 135 side, and may use the Ki to generate the AI. For example, in embodiments where the network 135 is an LTE network, the AI may include a random number (RAND), an authentication token (AUTN), expected response (XRES), and one or more keys. In such embodiments, an MME may use the IMSI to request an authentication vector (AV) from a Home Subscriber Server (HSS)/Authentication Center (AuC). The HSS/AuC may use the IMSI to look up the network-side Ki and a sequence number (SQN) associated with the IMSI. The AuC may increase the SQN and generate the RAND and the AV. The AV may comprise the following parameters: the XRES, the AUTN, a cipher key (C ), an integrity key (IK), and the RAND. The AV excluding the CK and IK may be provided to the MME. Instead of providing the CK and IK to the MME, the HSS/AuC may generate an Access Security Management Entity (ASME) key, (K-ASME) based on the CK, IK and other parameters, such as a serving network identity (SN ID) and the SQN. The MME may then store the AV parameters. The MME may also generate an ASME key set identifier (KSI- ASME), which is an index for the K-ASME. The KSI-ASME may be used by the iUICC module 120 to identify the K-ASME (and further keys derived from the K-ASME) that results from the AKA procedure.

At operation 1916, the network 135 may transmit an Authentication Request to the communications circuitry 105, which is then passed to the iUICC module 120 via the iUICC proxy 110. In embodiments where the network 135 is an LTE network, the MME may keep the K-ASME and the XRES, and include the RAND, AUTN, and the KSI- ASME in the Authentication Request. At operation 1918, the iUICC may generate or derive a response (RES) based on the information received in the Authentication Request. In embodiments where the network 135 is an LTE network and the selected profile 375 is a USIM profile, the iUICC module 120 may use the Ki and an SQN of the selected profile 375 to calculate its own version of the AUTN. The iUICC module 120 may compare the calculated AUTN with the received AUTN, and if they are consistent, the network 135 may be considered "authenticated." Further, in such embodiments, the iUICC module 120 may calculate the RES using one or more cryptographic functions with the Ki and the RAND as input parameters. Once the RES is generated, at operation 1920, the iUICC module 120 may provide the RES to the communications circuitry 105. At operation 1922 the communications circuitry 105 may generate an Authentication Response including the RES, and transmit the Authentications Response to the network 135 (for example, the MME).

At operation 1924, the network 135 may authenticate (Auth) the computing platform 200 and derive various keys to be used for communicating with the computing platform 200. In embodiments where the network 135 is an LTE network, the MME may authenticate the computing platform 200 by verifying that the RES is equal to XRES. In such embodiments, the MME may use the K-ASME to derive the CK and IK. In embodiments, the K-ASME to derive the CK and IK, and the other keys discussed herein, may be derived using key derivation functions delineated by current LTE standards, such as Third Generation Partnership Project (3GPP) technical specification (TS) 33.401 , version 13.2.0 (2016-03).

Once the authentication is complete, at operation 1926 the network 135 may transmit a security command to the iUICC module 120. In embodiments where the network 135 is an LTE network, the security command may include ciphering and integrity algorithms to be used for encoding NAS messages. The security command may also be referred to as a "security mode command" or a "NAS security mode command." At operation 1928, the iUICC may generate keys to be used for encrypting/decrypting messages transmitted/received to/from the network 135. In embodiments where the network 135 is an LTE network, the iUICC module 120 may compute the CK and IK using the ciphering and integrity algorithms in the security command. In some embodiments, the iUICC module 120 may derive the K-ASME using the CK, IK, SQN, and SN ID as inputs, and may store the K-ASME using the received KSI-ASME as its index. Thereafter, KSI-ASME is used instead of K-ASME during a NAS security setup between the computing platform 200 and the MME.

At operation 1930, the iUICC module 120 may transmit a security setup complete message to the network 135. The security setup complete message may also be referred to as a "security mode setup complete message" or a "NAS security mode setup complete message." In other embodiments, at operation 1930, the communications circuitry 105 may generate and transmit the security setup complete message to the network 135. In embodiments where the network 135 is an LTE network, the security setup complete message may be used to inform the MME of the successful generation of the IK and CK by having the security setup complete message encrypted and integrity protected using the generated keys. At operation 1932, the network 135 and/or the computing platform 200 may establish a communications session. In embodiments where the network 135 is an LTE network, the session may be established by performing a location update procedure and an Evolved Packet System (EPS) session establishment procedure according to LTE standards.

Additionally, although not shown by FIG. 19, in various embodiments the MME may derive an eNB key (K-eNB) for an E-UTRAN cell or evolved nodeB (eNB), and the MME may provide the eNB with the K-eNB in an Attach Accept message encapsulated in an Initial Context Setup Request message. The Attach Accept message may be a response to the Attach Request message discussed previously. The eNB may generate access stratum (AS) security keys from the K-eNB for encrypting/decrypting radio resource control (RRC) messages and user traffic to/from the computing platform 200. The AS security keys may include an RRC integrity key (IK-RRC), an RRC ciphering key (CK- RRC), and a key for ciphering user traffic (uK). The eNB may transmit an AS security mode command to the communications circuitry 105, which includes ciphering and integrity algorithms to be used for encoding RRC messages. The iUICC module 120 may generate/derive the C -RRC, IK-RRC, and uK using the ciphering and integrity algorithms in the AS security mode command. The iUICC module 120 may generate an AS security mode setup complete message, which may be transmitted by the communications circuitry 105 to the eNB-1. The AS security mode setup complete message may be encrypted and integrity protected using the generated IK-RRC and CK- RRC.

FIG. 20 is a dataflow diagram illustrating an example process 2000 for accessing services using an enabled profile 375 in accordance with various embodiments. In FIG 20, operations 2002, 2003, and 2004 may be the same or similar to operations 1902, 1903, and 1904 discussed with regard to FIG. 19. At operation 2006, the iUICC module 120 may select a profile 375 for accessing one or more services from service provider 145. At operation 2006, a communications session may be established by, for example, attaching the network 135 according to process 1900 discussed with regard to FIG. 19.

At operation 2008, the communications circuitry 105 may transmit a command to activate a profile 375 associated with the service provider 145, and at operation 2010 the iUICC module 120 may disable the currently enabled profile and enable the service provider profile 375. The service provider profile 375 may include an ISD-P, which may have been established according to process 1500 of FIG. 15; a key set, which may have been established by both the iUICC module 120 and the remote provisioning service 140 according to process 1600 of FIG. 16; and subscription information, which may have been downloaded with the profile 375 according to process 1700 of FIG. 17. Once the service provider profile 375 is enabled, at operation 2012 the iUICC module 120 may generate authentication information (AI). In embodiments, to generate the AI, the ISD-P or OSD of the profile 375 or a CASD of the iUICC module 120 may sign the subscription information and the public key of the key set with the private key of the key set. In some embodiments, the ISD-P, OSD, or CASD may also generate a random number or nonce, and include the random number or nonce in the AI.

At operation 2014 the iUICC module 120 may provide the AI to the communications circuitry 105. The communications circuitry 105 may combine the AI with a service request message, and at operation 2016 the communications circuitry 105 may transmit a service request to the service provider 145. The service request may be a typical HTTP or SOAP request message that includes the AI in the header or body of the message. At operation 2018, the service provider 145 may decrypt and verify the AI in the service request message using the key set. In embodiments, the key set may have been provided to the service provider 145 from the remote provisioning service 140 during the key establishment procedure 1600.

Assuming that the iUICC module 120 is properly verified, at operation 2020 the service provider 145 may establish an end-to-end encrypted tunnel (also referred to as a "secure channel") with the communications circuitry 105. Once the end-to-end encrypted tunnel is established, at operation 2022 the service provider 145 may provide the one or more services to the computing platform 200.

FIG. 21 is a dataflow diagram illustrating an example process 2100 for intra- enclave access in accordance with various embodiments. For illustrative purposes, the operations of process 2100 are described as being performed by iUICC module 120 to access profile data within a profile 375. However, process 2100 may be used by any enclave to access data or program code from another enclave.

Referring to FIG. 21 , upon proper activation of the iUICC module 120, at operation 2102 the iUICC module 2101 may obtain a measurement of the iUI CC enclave. In embodiments, the iUICC module 120 may obtain the measurement value from the iUICC SECS. At operation 2104, the iUICC module 120 may provide the iUICC enclave measurement to the enclave including the profile 375. In some embodiments, the communication path between the iUICC enclave and the profile enclave is secure, while in other embodiments, the communication path between the iUICC enclave and the profile enclave is not secure.

At operation 2106, the profile 375 may obtain an iUICC report using the iUICC enclave measurement. A report for the iUICC enclave may be generated by the profile enclave using the EREPORT instruction with the iUICC enclave measurement as an input value. The EREPORT instruction may copy fields from the iUICC SECS to populate a report structure with the iUICC enclave measurement, the enclave identity of the iUICC enclave, and/or an SVN of the iUICC module 120.

At operation 2108, the profile 375 may provide the iUICC report to the iUICC module 120, and at operation 21 10 the iUICC module 120 may verify the iUICC report. To verify the report, the iUICC module 120 may use the EGETKEY instruction to derive a report key. As mentioned previously, the report key returned by the EGETKEY instruction is derived from a secret embedded in the application circuitry 302 and the iUICC enclave measurement. The cryptographic properties of the underlying key derivation ensure that only the secure execution environment 115 implementation can produce the report key since only the secure execution environment 1 15 can access the embedded secret, and it would be impossible for an attacker to derive the report key without knowing the secret. Therefore, the iUICC module 120 may determine that the profile 375 is implemented in the secure execution environment 1 15 (and therefore is a trusted entity) so long as the iUICC module 120 is able to decrypt the report received from the profile enclave using the report key.

In some embodiments, the iUICC SEC may include a Message Authentication Code (MAC), which may be included in the report at operation 2106. In such embodiments, the iUICC module 120 may decrypt the report using the report key, and recompute its own MAC using a block cipher algorithm, determine the MAC from the report, and compare the re-computed MAC with the MAC accompanying the report. A match in the MAC value affirms that the profile enclave is indeed running in the same secure execution environment 115 as the iUICC enclave.

Referring back to FIG. 21, at operation 21 12 the profile 375 may provide a measurement of the profile enclave to the iUICC module 120. At operation 2114, the iUICC module 120 may obtain a profile report using the profile enclave measurement. At operation 21 16, the iUICC module 120 may provide the profile report to the profile 375. At operation 2118, the profile 375 may verify the profile report. Operations 2112-21 18 may be implemented in The same or similar manner as discussed previously with regard to operations 2102-21 10.

Assuming that the profile report was properly verified by the profile 375, at operation 2120 the iUICC module 120 and the profile 375 may establish an end-to-end encrypted tunnel (or secure channel) for exchanging data. The secure channel may be established according to GSMA standards, GlobalCard Platform standards, and/or other like standards. In embodiments, the secure channel may be established between an ISD-P 243 of the profile 375 and the ISD-R 240 of the iUICC module 120 (see for example, FIG. 2). At operation 2122, the iUICC module 120 and the profile 375 may exchange data. In embodiments, the data may include platform management instructions for provisioning the profile, enabling/disabling the profile, and the like. The data may also include outputs to be provided to untrusted applications or components outside the secure execution environment 115. For example, these outputs may be outputs from an NAA 220 or one or more applications 225, or the outputs may be user data 230 and/or credentials 235.

Some non-limiting Examples are provided below.

Example 1 may include a platform comprising cellular modem circuitry to facilitate communications over a cellular network; and program code of an integrated universal integrated circuit card, "iUICC," module to communicate with a remote provisioning service over the cellular network, wherein the iUICC module is to be implemented within: the cellular modem circuitry; or a secure execution environment of a host architecture coupled with the cellular modem circuitry, wherein the program code of the iUICC module is to be executed by an application processor of the host architecture when the iUICC module is implemented within the secure execution environment of the host architecture.

Example 2 may include the platform of example 1 and/or some other examples herein, wherein, when the iUICC module is implemented in the secure execution environment of the host architecture, the platform further comprises: management engine, "ME," circuitry coupled with the cellular modem circuitry, wherein the iUICC module is to communicate with the cellular modem circuitry via the ME circuitry.

Example 3 may include the platform of example 2 and/or some other examples herein, wherein the platform further comprises: an iUICC proxy to be implemented by the ME circuitry, wherein the iUICC proxy is to communicatively couple the iUICC module with the cellular modem circuitry.

Example 4 may include the platform of example 3 and/or some other examples herein, further comprising: a private low pin count, "LPC," serial bus coupling the cellular modem circuitry with the ME circuitry, wherein the LPC serial bus is not exposed to a host operating system of the platform.

Example 5 may include the platform of any one of examples 1-4 and/or some other examples herein, wherein, when the iUICC module is implemented in the secure execution environment of the host architecture, the secure execution environment comprises: one or more secure enclaves, wherein the one or more secure enclaves are isolated regions of one or more computer readable media of the host architecture, wherein the program code of the iUICC module is stored in an iUICC enclave of the one or more secure enclaves, and wherein the application processor of the host architecture is to execute the program code of the iUICC module in the iUICC enclave.

Example 6 may include the platform of example 5 and/or some other examples herein, wherein the iUICC module is to: receive a first request to activate the iUICC module from the application processor of the host architecture; transmit, to an enclave attestation and enrollment server, "EAES," via the cellular modem circuitry, a second request for attestation including a public key associated with the iUICC module; receive, from the enrollment server via the cellular modem circuitry, an attestation response based on a determination of whether the public key is registered in a whitelist; and permit the iUICC enclave to launch when the attestation response indicates that the public key is registered in the whitelist.

Example 7 may include the platform of example 5 and/or some other examples herein, wherein the iUICC enclave further includes an iUICC loader separate from the iUICC module, and wherein the iUICC loader is to: receive, from an EAES via the cellular modem circuitry, a whitelist of registered iUICC modules including associated public keys; receive a request to operate the iUICC module; determine whether a public key associated with the iUICC module is in the whitelist; and verify the iUICC module when the public key is in the registered whitelist.

Example 8 may include the platform of example 7 and/or some other examples herein, wherein the iUICC module is encrypted within the iUICC enclave, and wherein the iUICC loader is to: receive, from an enrollment server via the cellular modem circuitry, a private key associated with the iUICC module; and decrypt the iUICC module using the private key.

Example 9 may include the platform of example 1 and/or some other examples herein, wherein, when the iUICC module is implemented in the cellular modem circuitry, the iUICC module is to communicate with one or more modules of the cellular modem circuitry via an iUICC proxy implemented by the cellular modem circuitry.

Example 10 may include the platform of any one of examples 3, 5, or 9 and/or some other examples herein, wherein the platform is to establish a first end-to-end encrypted tunnel between the secure execution environment and a security assist server, "SAS," to facilitate a provisioning of the iUICC module and establish a second end-to-end encrypted tunnel between the iUICC proxy and the SAS to facilitate a provisioning of the iUICC proxy, wherein the first end-to-end encrypted tunnel is independent from the second end-to-end encrypted tunnel.

Example 11 may include the platform of example 10 and/or some other examples herein, wherein the iUICC module is to obtain a first certificate from the SAS for a first asymmetric key pair through the first end-to-end encrypted tunnel and the iUICC proxy is to obtain a second certificate from the SAS for a second asymmetric key pair through the second end-to-end encrypted tunnel.

Example 12 may include the platform of example 11 and/or some other examples herein, wherein the iUICC module and the iUICC proxy are to exchange application protocol data units, "APDUs," using asymmetric cryptography based on the first asymmetric key pair and the second asymmetric key pair.

Example 13 may include the platform of examples 1- 12 and/or some other examples herein, wherein the iUICC module is to communicate with the remote provisioning service through the iUICC proxy according to one or more Groupe Speciale Mobile Association, "GSMA," specified interfaces.

Example 14 may include the platform of examples 1- 12 and/or some other examples herein, wherein the platform is implemented in a laptop personal computer, "PC," a tablet PC, a smartphone, a wearable computing device, or a machine-type communication device.

Example 15 may include the platform of examples 2- 12 and/or some other examples herein, wherein the ME circuitry is a system-on-chip embedded in the host architecture, embedded in the cellular modem circuitry, or mounted separate from the host architecture or the cellular modem circuitry.

Example 16 may include one or more computer-readable media having instructions that, when executed by one or more processors, cause a computing device to: implement an integrated Universal Integrated Circuit Card, "iUICC," module within a secure execution environment, wherein to operate the iUICC module within the secure execution environment, the one or more processors are to execute the instructions to: transmit authentication information to management engine, "ME," circuitry, wherein the ME circuitry is to provide the authentication information to modem circuitry for communication over a cellular network. The one or more computer-readable media may be non-transitory computer-readable media.

Example 17 may include the one or more computer-readable media of example 16 and/or some other examples herein, wherein the ME circuitry includes at least one processor to operate an iUICC proxy for communication with the iUICC module.

Example 18 may include the one or more computer -readable media of example 16 and/or some other examples herein, wherein the secure execution environment includes an iUICC enclave in which the iUICC module is to operate, and wherein to operate the iUICC module, the one or more processors are further to execute the instructions to: receive, from the modem circuitry via the ME circuitry, a first command to establish a security domain associated with a profile to be provisioned in the secure execution environment, wherein the profile is associated with a cellular network operator to be used for accessing a cellular network of the cellular network operator, or wherein the profile is associated with a service provider to be used for accessing one or more services provided by the service provider; establish the security domain associated with the profile based on the first command; receive, from the modem circuitry via the ME circuitry, a second command to establish one or more keys according to an asymmetric key agreement algorithm, the one or more keys to be associated with a profile to be provisioned; establish the one or more keys based on the second command; receive, from the modem circuitry via the ME circuitry, the profile to be provisioned; establish a portion in the secure execution environment for storing the profile; store the profile in the portion of the secure execution environment; receive, from the modem circuitry via the ME circuitry, a third command to enable the profile after storage of the profile in the portion of the secure execution environment; and perform a network attachment procedure to enable the profile, and wherein the first command, the second command, and the third command are provided to the modem circuitry by a remote provisioning service using over-the-air interfaces.

Example 19 may include the one or more computer-readable media of example 18 and/or some other examples herein, wherein to establish the one or more keys, the one or more processors are further to execute the instructions to: transmit, to the modem circuitry via the ME circuitry, a random challenge for the remote provisioning service; receive, from the modem circuitry via the ME circuitry, a random challenge response from the remote provisioning service; determine a shared secret based on the random challenge response; derive the one or more keys based on the shared secret; and transmit, to the modem circuitry via the ME circuitry, a key response for the remote provisioning service to indicate that the one or more keys have been established.

Example 20 may include the one or more computer -readable media of example 18 and/or some other examples herein, wherein the profile is associated with the cellular network operator and to perform the network attachment procedure, the one or more processors are further to execute the instructions to: transmit, to the modem circuitry via the ME circuitry, an International Mobile Subscriber Identity, IMSI, associated with the enabled profile, wherein the modem circuitry is to use the IMSI for a connection setup procedure with the cellular network using the over-the-air interfaces; receive, from the modem circuitry via the ME circuitry, an authentication request provided to the modem circuitry by the cellular network; and generate an authentication response based on information included in the authentication request; transmit, to the modem circuitry via the ME circuitry, the authentication response, wherein the modem circuitry is to provide the authentication response to the cellular network using the over-the-air interfaces; receive, from the modem circuitry via the ME circuitry, a security command, wherein the security command is to indicate ciphering and integrity algorithms to be used for encoding messages to be communicated over the cellular network; generate, based on the security command, a key set for encoding messages to be communicated over the cellular network; and store the key set in association with the profile.

Example 21 may include the one or more computer -readable media of example 18 and/or some other examples herein, wherein, when the profile is associated with the cellular network operator, the profile comprises : a Universal Mobile Telecommunications System, "UMTS," Subscriber Identity Module, "SIM," used to access a Long Term Evolution network or a UMTS network; a Global System for Mobile Communications, "GSM," SIM used to access a GSM network; a Code Division Multiple Access, "CDMA," SIM used to access a CDMA network; an IP Multimedia Services SIM, "ISIM," used to access an IP multimedia subsystem application; or a Worldwide Interoperability for Microwave Access, "ΛΥίΜΛΧ.^" SIM used to access a WiMAX network.

Example 22 may include the one or more computer -readable media of example 16 and/or some other examples herein, wherein the secure execution environment comprises a plurality of profiles, and wherein the plurality of profiles includes a first profile comprising a UMTS SIM, a second profile comprising a GSM SIM, a third profile comprising a CDMA SIM, a fourth profile comprising an ISIM, and a fifth profile comprising a WiMAX SIM.

Example 23 may include the one or more computer-readable media of examples 16 or 18 and/or some other examples herein, wherein the secure execution environment includes one or more secure enclaves, wherein the one or more secure enclaves are defined by Software Guard Extensions.

Example 24 may include a computing device comprising: one or more computer- readable media including one or more secure enclaves, wherein an integrated universal integrated circuit card, "iUICC," enclave of the one or more secure enclaves includes program code for an iUICC module; and one or more processors to execute the program code of the iUICC module to communicate over a cellular network.

Example 25 may include the computing device of example 24 and/or some other examples herein, wherein to communicate over the cellular network, the one or more processors are to execute the program code of the iUICC module to: communicate with a remote provisioning service for remote provisioning of one or more cellular network operator profiles in the secure execution environment, wherein the remote provisioning of the one or more cellular network operator profiles includes enablement of the one or more cellular network operator profiles or disablement of the one or more cellular network operator profiles.

Example 26 may include the computing device of example 24 and/or some other examples herein, wherein the computing device further comprises: cellular modem circuitry; and management engine, "ME," circuitry coupled with the cellular modem circuitry, wherein the iUICC module is to communicate with the cellular modem circuitry via the ME circuitry.

Example 27 may include the computing device of example 26 and/or some other examples herein, wherein the ME circuitry is to implement an iUICC proxy to communicatively couple the iUICC module with the cellular modem circuitry.

Example 28 may include the computing device of example 27 and/or some other examples herein, wherein the ME circuitry is coupled with the cellular modem circuitry by a private low pin serial bus.

Example 29 may include the computing device of example 27 and/or some other examples herein, wherein the iUICC module and the iUICC proxy are to exchange application protocol data units, "APDUs," using asymmetric cryptography using a private key for signing the APDUs and a public key for verification of the APDUs.

Example 30 may include the computing device of examples 25-29 and/or some other examples herein, wherein the iUICC module is to communicate with the remote provisioning service through Groupe Speciale Mobile Association-specified interfaces.

Example 31 may include the computing device of examples 24-30 and/or some other examples herein, wherein the one or more secure enclaves are defined by Software Guard Extensions, and wherein the computing device is a laptop personal computer, "PC," a tablet PC, a smartphone, a wearable computing device, or a machine-type communication device.

Example 32 may include a method for implementing an integrated universal integrated circuit card, "iUICC," module, the method comprising: establishing, by a computing device, an iUICC enclave to include the iUICC module; establishing, by the computing device, an iUICC proxy for exchange of data between the iUICC module and communications circuitry of the computing device; and attaching, by the computing device, to a cellular network using information within the iUICC enclave or within another enclave associated with the iUICC enclave.

Example 33 may include the method of example 32 and/or some other examples herein, wherein establishing the iUICC enclave comprises: obtaining, by the computing device, program code for the iUICC module; receiving, by the computing device, a command to establish the iUICC enclave; initializing, by the computing device, a control structure for the iUICC enclave; loading, by the computing device, the program code for the iUICC module into the iUICC enclave; and initializing, by the computing device, the iUICC enclave.

Example 34 may include the method of example 33 and/or some other examples herein, wherein establishing the iUICC enclave further comprises: measuring, by the computing device before initializing the iUICC enclave, the iUICC enclave to obtain an iUICC enclave measurement; and providing, by the computing device, the iUICC enclave measurement for verification and attestation of the iUICC enclave.

Example 35 may include the method of example 34 and/or some other examples herein, wherein the providing the iUICC enclave measurement to the entity comprises: providing, by the computing device to communications circuitry of the computing device, the iUICC enclave measurement for transmission to a remote attestation platform; or providing, by the computing device, the iUICC enclave measurement to an attestation enclave.

Example 36 may include the method of example 35 and/or some other examples herein, wherein the remote attestation platform is an enclave attestation and enrollment server, EAES, and wherein the attestation enclave is located in a secure execution environment of the computing device.

Example 37 may include the method of example 36 and/or some other examples herein, wherein the secure execution environment is implemented by application circuitry of the computing device or cellular modem circuitry of the computing device.

Example 38 may include the method of any one of examples 36-37 and/or some other examples herein, wherein the iUICC module is to establish a security domain associated with a profile, establish one or more keys associated with the profile, obtain the profile, and enable the profile, wherein the profile is the information within the iUICC enclave or within the other enclave.

Example 39 may include the method of any one of examples 32-38 and/or some other examples herein, wherein establishing the iUICC proxy comprises: obtaining, by the application circuitry, program code for the iUICC proxy; and installing, by the application circuitry, the program code for the iUICC proxy.

Example 40 may include the method of example 39 and/or some other examples herein, wherein the program code for the iUICC proxy is obtained from a remote provisioning service or a security assist server.

Example 41 may include the method of examples 39 or 40 and/or some other examples herein, wherein the program code for the iUICC proxy is obtained at a same time as obtaining the program code for the iUICC module or the program code for the iUICC proxy is obtained after obtaining the program code for the iUICC module.

Example 42 may include the method of any one of examples 39-41 and/or some other examples herein, wherein installing the program code for the iUICC proxy comprises: installing, by the application circuitry, the program code for the iUICC proxy in the application circuitry of the computing device outside of the secure execution environment; or installing the program code for the iUICC proxy in management engine, ME, circuitry of the computing device, wherein the ME circuitry is a chipset separate from application circuitry of the computing device.

Example 43 may include the method of any one of examples 39-42 and/or some other examples herein, wherein the iUICC proxy is implemented as a secure application programming interface, API, or implemented as middleware.

Example 44 may include the method of any one of examples 32-43 and or some other examples herein, wherein attaching to the network comprises : obtaining, by the computing device, the information within the iUICC enclave or within the other enclave associated with the iUICC enclave; providing, by the computing device, the information to communications circuitry for transmission to a network element of the cellular network, wherein the cellular network is to use the information to authenticate the computing device; and establishing a communications session with the cellular network when the computing device is authenticated by the cellular network.

Example 45 may include the method of example 44 and/or some other examples herein, wherein attaching to the network further comprises : receiving, by the computing device from the communications circuitry, an authentication request; and providing, by the computing device to the iUICC module via the iUICC proxy, the authentication request, wherein the iUICC module is to use information contained in the authentication request to generate one or more keys for communicating with the cellular network. Example 45.5 may include an apparatus comprising: means for executing the method of any one of examples 32-46 and/or some other examples herein.

Example 46 may include one or more computer-readable media including instructions to cause a computer device, in response to execution of the instructions by the computer device, to perform the method of any one of examples 32-45 and/or some other examples herein.

Example 47 may include the one or more computer -readable media of example 46 and/or some other examples herein, wherein the computer device is a laptop personal computer, "PC," a tablet PC, a smartphone, a wearable computing device, or a machine- type communication device.

Example 48 may include a method for remote provisioning an integrated universal integrated circuit card, "iUICC," module, the method comprising: establishing, by the iUICC module, a security domain associated with a profile; establishing, by the iUICC module, one or more keys associated with the profile; receiving and installing, by the iUICC module, the profile; and enabling, by the iUICC module, the profile.

Example 49 may include the method of example 48 and/or some other examples herein, wherein establishing the security domain comprises: receiving, by the iUICC module from a remote provisioning service, a security domain command including an instruction to establish the security domain; creating, by the iUICC module, the security domain within an iUI CC enclave or a profile enclave that is established for the profile; and transmitting, by the iUICC module to the remote provisioning service, a security domain response indicating that the security domain was properly established or an indication that the security domain was not properly established.

Example 50 may include the method of example 49 and/or some other examples herein, wherein when the security domain response indicates that the security domain was not properly established, the security domain response further indicates a reason for failure to properly establish the security domain.

Example 51 may include the method of any one of examples 48-50 and/or some other examples herein, wherein establishing the one or more keys comprises: receiving, by the iUICC module from the remote provisioning service, an establish key command including an instruction to establish the one or more keys; deriving, by the iUICC module, the one or more keys based on the establish key command; and transmitting, by the iUICC module to the remote provisioning service, a key response including an indication that the one or more keys were properly established or that the one or more keys were not properly established.

Example 52 may include the method of example 51 and/or some other examples herein, wherein when the key response indicates that the one or more keys were not properly established, the key response further indicates a reason for failure to properly establish the one or more keys.

Example 53 may include the method of examples 51-52 and/or some other examples herein, wherein establishing the one or more keys further comprises: verifying, by the iUICC module, a certificate contained in the establish key command; generating, by the iUICC module, a random challenge based on proper verification of the certificate contained in the establish key command; transmitting, by the iUICC module to the remote provisioning service, the random challenge; receiving, by the iUICC module from the remote provisioning service, a random challenge response; deriving, by the iUICC module, the one or more keys based on the random challenge response; and transmitting, by the iUICC module to the remote provisioning service, the key response upon derivation of the one or more keys.

Example 54 may include the method of example 53 and/or some other examples herein, further comprising: storing, by the iUICC module, a public key of the certificate contained in the establish key command upon proper verification of the certificate contained in the establish key command.

Example 55 may include the method of example 54 and/or some other examples herein, wherein the random challenge response comprises a message including the random challenge and an ephemeral public key that is signed using a secret key, and wherein deriving the one or more keys comprises: verifying, by the iUICC module, the random challenge response using the stored public key from the certificate to obtain the ephemeral public key; deriving, by the iUICC module, a shared secret using the ephemeral public key and a stored secret key; generating, by the iUICC module, a derivation random using the shared secret; and generating, by the iUICC module, the key response to include the derivation random.

Example 56 may include the method of any one of examples 49-55 and/or some other examples herein, wherein receiving and installing the profile comprises: receiving, by the iUICC module from the remote provisioning service, the profile; decrypting, by the iUICC module, the profile using the established one or more keys; performing one of: loading, by the iUICC module, the decrypted profile into the profile enclave, or updating, by the iUICC module, the iUICC enclave to include the decrypted profile; and transmitting, by the iUICC module to the remote provisioning service, an execution response indicating that the profile was properly installed or that the profile was not properly installed.

Example 57 may include the method of example 56 and/or some other examples herein, wherein when the execution response indicates that the profile was not properly installed, and the execution response further indicates a reason for failure to properly install the profile.

Example 58 may include the method of any one of examples 49-57 and/or some other examples herein, wherein receiving and installing the profile comprises: receiving, by the iUICC module from the remote provisioning service, an enable profile command; enabling, by the iUICC module, the profile based on the enable profile command; transmitting, by the iUICC module to the remote provisioning service, a command response indicating that the profile was properly enabled or that the profile was not properly enabled; resetting, by the iUICC module, the iUICC module to initiate an attachment procedure; and initiating, by the iUI CC module, the attachment procedure.

Example 59 may include the method of example 58 and/or some other examples herein, wherein when the command response indicates that the profile was not properly enabled, the command response further indicates a reason for failure to properly enable the profile.

Example 60 may include the method of examples 58-59 and/or some other examples herein, wherein after performance of the attachment procedure, the method comprises: transmitting, by the iUICC module to the remote provisioning service, an attachment notification indicating whether the attachment procedure was successful or unsuccessful; and receiving, by the iUICC module from the ranote provisioning service, an attachment notification confirmation.

Example 61 may include the method of example 60 and/or some other examples herein, wherein after performance of the attachment procedure, the method comprises : transmitting, by the iUICC module to the remote provisioning service, an attachment notification indicating whether the attachment procedure was successful or unsuccessful; determining, by the iUICC module, that the attachment notification confirmation has not been received from the remote provisioning service; disabling, by the iUICC module, the profile when the attachment notification confirmation has not been received from the remote provisioning service; and enabling, by the iUICC module, a previously enabled profile for attaching to a network associated with the previously enabled profile. Example 62 may include the method of example 60 and/or some other examples herein, wherein after performance of the attachment procedure, the method comprises : transmitting, by the iUICC module to the remote provisioning service, an attachment notification indicating that the attachment procedure was unsuccessful; disabling, by the iUICC module, the profile when the attachment notification confirmation has not been received from the remote provisioning service; and deleting, by the iUICC module, the profile in accordance with a policy of the profile.

Example 63 may include the method of any one of examples 48-62 and/or some other examples herein, wherein the profile comprises the security domain, an operator- owned security domain, a policy, a file system, a network access application, one or more other applications, user data, and one or more credentials.

Example 64 may include the method of any one of examples 48-62 and/or some other examples herein, wherein the profile comprises the security domain, an operator owned security domain, a policy, a file system, a network access application, one or more other applications, user data, and one or more credentials.

Example 65 may include the method of example 64 and/or some other examples herein, wherein the profile is associated with a network operator associated with a wireless communications network, and wherein the operator owned security domain includes information to be used for authenticating the iUICC module for communicating over the wireless communications network.

Example 66 may include the method of example 64 and/or some other examples herein, wherein the profile is associated with a service provider that provides one or more services, and wherein the operator owned security domain includes information to be used for authenticating the iUICC module for accessing the one or more services.

Example 67 may include the method of any one of examples 48-66 and/or some other examples herein, wherein prior to establishing the security domain, the method comprises: performing, by the iUICC module, an enclave attestation procedure.

Example 68 may include the method of example 67 and/or some other examples herein, wherein performing the attestation procedure comprises : receiving, by the iUICC module from communications circuitry, an iUICC activation command; transmitting, by the iUICC module to the remote provisioning service, an attestation request; receiving, by the iUICC module from the remote provisioning service, a challenge message; generating, by the iUICC module, an enclave report in response to the challenge message; obtaining, by the iUICC module, an attestation signature based on the enclave report; generating, by the iUICC module, a challenge response based on the enclave report and the attestation signature; transmitting, by the iUICC module to the remote provisioning service, the challenge response; and receiving, by the iUICC module from the remote provisioning service, an attestation response upon proper verification of the challenge response by the remote provisioning service.

Example 69 may include the method of example 67 and/or some other examples herein, wherein performing the attestation procedure comprises : receiving, by the iUICC module from communications circuitry, an iUICC activation command; obtaining, by the iUICC module, an enclave measurement or an enclave report for the iUICC enclave; transmitting, by the iUICC module to an iUICC loader, the enclave measurement or the enclave report, wherein the iUICC loader is to load the iUICC module for execution upon proper verification of the enclave measurement or the enclave report, and wherein the proper verification of the enclave measurement or the enclave report is based on whether the enclave measurement or the enclave report is included in an enclave whitelist.

Example 70 may include one or more computer-readable media including instructions to cause a computer device, in response to execution of the instructions by the computer device, to perform the method of any one of examples 48-69 and/or some other examples herein.

Example 71 may include the one or more computer-readable media of example 70 and/ or some other examples herein, wherein the one or more computer-readable media are implemented in application circuitry of the computer device or modem circuitry of the computer device, and wherein the computer device is a laptop personal computer, "PC," a tablet PC, a smartphone, a wearable computing device, or a machine-type communication device.

Example 72 may include a method for remote provisioning an integrated universal integrated circuit card, "iUICC," module, the method comprising: transmitting, by the remote provisioning service to a computing device, program code for the iUICC module and an instruction to establish an iUICC enclave to include the iUICC module; establishing, by a remote provisioning service, a security domain associated with a profile; establishing, by the remote provisioning service, one or more keys associated with the profile; transmitting, by the remote provisioning service to the computing device, the profile; and transmitting, by the remote provisioning service to the computing device, an enable profile instruction to instruct the iUICC module to enable the profile.

Example 73 may include the method of example 72 and/or some other examples herein, further comprising: receiving, by the remote provisioning service, the profile from a network operator or a service provider, wherein when the profile is received from the network operator, the profile includes information for attaching to a communications network associated with the network operator, and wherein when the profile is received from the service provider, the profile includes information for obtaining one or more services provided by the service provider.

Example 74 may include the method of any one of examples 72-73 and/or some other examples herein, wherein the one or more keys are established using an Elliptic Curve cryptography Key Agreement algorithm (ECKA).

Example 75 may include the method of any one of examples 72-74 and/or some other examples herein, wherein transmitting the profile to the computing device comprises: establishing, by the remote provisioning service, a first end-to-end encrypted tunnel between a secure execution environment of the computing device and the remote provisioning service to facilitate a provisioning of the iUICC module, wherein the first end-to-end encrypted tunnel is established through an iUICC proxy of the computing device.

Example 76 may include the method of example 75 and/or some other examples herein, wherein transmitting the profile to the computing device comprises: establishing, by the remote provisioning service, a second end-to-end encrypted tunnel between the iUICC proxy and a security assist server (SAS) to facilitate a provisioning of the iUI CC proxy, wherein the first end-to-end encrypted tunnel is independent from the second end- to-end encrypted tunnel.

Example 77 may include the method of examples 76 and/or some other examples herein, wherein the remote provisioning service comprises : an enclave attestation and enrollment server for provisioning and attestation of the iUICC enclave within the computing device; the SAS for provisioning the iUICC proxy within the computing device; and a Subscription Manager Data Preparation entity and a Subscription Manager Secure Routing entity for provisioning the iUICC module within the iUICC enclave.

Example 78 may include one or more computer-readable media including instructions to cause a server, in response to execution of the instructions by a computer device, to perform the method of any one of examples 72-77 and/or some other examples herein.

Example 79 may include an apparatus to implement a remote provisioning service, the apparatus comprising: one or more processors coupled with a memory device, wherein the one or more processors are to execute instructions to: transmit program code for an integrated universal integrated circuit card, "iUICC," module, and a command to establish an iUICC enclave to include the iUICC module; establish a security domain associated with a profile; establish one or more keys associated with the profile; transmit the profile to a computing device; and transmit an enable profile instruction to instruct the iUICC module to enable the profile.

Example 80 may include the apparatus of example 79 and/or some other examples herein, wherein the one or more processors execute the instructions to: receive the profile from a network operator or a service provider, wherein when the profile is received from the network operator, the profile includes information for attaching to a communications network associated with the network operator, and wherein when the profile is received from the service provider, the profile includes information for obtaining one or more services provided by the service provider.

Example 81 may include the apparatus of any one of examples 79-80 and/or some other examples herein, wherein the one or more processors are to execute the instructions to establish the one or more keys using an Elliptic Curve cryptography Key Agreement algorithm (ECKA).

Example 82 may include the apparatus of any one of examples 79-81 and/or some other examples herein, wherein the one or more processors execute the instructions to: establish a first end-to-end encrypted tunnel between a secure execution environment of the computing device and the remote provisioning service to facilitate a provisioning of the iUICC module, wherein the first end-to-end encrypted tunnel is established through an iUICC proxy of the computing device.

Example 83 may include the apparatus of example 82 and/or some other examples herein, wherein the one or more processors execute the instructions to: establish a second end-to-end encrypted tunnel between the iUICC proxy and an SAS to facilitate a provisioning of the iUICC proxy, wherein the first end-to-end encrypted tunnel is independent from the second end-to-end encrypted tunnel.

Although certain embodiments have been illustrated and described herein for purposes of description, a wide variety of alternate and/or equivalent embodiments or implementations calculated to achieve the same purposes may be substituted for the embodiments shown and described without departing from the scope of the present disclosure. This application is intended to cover any adaptations or variations of the embodiments discussed herein, limited only by the claims.

Claims

CLAIMS WE CLAIM:

1. A platform comprising:

cellular modem circuitry to facilitate communications over a cellular network; and program code of an integrated universal integrated circuit card, "iUICC", module to communicate with a remote provisioning service over the cellular network, wherein the iUICC module is to be implemented within:

the cellular modem circuitry; or

a secure execution environment of a host architecture coupled with the cellular modem, wherein the program code of the iUICC module is to be executed by an application processor of the host architecture when the iUICC module is implemented within the secure execution environment of the host architecture.

2. The platform of claim 1, wherein, when the iUICC module is implemented in the secure execution environment of the host architecture, the platform further comprises:

management engine, "ME", circuitry coupled with the cellular modem circuitry, wherein the iUICC module is to communicate with the cellular modem circuitry via the ME circuitry.

3. The platform of claim 2, wherein the platform further comprises:

an iUICC proxy to be implemented by the ME circuitry, wherein the iUICC proxy is to communicatively couple the iUICC module with the cellular modem circuitry.

4. The platform of claim 3, further comprising:

a private low pin count, "LPC", serial bus coupling the cellular modem circuitry with the ME circuitry, wherein the LPC serial bus is not exposed to a host operating system of the platform.

5. The platform of any one of claims 1-4, wherein, when the iUICC module is implemented in the secure execution environment of the host architecture, the secure execution environment comprises:

one or more secure enclaves, wherein the one or more secure enclaves are isolated regions of one or more computer readable media of the host architecture, wherein the program code of the iUICC module is stored in an iUICC enclave of the one or more secure enclaves, and wherein the application processor of the host architecture is to execute the program code of the iUICC module in the iUICC enclave.

6. The platform of claim 5, wherein the iUICC module is to:

receive a first request to activate the iUICC module from the application processor of the host architecture;

transmit, to an enclave attestation and enrollment server, "EAES", via the cellular modem circuitry, a second request for attestation including a public key associated with the iUICC module;

receive, from the enrollment server via the cellular modem circuitry, an attestation response based on a determination of whether the public key is registered in a whitelist; and

permit the iUICC enclave to launch when the attestation response indicates that the public key is registered in the whitelist.

7. The platform of claim 5, wherein the iUICC enclave further includes an iUICC loader separate from the iUICC module, and wherein the iUICC loader is to:

receive, from an EAES via the cellular modem circuitry, a whitelist of registered iUICC modules including associated public keys;

receive a request to operate the iUICC module;

determine whether a public key associated with the iUICC module is in the whitelist; and

verify the iUICC module when the public key is in the registered whitelist.

8. The platform of claim 7, wherein the iUICC module is encrypted within the iUICC enclave, and wherein the iUICC loader is to:

receive, from an enrollment server via the cellular modem circuitry, a private key associated with the iUICC module; and

decrypt the iUICC module using the private key.

9. The platform of claim 1, wherein, when the iUICC module is implemented in the cellular modem circuitry, the iUICC module is to communicate with one or more modules of the cellular modem circuitry via an iUICC proxy implemented by the cellular modem circuitry.

10. The platform of any one of claims 3, 5, or 9, wherein the platform is to establish a first end-to-end encrypted tunnel between the secure execution environment and a security assist server, "SAS", to facilitate a provisioning of the iUICC module and establish a second end-to-end encrypted tunnel between the iUICC proxy and the SAS to facilitate a provisioning of the iUICC proxy, wherein the first end-to-end encrypted tunnel is independent from the second end-to-end encrypted tunnel.

11. The platform of claim 10, wherein the iUICC module is to obtain a first certificate from the SAS for a first asymmetric key pair through the first end-to-end encrypted tunnel and the iUICC proxy is to obtain a second certificate from the SAS for a second asymmetric key pair through the second end-to-end encrypted tunnel.

12. The platform of claim 11, wherein the iUICC module and the iUICC proxy are to exchange application protocol data units, "APDUs", using asymmetric cryptography based on the first asymmetric key pair and the second asymmetric key pair.

13. The platform of claims 1-12, wherein the iUICC module is to communicate with the remote provisioning service through the iUICC proxy according to one or more Groupe Speciale Mobile Association, "GSMA", specified interfaces.

14. The platform of claims 1-12, wherein the platform is implemented in a laptop personal computer, "PC", a tablet PC, a smartphone, a wearable computing device, or a machine- type communication device.

15. The platform of claims 2-12, wherein the ME circuitry is a system-on-chip embedded in the host architecture, embedded in the cellular modem circuitry, or mounted separate from the host architecture or the cellular modem circuitry.

16. A method for implementing an integrated Universal Integrated Circuit Card, "iUICC", module within a secure execution environment, the method comprising:

transmitting authentication information to management engine, "ME", circuitry, wherein the ME circuitry is to provide the authentication information to modem circuitry for communication over a cellular network.

17. The method of claim 16, wherein the ME circuitry includes at least one processor to operate an iUICC proxy for communication with the iUICC module.

18. The method of claim 16, wherein the secure execution environment includes an iUICC enclave in which the iUICC module is to operate, and wherein the method comprises: receiving, from the modem circuitry via the ME circuitry, a first command to establish a security domain associated with a profile to be provisioned in the secure execution environment, wherein the profile is associated with a cellular network operator to be used for accessing a cellular network of the cellular network operator, or wherein the profile is associated with a service provider to be used for accessing one or more services provided by the service provider;

establishing the security domain associated with the profile based on the first command;

receiving, from the modem circuitry via the ME circuitry, a second command to establish one or more keys according to an asymmetric key agreement algorithm, the one or more keys are to be associated with a profile to be provisioned; establishing the one or more keys based on the second command;

receiving, from the modem circuitry via the ME circuitry, the profile to be provisioned;

establishing a portion in the secure execution environment for storing the profile; store the profile in the portion of the secure execution environment;

receiving, from the modem circuitry via the ME circuitry, a third command to enable the profile after storage of the profile in the portion of the secure execution environment; and

performing a network attachment procedure to enable the profile, and

wherein the first command, the second command, and the third command are provided to the modem circuitry by a remote provisioning service using over-the-air interfaces.

19. The method of claim 18, wherein establishing the one or more keys comprises:

transmitting, to the modem circuitry via the ME circuitry, a random challenge for the remote provisioning service;

receiving, from the modem circuitry via the ME circuitry, a random challenge response from the remote provisioning service;

determining a shared secret based on the random challenge response;

deriving the one or more keys based on the shared secret; and

transmitting, to the modem circuitry via the ME circuitry, a key response for the remote provisioning service to indicate that the one or more keys have been established.

20. The method of claim 18, wherein the profile is associated with the cellular network operator and performing the network attachment procedure comprises:

transmitting, to the modem circuitry via the ME circuitry, an International Mobile Subscriber Identity, IMSI, associated with the enabled profile, wherein the modem circuitry is to use the IMSI for a connection setup procedure with the cellular network using the over-the-air interfaces;

receiving, from the modem circuitry via the ME circuitry, an authentication request provided to the modem circuitry by the cellular network;

generating an authentication response based on information included in the authentication request;

transmitting, to the modem circuitry via the ME circuitry, the authentication response, wherein the modem circuitry is to provide the authentication response to the cellular network using the over-the-air interfaces; receiving, from the modem circuitry via the ME circuitry, a security command, wherein the security command is to indicate ciphering and integrity algorithms to be used for encoding messages to be communicated over the cellular network;

generating, based on the security command, a key set for encoding messages to be communicated over the cellular network; and

storing the key set in association with the profile.

21. The method of claim 18, wherein, when the profile is associated with the cellular network operator, the profile comprises:

a Universal Mobile Telecommunications System, "UMTS", Subscriber Identity Module, "SIM", used to access a Long Term Evolution network or a UMTS network; a Global System for Mobile Communications, "GSM", SIM used to access a GSM network;

a Code Division Multiple Access, "CDMA", SIM used to access a CDMA network;

an IP Multimedia Services SIM, "ISEVI", used to access an IP multimedia subsystem applications; or

a Worldwide Interoperability for Microwave Access, "WiMAX", SIM used to access a WiMAX network.

22. The method of claim 16, wherein the secure execution environment comprises a plurality of profiles, and wherein the plurality of profiles includes a first profile comprising a UMTS SIM, a second profile comprising a GSM SIM, a third profile comprising a CDMA SIM, a fourth profile comprising a ISIM, and a fifth profile comprising a WiMAX SIM.

23. The method of claims 16 or 18, wherein the secure execution environment includes one or more secure enclaves, wherein the one or more secure enclaves are defined by

Software Guard Extensions.

24. A computing device comprising:

one or more computer readable media including one or more secure enclaves, wherein an integrated universal integrated circuit card, "iUICC", enclave of the one or more secure enclaves includes program code for an iUICC module; and

one or more processors to execute the program code of the iUICC module to communicate over a cellular network.

25. The computing device of claim 24, wherein to communicate over the cellular network, the one or more processors are to execute the program code of the iUICC module to: communicate with a remote provisioning service for remote provisioning of one or more cellular network operator profiles in the secure execution environment, wherein the remote provisioning of the one or more cellular network operator profiles includes enablement of the one or more cellular network operator profiles or disablement of the one or more cellular network operator profiles.

26. The computing device of claim 24, wherein the computing device further comprises: cellular modem circuitry; and

27. The computing device of claim 26, wherein the ME circuitry is to implement an iUICC proxy to communicatively couple the iUICC module with the cellular modem circuitry.

28. The computing device of claim 27, wherein the ME circuitry is coupled with the cellular modem circuitry by a private low pin serial bus.

29. The computing device of claim 27, wherein the iUICC module and the iUICC proxy are to exchange application protocol data units, "APDUs", using asymmetric cryptography using a private key for signing the APDUs and a public key for verification of the APDUs.

30. The computing device of claims 25-29, wherein the iUICC module is to communicate with the remote provisioning service through Groupe Speciale Mobile Association- specified interfaces.

31. The computing device of claims 24-29, wherein the one or more secure enclaves are defined by Software Guard Extensions, and wherein the computing device is a laptop personal computer, "PC", a tablet PC, a smartphone, a wearable computing device, or a machine-type communication device.