Techniques for subscriber identity module security

Abstract

The present disclosure provides a technique for subscriber identity module security. The application relates to devices and components including apparatuses, systems, and methods for pairing UICC / SIM with device components.

Description

[0001] Related Applications

[0002] This application claims priority to U.S. non-provisional patent application No. 18 / 427,688 filed on January 30, 2024, which claims priority to U.S. provisional patent application No. 63 / 578,354 filed on August 23, 2023, which are hereby incorporated by reference in their entirety for all purposes. Technical Field

[0003] The present disclosure relates to the field of wireless communications, and more particularly, to techniques for subscriber identity module security. Background Art

[0004] A Universal Integrated Circuit Card (UICC) refers to a hardware resource used by a Subscriber Identity Module (SIM). The SIM includes logic and data (e.g., identity and authentication information) that can be used to allow a user device to access a cellular network. Secure communications between the SIM and other components of the user device are desired. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1 A network environment according to some embodiments is shown.

[0006] Figure 2 Components of user equipment according to some embodiments are shown.

[0007] Figure 3 An authentication process according to some embodiments is shown.

[0008] Figure 4 Another authentication process according to some embodiments is shown.

[0009] Figure 5 Another authentication process according to some embodiments is shown.

[0010] Figure 6 Another authentication process according to some embodiments is shown.

[0011] Figure 7 Another authentication process according to some embodiments is shown.

[0012] Figure 8 A pairing process according to some embodiments is shown.

[0013] Fig. 9 Another pairing process according to some embodiments is shown.

[0014] Fig.10 Another authentication process according to some embodiments is shown.

[0015] Fig.11 Another authentication process according to some embodiments is shown.

[0016] Fig.12 An apparatus according to some embodiments is shown.

[0017] Fig.13 Another apparatus according to some embodiments is shown. DETAILED DESCRIPTION

[0018] The following specific embodiments relate to the accompanying drawings. The same figure numbers may be used to identify the same or similar elements in different drawings. In the following description, for the purpose of illustration rather than limitation, specific details, such as specific structures, architectures, interfaces and technologies are set forth to provide a thorough understanding of various aspects of various embodiments. However, it is obvious to those skilled in the art who benefit from the present disclosure that various aspects of various embodiments can be practiced in other examples that deviate from these specific details. In some cases, descriptions of well-known devices, circuits and methods are omitted so that the descriptions of various embodiments are not obscured by unnecessary details. For the purpose of this document, the phrases "A / B" and "A or B" refer to (A), (B) or (A and B); the phrase "(A)B" refers to (B) or (A and B), i.e. A is optional. And the phrase "based on A" refers to "based at least in part on A", for example, it can be "based only on A" or it can be "based in part on A".

[0019] The following is a glossary of terms that may be used in this disclosure.

[0020] The term "circuit" as used herein refers to the part of the hardware component configured to provide the described function or includes the hardware component.Hardware components may include electronic circuits, logic circuits, processors (shared, dedicated or group) or memories (shared, dedicated or group), application specific integrated circuits (ASICs), field programmable devices (FPDs) (e.g., field programmable gate arrays (FPGAs), programmable logic devices (PLDs), complex PLDs (CPLDs), high-capacity PLDs (HCPLDs), structured ASICs or programmable systems on chip (SoCs)) or digital signal processors (DSPs).In some embodiments, circuits may execute one or more software or firmware programs to provide at least some of the functions.The term "circuit" may also refer to a combination of one or more hardware elements and a program code for performing the function of the program code (or a combination of circuits used in an electrical or electronic system).In these embodiments, the combination of hardware elements and program code may be referred to as a circuit of a specific type.

[0021] As used herein, the term "processor circuit" refers to, is part of, or includes a circuit capable of sequentially and automatically performing a series of arithmetic or logical operations or recording, storing, or transmitting digital data. The term "processor circuit" may refer to an application processor, a baseband processor, a central processing unit (CPU), a graphics processing unit, a single-core processor, a dual-core processor, a triple-core processor, a quad-core processor, or any other device capable of executing or otherwise operating computer-executable instructions (such as program code, software modules, and / or functional processes).

[0022] As used herein, the term "interface circuit" refers to, is a part of, or includes a circuit that enables information exchange between two or more components or devices. The term "interface circuit" may refer to one or more hardware interfaces, such as a bus, an I / O interface, a peripheral component interface, and a network interface card.

[0023] As used herein, the term "user equipment" or "UE" refers to a device with radio communication capabilities that can allow a user to access network resources in a communication network. The term "user equipment" or "UE" may be considered synonymous with the following and may be referred to as a client, mobile phone, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment or reconfigurable mobile device. In addition, the term "user equipment" or "UE" may include any type of wireless / wired device or any computing device that includes a wireless communication interface.

[0024] As used herein, the term "computer system" refers to any type of interconnected electronic devices, computer devices, or components thereof. Additionally, the term "computer system" or "system" may refer to various components of a computer that are communicatively coupled to one another. Furthermore, the term "computer system" or "system" may refer to multiple computer devices or multiple computing systems that are communicatively coupled to one another and configured to share computing resources or networked resources.

[0025] As used herein, the term "resource" refers to a physical or virtual device, a physical or virtual component within a computing environment, or a physical or virtual component within a specific device, such as a computer device, a mechanical device, a memory space, a processor / CPU time, a processor / CPU usage rate, a processor and accelerator load, a hardware time or usage rate, a power supply, an input / output operation, a port or a network socket, a channel / link allocation, a throughput, a memory usage rate, a storage, a network, a database, and an application or a unit of workload. "Hardware resources" may refer to computing, storage, or network resources provided by physical hardware elements. "Virtualized resources" may refer to computing, storage, or network resources provided by a virtualized infrastructure to an application, device, or system. The term "network resources" or "communication resources" may refer to resources that can be accessed by a computer device / system via a communication network. The term "system resources" may refer to any kind of shared entity that provides a service, and may include computing resources or network resources. System resources may be considered as a set of coherent functions, network data objects, or services that can be accessed through a server, wherein such system resources reside on a single host or multiple hosts and can be clearly identified.

[0026] As used herein, the term "channel" refers to any tangible or intangible transmission medium for transmitting data or data streams. The term "channel" may be synonymous or equivalent to "communication channel", "data communication channel", "transmission channel", "data transmission channel", "access channel", "data access channel", "link", "data link", "carrier", "radio frequency carrier" or any other similar term representing a path or medium through which data is transmitted. In addition, as used herein, the term "link" refers to a connection made between two devices for transmitting and receiving information.

