Methods for establishing a secure communication channel

Method for establishing a secure communication channel

METHODS FOR ESTABLISHING A SECURE COMMUNICATION CHANNEL

The described embodiments generally relate to wireless communication technology. More specifically, the current embodiment relates to the deployment of an embedded subscriber identity module (eSIM) using a secure communication channel.

Wireless communication devices, such as smart phones, have been traditionally configured to utilize Universal Integrated Circuit Cards (UICC) that provide access to wireless network services. The UICC usually takes the form of a removable small card (for example, a Subscriber Identity Module (SIM) card) inserted into a wireless communication device. In most cases, each UICC is associated with a single "issuer" (such as a mobile network operator) that controls the programming and distribution of the UICC.

In a relatively recent implementation, a non-removable UICC is included on the system board of a wireless communication device, which is referred to herein as an embedded UICC (eUICC). These eUICCs are different from traditional removable UICCs. The difference is that eUICCs are non-removable and soldered to the system board of the wireless communication device. The eUICC can program one or more eSIMs, and each of the eSIMs can emulate and replicate the architecture of a typical SIM to enable wireless communication devices (including eUICC) to access wireless network services.

The use of eUICC and eSIM can provide significant advantages over traditional UICC. For example, due to the need not to adapt to the size and appearance of a removable SIM card, eUICC can provide wireless communication device manufacturers with increased flexibility in wireless communication device design. As another example, when configuring a wireless communication device to access the mobile network operators network, remotely The ability to deploy (for example, in the air) eSIM can provide convenience for consumers and suppliers.

