Method for registering device, embedded universal integrated circuit card and server

Abstract

A method for registering a mobile device including an embedded universal integrated circuit card (eUICC) at a mobile network server is disclosed. The method includes determining subscriber identification information and deriving a first key. Then, a registration request is sent to the mobile network server. And the eUICC signs first random data by using the first secret key and sends the first random data to the mobile network server. The server generates a server authentication key and authenticates the eUICC, and if successful, grants restricted access. The eUICC signs the first or second random data with a second key and sends a registration message comprising the signed first or second random data to the mobile network server, the mobile network server determines validity of the signed first or second random data, and if valid, the mobile network server sends a registration message comprising the signed first or second random data to the eUICC. And if so, granting regular access to the eUICC. Further disclosed herein are an embedded universal integrated circuit card, a mobile network server and a computer program product.

Description

Technical Field

[0001] This disclosure relates to a method for registering a mobile device including an embedded universal integrated circuit card (eUICC) at a mobile network server. The method includes determining subscriber identification information and deriving a first key. A registration request is then sent to the mobile network server. The eUICC signs first random data with the first key and sends it to the mobile network server after being initiated by the mobile device. The server generates a server authentication key and authenticates the eUICC, granting restricted access if successful. The eUICC signs first or second random data with a second key and sends a registration message including the signed first or second random data to the mobile network server, which determines the validity of the signed first or second random data and, if valid, grants regular access to the eUICC. This disclosure also relates to an embedded universal integrated circuit card (eUICC), a mobile network server, and a computer program product.

[0002] Therefore, this disclosure relates to the field of mobile communications, particularly with respect to an embedded subscriber identity module (eSIM) consisting of software mounted on an eUICC chip in a device. Background Technology

[0003] Cards with embedded subscriber identity modules (eSIMs) have been introduced using the GSMA standard. These replace the physical SIM cards that have been in use since 1991. eSIM technology has transformed the classic plastic SIM card into an electronic dataset called a profile. To successfully connect with a mobile network operator (MNO), the profile requires subscriber identification information, such as the International Mobile Subscriber Identity (IMSI).

[0004] Instead of sending physical (i.e., plastic) SIM cards to subscribers, eSIMs allow mobile network operators (MNOs) to easily download this profile and install it into an embedded secure element (e.g., an embedded universal integrated circuit card, eUICC) in the connected device (e.g., a mobile phone, tablet, laptop, or wearable device such as a smartwatch, smart ring or other smart jewelry, fitness tracker, smart glasses, augmented or virtual reality headset, or even speakers and headphones). This makes eSIM-enabled mobile devices available to subscribers (i.e., users) who do not have a profile. Therefore, they require some form of connectivity to obtain the profile from the MNO the user is subscribing to.

[0005] One possible technology for connecting an eUICC embedded mobile device to an MNO and downloading a first user subscription is to connect via an existing fixed network connection (such as a wireless network, i.e., Wi-Fi).

[0006] Another possible technology that enables mobile devices to connect to the MNO and download the profile is to provide the mobile device with a so-called bootstrap provisioning profile. The bootstrap profile is preloaded onto the eUICC by the eUICC manufacturer (EUM) or the original equipment manufacturer (OEM), and then the device is distributed to the end customer by delivering the device directly to the store or subscriber.

[0007] The bootstrap profile provides basic connectivity, allowing subscribers or end users to directly download the profile corresponding to their MNO subscription after device activation, without requiring a different connectivity (e.g., Wi-Fi). However, the bootstrap profile also requires an International Mobile Subscriber Identity (IMSI) for basic connectivity.

[0008] Bootstrap profiles are typically used very infrequently, perhaps once or twice, and only for downloading another profile. However, the IMSI, which acts as the profile identifier, is assigned to the bootstrap profile and needs to be managed in the MNO backend. The corresponding IMSIs are quite wasteful, and millions of subscriptions corresponding to IMSIs remain unused most of the time.

[0009] One way to avoid this is to use the same IMSI on multiple devices by assigning an IMSI range to each device's eUICC, and then, upon activation, the eUICC randomly selects an IMSI from that range. However, by using IMSI ranges, a conflict can occur when two eUICCs simultaneously randomly select the same IMSI. For the MNO backend, the simultaneous use of two identical IMSIs could also indicate the presence of a cloned device. Therefore, the MNO backend will issue an alert in this situation and block IMSIs from the network to prevent unauthorized access by cloned devices. Summary of the Invention

[0010] Improved registration of the mobile device at a mobile network server may be required. A method for registering a mobile device, an embedded universal integrated circuit card, a mobile network server, and a computer program product are provided.

[0011] In this document, the terms "embedded universal integrated circuit card" and "eUICC" may specifically refer to the hardware or software components used to produce the effects described herein. These hardware or software components may be manifested in a particularly independent manner, because the hardware component is formed as a closed component that interacts with other parts of the device, or because the software component can execute independently. However, these hardware or software components may also be manifested in a linked or even combined manner, because the hardware component forms part of another component. In this case, the hardware component may be manifested as a so-called "integrated universal integrated circuit card" or "iUICC". The software component may be manifested as part of a larger program and constitute a module, subroutine, or function of this larger program.