[0027] As used herein, the terms "instantiate," "instantiate," and the like refer to the creation of an instance. "Instance" also refers to a specific occurrence of an object, which may occur, for example, during the execution of program code.

[0028] The term "connected" may mean that two or more elements at a common communication protocol layer have an established signaling relationship with each other through a communication channel, link, interface, or reference point.

[0029] As used herein, the term "network element" refers to physical or virtualized equipment or infrastructure used to provide wired or wireless communication network services. The term "network element" may be considered synonymous with or referred to as a networked computer, networking hardware, network equipment, network node, or virtualized network function.

[0030] The term "information element" refers to a structural element that contains one or more fields. The term "field" refers to the individual contents of an information element, or a data element that contains the contents. An information element may include one or more additional information elements.

[0031] Figure 1 A network environment 100 according to some embodiments is shown. The network environment 100 may include a UE 104 communicatively coupled to a base station 108. The UE 104 and the base station 108 may communicate via an air interface compatible with a 3rd Generation Partnership Project (3GPP) Technical Specification (TS) such as those defining LTE, NR or later system standards. The base station 108 may be an evolved Node B (eNB) for providing one or more LTE cells or a next generation Node B (gNB) for providing one or more fifth generation (5G) (or later) new radio (NR) cells.

[0032] UE 104 includes a UICC 112 coupled to a baseband (BB) processor 116. As briefly discussed above, UICC 112 may have logic and data for accessing subscriber services. UICC 112 may be a removable circuit card or may be embedded in the platform circuitry of UE 104, in which case UICC 112 may be referred to as an embedded UICC (eUICC). In some embodiments, UICC 112 may host a SIM (or eSIM) that performs operations associated with UICC 112. As used herein, the terms UICC, eUICC, SIM, and eSIM may be used interchangeably with each other.

[0033] When UE 104 initially connects with base station 108, UICC 112 and BB processor 116 may cooperate to provide authentication and identity information to base station 108. Base station 108 may use the provided information to confirm that UE 104 has access rights to services provided by the mobile network operator. Embodiments of the present disclosure provide techniques for facilitating the establishment of a secure channel link between UICC 112 and BB processor 116. The secure channel link may prevent another UICC from being placed into UE 104 and replacing UICC 112 to communicate with BB processor 116 or base station 108.

[0034] Some embodiments describe establishing a secure communication link by creating a security association between the identity of the BB processor 116 and the identity of the UICC 112. The identity of the BB processor 116 may be an International Mobile Equipment Identity (IMEI), and the identity of the UICC 112 may be a UICC identifier (ID) (e.g., an eUICC identifier (EID)), a serial number, etc. The security association may be established during the manufacturing phase of the UE 104 or by subsequent configuration. In some embodiments, the security association may be a one-to-one association in which one identity of the UICC 112 (e.g., EID_1) is associated with one identity of the BB processor 116 (IMEI_1). Therefore, the UICC 112 may work only with the BB processor 116, and vice versa. In other embodiments, a many-to-one association or a one-to-many association may be used, as long as the association is securely established, as will be further described herein.

[0035] Figure 2 The components of the network environment are shown in more detail according to some embodiments. The UICC 112 may include a storage device having an identifier of the UICC (e.g., EID_1), and the BB processor 116 may include a storage device having an identifier of the BB processor (e.g., IMEI_1). At 204, the BB processor 116 may transmit IMEI_1 to the UICC 112. The UICC 112 may store IMEI_1 in a secure location within the UICC 112 (e.g., as a persistent IMEI_1) in a manner that prevents tampering or modification of IMEI_1. At 208, the UICC 112 may transmit EID_1 to the BB processor 116. The BB processor 116 may store EID_1 in a secure location within the BB processor 116 (e.g., as a persistent EID_1) in a manner that prevents tampering or modification of EID_1. In this way, IMEI_1 and EID_1 will be bound to each other. Thereafter, as part of any boot / reset procedure, an authentication handshake procedure may be used, where the UICC 112 sends EID_1 to the BB processor 116, and the BB processor 116 sends IMEI_1 to the UICC 112. The UICC 112 and BB processor 116 may then check the identities against their persistent copies.

[0036] Figure 3 An authentication flow 300 using a persistent identity according to some embodiments is shown. The authentication flow 300 may be initiated based on a phone reset that triggers a baseband reset and a UICC reset. This may prompt an ID authenticator 304 of the BB processor 116 at operation 1.

[0037] At operation 2 , the ID authenticator 304 may transmit the IMEI associated with the BB processor 116 to the UICC operating system (OS) 308 of the UICC 112 .

[0038] At operation 3, UICC OS 308 may determine whether the IMEI provided by BB processor 116 at operation 2 matches the persistent IMEI stored in UICC 112. If the two identities match, authentication flow 300 may proceed to operation 4, where UICC OS 308 provides the EID associated with UICC 112 to ID authenticator 304.

[0039] At operation 5, ID authenticator 304 may determine whether the EID provided by UICC 112 at operation 4 matches the persistent EID stored in BB processor 116. If the two identities match, authentication flow 300 may proceed to operation 6, where ID authenticator 304 provides an authentication success message to UICC OS 308.

[0040] At operation 7, the UICC OS 308 may transmit an Answer to Reset (ATR) to the ID authenticator 304. After transmitting the ATR, a secure communication link may be established between the UICC 112 and the BB processor 116. The UICC 112 may then be able to provide all available services to the BB processor 116 upon request.

[0041] Figure 4 An authentication flow 400 using a persistent identity is shown according to some embodiments. The authentication flow 400 corresponds to an embodiment in which a new UICC 412 is attempting to communicate with the BB processor 116 after the BB processor 116 previously established a secure communication link with another UICC (eg, UICC 112).

[0042] The authentication flow 400 may be initiated based on a phone reset that triggers a baseband reset and a UICC reset. This may prompt the ID authenticator 304 of the BB processor 116 at operation 1 .

[0043] At operation 2 , the ID authenticator 304 may transmit the IMEI associated with the BB processor 116 to the UICC OS 408 of the UICC 412 .

[0044] In this embodiment, assuming that the UICC 412 is attempting to gain access without previously establishing a secure communication link with the BB processor 116, the UICC 412 may not have a persistent IMEI that matches the IMEI provided at operation 2. However, if the UICC 412 is an imposter device, it may skip such steps. Figure 3 Operation 3 is described and proceeds to operation 4, making an implicit but erroneous assertion that the IMEI of operation 2 matches its persistent IMEI. At operation 4, the UICC OS 408 may transmit its EID to the BB processor 116.