Existing methods used to deploy eSIM (such as those provided by GlobalPlatform^TMThe methods specified by the specification involve the use of a symmetric key to encrypt the eSIM and transmit the eSIM self-provisioning entity to the eUICC of the wireless communication device. Specifically, each eUICC is associated with a symmetric key and stores the symmetric key, and the provisioning entity stores a copy of the symmetric key of the eUICC for each eUICC known to the provisioning entity. In this way, when the provisioning entity has the task of transferring the eSIM to the eUICC, the provisioning entity can use the symmetric key of the eUICC to securely encrypt the eSIM and transmit the eSIM to the eUICC, so that the eUICC can decrypt and utilize the eSIM. In terms of design, this symmetric key is shared by the deployment entity and eUICC and is only known to the deployment entity and eUICC in order to prevent malicious entities from intercepting, decrypting, and transmitting using eSIM. Disadvantageously, the security flaws associated with this design are still difficult to resolve, and the overall level of exposure increases with the increase in the size and complexity of the wireless system. Therefore, there is a need to provide an improved security solution for the communication channel established between the eUICC and external "off-card" entities.

Some example embodiments provide methods, devices, and computer program products for establishing a secure communication channel between an "off-card" entity (for example, a deployment entity) and an eUICC. Specifically, these example embodiments illustrate techniques related to the establishment of a symmetric key with a short range (that is, based on a working phase). Specifically, an off-card entity and each eUICC in a group of eUICCs managed by the off-card entity have long-term public key infrastructure (PKI) information. When a secure communication channel is to be established between the off-card entity and an eUICC, the eUICC and the off-card entity can authenticate each other based on the PKI information (for example, by verifying the public key) possessed by the respective entities. After authenticating each other, the off-card entity and the eUICC perform steps involving establishing a session-based symmetric key for protecting data transmitted between the off-card entity and the eUICC. When "full forward security" is required, each of the off-card entity and the eUICC generates a shared-based session that is used by each other to establish a The respective short-lived PKI information of the symmetric key. When "half forward security" is required, when the shared session-based symmetric key is created, only the off-card entity generates short-term PKI information, which can provide performance benefits. Once the shared session-based symmetric key is created, the off-card entity and the eUICC can safely communicate information between each other. In some embodiments, the shared session-based symmetric key can be cached by the off-card entity and the eUICC to reduce additional items involved when subsequently establishing a secure connection. Alternatively, the shared working phase-based symmetric key can be discarded every time the secure connection between the off-card entity and the eUICC is closed, thereby providing a higher level of security.

This summary is provided only for the purpose of summarizing some example embodiments in order to provide a basic understanding of some aspects of the invention. Therefore, it should be understood that the above-mentioned example embodiments are only examples, and should not be construed as narrowing the scope or spirit of the present invention in any way. Other embodiments, aspects and advantages will become apparent from the following detailed description of the accompanying drawings which illustrate the principles of the embodiments by way of example.

<p>100Example System</p><p>102Provisioning entity/block</p><p>104Internet</p><p>106Wireless communication device/block</p><p>110First-Order Entity</p><p>112 Tier 2 Entity</p><p>114Tier 3 Entity</p><p>120eUICC</p><p>200device</p><p>210Processing circuit</p><p>212Processor</p><p>214Memory</p><p>216Communication interface</p><p>218eSIM Preparation Module</p><p>219PKI Information</p><p>300device</p><p>310Processing circuit</p><p>312Processor</p><p>314Memory</p><p>316Communication interface</p><p>318User Interface</p><p>320eUICC</p><p>321PKI Information</p><p>400A method for establishing a secure working phase between the deployment entity and the eUICC of the communication device</p><p>Block 405-430</p><p>450Method for establishing a secure work phase between eUICC 120 and deployment entity 102</p><p>Block 455-480</p><p>500Full forward safety</p><p>Block 502-520</p><p>530Half forward safety</p><p>Block 532-546</p>

The present invention will be easily understood by the following detailed description in conjunction with the accompanying drawings. In the accompanying drawings, the same reference numerals denote the same structural elements, and among them: Figure 1 illustrates an example system for eSIM deployment according to some example embodiments .

Figure 2 illustrates a block diagram of a device that can be implemented on a deployment entity according to some example embodiments.

Figure 3 illustrates a block diagram of a device that can be implemented on a wireless communication device according to some example embodiments.

4A to 4B illustrate an example method for establishing a secure working phase between the deployment entity and the eUICC of the communication device according to some embodiments.

Figures 5A-5B illustrate example methods for establishing full forward security or half forward security according to some embodiments.

Reference will now be made in detail to the representative embodiments illustrated in the drawings. It should be understood that the following description is not intended to limit the embodiments to one preferred embodiment. On the contrary, the following description is intended to cover alternatives, modifications, and equivalents as may be included in the spirit and scope of the described embodiments as defined by the scope of the appended application.

The existing method for establishing secure communication between the eUICC and the "off-card" entity (also referred to as the "provisioning entity" in this article) relies on the pre-established, long-term symmetrical funds owned by the off-card entity and the eUICC. key. For example,<i>the Security Upgrade for Card Content Management Card Specification Version 2.2</i>-The GlobalPlatform of Amendment E since November 2011 (for all purposes, the full content of which is incorporated into this article by reference)^TMspecification<i>Version 1.0</i>It is specified that the symmetric key associated with the eUICC is located outside the card in conjunction with the eUICC for management tasks (for example, deploying a new eSIM to the eUICC, updating the existing eSIM at the eUICC, removing the eSIM from the eUICC and the like) Physical maintenance. Specifically, in order to establish a secure communication channel between the off-card entity and the eUICC, the off-card entity recognizes the eUICC, retrieves (for example, from the local database) the symmetric key associated with the eUICC, and uses the symmetric key to Encrypt the data transmitted to eUICC. Since the eUICC also has a symmetric key like the entity outside the card, the eUICC can successfully decrypt the data received from the entity outside the card, and can also encrypt the data transmitted back to the entity outside the card.

Disadvantageously, many security flaws continue to compromise the overall integrity of the aforementioned methods. One problem is that the off-card entity needs to store the symmetric key of each eUICC that the off-card entity is located to manage. When the eUICC needs to be managed, this can present a challenge for efficiently (ie, quickly) extracting the symmetric key. In addition, storing the set of symmetric keys creates a weakness, because each symmetric key is stored in at least two locations (ie, by an entity outside the card and stored by the eUICC). In addition, the amount of weaknesses increases proportionally with the level of backup implemented. For example, this can be problematic when a highly redundant database is used to store symmetric keys. Another problem is that when eUICC is manufactured, it is not clear how or who uses eUICC (for example, which mobile network operator will manage eUICC). because Therefore, when there is a change in the management and/or ownership of the eUICC, a large set of symmetric keys needs to be migrated between entities outside the card, which greatly increases the exposure level. Another problem is that the complexity of the symmetric key is increased to make it difficult for a malicious party to expose (for example, derive) the symmetric key. As this complexity increases, the computing resources required to implement secure communication using symmetric keys also increase, which may be detrimental to the overall performance of computing devices (for example, mobile devices) with limited available processing and power resources. Finally, another problem is that the significant "forward" security risk is associated with existing symmetric key methods. Specifically, if a malicious party obtains a symmetric key, the malicious party can use the symmetric key to potentially access the available communication data (for example, a previous conversation) that has been protected by the symmetric key.

Some example embodiments disclosed herein solve the aforementioned problems by implementing secure communication between an off-card entity and the eUICC (by establishing a symmetric key with a short range (ie, based on a session)). The entity outside the card that is configured to manage a group of eUICC has long-term public key infrastructure (PKI) information, which can include the public key (PK_server) And private (that is, secret) key (SK_server) Formed a pair. When a secure communication channel is to be established between the off-card entity and the eUICC, the eUICC can authenticate the off-card entity based on at least a part of the PKI information possessed by the off-card entity (for example, by verifying the certificate authority (CA), which The digital signature is included in the public key (PK_server)middle). Similarly, eUICC has its own long-term PKI information, which can include public key (PK_eUICC) And private key (SK_eUICC) Formed a pair. The entity outside the card can authenticate the eUICC based on at least a part of the long-term PKI information held by the eUICC (for example, by verifying the CA, its digital signature is included in the public key (PK) held by the eUICC._eUICC)middle). It should be noted that in some embodiments, a certificate authority is not required to perform the aforementioned authentication. Instead, if the root key set (the signature is based on the root key set) is trusted by the off-card entity and the eUICC, a self-signed certificate can be implemented. After authenticating each other, the off-card entity and the eUICC perform steps involving establishing a session-based symmetric key for protecting the data transmitted between the off-card entity and the eUICC. Here, it depends on the need for "full forward safety" or "half forward safety" Sex", two different methods can be used.