[0012] In this document, the term "mobile network server" can refer to multiple devices. In this context, network server functions can be performed by more than one server device, which can be a combination of physical and virtual servers that may be hosted in the same location or geographically dispersed. For example, there may be a first server, the HLR, which can be responsible for authentication and granting network access. Then, there may also be one or more second servers, the so-called "OTA servers," which communicate with the eUICC when it logs onto the network using a defined protocol (SMS, OTA, HTTP, etc.). OTA stands for Over-the-Air. Authentication based on subscriber identification information (such as a randomly selected IMSI) will be handled by the HLR server, which can also indicate that the device has "restricted access" to the network. A signed random value will be handled by the OTA server, and if the signed value is determined to be valid, the OTA server can indicate that the device has "full access" to the network.

[0013] In this document, the term "key" can refer to a cryptographic key, which can be a symmetric key, meaning that both parties in a communication possess the same identical key, which can be provided from one party to the other through different types of communication. This different type of communication can also be offline, transmitted in physical form, such as on a data storage device like a USB stick, hard drive, SSD drive, or optical disc (such as a CD-ROM). The key can also be part of an asymmetric key, where one party can generate both a private key and a public key. The private key can also be called a secret key. The private key or secret key cannot be shared, while the public key can be freely distributed without additional safeguards. Messages sent to one party can be encrypted with the public key and decrypted using only the private key. On the other hand, messages can be signed with the private key, and this signature can be verified or validated using the public key. The key can also be embodied in a certificate. A certificate contains a public key and may contain additional information such as the issuing organization, purpose, and other types of metadata. The certificate itself can be signed by a Certificate Authority (CA) using the CA's private key. This verifies the authenticity of the certificate. In this sense, in this disclosure, the key can be embodied in a certificate.

[0014] According to one aspect of this disclosure, a method for registering a mobile device including an embedded general-purpose integrated circuit card (eUICC) at a mobile network server is described, the method comprising:

[0015] The subscriber identification information is determined by the eUICC;

[0016] The eUICC derives the first key from the master secret key using a key derivation function and the subscriber identification information;

[0017] The eUICC sends a registration request to the mobile network server, wherein the registration request includes subscriber identification information;

[0018] The eUICC uses the first key to sign the first random data;

[0019] After being initiated by the mobile device, the eUICC sends the first signed random data to the mobile network server;

[0020] The mobile network server generates the server authentication key using an authentication key generation function.

[0021] The eUICC is authenticated by the mobile network server based on subscriber identification information, signed first random data, and server authentication key;

[0022] After successful authentication, the mobile network server grants restricted access to eUICC;

[0023] The eUICC uses a second key stored on the eUICC to sign either the first random data or the second random data;

[0024] The eUICC sends a registration message, including a first or second random data with signature, to the mobile network server;

[0025] The mobile network server determines the validity of the signed first or second random data included in the registration message based at least on a verification key and one of the subscriber identification information and the registration message; and

[0026] After determining that the first or second random data included in the registration message is valid, the mobile network server grants regular access to the eUICC.

[0027] According to another aspect of this disclosure, an embedded general-purpose integrated circuit card eUICC is described, which stores at least:

[0028] The id function is used to determine subscriber identification information;

[0029] Master secret key;

[0030] The second key; and

[0031] Key export function;

[0032] After activation, the eUICC is configured as follows:

[0033] Subscriber identification information is determined by executing the id function;

[0034] The first key is derived from the master secret key using a key derivation function and subscriber identification information;

[0035] Sign the first random data using the first key;

[0036] After being initiated by the mobile device, the first random data with signature is sent to the mobile network server;

[0037] Sign the first random data or the second random data using the second key; and

[0038] Send a registration message to the mobile network server, which includes a first or second random data that has been signed.

[0039] According to another aspect of this disclosure, a mobile network server is described, on which at least:

[0040] Multiple subscriber identification information; and

[0041] Authentication key generation function;

[0042] The mobile network server is configured as follows:

[0043] Receive a registration request for the eUICC of the registered mobile device, wherein the request includes subscriber identification information;

[0044] Receive signed first random data from the eUICC;

[0045] Generate the server authentication key using the authentication key generation function;

[0046] The eUICC is authenticated based on subscriber identification information, signed first random data, and server authentication key;

[0047] After successful authentication, grant restricted access to the eUICC.

[0048] Receive a registration message from the eUICC, which includes either a first random data signature or a second random data signature.

[0049] The validity of the signed first or second random data included in the registration message is determined based on at least one of the subscriber identification information, the registration message, and the verification key; and

[0050] After determining that the first or second random data included in the registration message is valid, normal access is granted to the eUICC.