[0045] At operation 5, the ID authenticator 304 may determine that the EID provided by the UICC 412 at operation 4 does not match the persistent EID stored in the BB processor 116. Therefore, the authentication flow 400 may proceed to operation 6, where the ID authenticator 304 transmits an authentication failure message to the UICC OS 408. In this example, the communication between the UICC 412 and the BB processor 116 may be limited. For example, in some embodiments, the UICC 412 may only be able to provide a subset of available operations to the BB processor 116. The subset of available operations may be, for example, operations to perform an initialization process with the BB processor 116, operations to enable installation of UICC firmware, or operations to debug or identify 412 the UICC.

[0046] Figure 5 An authentication flow 500 using a persistent identity is shown according to some embodiments. Authentication flow 500 corresponds to an embodiment in which a new BB processor 516 is attempting to communicate with UICC 112 after UICC 112 previously established a secure communication link with another BB processor (eg, BB processor 116).

[0047] The authentication flow 500 may be initiated based on a phone reset that triggers a baseband reset and a UICC reset. This may prompt the ID authenticator 504 of the BB processor 516 at operation 1.

[0048] At operation 2 , the ID authenticator 504 may transmit the IMEI associated with the BB processor 516 to the UICC OS 308 of the UICC 112 .

[0049] At operation 3, the UICC OS 308 may compare the IMEI provided at operation 2 with the persistent IMEI previously stored in the UICC 112 and determine that they do not match. Subsequently, the authentication flow 500 may proceed to operation 4, where the UICC OS 308 transmits a negative acknowledgement to the baseband processor 516. In this example, the communication between the UICC 112 and the BB processor 516 may be limited. For example, in some embodiments, the UICC 112 may only be able to provide a subset of available operations to the BB processor 516. The subset of available operations may be, for example, operations to perform an initialization process using the BB processor 516, operations to enable installation of UICC firmware, or operations to debug or identify the 112 UICC.

[0050] In some embodiments, the secure communication link between the UICC 112 and the BB processor 116 can be established in the field and facilitated by the security platform of the UE 104. The security platform, which may also be referred to as a "secure enclave", may be a dedicated security subsystem that is integrated into a system on a chip (SoC) but isolated from other processors (e.g., an application processor) to provide an additional layer of security. The secure enclave can operate to keep sensitive user data safe even if the application processor is compromised. The secure enclave may include a secure enclave processor (SEP) dedicated to the operation of the secure enclave, a boot read-only memory (ROM) that establishes a hardware root of trust, an advanced encryption standard (AES) engine for efficient and secure cryptographic operations, and protected memory / storage.

[0051] Figure 6 An authentication flow 600 according to some embodiments is shown. The authentication flow 600 may involve messages between the UE 104, a device service (DS) server 604, and a certificate server 608. The DS server 604 may be a server that runs on a company's infrastructure and provides document processing tasks (e.g., storing, processing, and protecting data) for the company. The DS server 604 may provide various tokens and keys.

[0052] The authentication flow 600 may include the UE 104 asking the SEP on the device to generate a UICC key pair via a device identity framework at 604. The device identity framework may be similar to that described elsewhere herein.

[0053] The authentication flow 600 may include, at 616, the UE 104 sending a certificate request to the certificate server 608. The certificate request may be generated based on one or more keys in the UICC key pair.

[0054] At 620, the certificate server 608 can generate a certificate and provide the certificate to the UE 104. The certificate can prove the credentials of the UE 104.

[0055] At 624, the UE 104 may transmit the certificate to the DS server 604. In some implementations, the UE 104 may also transmit an ID associated with the UICC 112 of the UE 104.

[0056] Upon receiving the certificate, the DS server 604 may use the backend information to verify the pairing between the UICC 112 and the BB processor 116. Specifically, the DS server 604 may verify the certificate at 628, extract the serial number (corresponding to the BB processor 116) at 632, and perform a database lookup for the UICC ID based on the serial number. The database may have the serial number (or other BB processor identity) securely associated with the UICC ID (e.g., EID).

[0057] At 640, DS server 604 may sign the certificate, which may include the SEP public key and the EID obtained from the database, and provide the signed certificate to UE 104. The certificate may be injected into UICC 112. UICC 112 may verify the certificate and extract the SEP key for later use.

[0058] In some implementations, the UICC 112 may be paired with a security module associated with the BB processor (eg, baseband SEP). This may reduce attack services, but the specific implementation may be limited to new product introductions.

[0059] In some embodiments, the UICC 112 may be paired with the baseband 116 through an in-factory pairing process. In some instances, this may use an Elliptic Curve Digital Signature Algorithm (ECDSA) signature verification, where the UICC 112 generates a challenge and sends it to the baseband SEP. The baseband SEP may sign it and send the signature back to the UICC 112. The UICC 112 may then verify the signature using the SEP's public key (AuthKey). The SEP's public key may be injected during the factory process or by using some ECKA (Elliptic Curve Key Agreement) mechanism instead of ECDSA to create a shared secret between the SEP and the UICC 112 that can be used to establish a secure channel. Figure 7 An authentication flow 700 is shown for an in-factory pairing process according to some embodiments.

[0060] The authentication flow 700 may involve messages between a server 704, an application processor (AP) 708 of the UE 104, the UICC 112, and the SEP 712. The authentication flow 700 may include a provisioning phase, a pairing phase, and a verification phase.

[0061] During the configuration phase, SEP 712 may be configured with public and secret keys for ECDSA. The public key may be referred to as PK.SIK.ECDSA, and the secret key may be referred to as SK.SIK.ECDSA. SEP 712 may also be configured with a SEP certificate (SCRT). UICC 112 may be configured with a UICC chipset root (PK.EUICCCHIPSET.ECDSA); a key pair (SK.EUICC.ECDSA and PK.EUICC.ECDSA); and a certificate (CERT.EUICC.ECDSA). Server 704 may be configured with: a provider root (PK.PROVIDER.ECDSA); a GSMA root (PK.GSMA.ROOT.ECDSA); a key pair (SK.SERVER.ECDSA and PK.SERVER.ECDSA); and a certificate (CERT.SERVER.ECDSA).