When full forward security is required, each of the off-card entity and eUICC generates its own short-lived PKI information. Specifically, an entity outside the card generates a short-lived public key (ePK_server) And the corresponding short-lived private (that is, secret) key (eSK_server); Use the long-term private key associated with the entity outside the card (SK_server) Sign ePK_server; And will be signed ePK_serverProvided to eUICC. Similarly, eUICC generates a short public key (ePK_eUICC) And the corresponding short-lived private key (eSK_eUICC); Use the long-term private key associated with eUICC (SK_eUICC) Sign ePK_eUICC; And will be signed ePK_eUICCProvided to entities outside the card. Subsequently, the off-card entity uses eSK_serverAnd signed ePK_eUICCTo generate a key based on the session (ie, short-lived), and eUICC uses eSK_eUICCAnd signed ePK_serverTo generate an equivalent symmetric key based on the session. This session-based symmetric key, which is independently generated by the off-card entity and eUICC and currently available for both off-card entity and eUICC, can be used by the off-card entity and eUICC to ensure the communication between the off-card entity and eUICC. Safe until the work phase is closed. It should be noted that the dual use of separate short-lived PKI information at the off-card entity and at the eUICC provides the benefit of preventing "interceptive" attacks. In addition, even when the long-term PKI information associated with the off-card entity and/or eUICC is cracked, the dual use of the single short-lived PKI information makes it difficult for malicious parties to access previous communications associated with the eUICC.

When half of the forward security is required, only entities outside the card generate short-term PKI information. Specifically, an entity outside the card generates a short-lived public key (ePK_server) And the corresponding short-lived private (that is, secret) key (eSK_server); Use the long-term private key associated with the entity outside the card (SK_server) Sign the short public key ePK_server; And will be signed ePK_serverProvided to eUICC. eUICC public key PK_eUICCProvided to entities outside the card. Subsequently, the entity outside the card uses the short-lived secret key eSK_serverAnd the public key PK provided_eUICCTo generate a key based on the session (ie, short-lived), and eUICC uses its own secret key SK_eUICCAnd ePK_serverTo generate an equivalent symmetric key based on the session. Independently produced And the symmetric key currently available for both the off-card entity and the eUICC based on the working phase can be used to ensure the security of the communication transmitted between the off-card entity and the eUICC until the working phase is closed. It should be noted that since the half-forward security method does not require the eUICC to generate short-term PKI information, it can reduce the amount of additional processing required at the eUICC. However, the disadvantage is that if the long-term private key (ie, SK_eUICC) Is cracked by a malicious party, the malicious party can potentially use the cracked SK_eUICCThe key accesses the previous communication associated with the eUICC.

After creating a shared session-based symmetric key, the off-card entity and eUICC can safely communicate information between each other. In some embodiments, each of the off-card entity and the eUICC can be configured to cache the shared session-based symmetric key to reduce the additional items involved when the secure communication channel is subsequently established. However, in order to maintain the highest level of security, each of the off-card entity and eUICC can be configured to generate a new session-based symmetric key each time a secure communication channel is established (using the method described in this article ).

The aforementioned techniques provide various benefits that are not provided by conventional methods. One benefit is that the off-card entity and the eUICC can establish a secure communication channel via an unprotected connection (for example, the Internet). This increases the overall bandwidth available, which can be critical in peak management time (for example, in the case of starting a new wireless device). Another benefit is that when the off-card entity and the eUICC authenticate each other, the certificate authority can be used to increase the level of security (although, as mentioned above, this approach is not required). Another benefit is that the shared session-based symmetric key can be cached for subsequent use, which can help reduce additional items involved every time the off-card entity and the eUICC need to communicate with each other securely. Another benefit is that "full forward" security and "half forward" security can be implemented, which can increase customer satisfaction with privacy concerns. In some embodiments, another benefit is that short-term PKI information is not derived using long-term PKI information assigned to off-card entities and/or eUICC. Advantageously, this can increase the difficulty involved in deriving long-term PKI information (even when short-term PKI information is cracked) Time).

It should be understood that various encryption algorithms can be used to perform the various techniques described in this article, such as the Diffie-Hellman algorithm, elliptic curve cryptography (ECC), Rivest/Shamir/Adleman (RSA) asymmetric algorithm and its Similar.

These and other embodiments are discussed below with reference to FIGS. 1 to 3, 4A to 4B, and 5A to 5B. However, those familiar with the art will easily understand that the detailed descriptions given in this document regarding these drawings are only for explanatory purposes and should not be construed as restrictive.

Figure 1 illustrates an example system 100 for eSIM deployment according to some example embodiments. The system 100 may include a deployment entity 102 and one or more wireless communication devices 106, which may communicate via a network 104.

The deployment entity 102 may be embodied as one or more computing devices. According to various example embodiments, the one or more computing devices may be configured to generate eSIMs and/or deploy eSIMs to be implemented on the wireless communication device 106 eUICC (e.g., eUICC 120). For example, the provisioning entity 102 may include one or more physical servers, a cloud computing infrastructure configured to implement the functionality of the provisioning entity 102 (for example, a virtual computing system implemented on the underlying physical hardware) And/or other server devices. In an embodiment where multiple physical computing devices provide the functionality of the deployment entity 102, the computing devices may be co-located in a common location, or may be dispersed across multiple physical locations and communicate via the network 104. The provisioning entity 102 can be hosted/operated by any entity that can maintain and deploy the pool of eSIMs, such as (by way of non-limiting examples) mobile network operators, device manufacturers, device suppliers, or other such entities.

The network 104 may be embodied as any network or combination of networks configured to support communication between two or more computing devices (such as the deployment entity 102 and the wireless communication device 106). By way of non-limiting example, the network 104 may include one or more wired networks, one or more wireless networks (e.g., cellular network, wireless local area network, wireless wide area network, wireless metropolitan area network, A certain combination thereof or the like), or a combination thereof, and in some example embodiments, the network 104 may include the Internet.