[0051] In this document, the terms "basic connectivity," "restricted connectivity," or "basic / restricted access" may specifically refer to a connection between a mobile device and a mobile network server that does not allow access to other devices or networks (such as the Internet) outside of the mobile network server. This type of connection can be used by the mobile device for communication only with the mobile network server.

[0052] In this document, the terms “regular access” or “full connectivity” may specifically refer to a type of connection that allows a mobile device to access devices or networks outside of a mobile network server, subject to a corresponding contract or subscription.

[0053] In this document, the term "subscriber identification information" may specifically refer to information that should be unique and usable to identify a subscriber. Many possible implementations exist, such as IMSI (International Mobile Subscriber Identity), ICCID (Integrated Circuit Card Identifier), IMPI (IMS (IP Multimedia Subsystem) Private Subscriber Identity), EUIMID (Extended UIMID (Subscriber Identity Module Identifier)), RUIMID (Removable UIMID), etc. Furthermore, CDMA (Code Division Multiple Access) applications on SIM cards can be used. Therefore, its unique identifier is referred to as IMSI_M (IMSI-Mobile) or MIN (Mobile Identifier) ​​together with ESN (Electronic Serial Number) or MEID (Mobile Equipment Identifier). In the following description of features of this disclosure, if one of the above is used, then each of the above may be used in practice.

[0054] According to an exemplary embodiment, the present invention can be based on the concept that an MNO can request additional registration from an eUICC or at least receive additional registrations to verify authenticity and allow eUICCs that may be clones in some cases. Typically, an MNO does not allow the same subscriber identification information to be registered twice and considers such eUICCs as unwanted clones, even assuming they have been hacked and initiating appropriate countermeasures.

[0055] However, in some scenarios, it may be desirable to use the same subscriber identification information across different devices / eUICCs, for example, for bootstrapping purposes where the subscription is only used for a short period. But without any additional steps, the MNO may not be able to easily detect whether two devices / eUICCs using the same subscriber identification information are desired or undesirable clones.

[0056] This disclosure provides a procedure in which the MNO can request the eUICC to perform a second registration before granting full network access (i.e., regular access) to the device / eUICC. Only after this second layer of security check can the MNO then grant full connectivity to the device / eUICC and thus grant regular access to the subscribed services, i.e., Internet access, voice calls, SMS, etc.

[0057] This mechanism can limit the abuse of other high-attack surfaces on the eUICC due to the master secret being stored in the applet / eUICC and / or due to the necessary key transfer between EUM and MNO.

[0058] The apparatus and methods described in this disclosure can help distinguish unwanted (e.g., hacked) clones from eUICCs that are sharing subscriber identification information (such as IMSI ranges). The disclosed techniques can also support fraud protection mechanisms for clone detection employed by MNOs.

[0059] In summary, this disclosure enables MNOs to effectively prevent the cracking of individual eUICCs and associated public network credentials, which could then be reproduced on a large scale by unauthorized entities. This can be achieved through additional registration, namely, a second-level chip-specific authentication.

[0060] The foregoing limitations and other aspects of this disclosure will become apparent from the examples of embodiments described below, and will be illustrated with reference to these examples of embodiments. This disclosure will be described in more detail below with reference to examples of embodiments, but this disclosure is not limited to these examples of embodiments.

[0061] Exemplary embodiments

[0062] According to an embodiment, the second key can be the eUICC private key of the eUICC key pair. Therefore, the verification key can be the eUICC public key in the eUICC key pair. The eUICC public key is then signed using the eUICC manufacturer's EUM private key, and the registration message includes the eUICC public key. By using this asymmetric cryptography technique, no further prior communication is required besides making the EUM public key generally available to the mobile network server. The EUM public key can be used to verify the signature of the eUICC public key, which in turn can be used to verify the registration message.

[0063] According to an embodiment, the second key is a verification key. Therefore, this key is a symmetric key, which is received by the eUICC manufacturer, EUM, from the mobile network operator, MNO, that operates the mobile network server; alternatively, the key is received by the mobile network operator, MNO, from the eUICC manufacturer, EUM. In either case, regardless of whether EUM or MNO possesses the key first, or even generates the key, the transmission of the symmetric key is performed in advance. Since EUM therefore possesses this key, it can store it on the eUICC. The symmetric key can then also be used to verify registration messages. Thus, the transmission of the symmetric key can be performed securely through a communication path different from that of the device. The communication path used to transmit the symmetric key can also be offline, i.e., the transmission can be in physical form, such as on a data storage device like a USB stick, hard drive, SSD drive, or optical disc (such as a CD-ROM).

[0064] According to an embodiment, the method may further include blocking the mobile device from accessing the mobile network server after the mobile network server determines that the first or second signed random data of the eUICC is invalid. Thus, the mobile network server can increase security by blocking devices that have failed to register successfully.

[0065] According to an embodiment, the method may further include receiving a request to sign random data. The request may be sent from a mobile network server to the eUICC. In response to sending a registration request, a first request to sign the random data may exist. The signature request from the mobile network server may include first random data, which is then signed by the eUICC.