[0062] After the configuration phase, the pairing phase may begin at 716, where a start pairing message is transmitted from the AP 708 to the server 704. The start pairing message may include an ECID, an EID, or a Global System for Mobile Communications Association (GSMA)_Subject Key Identifier (SKI). The GSMA_SKI may be a list of one or more Certificate Authority (CI) public keys of the GSMA certificate chain that allows external entities to know what GSMA root CI is trusted by the eUICC.

[0063] The server 704 may respond with an authentication request message at 720. The authentication request message may include a hardware security module (HSM) challenge for the SEP and UICC (HSMChallengeSEP, HSMChallengEUICC).

[0064] At 724, AP 708 may send a generate attestation message to SEP 712. The generate attestation message may include an HSM challenge (HSMChallengeSEP) for the SEP. In response to the HSM challenge, SEP 712 may respond with a SEP attestation (attV2AuthKey) conveying the SEP authentication key and a SEP certificate (SCRT) including a public key. The SEP attestation may be signed by a SEP specific key pair.

[0065] At 732, AP 708 may send a Local Profile Assistant (LPA) Signature Request message to UICC 112. The LPA Signature Request message may include an HSM challenge for UICC 112. In some implementations, the LPA Signature Request message may also include additional metadata that may be signed by UICC 112.

[0066] The UICC 112 may respond to the HSM challenge with an LPA signed response at 736. The LPA signed response may include a payload with an HSM challenge for the UICC (HSMChallengeEUICC) signed with the UICC signature (UICCSignature) and a UICC certificate chain (UICCCertificate) generated by the UICC as a challenge to verify the UICC signature.

[0067] At 744, AP 708 may transmit an authentication response message (AuthRsp) to server 704. The authentication response message may include a SEP attestation conveying a SEP authentication key (attV2AuthKey), a SEP certificate (SCRT), a UICC-signed payload (e.g., HSMChallengeUICC and UICCSignature), and a UICC certificate chain (UICCCertificate).

[0068] The server 704 may verify the SCRT certificate, extract the public key, verify the SEP attestation using the public key, and verify the UICC signature based on the UICC certificate chain. Upon verification, the server 704 may respond with a Store Pairing Key message at 748. The Store Pairing Key message may include the server attestation (attSER). The server attestation may include the UICC ID associated with the UICC, the public key of the SEP (AuthKey), the UICC challenge from the LPA Signature Response message, and additional metadata.

[0069] At 752 , the AP 708 may transmit a store pairing key message with the server attestation (attSER) and the server certificate (ServerCRT) to the UICC 112 .

[0070] Upon receiving the store pairing message from AP 708, UICC 112 may verify the server certificate chain using PK.EUICCCHIPSET.ECDSA, verify the attSER signature using PK.SERVER.ECDSA, verify the EID in attSER, and store the public key of the SEP.

[0071] At 760, the UICC may transmit a response to the AP 708. The response may indicate that the UICC 112 has verified the server certificate and stored the public key (AuthKey) of the SEP.

[0072] In some embodiments, the UICC pairing may need to be repaired or reset. This can be done by injecting a recovery root in the UICC 112 during the manufacture of the UE 104, for example. The corporate server may have a dedicated policy defined under the leaf certificate for resetting the pairing. When a reset is required, the UICC 112 may generate a random number (nonce). The recovery root may be used to generate the random number. The random number may be sent to the corporate server, which signs the random number for authorization. The server may then send a special application protocol data unit (APDU) to the UICC 112 via the BB processor 116 to trigger the pairing reset.

[0073] In some embodiments, IMEI pairing may be performed by pairing the UICC 112 with the BB processor 116 when the UE 104 is first powered on. This may apply to new devices or legacy devices in the field.

[0074] Figure 8 A pairing process 800 is shown according to some embodiments.

[0075] At 804, UICC 112 may send an ATR message to BB processor 116. The transmission of the ATR message may be triggered by a power-on or reset operation. The ATR may include an indication of the pairing capability of UICC 112, and may also include an indication that UICC 112 is not paired. The unpaired indication may be included in an information element (IE) of the ATR message.

[0076] At 808, the BB processor 116 may send an initialization pairing message to the UICC 112. The initialization pairing message may include the IMEI associated with the BB processor 116.

[0077] At 812, UICC 112 may generate a random key. At 816, UICC 112 may transmit the random key to BB processor 116. At 820, BB processor 116 may store the random key. The random key may be stored in a local memory. In some implementations, the random key may additionally / alternatively be saved in a remote memory (e.g., a cloud storage device) for recovery.

[0078] At 824, BB processor 116 may transmit a final pairing message to UICC 112. UICC 112 may submit the IMEI / key binding upon receiving the final pairing message.

[0079] The final pairing message may be used to confirm that the BB processor 116 has successfully saved the key. This may avoid failures that may otherwise occur if the BB processor 116 experiences an error or reset after the UICC 112 transmits the key at 816 but before the BB processor 116 successfully stores the key.

[0080] Fig. 9 A pairing process 900 is shown according to some embodiments. For example, the pairing process 900 may occur after the UICC 112 is successfully paired with the BB processor 116 using the pairing process 800. The pairing process 900 may represent a pairing attack in which a BB processor 904 different from the BB processor 116 paired with the UICC 112 is attempting to pair with the UICC 112.

[0081] At 908, UICC 112 may send an ATR message to BB processor 904. The ATR message may include an indication of the pairing capabilities of UICC 112 and an indication that UICC 112 is operating in a restricted (or paired) state. The restricted indicator may be included in the IE of the ATR.

[0082] At 912, the BB processor 904 may send an initialization pairing message to the UICC 112. The initialization pairing message may include the IMEI associated with the BB processor 904.

[0083] UICC 112 may detect a failure at 916 due to a previous pairing of UICC 112 with BB processor 116. Therefore, at 920, UICC 112 may send a rejection message to BB processor 904.

[0084] Fig.10 An authentication flow 1000 is shown according to some embodiments. For example, the authentication flow 1000 may occur after the UICC 112 has successfully paired with the BB processor 116 using the pairing flow 800. The authentication flow 1000 is an example of a successful authentication.

[0085] At 1004, UICC 112 may send an ATR to BB processor 116. The ATR may include an indication of the pairing capabilities of UICC 112 and an indication that UICC 112 is operating in a restricted (or paired) state. The restricted indicator may be included in an IE of the ATR.

[0086] At 1008 , the BB processor 116 may send an initialization authorization message to the UICC 112 .

[0087] At 1012 , the UICC 112 may transmit a random number to the BB processor 116 .