The wireless communication device 106 can be embodied as any computing device that can be configured to access a cellular network. By way of non-limiting examples, the wireless communication device 106 may be embodied as a cellular phone (such as a smart phone), a tablet computing device, a digital media player device, a cellular wireless hotspot device, a laptop computer, some combination thereof, or Its similar. As another example, the wireless communication device 106 may be embodied as a machine-to-machine (M2M) device or the like that can be configured to access a cellular network.

The wireless communication device 106 may include the eUICC 120, which may also be referred to as a "secure element." In some embodiments, the eUICC 120 may be embedded (eg, soldered to) the main system board of the wireless communication device 106. In some example embodiments, the eUICC 120 may include a sandboxed hardware/software environment that cannot be directly accessed by external entities, such as a main or host operating system (OS) that can be executed on the wireless communication device 106. The eUICC 120 can include processing circuits (such as microprocessors) and storage devices that can work together to process commands and perform various authentication mechanisms. Various authentication mechanisms can be used to enable the wireless communication device 106 to access the mobile network operator's network . In this regard, the eUICC 120 can be configured to maintain one or more eSIMs, such as eSIMs that can be deployed by the deployment entity 102. The eUICC 120 can be configured to use the eSIM installed on the eUICC 120 to facilitate network authentication for accessing the mobile operator's network.

The wireless communication device 106 and therefore the eSIM that can be deployed and/or installed on the eUICC 120 by the deployment entity 102 can be configured to access the network using any of various radio access technologies (RAT) . By way of non-limiting examples, the wireless communication device 106 and/or eSIM according to some example embodiments may support Long Term Evolution (LTE) RATs, such as various versions of the LTE standard specified by the 3rd Generation Partnership Project (3GPP), including Various versions of LTE, LTE-Advanced (LTE-A) and/or other existing or future versions using LTE technology. As another example, the wireless communication device 106 and/or eSIM according to some example embodiments may support a third-generation (3G) cellular RAT (such as Wideband Code Division Multiple Access (WCDMA) or other Universal Mobile Telecommunications System (UMTS) RAT, such as Time Division Synchronous Code Division Multiple Access (TD-SCDMA), CDMA2000, 1xRTT, and/or the like). As another example, according to The wireless communication device 106 and/or eSIM of some example embodiments may support a second generation (2G) cellular RAT, such as the Global System for Mobile Communications (GSM) RAT. It will be appreciated that the aforementioned RAT is provided by way of example and not by way of limitation. In this regard, the wireless communication device 106 and/or eSIM according to some example embodiments may be configured to pass through any existing or future cellular RATs (including, for example, various fifth-generation (5G) RATs under development). ) To communicate.

As previously described, the deployment entity 102 can be configured to deploy the eSIM to the eUICC 120 via the network 104. For example, this deployment can be implemented using various over-the-air (OTA) technologies. Additionally or alternatively, in some example embodiments, the wireless communication device 106 can be connected to the network 104 and/or directly connected to the deployment entity 102 via a wired connection, and the eSIM can be deployed to the eUICC 120 via a wired connection. According to various embodiments described further below, the eSIM deployed to the eUICC 120 can be included in the eSIM package, and the eSIM package can be generated and formatted by the deployment entity 102. The eUICC 120 can be configured to unpackage the eSIM from the eSIM kit and install the eSIM on the eUICC 120.

In some example embodiments, the deployment entity 102 and the eUICC 120 may be configured to implement and/or otherwise support one or more logical security layers, which may be provided for the deployment process Security mechanism. For example, the provisioning entity 102 of some example embodiments may be configured to implement one or more of a first-level (L1) entity 110, a second-level (L2) entity 112, and a third-level (L3) entity 114. The eUICC 120 of some example embodiments may implement a logical security layer and/or program (for example, L1, L2, and L3) corresponding to the logical security entity of the provisioning entity 102 on the local end. According to some example embodiments, L1 (for example, L1 entity 110 and any corresponding L1 layer/program on eUICC 120) can provide encryption services; L2 (for example, L2 entity 112 and any corresponding L2 layer/program on eUICC 120) ) Can provide anti-cloning service; and L3 (for example, any corresponding L3 layer/program on L3 entity 114 and eUICC 120) can provide authorization service. In some example embodiments, one or more of the L1 entity 110, the L2 entity 112, and the L3 entity 114 may be executed on a common entity server or a collection of servers The physical implementation of logical software. Alternatively, in some example embodiments, individual logical security entities (such as each of the L1 entity 110, the L2 entity 112, and the L3 entity 114) may be implemented on a physical server that implements another logical security Separation of physical servers.

FIG. 2 illustrates a block diagram of a device 200 that may be implemented on a provisioning server (such as a provisioning entity 102) according to some example embodiments. In this regard, the apparatus 200 can be implemented on any computing device or a plurality of computing devices that can be collectively configured to implement the functionality of the deployment entity 102. Therefore, it will be appreciated that, according to one or more example embodiments, one or more of the components illustrated in and described in relation to FIG. 2 may be implemented on a single computing device; or may be dispersed across a plurality of computing devices, The plurality of computing devices can collectively provide the functionality of the deployment entity 102. In addition, it should be understood that the components, devices, or elements illustrated in FIG. 2 and described in relation to FIG. 2 below may not be mandatory, and therefore some may be omitted in some embodiments. In addition, some embodiments may include additional or different components, devices, or elements beyond those illustrated in and described with respect to FIG. 2.