[0066] After successful authentication of the eUICC at the mobile network server, a second request for signing random data may also exist. This second request is also sent from the mobile network server to the eUICC and may include random data to be signed by the eUICC. The second request may (potentially) include the first random data again, or provide new second random data to be signed. It may also include an indication from the authentication step that the first random data will be reused, thus saving bandwidth by eliminating the need to include the first random data again. The first and second signing requests may be particularly useful if the mobile network server determines that the eUICC's subscriber identification information was previously used for mobile device registration. Thus, the mobile network server can improve the overall speed of registration because only those eUICCs determined to use subscriber identification information (such as IMSI) previously used for registration are requested for authentication.

[0067] According to embodiments, communication between the eUICC and the mobile network server can be performed via at least one of an over-the-air server, a toolkit framework, Short Message Service (SMS) messages, USSD (Unstructured Supplemental Service Data), a Hypertext Transfer Protocol (HTTP) pull session, and Signalling System No. 7 (SS7) messages. Since the mobile network server is connected to the mobile device with basic connectivity during registration, any of the communication technologies can be used to transmit the signature request. This communication may include sending a registration message and a request to sign random data, which can be pushed from the mobile network server to the eUICC.

[0068] According to one embodiment, the eUICC is further configured to receive a request from the mobile network server to sign first or second random data. The request may include the random data to be signed. This improves the overall speed of registration because only those eUICCs determined to be authorized to authenticate using subscriber identification information previously used for registration are requested.

[0069] According to one embodiment, the mobile network server may additionally store a key list thereon, wherein each key in the key list is associated with one of the plurality of subscriber identification information, and wherein an authentication key generation function retrieves the server authentication key associated with the subscriber identification information included in the registration request. Therefore, the processing load on the mobile network server can be reduced because the key list has already been generated and securely transmitted to the mobile network server.

[0070] According to an embodiment, the mobile network server may additionally store a master secret key and a key derivation function thereon, wherein the authentication key generation function derives the server authentication key from the master secret key using the key derivation function and subscriber identification information included in the registration request. This reduces the storage space consumed on the mobile network server because, for each eUICC, a key is generated after receiving a registration request including subscriber identification information. Note that the key derivation function is therefore deterministic and is the same as the function used by the eUICC to derive the first key.

[0071] According to an embodiment, the mobile network server is further configured to block access from mobile devices in the event that the signed random data is invalid. Therefore, the mobile network server can ensure that regular access (i.e., subscribed services) is only granted to mobile devices that can successfully register, and the mobile network server can increase security by blocking those devices that fail to register.

[0072] According to one embodiment, the mobile network server is further configured to send a request to the mobile device to sign first or second random data after successful eUICC authentication. This can be in response to a determination that subscriber identification information was previously used for mobile device registration. The request may also include random data to be signed. This can improve the overall speed of registration because only those eUICCs determined to use subscriber identification information (such as IMSI) previously used for registration are requested for authentication.

[0073] According to an embodiment, a computer program product includes instructions that, when executed by a computer, cause the computer to perform the methods described above. Attached Figure Description

[0074] Figure 1 A data flow according to an exemplary embodiment of this disclosure is shown.

[0075] Figure 2 Another data stream is shown according to an exemplary embodiment of this disclosure.

[0076] Figure 3 A flowchart illustrating a method for registering a mobile device according to an exemplary embodiment of the present disclosure is shown. Detailed Implementation

[0077] Figure 1 A data flow according to an exemplary embodiment of this disclosure is shown. The following abbreviations are generally used in this disclosure:

[0078] eUICC refers to an embedded general-purpose integrated circuit card.

[0079] EUM refers to the manufacturer of eUICC.

[0080] OEM stands for Original Equipment Manufacturer, which is the manufacturer of the equipment.

[0081] IMSI stands for International Mobile Subscriber Identity.

[0082] KDF stands for Key Derivation Function.

[0083] MNO stands for Mobile Network Operator.

[0084] HLR stands for Home Location Register. It is used synonymously with MNO in this disclosure.

[0085] SIG stands for signature. SIG(x) specifically refers to signed data, where data x is signed with a secret key.

[0086] SK refers to an entity's secret key, which is typically made unusable by other entities. It is usually used to sign data or generate signed data. It is sometimes called SecKey.

[0087] PK refers to an entity's public key, which is typically made available to other entities. It is sometimes called a PubKey. The entity's public key can be used to test the validity of a signature.

[0088] AUTH stands for authentication, which is the process of proving an entity's identity or authorization.

[0089] SIGN_REQ stands for Signature Request. It provides a hint to sign the data.

[0090] SIGN_RESP refers to the response to a signature request. It provides the signed data.

[0091] OK and NOK respectively refer to confirmation or affirmation (OK) or rejection or denial (NOK).