[0088] At 1016, the BB processor 116 may transmit a message authentication code (MAC) message to the UICC 112. The MAC message may be based on a random number and one or more IMEIs of the BB processor 116. The MAC message may be based on a cipher-based MAC (CMAC), a hash-based MAC (HMAC), or another MAC algorithm.

[0089] UICC 112 may perform multiple verifications. For example, UICC 112 may perform MAC verification, IMEI verification to determine that the IMEI received at 1016 matches the IMEI received from the initial pairing, and perform random number verification to determine that the random number received at 1016 matches the random number provided at 1012.

[0090] At 1020, the UICC may determine that the authentication is successful, and the authentication flow 1000 may proceed to the UICC 112 entering an unrestricted state at 1024. In the unrestricted state, the UICC 112 may perform all available UICC operations requested by the BB processor 116. In some implementations, the UICC 112 may transmit a message to the BB processor 116 to indicate whether the authentication at 1020 is successful.

[0091] Fig.11 An authentication flow 1100 is shown according to some embodiments. The authentication flow 1100 is an example of an authentication failure as a result of the BB processor 116 attempting to authenticate to the UICC 112, for example, after the UICC 112 has successfully paired with the BB processor 1116 using the pairing flow 800.

[0092] At 1104, UICC 112 may send an ATR message to BB processor 1116. The ATR message may include an indication of the pairing capabilities of UICC 112 and an indication that UICC 112 is operating in a restricted (or paired) state. The restricted indicator may be included in an IE of the ATR message.

[0093] At 1108 , the BB processor 1116 may send an initialization authorization message to the UICC 112 .

[0094] At 1112 , the UICC 112 may transmit a random number to the BB processor 1116 .

[0095] At 1116, the BB processor 116 may transmit a MAC message to the UICC 112. The MAC message may be based on the random number and the IMEI of the BB processor 1116.

[0096] UICC 112 may perform multiple verifications. For example, UICC 112 may perform MAC verification, IMEI verification to determine that the IMEI received at 1116 matches the IMEI received from the initial pairing, and perform random number verification to determine that the random number received at 1116 matches the random number provided at 1012.

[0097] At 1120, UICC 112 may determine that at least one of the verifications was unsuccessful. The verification failure in this example may be an IMEI verification (assuming that the IMEI of BB processor 1116 does not match the IMEI of BB processor 116); however, in other examples, the failed verification may involve a MAC verification or a random number verification. After determining that at least one verification has failed, the authentication flow 1100 may proceed to UICC 112 remaining in a restricted state at 1124. In the restricted state, UICC 112 may only perform a subset of available UICC operations requested by BB processor 116.

[0098] In some implementations, pairing of the UICC 112 and the BB processor 116 may occur upon a warm reset trigger or a cold reset trigger.

[0099] In some embodiments, when the BB processor 116 does not have access to the appropriate keys, the UICC 112 may operate in an unpaired or restricted state, in which the UICC responds only to a subset of commands that would otherwise be available when the UICC 112 operates in a normal or unrestricted state. The subset of commands may correspond to critical operations, such as directing communications with the BB processor 116 or allowing management operations. For example, the subset of commands may involve operations that utilize the BB processor 116 to perform an initialization process, operations that enable installation of UICC firmware, or operations to debug or identify the UICC 112. In some embodiments, the UICC 112 may respond to one or more of these commands even when in a restricted state.

[0100] Commands other than a subset of allowed commands may be blocked in a restricted state.

[0101] Fig.12 A device 1200 is shown according to some embodiments. The device 1200 may be similar to the UE 104 and may be substantially interchangeable therewith.

[0102] Device 1200 can be any mobile or non-mobile computing device, such as, for example, a mobile phone, a computer, a server, a tablet, an industrial wireless sensor (e.g., a microphone, a carbon dioxide sensor, a pressure sensor, a humidity sensor, a thermometer, a motion sensor, an accelerometer, a laser scanner, a fluid level sensor, an inventory sensor, a voltage / current meter, or an actuator), a video surveillance / monitoring device (e.g., a camera or a camcorder), a wearable device (e.g., a smart watch), or an Internet of Things device.

[0103] Device 1200 may include a processor 1204, an interface circuit 1208, a memory / storage 1212, a user interface 1216, a sensor 1220, a driver circuit 1222, a power management integrated circuit (PMIC) 1224, a battery 1228, and a secure enclave 1240. The components of device 1200 may be implemented as an integrated circuit (IC), a portion of an integrated circuit, a discrete electronic device or other module, logical component, hardware, software, firmware, or a combination thereof. Fig.12 The block diagram of UE 1200 is intended to show a high-level view of some of the components of UE 1200. However, some of the components shown may be omitted, additional components may be present, and different arrangements of the components shown may occur in other implementations.

[0104] Components of device 1200 may be coupled to various other components via one or more interconnects 1232, which may represent any type of interface, input / output, bus (local, system, or extension), transmission line, trace, or optical connection that allows various circuit components (on a common or different chip or chipsets) to interact with each other.

[0105] The processor 1204 may include processor circuits such as, for example, a BB processor circuit (BB) 1204A, a central processor unit circuit (CPU) 1204B, a graphics processor unit circuit (GPU) 1204C, and a secure enclave 1204D. The processor 1204 may include any type of circuit or processor circuit that executes or otherwise operates computer executable instructions (such as program codes, software modules, or functional processes) from the memory / storage device 1212 to cause the device 1200 to perform operations as described herein (such as those described in the authentication flow, pairing flow, or operation flow described herein).

[0106] In some embodiments, the baseband processor circuit 1204A, which may correspond to the BB processor 116, may access the communication protocol stack 1236 in the memory / storage device 1212 to communicate through a 3GPP compatible network. Generally speaking, the baseband processor circuit 1204A may access the communication protocol stack 1236 to perform the following operations: perform user plane functions at the PHY layer, MAC layer, RLC layer, PDCP layer, SDAP layer, and PDU layer; and perform control plane functions at the PHY layer, MAC layer, RLC layer, PDCP layer, RRC layer, and NAS layer. In some embodiments, the PHY layer operations may be additionally / alternatively performed by components of the interface circuit 1208.

[0107] The baseband processor circuit 1204A may generate or process baseband signals or waveforms that carry information in a 3GPP-compatible network. In some embodiments, the waveforms used for NR may be based on cyclic prefix OFDM (CP-OFDM) in the uplink or downlink, and discrete Fourier transform spread OFDM (DFT-S-OFDM) in the uplink.