In some example embodiments, the device 200 may include a processing circuit 210 that may be configured to perform actions in accordance with one or more of the example embodiments disclosed herein. In this regard, the processing circuit 210 may be configured to execute one or more of the functionality of the provisioning server (such as the provisioning entity 102) and/or controlling the provisioning server (such as the provisioning entity 102) according to various example embodiments. 102) The performance of one or more functionalities. Therefore, according to one or more example embodiments (such as those illustrated in FIGS. 4A to 4B and FIGS. 5A to 5B and described below with respect to FIGS. 4A to 4B and FIGS. 5A to 5B), the processing The circuit 210 can be configured to perform data processing, application execution, and/or other processing and management services that can be implemented to prepare and deploy an eSIM.

In some embodiments, the device 200 or parts or components thereof (such as the processing circuit 210) may be implemented via one or more integrated circuits, and each of the one or more integrated circuits may include one or more chips . In some cases, one or more of the processing circuit 210 and/or the device 200 One additional component can therefore be configured to implement an embodiment on an integrated circuit (for example, as a "system-on-a-chip").

In some example embodiments, the processing circuit 210 may include a processor 212, and in some embodiments (such as the embodiment illustrated in FIG. 2), the processing circuit 210 may further include a memory 214. The processing circuit 210 can communicate with the communication interface 216 and/or the eSIM preparation module 218 or control the communication interface 216 and/or the eSIM preparation module 218 in other ways.

The processor 212 may be embodied in various forms. For example, the processor 212 may be embodied as various hardware-based processing components, such as microprocessors, co-processors, controllers, or various other computing or processing devices, including such as ASIC (Special Application Integrated Circuit), FPGA ( Field programmable gate array), a certain combination thereof, or an integrated circuit of the like. Although illustrated as a single processor, it should be understood that the processor 212 may include a plurality of processors. The plurality of processors can effectively communicate with each other and can be collectively configured to perform one or more functionalities of the deployment entity 102. In some embodiments where the apparatus 200 is embodied on a plurality of arithmetic devices, the plurality of processors that can collectively form the processor 212 may be dispersed across the plurality of arithmetic devices, and the plurality of arithmetic devices may be directly connected to each other and/or via a network. Communication channels (such as network 104) efficiently. In some example embodiments, the processor 212 may be configured to execute instructions that may be stored in the memory 214 and/or may be accessed by the processor 212 in other ways. In this way, whether configured by hardware or by a combination of hardware and software, the processor 212 can perform operations according to various embodiments when configured accordingly.

In some example embodiments, the memory 214 may include one or more memories and/or other storage devices. The memory 214 may include fixed and/or removable memory devices. 214 includes a plurality of memory devices according to embodiments of memory, the plurality of memory devices may be embodied on a single computing device or across a plurality of computing devices (for example , such as the formation of some examples of embodiments cloth embodiment of the construction entity 102 A plurality of arithmetic devices) are scattered, and the plurality of arithmetic devices can collectively provide the functionality of the apparatus 200. In some embodiments, the memory 214 may include a non-transitory computer-readable storage medium that can store Computer program instructions that can be executed by the processor 212. In this regard, the memory 214 may be configured to store information, data, applications, commands, and/or the like for enabling the device 200 to deploy various functions of the entity 102 according to one or more example embodiments . For example, the memory 214 of some example embodiments may be configured to store one or more eSIMs, which may be used to deploy to an eUICC (such as eUICC 120). Additionally or alternatively, the memory 214 can store parameters associated with various eUICCs, as described further below, which can be used to facilitate the preparation and packaging of eSIMs for deployment. In some embodiments, the memory 214 may communicate with one or more of the processor 212, the communication interface 216, or the eSIM preparation module 218 via one or more buses used to transfer information between the components of the device 200.

The device 200 may further include a communication interface 216. The communication interface 216 may be configured to enable the device 200 to communicate with another computing device (such as via the network 104). In this regard, the communication interface 216 may include one or more interface mechanisms for enabling communication with other devices and/or networks. In this way, the communication interface 216 may include, for example, an antenna (or multiple antennas) and is used to enable communication with a wireless communication network (for example, a cellular network, Wi-Fi, Li-Fi, WLAN, and/or other wireless communication networks). Communication network) supporting hardware and/or software, and/or used to support communication via cable, digital subscriber line (DSL), USB, FireWire, Ethernet, one or more optical transmission technologies And/or the communication modem or other hardware/software for the communication of other wired network connection methods. Thus, for example, the communication interface 216 can be configured to support communication with the wireless communication device 106 and/or the eUICC 120 implemented thereon via the network 104, so that the deployment entity 102 can participate in the eSIM deployment phase And deploy eSIM to eUICC 120.

The device 200 may further include an eSIM preparation module 218. The eSIM preparation module 218 can be embodied as various components, such as circuits, hardware, and computer program products including computer-readable media (such as memory 214) storing computer-readable program instructions that can be executed by processing devices (such as processor 212) , Or some combination thereof. In some embodiments, the processor 212 (or processing power The circuit 210) may include or otherwise control the eSIM preparation module 218. According to one or more example embodiments, such as those illustrated in FIGS. 4A to 4B and FIGS. 5A to 5B and described below with respect to FIGS. 4A to 4B and FIGS. 5A to 5B, some example embodiments The eSIM preparation module 218 can be configured to use the PKI information 219 to prepare and deploy an eSIM.