[0092] Figure 1Exemplary steps that can be used in the disclosed method are shown. The EUM has already stored a second key on the eUICC and generated individual key pairs for each eUICC with an associated certificate. The eUICC keys are signed by the EUM to indicate that the EUM has created them. Specifically, the public key of each eUICC is signed with the EUM's secret key. The eUICC secret key is also stored on the eUICC.

[0093] The EUM generates bootstrap data, which may include subscriber identification information, such as the IMSI. Optionally, multiple IMSIs may be limited to a range or list of IMSIs. Alternatively, other information as described above may be used. The bootstrap data may also include a master key for the key derivation function. To enable the MNO to perform the described verification procedure, the EUM securely shares necessary data with the corresponding MNO, if necessary. This may include a shared symmetric key or a public eUICC or EUM key. Furthermore, sufficient data is provided to the MNO to verify the signature made using a second key, which will be described in detail later.

[0094] EUM stores the corresponding data on each eUICC. This can be done on the eUICC itself, which is then delivered to the OEM for soldering into the device and delivery to an EUM-certified facility. Alternatively, data can be transferred to the eUICCs while they are already in the device. In either case, data transfer typically occurs before the device is delivered to the subscriber (i.e., the end user). Since this applies to more than one eUICC, it can be performed as a loop, such as... Figure 1 As indicated in the document.

[0095] When the device or eUICC is activated, the device performs bootstrap functionality, during which the eUICC determines subscriber identification information. If a range or list of IMSIs is defined, this determination means selecting an IMSI from a predefined set of IMSIs (e.g., a range of IMSIs). This can be performed randomly or based on a function using some semi-random value (such as the current time). In other words, in this example, an International Mobile Subscriber Identity (IMSI) is selected from a predefined set of IMSIs. Alternatively, as described above, other subscriber identification information can be used.

[0096] Furthermore, a key derivation function is executed, thereby generating an individual, unique first key for the device. The KDF uses the master key stored on the eUICC by the EUM and the determined subscriber identification information. In other words, the eUICC first key is derived from the master secret key using a predefined key derivation function and subscriber identification information. The KDF is deterministic, therefore the same key is generated for the same input variables. To verify the signature using the first key, the KDF is either executed a second time by the MNO as an authentication key generation function or by the EUM using the same input variables. In the latter case, the EUM securely transmits the key to the MNO.