[0108] The secure enclave 1204D may include components of a security subsystem that is isolated from the main processor (e.g., CPU 1204B) to keep user data secure even if the main processor is compromised. The secure enclave 1204D may include, for example, a SEP, a memory protection engine, a true random number generator (TRNG), a secure enclave AES engine, a public key accelerator, and an inter-IC bus.

[0109] The memory / storage 1212 may include one or more non-transitory computer-readable media including instructions (e.g., the communication protocol stack 1236) that may be executed by one or more of the processors 1204 to cause the device 1200 to perform various operations described herein. The memory / storage 1212 includes any type of volatile or non-volatile memory that may be distributed throughout the device 1200. In some embodiments, some of the memory / storage 1212 may be located on the processor 1204 itself (e.g., L1 cache and L2 cache), while other memory / storage 1212 is external to the processor 1204 but can be accessed via a memory interface. The memory / storage 1212 may include any suitable volatile or non-volatile memory, such as, but not limited to, dynamic random access memory (DRAM), static random access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state memory, or any other type of memory device technology.

[0110] The interface circuit 1208 may be a radio frequency (RF) interface having a transceiver circuit and a radio frequency front end module (RFEM) that allows the device 1200 to communicate with other devices via a radio access network. The RF interface may include various elements arranged in a transmit path or a receive path. These elements may include, for example, switches, mixers, amplifiers, filters, synthesizer circuits, and control circuits. The interface circuit 1208 may additionally / alternatively include other network interfaces for communicating via other wired or wireless networks, for example, an Ethernet interface.

[0111] The user interface 1216 includes various input / output (I / O) devices designed to enable a user to interact with the device 1200. The user interface 1216 includes input device circuits and output device circuits. The input device circuit includes any physical or virtual components for accepting input, including in particular one or more physical or virtual buttons (e.g., reset buttons), physical keyboards, keypads, mice, touch pads, touch screens, microphones, scanners, headphones, etc. The output device circuit includes any physical or virtual components for displaying information or otherwise conveying information (such as sensor readings, actuator positions, or other similar information). The output device circuit may include any number or combination of audio or visual displays, including in particular one or more simple visual outputs / indicators (e.g., binary state indicators, such as light emitting diodes (LEDs) and multi-character visual outputs) or more complex outputs, such as display devices or touch screens (e.g., liquid crystal displays (LCDs), LED displays, quantum dot displays, and projectors), wherein the output of characters, graphics, multimedia objects, etc. is generated or produced by the operation of the device 1200.

[0112] Sensors 1220 may include devices, modules, or subsystems that are designed to detect events or changes in their environment and send information about the detected events (sensor data) to some other device, module, or subsystem. Examples of such sensors include: an inertial measurement unit including an accelerometer, gyroscope, or magnetometer; a microelectromechanical system or nanoelectromechanical system including a three-axis accelerometer, a three-axis gyroscope, or a magnetometer; a liquid level sensor; a flow sensor; a temperature sensor (e.g., a thermistor); a pressure sensor; a barometric pressure sensor; a gravity meter; an altimeter; an image capture device (e.g., a camera or a lensless aperture); a light detection and ranging sensor; a proximity sensor (e.g., an infrared radiation detector, etc.); a depth sensor; an ambient light sensor; an ultrasonic transceiver; and a microphone or other similar audio capture device.

[0113] The driver circuit 1222 may include software and hardware elements that operate to control a particular device embedded in, attached to, or otherwise communicatively coupled to the device 1200. The driver circuit 1222 may include various drivers to allow other components to interact with or control various input / output (I / O) devices that may be present in or connected to the device 1200. For example, the driver circuit 1222 may include a display driver for controlling and allowing access to a display device, a touch screen driver for controlling and allowing access to a touch screen interface, a sensor driver for obtaining sensor readings of the sensor 1220 and controlling and allowing access to the sensor 1220, a driver for obtaining an actuator position of an electromechanical component or controlling and allowing access to an electromechanical component, a camera driver for controlling and allowing access to an embedded image capture device, and an audio driver for controlling and allowing access to one or more audio devices.

[0114] The PMIC 1224 can manage the power provided to the various components of the device 1200. Specifically, with respect to the processor 1204, the PMIC 1224 can control power source selection, voltage scaling, battery charging, or DC-DC conversion.

[0115] In some embodiments, the PMIC 1224 may control or otherwise be a part of various power saving mechanisms of the device 1200 including DRX, as discussed herein.

[0116] The battery 1228 can power the device 1200, but in some examples, the device 1200 can be installed or deployed in a fixed location and can have a power source coupled to the power grid. The battery 1228 can be a lithium-ion battery, a metal-air battery, such as a zinc-air battery, an aluminum-air battery, a lithium-air battery, etc. In some specific implementations, such as in vehicle-based applications, the battery 1228 can be a typical lead-acid automobile battery.

[0117] Fig.13 An example device 1300 is shown in accordance with some embodiments. Device 1300 may be similar to base station 108, DS server 604, certificate server 608, or server 704, and may be substantially interchangeable therewith.

[0118] Device 1300 may include a processor 1304 , an RF interface circuit 1308 , a core network (CN) interface circuit 1312 , a memory / storage circuit 1316 , and antenna structures 1326 .

[0119] Components of device 1300 may be coupled to various other components via one or more interconnects 1328 .

[0120] The processor 1304, RF interface circuit 1308, memory / storage circuit 1316 (including communication protocol stack 1310), antenna structure 1326 and interconnect 1328 may be similar to those described in detail in the accompanying drawings. Fig.12 Like named elements are shown and described.

[0121] The CN interface circuit 1312 may provide connectivity to a core network (e.g., a 5th Generation Core Network (5GC) using a 5th Generation Core Network (5GC) compatible network interface protocol such as a Carrier Ethernet protocol or some other suitable protocol). Network connectivity may be provided to / from the device 1300 via optical fiber or wireless backhaul. The CN interface circuit 1312 may include one or more dedicated processors or FPGAs for communicating using one or more of the aforementioned protocols. In some implementations, the CN interface circuit 1312 may include multiple controllers for providing connectivity to other networks using the same or different protocols.

[0122] It is understood that the use of personally identifiable information should be subject to privacy policies and practices that are generally recognized to meet or exceed industry or government requirements for maintaining user privacy. Specifically, personally identifiable information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use, and the nature of the authorized use should be clearly stated to users.