Figure 3 illustrates a block diagram of an apparatus 300 that may be implemented on a wireless communication device, such as the wireless communication device 106, according to some example embodiments. It should be understood that the components, devices, or elements illustrated in FIG. 3 below and described in relation to FIG. 3 may not be mandatory and therefore some may be omitted in some embodiments. In addition, some embodiments may include additional or different components, devices, or elements beyond what is illustrated in and described with respect to FIG. 3.

In some example embodiments, the device 300 may include a processing circuit 310 that can be configured to perform actions according to one or more of the example embodiments disclosed herein. In this regard, according to various example embodiments, the processing circuit 310 may be configured to perform one or more functionalities of the device 300 and/or control the performance of one or more functionalities of the device 300, and thus be implemented according to various examples Examples can provide components for performing the functionality of the device 300. According to one or more example embodiments, the processing circuit 310 may be configured to perform data processing, application execution, and/or other processing and management services. For example, in some embodiments, the processing circuit 310 may be configured to support the operation of the main host operating system of the wireless communication device.

In some embodiments, the device 300 or parts or components thereof (such as the processing circuit 310) may be implemented via one or more integrated circuits, and each of the one or more integrated circuits may include one or more chips . In some cases, one or more of the additional components of the processing circuit 310 and/or the device 300 may therefore be configured to implement an embodiment on an integrated circuit (eg, as a "system on a chip"). In some example embodiments, when implemented on a computing device or otherwise operatively coupled to the computing device, one or more components of the apparatus 300 may be implemented to enable the computing device to access a network (such as wireless Network 104) on the chipset. In some of these example embodiments, the device 300 may include a cellular baseband chipset, which may be configured to enable computing devices (such as wireless communication devices 106) Enough to operate on one or more cellular networks.

In some example embodiments, the processing circuit 310 may include a processor 312, and in some embodiments, such as illustrated in FIG. 3, the processing circuit 310 may further include a memory 314. The processing circuit 310 can communicate with the communication interface 316 and/or the user interface 318 or control the communication interface 316 and/or the user interface 318 in other ways.

The processor 312 may be embodied in various forms. For example, the processor 312 may be embodied as various hardware-based processing components, such as microprocessors, co-processors, controllers, or various other computing or processing devices, including such as ASIC (Special Application Integrated Circuit), FPGA ( Field programmable gate array), a certain combination thereof, or an integrated circuit of the like. Although illustrated as a single processor, it should be understood that the processor 312 may include a plurality of processors. The plurality of processors can effectively communicate with each other, and can be collectively configured to perform one or more functionalities of the wireless communication device 106, as described herein. In some example embodiments, the processor 312 may be configured to execute instructions that may be stored in the memory 314 or that may be accessed by the processor 312 in other ways. In this way, whether configured by hardware or by a combination of hardware and software, when configured accordingly, the processor 312 can perform operations according to various embodiments.

In some example embodiments, the memory 314 may include one or more memory devices. The memory 314 may include fixed and/or removable memory devices. In some embodiments, the memory 314 can provide a non-transitory computer-readable storage medium that can store computer program instructions that can be executed by the processor 312. In this regard, the memory 314 may be configured to store information, data, application programs, instructions, and/or the like used to enable the device 300 to perform various functions according to one or more example embodiments. In some embodiments, the memory 314 may be one or more of the processor 312, the communication interface 316, the user interface 318, or the eUICC 320 via one or more buses used to transfer information between the components of the device 300 Communication.

The device 300 may further include a communication interface 316. Communication media of some example embodiments The surface 316 may provide a wireless communication interface configured to enable the device 300 to send wireless signals to and receive signals from one or more wireless networks. For example, the communication interface 316 of some example embodiments may be configured to support access to the cellular network by enabling wireless communication with the cellular base station. Therefore, the communication interface 316 may include one or more transceivers and supporting hardware and/or software for enabling communication according to one or more cellular RATs. The communication interface 316 of some embodiments may further include one or more transceivers and/or other radio components to support one or more other wireless communication technologies, such as Wi-Fi (for example, IEEE 802.11 technology), Bluetooth, and/or Other wireless communication technologies. In some example embodiments, the communication interface 316 may additionally include support for connecting via cable, digital subscriber line (DSL), USB, Firewire, Ethernet, one or more optical transmission technologies, and/or other wired networks The communication modem or other hardware/software of the method of communication.

In some example embodiments, the device 300 may include a user interface 318. However, it should be understood that in some example embodiments, one or more aspects of the user interface 318 may be omitted, and in some embodiments, the user interface 318 may be omitted entirely. The user interface 318 may communicate with the processing circuit 310 to receive instructions input by the user and/or provide audible, visual, mechanical, or other output to the user. In this manner, the user interface 318 may include, for example, a keyboard, a mouse, a joystick, a display, a touch screen display, a microphone, a speaker, one or more biometric input devices, and/or other input/output mechanisms. In embodiments where the user interface 318 includes a touch screen display, the user interface 318 may be additionally configured to detect and/or receive touch and/or other movement gestures or other input instructions to the display.

The device 300 may further include an eUICC 320, and the eUICC 320 may, for example, include an embodiment of the eUICC 120. Therefore, according to various example embodiments, the eUICC 320 may include processing circuits and storage devices that can be configured to store and manage one or more eSIMs deployed by the deployment entity 102. According to various example embodiments, such as those illustrated in FIGS. 4A to 4B and FIGS. 5A to 5B and described below with respect to FIGS. 4A to 4B and FIGS. 5A to 5B Etc., the eUICC 320 can be configured to use the PKI information 321 to de-package and install the eSIM deployed by the deployment entity 102.