[0097] As an example of subscriber identification information, it should be noted that an IMSI can include static and dynamic portions. The static portion can identify the corresponding network operator (via the Mobile Country Code (MCC) and Mobile Network Code (MNC), and is identical for all IMSIs of the MNO within that country. The dynamic portion can be designed in a sequential manner, contributing to the uniqueness of the IMSI. The IMSI available for use by the eUICC can be a selection from a pool of MNO numbers, but can be a range of numbers or a list of non-sequential numbers. An ICCID is also constructed, which includes a primary industry identifier, a country code, an issuer identification number, a personal account identification number, and a checksum portion.

[0098] Then, network authentication is performed based on the server authentication key generated by the mobile network server, along with subscriber identification information and signed first random data. If authentication is successful, the device is granted limited connectivity or basic access, meaning the MNO will not yet grant the device full connectivity or regular access. The device cannot use services such as internet access or voice calls, but is limited to communicating with the MNO network itself. In other words, the eUICC is authenticated at the mobile network server to obtain limited access to the mobile network server.

[0099] In other words, the authentication key is derived using the subscriber identification information (whose intent serves as a unique identifier), and then the authentication key is used to perform network authentication. Therefore, the KDF is stored on the eUICC, and the first key can be derived from the KDF using the master secret key by using the subscriber identification information.

[0100] eUICC can send registration messages to the MNO backend, i.e., the MNO server or mobile network server, without prompting, thus utilizing push technology. Alternatively, the mobile network server can request eUICC to sign random data. eUICC will then respond to this request, signing the random data and returning the signed data.

[0101] The random data to be signed could again be the first random data that may have already been transmitted in the authentication steps, or it could now be the second random data. In other words, the random data is signed with a second key. As detailed above, asymmetric or symmetric principles can be applied to the method. Therefore, the second key could be the eUICC private key in the eUICC key pair, and the verification key could be the eUICC public key in the eUICC key pair, which is signed with the eUICC manufacturer's EUM private key. The asymmetric key (i.e., the eUICC public key) would then be included in the registration message.

[0102] Alternatively, the second key can be the same as the verification key, and therefore a symmetric key. For the symmetric procedure to work, the symmetric key needs to be exchanged between the manufacturer storing the key on the eUICC and the mobile network operator (MNO) operating the mobile network server. In the first variant, the EUM generates the key and transmits it to the MNO. The EUM then stores the key on the eUICC, and the MNO stores the key on the mobile network server. In the second variant, the MNO generates the key and stores it on the mobile network server. The symmetric key is then transmitted from the mobile network server or the MNO to the EUM, which stores the key on the eUICC.

[0103] Both variations of the symmetric key require secure transmission of the key between the MNO and EUM (i.e., via secure communication methods). This means using a transmission path different from that used in other communication steps of the method. As detailed above, the key can be transmitted via other electronic means, but particularly offline transmission is preferred.

[0104] The mobile network operator's mobile network server (sometimes used synonymously) can then determine the validity of the signed random data and thereby determine whether eUICC is correctly requesting registration.

[0105] If the signature is valid, OK, then the MNO grants full connectivity to the device / eUICC. The device is then permitted on the mobile network server. In other words, after the mobile network server determines that the signed random data of the eUICC is valid, the mobile device is granted normal access to the mobile network server.

[0106] If the eUICC cannot prove its validity, i.e., if the signature is invalid (NOK), then the device / eUICC is blocked from entering the network. The mobile network server rejects the device. In other words, after the mobile network server determines that the signed random data of the eUICC is invalid, it blocks the mobile device from accessing the mobile network server.

[0107] The validity of signed random data can be determined at least based on the verification key. It should be noted that the nature of the verification key can depend on the cryptographic technique used, as detailed above. If an asymmetric key is used, the verification key is the eUICC public key of the eUICC key pair, which is signed with the eUICC manufacturer's EUM private key. Therefore, the public key is part of the registration message, making it verifiable by the MNO.

[0108] If a symmetric key is used, the verification key is the key that EUM and MNO exchange as discussed above.

[0109] Note that communication between the MNO and eUICC can be implemented in different variations. An exemplary variation is that the MNO pushes a request to the eUICC. The signature request can be pushed from the mobile network server to the eUICC via an over-the-air server, Short Message Service (SMS) message, Hypertext Transfer Protocol push session, or Signalling System No. 7 (SS7) message. Other transport methods are possible, and requests can be pushed via more than one method simultaneously.

[0110] Another exemplary variant is that the eUICC proactively pushes the required data to the MNO. The registration message can be sent by an over-the-air server, toolkit framework, Short Message Service (SMS) message, USSD as Unstructured Supplemental Service Data, Hypertext Transfer Protocol pull session, or Signalling System No. 7 (SS7) message. Other transport methods are possible, and the registration message can be pushed via more than one method simultaneously. As previously described, instead of incoming random data to be signed (i.e., included in a signature request), the eUICC can use random data from previous communications (e.g., a basic authentication request) to be included in the signature or signed random data.

[0111] Figure 2 Another data flow according to an exemplary embodiment of this disclosure is illustrated, specifically another data flow requesting authentication to the eUICC. In this embodiment, settings on the eUICC may instruct the device to perform an additional request for authentication to the eUICC. This additional request is based on a newly defined terminal capability of the device, which may be referred to as "authentication control." The device may issue a toolkit envelope containing the authentication request. The toolkit envelope may also contain response data. The eUICC may then perform additional security operations, such as creating a signature on the given data and sending it back to the server. The device then sends all eUICC response data back to the HLR or MNO, respectively.

[0112] from Figure 2 As can be seen from this, eUICC preparation and preparatory data exchange correspond to Figure 1The data flow described in the text. This specifically refers to eUICC personalization, i.e., generating individual key pairs and storing them on the eUICC, and the selection of an IMSI by the eUICC from a plurality of pre-defined IMSIs.

[0113] Optionally, such as Figure 2 As shown, the device may first check whether a specific additional authentication flow is required. This specific additional authentication is also known as authentication control. Authentication control can also be viewed as a feature that allows the eUICC and the device to be activated or deactivated. This check may be performed, for example, during the device's activation or boot process.

[0114] The device can read the selected IMSI from the eUICC and initiate the network authentication process by transmitting an authentication request including the IMSI to the MNO. Alternatively, alternative subscriber identification information can be used.

[0115] The MNO / HLR can then send authentication request data back to the device, which is transmitted on the eUICC. The eUICC processes the authentication request and transmits the authentication response to the device.

[0116] If the authorization control requirement is confirmed, i.e., the authentication control is determined to be activated, the device may issue a second request to the eUICC, the second request containing information from the previous request. Figure 1 The authentication data is described in the context of the authentication request or response.

[0117] The eUICC can then apply additional security operations, such as signing the data and sending the signature back to the device along with a public key identifier or certificate. The device can then transmit this authentication, including the authentication response, from the eUICC to the MNO, which can then check not only the standard authentication response but also additional authentication control data (if available).

[0118] Based on the validity of the received eUICC data, the MNO / HLR will then grant or deny access to the device and eUICC.

[0119] In other words, this disclosure provides two levels of authentication, namely, evidence that the device is indeed the device it claims to be (i.e., a correct and valid IMSI on a correct and valid eUICC). Authentication is divided into two steps, or in other words, relies on two cryptographic tokens. Full-service access to the corresponding device (i.e., IMSI or eUICC) is only authorized when both tokens are valid. In this sense, authorization also applies to two steps, each following a corresponding authentication step.

[0120] In summary, there is a first step involving authenticating a unique identifier (such as IMSI, ICCID, IMPI, RUIMID, etc.) via a key derivation function (KDF). If successful, limited authorization is granted, i.e., access only to the internal MNO network. There is also a second step involving authenticating the unique identifier via the described signing process. If successful, full authorization for complete access is granted, including, for example, internet access.

[0121] Figure 3 A flowchart illustrating a method 100 for registering a mobile device according to an exemplary embodiment of the present disclosure is shown.

[0122] Method 100 can be used to register a mobile device, including an embedded general-purpose integrated circuit card (eUICC), at a mobile network server.

[0123] Method 100 begins with eUICC determining subscriber identification information 105. As discussed, subscriber identification information may be IMSI, ICCID, IMPI, EUIMID, RUIMID, etc. Subscriber identification information may be determined by eUICC from a predefined list or range.

[0124] Then, method 100 continues, where the eUICC derives a first key from the master secret key 110 using a key derivation function (KDF) and subscriber identification information. The key derivation function (KDF) and the master secret key are stored on the eUICC. Using the KDF, the device can generate an authentication key for authentication at the mobile network operator.

[0125] Then, method 100 continues, with eUICC sending a 115 registration request to the mobile network server, wherein the registration request includes subscriber identification information.

[0126] In response to the transmission of the registration request 115, the mobile network server may send a request to sign the first random data. Therefore, this request can be received by the eUICC from the mobile network server in step 116. This signing request may include the first random data to be signed by the eUICC. An alternative to receiving the first random data via the signing request in step 116 is that the first random data is predefined and stored on the eUICC.

[0127] Then, method 100 continues, with eUICC signing the first random data 120 using the first key derived in step 110, and eUICC sending the signed first random data to the mobile network server 125 after being initiated by the mobile device.

[0128] In other words, in the network registration process, network authentication is triggered by the mobile device, or more specifically, by the mobile device's data transmission unit (i.e., modem). The eSIM or SIM does not initiate the transmission, but is part of the transmission path as a starting point. Therefore, the registration request is sent by the eUICC, but it is triggered, initiated, or launched by the mobile device, which is also part of the transmission path. The eUICC transmits a signed first random data to the mobile device, which then transmits it to the mobile network server.

[0129] In step 130, the mobile network server generates a server authentication key using an authentication key generation function. The server authentication key can be generated based on the subscriber identification information transmitted in step 115. The generation of the server authentication key in step 130 can be performed at any stage after receiving the registration request in step 115. Figure 3 An option for the timing of generating the server authentication key in step 130 is shown.

[0130] Then, method 100 continues, authenticating the eUICC at the mobile network server based on the subscriber identification information, the signed first random data, and the server authentication key. If the authentication in step 135 is successful, then in step 140, the mobile network grants the eUICC limited access to the mobile network server. As described above, limited access or basic connectivity only allows the device to communicate with the MNO, but does not allow the device to use services beyond those of the server, such as voice calls or internet access.

[0131] Following successful authentication in step 135, the mobile network server can send a request to sign either the first or second random data. This request can then be received by the eUICC from the mobile network server in step 136. This signing request may include the first random data, or it may provide new second random data, or it may provide an indication of which data to use, without sending the actual data to be signed by the eUICC. Like the first random data, the second random data can also be predefined and stored on the eUICC.

[0132] Then, method 100 continues, signing the random data using the second key 145, and sending the signed random data to the mobile network server in the registration message 150. The second key is stored on the eUICC. The random data signed in step 145 can be either the first random data or new second random data.

[0133] Although sending a 150 registration message from eUICC to the mobile network server can be implemented in several variations, in all variations that can use different transmission paths, the registration message is transmitted via the mobile device that provides the transmission capability.

[0134] In some variants, the mobile device does not trigger data exchange; instead, it transparently forwards data from the eUICC to the mobile network server. In other variants, the mobile device supports authentication control capabilities, as described above. Figure 2 As described. In this case, eUICC triggers the transmission of the registration message.

[0135] However, for all variants, the mobile device acts as a transparent carrier, so eUICC sends the registration message.

[0136] Then, method 100 proceeds, whereby the mobile network server determines whether the signed first or second random data included in the registration message 155 is valid. The determination of validity is performed based on a verification key. As stated above, if an asymmetric key is used, the verification key is the eUICC public pair included in the registration message, and if a symmetric key is used, the verification key was previously exchanged between the MNO and EUM.

[0137] After determining in step 155 that the signed first or second random data included in the registration message is valid, method 100 continues, and the mobile network server grants 160 regular access to the eUICC.

[0138] Optionally, after determining in step 155 that the signed first or second random data included in the registration message is invalid, method 100 continues, and the mobile network server blocks 165 eUICC from making regular access.

[0139] Figure Labels

[0140] 100 Method for registering mobile devices including eUICC

[0141] 105 confirms subscriber identification information

[0142] 110 Export First Key

[0143] 115 sends registration request

[0144] 116 receives requests to sign random data.

[0145] 120 Sign the first random data using the first key.

[0146] 125 sends the first signed random data

[0147] 130 generates server authentication key

[0148] 135 certification eUICC

[0149] 136 receives requests to sign random data.

[0150] 140 Granted Restricted Access

[0151] 145. Sign the first or second random data using the second key.

[0152] 150 sent registration message

[0153] 155. Determine the validity of the first or second signed random data.

[0154] 160 granted regular access

[0155] 165 blocked access.

Claims

1. A method (100) for registering a mobile device including an embedded general-purpose integrated circuit card (eUICC) at a mobile network server, characterized in that, The method (100) includes: The subscriber identification information is determined by the eUICC (105); The eUICC derives (110) the first key from the master secret key using a key derivation function and the subscriber identification information; The eUICC sends a (115) registration request to the mobile network server, wherein the registration request includes the subscriber identification information; The eUICC uses the first key to sign the first random data (120); After being initiated by the mobile device, the eUICC sends (125) the first random data with signature to the mobile network server; The mobile network server generates a server authentication key (130) using an authentication key generation function; The eUICC is authenticated by the mobile network server based on the subscriber identification information, the signed first random data, and the server authentication key (135); After successful authentication (135), the mobile network server grants (140) restricted access to the eUICC; The eUICC uses the second key stored on the eUICC to sign the first random data or the second random data (145). The eUICC sends (150) a registration message including a first or second random data with signature to the mobile network server; The mobile network server determines (155) whether the signed first or second random data included in the registration message is valid, at least based on a verification key; and After determining (155) that the signed first or second random data included in the registration message is valid, the mobile network server grants (160) regular access to the eUICC.

2. The method (100) according to claim 1, characterized in that... The second key is the eUICC private key in the eUICC key pair; The verification key is the eUICC public key in the eUICC key pair; The eUICC public key is signed with the eUICC manufacturer's EUM private key; and The registration message also includes the eUICC public key.

3. The method (100) according to claim 1, characterized in that... The second key is the verification key, which is a symmetric key received by the eUICC manufacturer EUM from the mobile network operator MNO, or by the mobile network operator MNO from the eUICC manufacturer EUM via a secure communication method, wherein the mobile network operator operates the mobile network server.

4. The method (100) according to any one of claims 1 to 3, characterized in that, Others include After determining (155) that the signed first or second random data included in the registration message is invalid, the mobile network server blocks (165) the eUICC from accessing the mobile network server.

5. The method (100) according to any one of claims 1 to 4, characterized in that, In addition to at least one of the following In response to the sending (115) of the registration request, the eUICC receives (116) a request to sign the first random data from the mobile network server; After successful authentication (135) at the mobile network server, the eUICC receives (136) a request from the mobile network server to sign the first or second random data.

6. The method (100) according to any one of claims 1 to 5, characterized in that... The communication between the eUICC and the mobile network server is performed via at least one of the following: -Airborne server; - Toolkit framework; -Short Message Service (SMS) messages; - USSD serves as an unstructured supplementary service data; -Hypertext Transfer Protocol (HTTP) session retrieval; -7 signaling system message.

7. An embedded universal integrated circuit card eUICC, characterized in that, It stores at least the following: The id function is used to determine subscriber identification information; Master secret key; Second key; as well as Key export function; After activation, the eUICC is configured as follows: The subscriber identification information is determined by executing the id function. The first key is derived from the master secret key using the key derivation function and the subscriber identification information; Sign the first random data using the first key; After being initiated by the mobile device, the first random data with signature is sent to the mobile network server; Sign the first random data or the second random data using the second key; and Send a registration message, including a first or second random data with signature, to the mobile network server.

8. The eUICC according to claim 7, characterized in that... The second key is the eUICC private key in the eUICC key pair, and the registration message further includes the eUICC public key in the eUICC key pair, wherein the eUICC public key is signed with the eUICC manufacturer's EUM private key; or The second key is a symmetric key, which is received by the eUICC manufacturer EUM from the mobile network operator MNO, or by the mobile network operator MNO from the eUICC manufacturer EUM via a secure communication method, wherein the mobile network operator operates the mobile network server.

9. A mobile network server, characterized in that, It stores at least the following: Multiple subscriber identification information; and Authentication key generation function; The mobile network server is configured to: Receive a registration request for the eUICC of the registered mobile device, wherein the request includes subscriber identification information; Receive signed first random data from the eUICC; The server authentication key is generated using the authentication key generation function. The eUICC is authenticated based on the subscriber identification information, the signed first random data, and the server authentication key. After successful authentication, grant restricted access to the eUICC. Receive a registration message from the eUICC including the signed first random data or the signed second random data; At least based on the verification key, it is determined whether the signed first or second random data included in the registration message is valid; and After determining that the signed first or second random data included in the registration message is valid, normal access is granted to the eUICC.

10. A computer program product, characterized in that, Includes instructions that, when a computer executes a program, cause the computer to perform the method (100) according to any one of claims 1 to 6.

Images