[0123] For one or more embodiments, at least one of the components shown in one or more of the foregoing figures may be configured to perform one or more operations, techniques, processes, or methods described in the following example section. For example, the baseband circuit described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the following examples. For another example, the circuit associated with the UE, base station, or network element described above in conjunction with one or more of the foregoing figures may be configured to operate according to one or more of the examples shown in the example section below.

[0124] Example

[0125] In the following sections, additional exemplary embodiments are provided.

[0126] Embodiment 1 includes a method, comprising: generating a start pairing message to be transmitted to a server, the start pairing message being used to pair a universal integrated circuit card (UICC) and a baseband processor of a device; processing an authentication request received from the server; generating a generate proof message to be transmitted to a secure enclave processor (SEP) on the device based on the authentication request; and receiving a SEP proof signed by a SEP-specific key pair from the SEP, the SEP proof conveying a SEP certificate.

[0127] Embodiment 2 includes a method according to embodiment 1 or some other embodiment herein, wherein the UICC is an embedded UICC (eUICC), and the start pairing message includes: a unique chip identifier (ECID) associated with the device, an eUICC identifier (EID) associated with the eUICC, or a Global System for Mobile Communications Association (GSMA) topic key identifier.

[0128] Embodiment 3 includes the method of claim 1 or 2 or some other embodiment herein, wherein the UICC is an embedded UICC (eUICC), the authentication request includes one or more hardware security module (HSM) challenges, and the generate attestation message includes the one or more HSM challenges.

[0129] Embodiment 4 includes the method according to embodiment 3 or some other embodiment herein, wherein the one or more HSM challenges include: an HSM challenge for the SEP; or an HSM challenge for the eUICC.

[0130] Embodiment 5 includes a method according to embodiment 3 or some other embodiment herein, wherein the one or more HSM challenges include an HSM challenge for the eUICC, and the method further includes: generating a local profile assistant (LPA) signature request with the HSM challenge for the UICC to be transmitted to the eUICC.

[0131] Embodiment 6 includes the method according to embodiment 5 or some other embodiment herein, the method further comprising: receiving an LPA signature response from the eUICC, the LPA signature response including a payload having the HSM challenge for the UICC signed with the UICC signature and a certificate chain to be used to verify the UICC signature; and generating an authentication response to be transmitted to the server based on the LPA signature response.

[0132] Embodiment 7 includes the method of embodiment 6 or some other embodiment herein, wherein the authentication response includes the SEP attestation, the certificate, an eUICC signature, or an eUICC certificate.

[0133] Embodiment 8 includes a method according to embodiment 6 or some other embodiment herein, further comprising: receiving a first storage pairing key message including a server certificate from the server; and generating a second storage pairing key message to be transmitted to the eUICC with the server certificate and a signed certificate from the server, wherein the server certificate includes a UICC identifier (ID) associated with the UICC and a public key of the SEP certificate.

[0134] Embodiment 9 includes the method of embodiment 8 or some other embodiment herein, further comprising: receiving a response from the UICC indicating that the UICC verified the SEP attestation, the signed certificate, and the EID and has stored the public key.

[0135] Embodiment 10 includes a method to be implemented by a universal integrated circuit card (UICC), the method comprising: transmitting a reset answer (ATR) message including pairing capabilities of the UICC and an unpaired indication to a baseband processor; receiving an initialization pairing message with an international mobile equipment identifier (IMEI) associated with the baseband processor from the baseband processor; generating a random key; and transmitting the random key to the baseband processor.

[0136] Embodiment 11 includes the method according to embodiment 10 or an embodiment herein, the method further comprising: receiving a final pairing message from the baseband processor indicating that the random key is stored by the baseband processor.

[0137] Embodiment 12 includes the method according to embodiment 11 or some other embodiment herein, further comprising: entering a pairing state based on the reception of the final pairing message.

[0138] Embodiment 13 includes a method according to embodiment 12 or some other embodiment herein, wherein the ATR message is a first ATR message, and the method further includes: detecting a power-on or reset event; determining that the UICC is in the pairing state based on the detection of the power-on or reset event; and transmitting a second ATR message with a restricted indication to the processor, the restricted indication being used to indicate that the operation of the UICC is limited to a subset of available operations.

[0139] Embodiment 14 may include a method according to embodiment 13 or some other embodiment herein, the method further comprising: receiving an initialization authentication message from the processor; transmitting a random number to the processor; receiving a message authentication code (MAC) message from the processor, the MAC message being based on the random number and an IMEI associated with the processor; and performing one or more verification operations based on the MAC message; and determining that the processor is the baseband processor based on performing the one or more verification operations.

[0140] Embodiment 15 includes a method according to embodiment 14 or some other embodiment herein, wherein the MAC message is based on a cryptographic-based MAC algorithm or a hash-based MAC algorithm.

[0141] Embodiment 16 includes a method according to embodiment 14 or some other embodiment herein, wherein the one or more verification operations include: verification of the MAC message, verification of the IMEI, or verification of the random number.

[0142] Embodiment 17 includes the method of embodiment 14 or some other embodiment herein, further comprising: based on the determination that the processor is the baseband processor, transmitting a message to the baseband processor indicating that the UICC is no longer limited to the subset of available operations.

[0143] Embodiment 18 includes a method according to embodiment 13 or some other embodiment herein, wherein the subset of available operations includes operations of performing an initialization process with the baseband processor.

[0144] Embodiment 19 includes a method as in embodiment 13 or some other embodiment herein, wherein the subset of available operations includes operations that enable installation of UICC firmware.

[0145] Embodiment 20 includes a method as described in embodiment 13 or some other embodiment herein, wherein the subset of available operations includes operations to debug or identify the UICC.

[0146] Another embodiment may include an apparatus comprising means for performing one or more elements of a method as described or associated with any of Embodiments 1 to 20, or any other method or process described herein.

[0147] Another embodiment may include one or more non-transitory computer-readable media, which include instructions that, when executed by one or more processors of an electronic device, cause the one or more processors to perform one or more elements of a method described or related to any of Embodiments 1 to 20 or any other method or process described herein.

[0148] Another embodiment may include an apparatus comprising logic components, modules, or circuits for performing one or more elements of the method described in or related to any of Embodiments 1 to 20, or any other method or process described herein.

[0149] Another embodiment may include a method, technique or process described or related to any one of Embodiments 1 to 20, or a portion or component thereof.

[0150] Another embodiment may include a device comprising: one or more processors and one or more computer-readable media, the one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform a method, technique, or process, or portion thereof, described or related to any one of Embodiments 1 to 20.