Figure 4A illustrates a method 400 for establishing a secure working phase between a deployment entity and an eUICC of a communication device according to some embodiments. Specifically, the method 400 may be executed by the provisioning entity 102 of some example embodiments. One or more of the processing circuit 210, the processor 212, the memory 214, the communication interface 216, and the eSIM preparation module 218 may, for example, provide components for performing the operations described in FIG. 4A and described in relation to FIG. 4A .

As shown in FIG. 4A, the method 400 starts at 405, in which the provisioning entity 102 receives from a mobile device (for example, the wireless communication device 106) that includes an eUICC (for example, the eUICC 120 of the wireless communication device 106) a request to establish a secure communication channel ask. 405 may be executed in response to determining that the eUICC 120 is the target to which the eSIM is to be deployed, and the determination may be initiated by the wireless communication device 106 and/or the eUICC 120. At 410, the deployment entity 102 authenticates the eUICC 120 based on the PKI information associated with the eUICC 120 and provided by the eUICC 120. Specifically, the provisioning entity 102 can be based on the public key (PK_eUICC) Authenticate eUICC 120. For example, authentication further involves the provisioning entity 102 requesting the eUICC 120 to use the corresponding private key (SK_eUICC) Sign data (for example, random value) to prove that eUICC 120 is a PK_eUICCAnd SK_eUICCThe true owner.

At 415, in conjunction with the eUICC 120, the deployment entity 102 generates a symmetric key based on the working phase (ie, a short-lived symmetric key). In some embodiments, the provisioning server 102 may implement a Certificate Authority Secure Domain (CASD), which is configured to facilitate the creation of a secure communication channel by each of the provisioning entity 102 and eUICC 120. The symmetric key used is based on the session. For example, when the deployment entity 102 attempts to establish a secure communication channel with the eUICC 120, the deployment server 102 may send to CASD a session-based report based on at least the PKI information exchanged between the deployment entity 102 and the eUICC 120. Symmetric key request. At 420, the provisioning entity 102 stores the work phase-based The symmetric key. At 425, the deployment entity 102 establishes a secure communication channel with the eUICC 120 using the symmetric key based on the session. In some cases, the deployment server 102 may optionally cache (for example, in a secure network domain) the symmetric key based on the session used to establish a subsequent secure communication channel with the eUICC 120. The caching of the symmetric key based on the session by the provisioning server 102 will also involve the eUICC 120 caching the symmetric key based on the session, so that the subsequent secure communication channel can be effectively established. At 430, the deployment entity 102 provides management tasks to the eUICC 120 via a secure communication channel. For example, these management tasks may involve providing a new eSIM to be installed by the eUICC 120; providing updates to the eSIM managed by the eUICC 120 (e.g., enabling/disabling eSIM; updating the eSIM to a new version, etc.); so The eSIM managed by the eUICC 120 is removed from the eUICC 120, and the like.

FIG. 4B illustrates a method 450 for establishing a secure work phase between the eUICC 120 and the provisioning entity 102 according to some embodiments. As shown, the method 450 starts at 455, where the eUICC 120 sends a request to the provisioning entity 102 to establish a secure communication channel. At 460, the eUICC 120 authenticates the deployment entity 102 based on the PKI information associated with the deployment entity 102 and provided by the deployment entity 102 (for example, the public key included in the PKI information 219). At 465, in conjunction with the deployment entity 102, the eUICC 120 generates a symmetric key based on the session. In some embodiments, the eUICC 120 may implement a certificate authority secure domain (CASD), which is configured to facilitate the creation of a secure communication channel by the eUICC 120 and the deployment entity 102. The symmetric key used by each of them is based on the session. For example, when the eUICC 120 attempts to establish a secure communication channel with the deployment entity 102, the eUICC 120 may issue to CASD a symmetric key based on the session at least based on the PKI information exchanged between the eUICC 120 and the deployment entity 102 Request.

At 470, the eUICC 120 stores the symmetric key based on the session in a secure domain managed by the eUICC 120 (for example, a protected area of the memory included in the eUICC 120). At 475, eUICC 120 uses the symmetric key based on the session The body 102 establishes a secure communication channel. In some cases, the eUICC 120 may optionally cache a session-based symmetric key used to establish a subsequent secure communication channel with the deployment entity 102 (for example, in a secure network domain). The caching of the session-based symmetric key at the eUICC 120 will also involve the provisioning server 102 to cache the session-based symmetric key, so that the subsequent secure communication channel can be effectively established. At 480, the eUICC 120 performs management tasks provided by the deployment entity 102 via a secure communication channel.

It should be understood that the operations illustrated in FIGS. 4A to 4B and described with respect to FIGS. 4A to 4B are not limited to the illustrated order. In this regard, various operations may be performed simultaneously and/or in a different order than that illustrated in FIGS. 4A to 4B.