[0151] Another embodiment may include a signal as described or related to any one of embodiments 1 to 20, or a portion or component thereof.

[0152] Another embodiment may include a datagram, information element, packet, frame, segment, PDU or message, or a portion or component thereof, as described or related to any one of embodiments 1 to 20, or otherwise described in the present disclosure.

[0153] Another embodiment may include a signal encoded with data as described or related to any one of Embodiments 1 to 20, or a portion or component thereof, or described in other ways in this disclosure.

[0154] Another embodiment may include a signal encoded with a datagram, IE, packet, frame, segment, PDU or message as described or associated with any of Embodiments 1 to 20, or a portion or component thereof, or otherwise described in the present disclosure.

[0155] Another embodiment may include an electromagnetic signal carrying computer-readable instructions, wherein execution of the computer-readable instructions by one or more processors will cause the one or more processors to perform a method, technique, or process, or portion thereof, described or related to any one of Embodiments 1 to 20.

[0156] Another embodiment may include a computer program comprising instructions, wherein execution of the program by a processing element causes the processing element to perform a method, technique, or process described or related to any one of Embodiments 1 to 20, or a portion thereof.

[0157] Another embodiment may include a signal in a wireless network as shown and described herein.

[0158]

[0013] Another embodiment may include a method of communicating in a wireless network as shown and described herein.

[0159]

[0013] Another embodiment may include a system for providing wireless communications as shown and described herein.

[0160]

[0013] Another embodiment may include an apparatus for providing wireless communications as shown and described herein.

[0161] Unless explicitly stated otherwise, any of the above examples may be combined with any other example (or combination of examples). The foregoing description of one or more specific implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise form disclosed. Modifications and variations are possible in view of the above teachings or may be obtained from the practice of various embodiments.

[0162] Although the above embodiments have been described in considerable detail, numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to include all such variations and modifications.

Claims

1. A method comprising: generating a start pairing message to be transmitted to a server, the start pairing message being used to pair a universal integrated circuit card (UICC) with a baseband processor of the device; Processing an authentication request received from the server; generating, based on the authentication request, a generation proof message to be transmitted to a secure enclave processor (SEP) on the device; as well as A SEP attestation signed by a SEP-specific key pair is received from the SEP, the SEP attestation conveying a SEP certificate.

2. The method of claim 1 , wherein the UICC is an embedded UICC (eUICC), and the start pairing message comprises: A unique chip identifier (ECID) associated with the device, an eUICC identifier (EID) associated with the eUICC, or a Global System for Mobile Communications Association (GSMA) subject key identifier.

3. The method of claim 1 , wherein the UICC is an embedded UICC (eUICC), the authentication request comprises one or more hardware security module (HSM) challenges, and the generating attestation message comprises the one or more HSM challenges.

4. The method of claim 3, wherein the one or more HSM challenges include: HSM queries on the SEP; or An HSM challenge for the eUICC.

5. The method of claim 3, wherein the one or more HSM challenges include an HSM challenge for the eUICC, and the method further comprises: A Local Profile Assistant (LPA) signed request with the HSM challenge for the eUICC is generated to be transmitted to the eUICC.

6. The method according to claim 5, further comprising: receiving, from the eUICC, an LPA signed response, the LPA signed response comprising a payload having the HSM challenge for the UICC signed with a UICC signature and a certificate chain to be used to verify the UICC signature; as well as An authentication response is generated based on the LPA signed response to be transmitted to the server.

7. The method of claim 6, wherein the authentication response comprises the SEP attestation, the certificate, an eUICC signature, or an eUICC certificate.

8. The method according to claim 6 or 7, further comprising: receiving, from the server, a first stored pairing key message including a server certificate; as well as generating a second stored pairing key message to be transmitted to the eUICC with the server certificate and a signed certificate from the server, The server certificate includes an eUICC identifier (EID) associated with the eUICC and a public key of the SEP certificate.

9. The method according to claim 8, further comprising: A response is received from the UICC indicating that the UICC verified the SEP attestation, the signed certificate, and the EID and has stored the public key.

10. A universal integrated circuit card (UICC), comprising: Interface circuit; and A processing circuit, the processing circuit is coupled to the interface circuit, and the processing circuit is used to: transmitting, via the interface circuit, to a baseband processor, an answer to reset (ATR) message including a pairing capability of the UICC and an unpaired indication; receiving, via the interface circuitry, from the baseband processor an initialization pairing message having an International Mobile Equipment Identifier (IMEI) associated with the baseband processor; Generate a random key; as well as The random key is transmitted to the baseband processor via the interface circuit.

11. The UICC according to claim 10, wherein the processing circuit is further configured to: A final pairing message indicating the random key stored by the baseband processor is received from the baseband processor via the interface circuit.

12. The UICC according to claim 11, wherein the processing circuit is further configured to: A pairing state is entered based on receipt of the final pairing message.

13. The UICC of claim 12, wherein the ATR message is a first ATR message and the processing circuit is further configured to: Detecting power-on or reset events; and determining that the UICC is in the pairing state based on detecting the power on or reset event; and A second ATR message with a restriction indication is transmitted to the processor to indicate that operation of the UICC is restricted to a subset of available operations.

14. The UICC according to claim 13, wherein the processing circuit is further configured to: receiving an initialization authentication message from the processor via the interface circuit; transmitting a random number to the processor via the interface circuit; receiving a message authentication code (MAC) message from the processor via the interface circuit, the message authentication code (MAC) message being based on the random number and an IMEI associated with the processor; performing one or more authentication operations based on the MAC message; as well as The processor is determined to be the baseband processor based on the execution of the one or more verification operations.

15. The UICC of claim 14, wherein the MAC message is based on a cryptographic-based MAC algorithm or a hash-based MAC algorithm.

16. The UICC of claim 14, wherein the one or more authentication operations comprise: Verification of the MAC message, verification of the IMEI or verification of the random number.

17. The UICC according to claim 14, wherein the processing circuit is further configured to: Based on a determination that the processor is the baseband processor, a message is transmitted to the baseband processor indicating that the UICC is no longer restricted to the subset of available operations.

18. A UICC according to any one of claims 13 to 17, wherein the subset of available operations comprises an operation to perform an initialisation procedure with the baseband processor.

19. A UICC according to any one of claims 13 to 17, wherein the subset of available operations comprises operations enabling installation of UICC firmware.

20. A UICC according to any one of claims 13 to 17, wherein the subset of available operations comprises operations to debug or identify the UICC.

Images