Figure 5A illustrates a method for establishing full forward security 500 according to some embodiments. As shown, the method 500 starts at 502, which involves the provisioning entity 102 having a long-term key (SK_server, PK_server) (For example, the PKI information 219 illustrated in FIG. 2). At 504, the provisioning entity 102 generates a key (eSK_server, EPK_server) Short-term PKI information of the composition. At 506, the deployment entity 102 uses SK_serverSign ePK_server. At 508, the deployment entity 102 will sign the ePK_serverProvide to the wireless communication device 106 and receive the signed ePK from the wireless communication device 106_eUICC(It is generated by the wireless communication device at step 516, described below). At 510, the deployment entity 102 uses eSK_serverAnd signed ePK_eUICCGenerate a shared secret (ShS) (that is, a symmetric key based on the working phase).

At 512, the wireless communication device 106 has a long-term key (SK_eUICC, PK_eUICC) (For example, the PKI information 321 illustrated in FIG. 3). At 514, the wireless communication device 106 generates a key (eSK_eUICC, EPK_eUICC) Short-term PKI information of the composition. At 516, the wireless communication device 106 uses SK_eUICCSign ePK_eUICC. At 518, the wireless communication device 106 will be signed ePK_eUICCProvide to the deployment entity 102, and receive the signed ePK from the deployment entity 102_server(It was generated at 506 as described above). At 520, the wireless communication device 106 uses eSK_eUICCAnd signed ePK_serverGenerate the same ShS (that is, based on the symmetric key of the session).

Figure 5B illustrates a method 530 for establishing half forward security according to some embodiments. As shown, the method 530 starts at 532, which involves the provisioning entity 102 having a long-term key (SK_server, PK_server) (For example, the PKI information 219 illustrated in FIG. 2). At 534, the provisioning entity 102 generates a key (eSK_server, EPK_server) Short-term PKI information of the composition. At 536, the deployment entity 102 uses SK_serverSign ePK_server. At 538, the deployment entity 102 will sign the ePK_serverProvide to the wireless communication device 106, and receive the PK from the wireless communication device 106_eUICC. At 540, the deployment entity 102 uses eSK_serverAnd PK_eUICCGenerate ShS (that is, based on the symmetric key of the session).

At 542, the wireless communication device 106 has a long-term key (SK_eUICC, PK_eUICC) (For example, the PKI information 321 illustrated in FIG. 3). At 544, the wireless communication device 106 will PK_eUICCProvide to the deployment entity 102, and receive the signed ePK from the deployment entity 102_server(It was generated at 536 as described above). At 546, the wireless communication device 106 uses PK_eUICCAnd signed ePK_serverGenerate a shared secret (ShS).

In summary, the techniques described in this article provide various advantages over conventional methods. Specifically, these technologies enable off-card entities and eUICCs to establish secure communication channels via unprotected connections (such as the Internet), thereby increasing the overall bandwidth available for establishing these connections. Furthermore, during peak management times (for example, in the case of starting a new wireless device), this can be critical. These technologies also allow the participation of certificate authorities to provide an increased level of security when the off-card entity and eUICC authenticate each other (although, as mentioned above, this approach is not required). These technologies also enable the symmetric key based on the working phase to be cached for subsequent use, which can help reduce the additional items involved every time the off-card entity and the eUICC need to communicate with each other securely. These technologies further enable the establishment of full forward security or half forward security, which can be an ideal feature in terms of customer privacy concerns. These technologies also provide the benefit of creating short-term PKI information that is not derived using long-term PKI information, which can increase the difficulty involved in deriving long-term PKI information (even when the short-term PKI information is cracked).

The various aspects, embodiments, implementations or features of the described embodiments can be used individually or in any combination. The various aspects of the described embodiments can be implemented by software, hardware, or a combination of hardware and software. The described embodiments may also be embodied as a computer-readable medium (or several media) storing computer-readable program code, the computer-readable program code including instructions that can be executed by one or more computing devices. The computer-readable medium can be associated with any data storage device that can store data, which can then be read by a computer system. Examples of computer-readable media include read-only memory, random access memory, CD-ROM, HDD, DVD, magnetic tape, and optical data storage devices. Computer-readable media can also be distributed on computer systems coupled to a network, so that computer-readable program codes can be stored and executed in a distributed manner.

In the foregoing detailed description, reference is made to the accompanying drawings, which form a part of the description and in which specific embodiments according to the embodiments are shown by way of illustration. Although these embodiments are described in sufficient detail to enable those skilled in the art to practice the described embodiments, it should be understood that these examples are not limitative; so that other embodiments can be used, and can be used without departing from the The spirit and scope of the described embodiments have been changed. For example, it should be understood that the ordering of the operations described in the flowcharts is non-limiting, so that the ordering of two or more operations described in the flowcharts and described in relation to the flowcharts can be based on some example embodiments And change. As another example, it should be understood that, in some embodiments, one or more operations illustrated in and described with respect to the flowchart may be optional and may be omitted.

In addition, for the purpose of explanation, the foregoing description uses specific terminology to provide a thorough understanding of the embodiments. However, it will be obvious to those skilled in the art that no specific details are required in order to practice the described embodiments. Therefore, the foregoing description of specific embodiments is presented for the purposes of illustration and description. The description of the embodiments presented in the foregoing description and the examples disclosed with respect to these embodiments are provided only to add context and assist the understanding of the embodiments. This description is not intended to be exhaustive or to limit the described embodiments to the precise form disclosed. It will be obvious to those who are familiar with this technique. In view of the above teaching, many Modifications, alternative applications and changes are possible. In this regard, those skilled in the art will easily understand that the embodiments can be practiced without some or all of these specific details. In addition, in some cases, well-known program steps have not been described in detail in order to avoid unnecessarily obscuring the described embodiments.