Subscription Confidentiality Identifier

Abstract

To provide a method for facilitating security in communications between user equipment (UE) and a communication network, as well as an authentication server, a de-concealing server, and UE.SOLUTION: In a home network of user equipment, an authentication server function AUSF receives a subscription concealed identifier (SUCI), determines a de-concealing server (e.g. SIDF 6) to use to decrypt the encrypted part of SUCI, sends the SUCI to the de-concealing server, and receives a subscription permanent identifier (SUPI) in response. The SUCI includes an encrypted part in which at least a part of the SUPI is encrypted, and a clear text part, the clear text part includes a home network identifier and an encryption scheme identifier for identifying the encryption scheme used by the UE to encrypt the SUPI in the SUCI.SELECTED DRAWING: Figure 6

Description

[Technical field]

[0001] The present invention relates to an authentication server, a de-concealing server, and a method implemented by a user equipment (UE), respectively. Additionally, a UE, a de-concealing server, an authentication server, a computer program, and memory circuitry are also disclosed. [Background technology]

[0002] It is important to maintain confidentiality of a user equipment's (UE's) long-term subscription identifier (e.g., IMSI (International Mobile Subscription Identity)). Earlier generation 3GPP systems (e.g., 4G / LTE, 3G / UMTS, 2G / GSM) included mechanisms for confidentiality of long-term subscription identifiers using one or more short-term subscription identifiers. GUTI (Globally Unique Temporary Identifier) ​​and C-RNTI (Cell Radio Network Temporary Identifier) ​​are examples of short-term subscription identifiers in 4G / LTE systems. However, legacy mechanisms may expose the long-term subscription identifier in clear text over the air interface. For example, a so-called "IMSI catcher" may just ask the UE for the long-term identifier, for example, using an Identifier Request / Response message.

[0003] The Third Generation Partnership Project (3GPP) is currently discussing how security, including privacy, can be improved in communication networks. With regard to 5G, it is noted that 3GPP TS33.501 V0.2.0 refers to a Subscription Permanent Identifier (SUPI), where the SUPI can be concealed, for example in the form of a pseudonym or a public-key encrypted SUPI. Summary of the Invention

[0004] It is an object of the present invention to facilitate security in communications between a UE and a communications network.

[0005] A first aspect of the present invention relates to a method implemented by an authentication server in a home network of a UE for obtaining a SUPI, the method comprising: receiving a subscription concealed identifier (SUCI), the SUCI comprising: an encrypted portion in which at least a portion of the SUPI is encrypted; a plaintext portion comprising a home network identifier and an encryption method identifier that identifies an encryption method used by the UE to encrypt the SUPI in the SUCI; receiving a subscription ciphering identifier (SUCI); determining a decryption server to use to decrypt the encrypted portion of the SUCI; Sending the SUCI to a deciphering server; Receiving SUPI in response Includes.

[0006] The plaintext portion of the SUCI may comprise a public key identifier for the home network's public key.

[0007] The deciphering server may be one of a plurality of deciphering servers, and determining the deciphering server may be based on information received from the UE. In such a case, the information may be a public key identifier for a public key of the home network. The public key identifier may be included in the plaintext portion of the SUCI.

[0008] The information may be an encryption scheme identifier, and the determined decryption server then supports decryption by the encryption scheme.

[0009] The method, in one embodiment, may further include receiving a SUCI from the UE as part of a registration procedure for registering the UE with the wireless communication network.

[0010] The method, in one embodiment, may further include receiving a SUCI from the UE via an authentication request from a security anchor function.

[0011] The authentication server may be one of a number of deciphering servers.

[0012] The method may further include sending, in the same message, to the determined deciphering server, the SUCI and a request for an authentication vector for authenticating the UE.

[0013] The method may further include receiving, in the same response, the authentication vector and the SUPI from the determined decryption server.

[0014] The SUPI may comprise a Mobile Subscription Identification Number (MSIN), a Mobile Country Code (MCC), and a Mobile Network Code (MNC). The MSIN is encrypted in the encrypted portion of the SUCI in such an embodiment, and the MCC and MNC are home network identifiers in the clear portion of the SUCI. The SUPI may be a network access identifier in an alternative embodiment.

[0015] A second aspect of the invention relates to a method implemented by a deciphering server for providing a SUPI to an authentication server, the method comprising: receiving, from an authentication server, a SUCI comprising an encrypted portion in which at least a portion of the SUCI is encrypted, and a plaintext portion, the plaintext portion comprising a home network identifier and an encryption scheme identifier used by the UE to encrypt the SUPI in the SUCI and identifying an encryption scheme supported by a deciphering server; decrypting the encrypted portion of the SUCI using the encryption scheme indicated by the encryption scheme identifier to obtain a SUPI; Sending the SUPI to the authentication server Includes.

[0016] The plaintext portion of the SUCI may also include a key identifier that is used to identify the decryption key used to decrypt the SUPI. The key identifier may also be used to identify the decryption server.

[0017] The key corresponding to the key identifier may be a public key of the UE's home network.

[0018] In one embodiment of the second aspect, receiving the SUCI includes receiving, in the same message, the SUCI and a request for an authentication vector for authenticating the UE.

[0019] Sending the authentication vector and the SUPI to the authentication server can be done in the same message.

[0020] A third aspect relates to a method implemented by a UE, the method comprising: generating a SUCI, the SUCI comprising an encrypted portion in which at least a portion of the SUPI is encrypted, and a plaintext portion, the plaintext portion comprising a home network identifier and an encryption scheme identifier that identifies an encryption scheme used by the UE to encrypt the SUPI in the SUCI; sending the SUCI to an authentication server for forwarding the SUCI to a decryption server capable of decrypting the SUCI; Includes.

[0021] The SUCI may be transmitted in a request to register with a wireless communication network.

[0022] Generating the SUCI may be performed using a tamper resistant secure hardware component of the UE to generate the SUCI. In such a case, generating the SUCI may include generating the SUCI based on a private key selected from a plurality of private keys stored in the tamper resistant secure hardware component.

[0023] In one embodiment, generating the SUCI includes sending a time to a tamper-resistant secure hardware component for use in generating the SUCI.

[0024] Generating the SUCI, in one embodiment, includes generating the SUCI from a private key that comprises the SUCI.

[0025] Sending the SUCI to the authentication server, in one embodiment, includes sending the SUCI to the authentication server in response to an identifier request message received from an authentication and mobility management function (AMF) as part of a procedure for registering the UE in a wireless communication network. In such an embodiment, the method may further include sending a registration request to the AMF, the registration request comprising the 5G Global Unique Temporary Identifier, and receiving the identifier request message in response.

[0026] The method according to the third aspect may further include, after sending the SUCI, successfully authenticating with the authentication server and receiving a registration acceptance message in response.

[0027] In an embodiment of the first, second and third aspects, the encryption scheme is a null encryption scheme.

[0028] In embodiments of the first, second and third aspects, the encryption scheme may be an Elliptic Curve Integrated Encryption Scheme (ECIES), as an alternative to a null scheme or other encryption scheme, and the plaintext portion of the SUCI may, in such embodiments, comprise the UE's ephemeral public key for use in the ECIES.

[0029] A fourth aspect relates to an authentication server for a home network of a UE to obtain a SUPI. The authentication server comprises a processing circuit and a memory circuit. The memory circuit includes instructions executable by the processing circuit such that the authentication server: receiving a subscription concealment identifier (SUCI), the SUCI comprising an encrypted portion in which at least a portion of the SUPI is encrypted, and a plaintext portion, the plaintext portion comprising a home network identifier and an encryption scheme identifier that identifies an encryption scheme used by the UE to encrypt the SUPI in the SUCI; determining a decryption server to use to decrypt the encrypted portion of the SUCI; Sending the SUCI to a deciphering server; Receiving SUPI in response The method is executable to:

[0030] A fifth aspect relates to an authentication server for a home network of a UE to obtain a SUPI, the authentication server comprising: receiving a SUCI, the SUCI comprising an encrypted portion in which at least a portion of the SUPI is encrypted, and a plaintext portion, the plaintext portion comprising a home network identifier and an encryption scheme identifier that identifies an encryption scheme used by the UE to encrypt the SUPI in the SUCI; determining a decryption server to use to decrypt the encrypted portion of the SUCI; Sending the SUCI to a deciphering server; Receiving SUPI in response The following is set:

[0031] A sixth aspect relates to an authentication server for a home network of a UE to obtain a SUPI, the authentication server comprising: an interface module configured to receive a SUCI, the SUCI comprising an encrypted portion in which at least a portion of the SUPI is encrypted, and a plaintext portion, the plaintext portion comprising a home network identifier and an encryption scheme identifier that identifies an encryption scheme used by the UE to encrypt the SUPI in the SUCI; a decision module configured to determine which decryption server to use to decrypt the encrypted portion of the SUCI; Equipped with The interface module is further configured to send the SUCI to the deciphering server and receive the SUPI in response.

[0032] The present invention also relates to an authentication server according to any one of the fourth to sixth aspects, configured to implement any one of the embodiments of the method according to the first aspect.

[0033] A seventh aspect relates to a deciphering server for providing a SUPI to an authentication server. The deciphering server comprises a processing circuit element and a memory circuit element. The memory circuit element includes instructions executable by the processing circuit element such that the deciphering server: receiving, from an authentication server, a SUCI comprising an encrypted portion in which at least a portion of the SUCI is encrypted, and a plaintext portion, the plaintext portion comprising a home network identifier and an encryption scheme identifier used by the UE to encrypt the SUPI in the SUCI and identifying an encryption scheme supported by the deciphering server; decrypting the encrypted portion of the SUCI using the encryption scheme indicated by the encryption scheme identifier to obtain a SUPI; Sending the SUPI to the authentication server The device is operable to:

[0034] An eighth aspect relates to a deciphering server for providing a SUPI to an authentication server. The deciphering server comprises: receiving, from an authentication server, a SUCI comprising an encrypted portion in which at least a portion of the SUCI is encrypted, and a plaintext portion, the plaintext portion comprising a home network identifier and an encryption scheme identifier used by the UE to encrypt the SUPI in the SUCI and identifying an encryption scheme supported by the deciphering server; decrypting at least a portion of the SUCI using the encryption scheme indicated by the encryption scheme identifier to obtain a SUPI; Sending the SUPI to the authentication server The following is set:

[0035] A ninth aspect relates to a deciphering server for providing a SUPI to an authentication server. The deciphering server comprises: a receiving module configured to receive a SUCI from an authentication server, the SUCI comprising an encrypted portion in which at least a portion of the SUPI is encrypted, and a plaintext portion, the plaintext portion comprising a home network identifier and an encryption scheme identifier used by the UE to encrypt the SUPI in the SUCI and identifying an encryption scheme supported by the deciphering server; a decryption module configured to decrypt at least a portion of the SUCI using the encryption scheme indicated by the encryption scheme identifier to obtain the SUPI; A sending module configured to send the SUPI to the authentication server; Equipped with.

[0036] The invention also relates to a deciphering server of any one of the sixth, eighth and ninth aspects, configured to implement any one of the embodiments of the second aspect.

[0037] A tenth aspect relates to a UE comprising processing circuitry and memory circuitry, the memory circuitry including instructions executable by the processing circuitry such that the UE: generating a SUCI, the SUCI comprising an encrypted portion in which at least a portion of the SUPI is encrypted, and a plaintext portion, the plaintext portion comprising a home network identifier and an encryption scheme identifier that identifies an encryption scheme used by the UE to encrypt the SUPI in the SUCI; sending the SUCI to an authentication server for forwarding the SUCI to a decryption server capable of decrypting the SUCI; The device is operable to:

[0038] An eleventh aspect is generating a SUCI, the SUCI comprising an encrypted portion in which at least a portion of the SUPI is encrypted, and a plaintext portion, the plaintext portion comprising a home network identifier and an encryption scheme identifier that identifies an encryption scheme used by the UE to encrypt the SUPI in the SUCI; sending the SUCI to an authentication server for forwarding the SUCI to a decryption server capable of decrypting the SUCI; This relates to a UE that is configured to perform the above.

[0039] A twelfth aspect is a generating module configured to generate a SUCI, the SUCI comprising an encrypted portion in which at least a portion of the SUPI is encrypted, and a plaintext portion, the plaintext portion comprising a home network identifier and an encryption scheme identifier that identifies an encryption scheme used by the UE to encrypt the SUPI in the SUCI; a sending module configured to send the SUCI to an authentication server for forwarding the SUCI to a decryption server capable of decrypting the SUCI; The present invention relates to a UE comprising:

[0040] The plaintext portion of the SUCI may comprise a public key identifier for the home network's public key according to embodiments of the first, third and twelfth aspects.

[0041] The SUPI may comprise a mobile subscription identification number.

[0042] The SUPI may be a network access identifier.

[0043] The present invention also relates to a user equipment of any one of the tenth, eleventh and twelfth aspects, configured to implement any one of the embodiments of the third aspect.

[0044] A thirteenth aspect relates to a computer program comprising instructions which, when executed on at least one processing circuit element of a server device, cause the at least one processing circuit element to perform a method according to any one of the first to third aspects.

[0045] A fourteenth aspect relates to a memory circuit element containing a computer program. [Brief description of the drawings]

[0046] [Figure 1] 1 illustrates an exemplary wireless communication network. [Diagram 2] A diagram showing an example of a UE encrypting the UE's long-term subscription identifier as part of an attachment procedure. [Diagram 3] FIG. 1 illustrates an example of a subscription concealment identifier (SUCI). [Figure 4] FIG. 2 is a diagram illustrating an example of a private key. [Diagram 5] FIG. 1 illustrates the 3GPP public key privacy scheme. [Figure 6] FIG. 1 illustrates an example of a registration procedure. [Figure 7] A diagram showing an example of a UE's 5G-USIM / UICC generating a SUCI. [Figure 8] A figure showing an example in which the 5G-USIM / UICC does not have a private key. [Figure 9] A diagram showing an example of an ME generating a SUCI. [Figure 10] FIG. 13 shows an example in which the ME is notified about an updated private key. [Figure 11] A diagram showing an example in which the ME detects that the 5G-USIM / UICC has been replaced. [Figure 12] FIG. 13 is a diagram illustrating an example of private key verification data. [Figure 13] A diagram illustrating an example UE registration process in which the UE does not have a valid private key. [Figure 14] A diagram showing an example UE registration process in which the UE's private key needs to be updated. [Figure 15] FIG. 2 illustrates an example of how a private key and private key verification data relate to each other. [Figure 16] FIG. 2 illustrates a hardware embodiment, for example for an authentication server. [Figure 17] FIG. 2 illustrates an embodiment of an authentication server. [Figure 18] FIG. 2 illustrates an embodiment of an authentication server. [Figure 19] FIG. 1 illustrates an embodiment, for example for a deciphering server. [Figure 20] FIG. 2 illustrates an embodiment of a decryption server. [Figure 21] FIG. 1 illustrates an embodiment of a UE. [Figure 22] FIG. 1 illustrates an embodiment of a UE. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0047] 1 illustrates an exemplary wireless communication network 30 including a UE 1, a serving network 2, and a home network 3. Both the UE and the home network are communicatively connected to the serving network and exchange signals with each other via the serving network. The UE is configured with a subscription identifier that identifies a subscription supported by the home network and uses the serving network to access the home network.

[0048] Common examples of UE1 include a mobile equipment (ME), a mobile terminal, a smartphone, a personal computer, a laptop computer, a desktop computer, a workstation, a tablet computer, a wearable computer, and / or a smart appliance. According to a particular embodiment of the UE, the UE may comprise a general-purpose memory storage as part of the ME and a tamper-resistant secure hardware component that provides secure storage, such as a 5G-USIM (Universal Subscriber Identity Module), e.g., a UICC (Universal Integrated Circuit Card) with a 5G-USIM installed thereon, and / or other secure storage device. According to such an embodiment, any of the capabilities described as being in the UE may generally be implemented using the tamper-resistant secure hardware component of the UE.

[0049] The serving network 2 includes one or more physical devices and / or signaling media capable of exchanging communication signals with the UE 1 and the home network 3. In particular, the serving network may include hardware providing one or more access points (e.g., base stations, eNodeBs, femtocells, and / or wireless access points), access networks, authentication servers, access and mobility management functions (AMFs), security anchor functions (SEAFs), authentication server functions (AUSFs), and / or any combination thereof (not shown). In particular, the authentication server may provide one or more AMFs, SEAFs, AUSFs, and / or any combination thereof. Details of these network entities are described in more detail below.

[0050] The home network 3 includes one or more physical devices and / or signaling media capable of exchanging communication signals with the UE 1 via the serving network 2. In particular, the home network may include one or more de-ciphering servers, authentication servers (e.g., as described above), key provisioning servers, Subscription Identifier De-concealing Functions (SIDFs), Private Key Provisioning Functions (PKPFs), Unified Data Management (UDMs), and / or any combination thereof (not shown). In particular, the de-ciphering servers may provide one or more SIDFs, PKPFs, and / or any combination thereof. Details of these network entities are also described in more detail below.

[0051] Examples of serving and / or home networks include (without limitation) one or more of a local area network, a wireless network, a cellular network, an Internet Protocol-based network, an Ethernet network, an optical network, and / or a circuit-switched network. Such networks may comprise any number of networking devices, such as routers, gateways, switches, hubs, firewalls, etc. (not shown) that support the exchange of such communication signals.

[0052] Although Figure 1 shows separate serving and home networks, in some embodiments of the present disclosure, home network 3 may be serving network 2, i.e., the UE may not be roaming. Additionally, although examples of specific functions in either the home network or the serving network are specified above, those specific functions may be in the other of the home network or the serving network according to certain embodiments. Furthermore, although only one UE 1 is shown in Figure 1, the serving and home networks may support multiple UEs according to certain embodiments.

[0053] One exemplary manner for maintaining confidentiality of the UE's long-term subscription identifier is to protect it using a home network public key. The home network public key may be provisioned in the UE 1 without attestation such that a global Public Key Infrastructure (PKI) or Certificate Authority (CA) is not required (i.e., the technique is used asymmetrically between the UE and functions in the home network 3). In such an example, the UE may be expected to encrypt the long-term subscription identifier, which is then sent towards the home network using the home network public key.

[0054] FIG. 2 illustrates one such specific example where the UE encrypts the UE's long-term subscription identifier as part of the attachment procedure. According to the example of FIG. 2, UE1 encrypts the UE1's IMSI, keeps the UE1's MCC (Mobile Country Code) and MNC (Mobile Network Code) parts in plaintext, and sends an attach request to the serving network 2 with the encrypted IMSI as the UE1's identifier (step 1). The serving network identifies the UE's home network 3 using the plaintext MCC / MNC, and requests authentication information from the UE's home network using the encrypted IMSI as the UE's identifier (step 2). The home network decrypts the IMSI from the encrypted IMSI and fetches the corresponding authentication information. In response to the authentication information request, the home network sends the UE's authentication information together with the plaintext IMSI to the serving network (step 3). The serving network conducts an authentication procedure with the UE to authenticate the UE (step 4). If the authentication procedure is successful, the serving network sends an attach accept message to the UE (step 5).

[0055] In such an approach, the home network public key may be pre-provisioned in the USIM and / or provisioned using an over-the-air (OTA) provisioning procedure. While the approach shown in Figure 2 protects long-term subscription identifiers in at least some embodiments, some such embodiments may include one or more deficiencies. For example, the approach shown in Figure 2 may be hindered by legacy USIMs that cannot be successfully modified (e.g., due to technical limitations, lack of storage space, or other limitations), some home operators that may not support OTA provisioning, and / or USIMs that may not be updatable.

[0056] Various embodiments of the present disclosure provide alternatives to at least some aspects of the particular embodiment shown in FIG. 2, which alternatives correspond to the interactions between components in FIG. 3-FIG. 8, i.e., in the document "Deliverable D3.6 5G-PPP Security enablers open specifications (v2.0)". Particular embodiments allow the home network 3's public key to be provisioned (e.g., newly provisioned or refreshed) and stored in the UE 1, such that the UE 1 can encrypt the subscription identifier of the UE 1 with this public key. Moreover, in particular embodiments, the core network (such as the 5GC (5G Core) network) triggers the provisioning of the home network public key via existing traffic procedures specified by 3GPP (e.g., registration / authentication signaling, e.g., non-access stratum messages between the UE and the AMF / SEAF node for registration procedures), without the need to rely on additional infrastructure and out-of-band procedures, such as performing an OTA update procedure.

[0057] Although various embodiments herein describe certain features or actions that are performed by the UE1, such features or actions should not be inferred to be performed by any particular component of the UE unless otherwise specified. For example, such functionality may or may not be performed by the UICC, USIM, embedded UICC, integrated UICC, or other circuitry and / or software of the UE (e.g., baseband circuitry in the ME), depending on the particular embodiment.

[0058] Certain embodiments include a Subscription Persistent Identifier (SUPI). The SUPI is a plaintext globally unique 5G persistent identifier assigned to each subscriber in a 5G system. The SUPI can be IMSI-based or non-IMSI-based. An embodiment including an IMSI-based SUPI may use an IMSI, for example, as described in 3GPP TS23.003 V15.0.0. An embodiment including a non-IMSI-based SUPI may be based on a Network Access Identifier (NAI) with NAI IETF RFC4282-based user identity information, as described in 3GPP TS23.003 V15.0.0. In some embodiments, the SUPI includes the address of the home network (e.g., MCC and MNC in the case of an IMSI-based SUPI). Such an embodiment may enable some roaming scenarios, for example, by providing the serving network 2 with information useful for identifying the UE's home network 3. If the SUPI is an NAI, the SUPI may also include an IMSI, but the SUPI may also be non-IMSI-based.

[0059] Certain embodiments additionally or alternatively include a Subscription Confidentiality Identifier (SUCI), as shown in the example of Figure 3. The SUCI is a protected version of the SUPI. The SUCI includes a plaintext portion and an encrypted portion.

[0060] The plaintext portion includes a home network identifier that identifies the home network of UE1. For example, the SUCI may include the MCC and MNC of the home network. The plaintext portion may also include a public key identifier, an encryption scheme identifier, and / or scheme-related parameters useful for decrypting the encrypted portion of the SUCI with an encryption scheme, such as the UE's ephemeral public key or other parameters for use in the Elliptic Curve Integrated Encryption Scheme (ECIES) or other encryption scheme. The term ephemeral key is known to those skilled in the art and is defined as a key whose use is limited to a short period of time, such as a single telecommunication connection (or session), after which all traces of the key are removed. As described below, the public key identifier is an identifier that may be used within the home network to identify the correct SIDF in a home network that includes multiple SIDFs. ECIES, public key identifiers, and SIDFs are described in more detail below. Those skilled in the art will appreciate that the "plaintext portion" in the context of SUCI means that the information therein is unmasked / unencrypted information.

[0061] When the encrypted portion is included in the SUCI, the SUCI is a protected version of the SUPI. The encrypted portion includes an encrypted subscription identifier, such as a MSIN (Mobile Subscriber Identification Number) or a username. The username is the NAI, e.g., username@mnc <mnc>.mcc <mcc>In the example, all characters before the "@" are encrypted. In the case of a decorated NAI having the form "homerealm!username@otherrealm", only the username portion of the text to the left of the "@" is encrypted since the homerealm may be used as routing information. Thus, decrypting the encrypted portion of the SUCI may be performed to know the corresponding SUPI. ECIES is an example of a public key encryption scheme that may be used to generate a SUCI from a SUPI and / or a SUCI from a SUPI. As described further below, the encrypted portion of the SUCI may use a null encryption scheme, for example, if UE1 has not been provisioned with the public key of the home network.

[0062] The SIDF is a function in the home network responsible for decrypting the SUCI. In particular, in 5G architectures, the SIDF may be co-located in the Unified Data Management (UDM). The SIDF may alternatively be said to be part of or provided by the UDM. Additionally or alternatively, the SIDF may be a separate entity from the UDM and / or co-located with the Authentication Server Function (AUSF).

[0063] 4 illustrates an example of a private key. This particular example of a private key includes a public key of a home network. In some embodiments, the private key also includes one or more public key scheme relationship parameters, a long-term subscription identifier, a subject field indicating the network, domain, or context to which the private key is associated (e.g., the subject can be a home network identifier, such as MCC / MNC), a public key scheme identifier, a public key scheme relationship domain specific value (e.g., for the ECIES scheme, a value for the elliptic curve domain), a public key identifier as described in more detail below, a validity time indicating when the private key is valid (e.g., not valid before the time and / or not valid after the time), a key usage field indicating one or more ways in which the key may be used (e.g., subscription identifier privacy, slice selection privacy, etc.), and / or a digital signature calculated over some or all of the private key.

[0064] In particular, the key usage field may be set to indicate that the key is useful for "subscription privacy" in accordance with an embodiment of the present disclosure. Privacy uses beyond the scope of the present disclosure may additionally or alternatively indicate other uses for the private key. For example, the private key may be used for "Network Slice Selection Assistance Information (NSSAI) Privacy" purposes instead of or in addition to the "subscription privacy" purposes. Indeed, such other purposes may include similar methods, devices, and systems in UE1 and / or in the home network for initial provisioning, refresh, and other features described herein. In some embodiments, one private key may indicate multiple usages, while other embodiments may include a respective private key for each usage, with the key usage field of each private key indicating a single key usage (e.g., one of the private keys may indicate "subscription privacy" and the other private key may indicate "NSSAI privacy"). The key usage field may be formatted as an integer, one or more enumerated values, an alphanumeric string, a bit string, a defined string, and / or an array of any of the formats described above, among others.

[0065] The 3GPP public key privacy scheme (3GPK scheme) is a standardized public key scheme that UE1 may support for interoperability between the UE and, for example, a mobile operator. In the absence of a standardized scheme, the UE vendor would likely need to coordinate with such an operator to implement a privacy mechanism. According to a particular embodiment, the UE should support whatever scheme is permitted and / or standardized so that the home network can freely choose the scheme without creating interoperability difficulties. One such scheme in particular is, for example, ECIES. A particular scheme may be adopted as a standard and given an identifier (also called a "register") for interoperability. For each such scheme, any particular algorithms that need to be supported may also be specified. For example, in the case of ECIES, key agreement (KA), key derivation (KD) function (KDF), symmetric integrity, and symmetric encryption may be specified. One or more parameters related to such a scheme, as well as potential static values ​​of those parameters (in one or more cases), may also be specified. For example, in ECIES, elliptic curve domain parameters (p, a, b, G, n, h) for curves over prime fields and / or elliptic curve domain parameters (m, f(x), a, b, G, n, h) for curves over binary fields may be specified.

[0066] 5 shows an exemplary 3GPK scheme. Each scheme adopted as a standard may be assigned a particular identifier. For example, a null scheme may be assigned a 0, an ECIES may be assigned a 1, and so on. The identifier may be, for example, a 4-bit identifier. Other embodiments may format the scheme identifier in other ways, including, but not limited to, one or more integers, numeric strings, alphanumeric strings, bit strings, and / or other data types.

[0067] According to embodiments herein, the UE registers with the wireless communication network 30 according to a registration procedure, such as the exemplary registration procedure shown in Figure 6. According to the exemplary registration procedure shown in Figure 6, the UE uses the home network's public key to conceal the long-term subscription identifier. One or more particular interfaces shown in Figure 6, such as those designated by N and a subsequent numeric designation (e.g., N1, N12, N13), are in accordance with 3GPP TS 23.501, but the signaling carried over such interfaces as described herein, as well as others of the interfaces themselves (e.g., Nxx), are not known or described in any known technical field.

[0068] According to the example of FIG. 6, UE1 sends a registration request to AMF / SEAF4, including a temporary identifier (e.g., 5G-GUTI) in the registration request (step 1). Failing to recognize 5G-GUTI, AMF / SEAF sends an Identifier Request message to the UE to request an identifier for the UE (step 2). The UE responds to the Identifier Request message with an Identifier Response message comprising a SUCI (step 3). The AMF / SEAF requests authentication of the UE to AUSF5 in the home network 3 and includes the SUCI in the authentication request (step 4). The AUSF uses the information encoded in the SUCI to determine which of multiple SIDFs should be used to decrypt at least a portion of the SUCI (step 5). In particular, the AUSF may use a public key identifier carried in the SUCI (or otherwise present in the authentication request message) to identify the correct SIDF6. In some embodiments, the AUSF may additionally or alternatively use a scheme identifier to identify the correct SIDF. In other words, different SIDFs may handle different encryption schemes (e.g., a first SIDF may handle ECIES and a second SIDF may handle RSA), and the AUSF may choose the appropriate SIDF based on which scheme is identified by the SUCI. Also, in an alternative embodiment, the information used to identify the correct SIDF 6 may be a parameter or ID indicative of the SIDF 6, and which parameter / ID is stored or provisioned into the tamper-resistant secure hardware component 8.

[0069] An embodiment of the present disclosure may include multiple SIDFs to avoid having a single point of failure, for example, in the case of a network with a large number of subscribers. Thus, a distributed SIDF deployment may be advantageous to improve fault tolerance, load balancing, and / or overall capacity of the network. Additionally or alternatively, different SIDF instances may be deployed to handle different sets of home network public keys. Thus, the public key identifier in the SUCI may be used to select the appropriate SIDF instance(s) according to one or more embodiments herein. Alternatively, in certain embodiments where only one SIDF is deployed, the public key identifier may be omitted from the SUCI.

[0070] The AUSF 5 sends the SUCI to the selected SIDF 6 (step 6). If the SIDF is co-located in a UDM 7 (e.g., therefore the Nxx message in step 6 of FIG. 6 is an N13 message), the same message can be used to request an authentication vector or authentication certificate from the UDM. The SIDF decrypts the SUCI to obtain the corresponding SUPI and returns the SUPI to the AUSF (step 7). If the SIDF is co-located in a UDM, the same message can be used to return the authentication vector / certificate to the AUSF.

[0071] The AUSF 5 and UE 1 exchange authentication messages using the authentication vector / certificate received from the UDM 7 (step 8). If the AUSF has not yet received the required authentication vector / certificate from the UDM (e.g., in step 7 described above), the AUSF may request the authentication vector / certificate from the UDM before initiating authentication with the UE (not shown). Alternatively, the AUSF may leave authentication to the SEAF. In such an embodiment, the AUSF may simply forward the SUPI to the SEAF in this step and rely on the SEAF to perform authentication in the next step.

[0072] Continuing with the example where the AUSF 5 successfully authenticates the UE 1, the AUSF returns a SUPI to the AMF / SEAF 4 (step 9). The AMF / SEAF accepts the UE's registration and sends a registration accept message to the UE (step 10).

[0073] As briefly described above, certain features of the UE 1 may be implemented by the UE's tamper-resistant secure hardware component 8. Figure 7 shows a particular example in which a 5G-USIM / UICC 8a of the UE generates a SUCI. This particular example uses the term 5G-USIM / UICC, but this term should not be considered a limitation with respect to any version or vendor of USIM or UICC technology, nor should this term be considered a limitation with respect to any generation of mobile networks, e.g., 2G / 3G / 4G / 5G.

[0074] According to the example of FIG. 7, the ME 9 requests a SUCI (step 1). In some such embodiments, this SUCI request may include a time. In other such embodiments, the request may simply be a read operation from the 5G-USIM / UICC 8a. According to such embodiments where there are multiple home network public keys, the 5G-USIM / UICC selects the correct corresponding private key (e.g., based on the time) and generates a SUCI using the selected private key (step 2). Alternatively, for such embodiments where there is only one private key, the 5G-USIM / UICC simply uses that private key. The 5G-USIM / UICC then returns the SUCI to the ME (step 3).

[0075] Figure 8 shows an example where the 5G-USIM / UICC does not have a private key or does not support this feature.

[0076] According to the example of Figure 8, the ME 9 requests the SUCI with a request (which in some embodiments may include a time) in a similar manner as described above with respect to Figure 7. However, in this example, since the 5G-USIM / UICC 8a supports this feature, the 5G-USIM / UICC 8a does not have the private key or recognize the command (step 2). Therefore, the 5G-USIM / UICC returns an error message (or empty data) to the ME (step 3).

[0077] As an alternative to the example of Figure 8, the ME 9 may learn that the 5G-USIM / UICC 8a does not have or support a private key by other means, according to certain embodiments. For example, the ME may obtain version and / or vendor information of the 5G-USIM / UICC and determine that the private key is not supported or does not exist based on this information. As another example, the ME may determine that the private key is not supported or does not exist in the 5G-USIM / UICC based on some other response message from the 5G-USIM / UICC.

[0078] Figure 9 shows an example in which the ME9 generates the SUCI, but the private key itself is stored in the 5G-USIM / UICC8a.

[0079] According to the example of FIG. 9, the ME 9 does not have a private key and requests a private key from the 5G-USIM / UICC 8a (step 1). In some embodiments, the request includes a time. In other embodiments, the request is a direct read operation from the 5G-USIM / UICC memory. The 5G-USIM / UICC then chooses a private key (e.g., based on the time, if given in the request) (step 2). The 5G-USIM / UICC returns the private key to the ME (step 3). At this point, the ME may, in some (but not necessarily all) embodiments, store the private key and / or the SUPI in the ME's non-volatile memory (step 4). The ME then generates a SUCI based on the SUPI and the private key (step 5).

[0080] Figure 10 shows an example where the ME 9 is notified if the private key has been updated in the 5G-USIM / UICC 8a. In this scenario, the ME has subscribed to private key changes and gets notified when an update is available. This scenario assumes that the ME stores the private key or asks the 5G-USIM / UICC for the private key as needed to get the latest private key.

[0081] According to the example of Fig. 10, the ME 9 sends a request to the 5G-USIM / UICC 8a requesting to subscribe to private key updates (step 1). The request may, in some embodiments, include a SUPI. The 5G-USIM / UICC accepts the subscription and sends an acknowledgment to the ME in response (step 2). When the home network updates the private key(s) or delivers one or more new private keys to the 5G-USIM / UICC (step 3), the 5G-USIM / UICC notifies the ME that one or more new private keys are available (step 4). Although Fig. 10 depicts a notification message including the private key(s), according to other embodiments, the ME may alternatively read the private key from the 5G-USIM / UICC based on the notification. The ME acknowledges the notification (step 5). The ME then stores the new private key(s) in the ME's non-volatile memory (step 6). The ME may replace existing private key data if the MCC / MNC / MSID in the previously stored private key data is identical.

[0082] 11 illustrates an example in which a UE is powered on and the ME 9 detects that the 5G-USIM / UICC 8a has been replaced (e.g., replaced with a different 5G-USIM / UICC or simply removed and reinserted, according to various embodiments). Certain embodiments treat replacement with a different 5G-USIM / UICC the same as removal and reinsertion (e.g., for security reasons), although other embodiments may respond differently based on which of these two scenarios is detected.

[0083] According to the example of Figure 11, UE1 is powered on (step 1). ME9 sends a message to 5G-USIM / UICC8a (step 2), and the 5G-USIM / UICC responds in a manner that is inconsistent with when the UE was previously powered on (step 3). For example, the response message may include a different SUPI than any the ME has seen before.

[0084] The ME 9 determines that the 5G-USIM / UICC 8a has been replaced (step 4). For example, the 5G-USIM / UICC may be different in some respect from the previous time the UE 1 was powered on, indicating that the 5G-USIM / UICC has been replaced with a different one. Alternatively, the ME may detect that the 5G-USIM / UICC has been replaced using a non-volatile memory updated by a mechanical, electrical, or software mechanism, such as, for example, an optical sensor, a switch, a weight sensor, a pressure sensor, and / or electrical circuitry that is triggered when the 5G-USIM / UICC is removed and / or inserted, whether the same 5G-USIM / UICC or a different 5G-USIM / UICC is removed and reinserted.

[0085] The ME 9 removes from non-volatile memory the private key that it previously stored (if there is a private key). Additionally or alternatively, if the ME stored the SUPI of the old 5G-USIM / UICC in its memory along with the private key, the ME may decide to remove the private key from non-volatile memory based on a comparison of the SUPI returned by the new 5G-USIM / UICC 8a with the SUPI stored along with the old private key.

[0086] Certain embodiments described above describe ways in which devices in a wireless communication system may securely exchange subscription identifiers, including the generation and use of certain data structures and corresponding encryption / decryption schemes. In particular, the embodiments described above allow this secure exchange to be performed as part of registering UE 1 with wireless communication network 30. Many such embodiments presume that the UE is provisioned with a valid private key.

[0087] To ensure that UE1 does in fact have a valid private key, further embodiments of the present disclosure describe a manner of provisioning a UE. Particular embodiments related to provisioning may include private key verification data (MAC-P). As shown in the example of FIG. 12, the MAC-P includes a message authentication code (MAC). The MAC is calculated based on the private key and a provisioning key (described in further detail below). For example, the MAC may be calculated over various fields of the private key, including but not limited to the home network public key and its related parameters described above, in combination with the provisioning key.

[0088] The MAC-P may also include a provisioning key identifier (e.g., RAND) and / or an integrity protection algorithm identifier, according to some embodiments. According to some embodiments in which the MAC-P does not include an integrity protection algorithm identifier, the integrity protection algorithm used may be identified separately from the MAC-P, or a predefined key derivation function (KDF), such as, for example, HMAC-SHA-256, may be used. The MAC-P may additionally or alternatively include a counter field that may be used to distinguish the MAC-P from multiple MAC-Ps (e.g., when more than one MAC-P is computed using the same provisioning key). The relationship between the secret key (e.g., shown in FIG. 4) and the MAC-P (e.g., shown in FIG. 12) is further described below with respect to FIG. 15.

[0089] The provisioning key is a secret shared between UE1 and the PKPF10 (see FIG. 13), which is described in more detail below. The provisioning key is UE specific, i.e., the provisioning key is a key that is associated in the home network 3 with the UE and / or the 5G USIM, UICC8a, or any other hardware in the UE / ME on which the SIM / USIM is authorized to be stored. In some embodiments, the provisioning key is a home network master key in 5G or future networks, e.g., K, created when UE1 authenticates with the network, e.g., as created in 5G AKA, EAP-AKA', and EAP-TLS (Extensible Authentication Protocol-Transport Layer Security). AUSF In some such embodiments, the AUSF may include the home network master key. Additionally, when the UE re-authenticates, a new home network master key may be created.

[0090] According to one example, the provisioning key may be created from CK (ciphering key), IK (integrity key) (e.g., by applying a KDF such as HMAC-SHA-256, or other secure one-way hash function such as SHA-256, or concatenation of CK and IK). The provisioning key may be generated from CK' and IK' generated from CK and IK in the EAP-AKA' method as an alternative to direct generation from the master key or CK / IK. In another alternative, the provisioning key may be generated from EMSK (extended master session key) in the case of EAP-TLS specified in RFC5216. Since the same home network master key may be used to derive multiple keys, embodiments of the present disclosure use at least one further standard parameter in combination with the home network master key as input for deriving the provisioning key. For example, when a standard KDF is used, an FC (Function Code) may be used as input (e.g., as specified in TS33.220, such as TS33.220 V15.0.0) to create a provisioning key that is distinguishable from other keys created using the home network master key.

[0091] According to another example, the provisioning key may be the same as the ephemeral shared key shared between SIDF6 and UE1, or a key derived from the ephemeral shared key, especially when the encryption scheme used is a hybrid public key scheme such as ECIES. For example, ECIES uses a public key mechanism (e.g., Diffie-Hellman) for key agreement between SIDF and UE, which results in a shared key that is ephemeral. For security purposes, that ephemeral shared key is generally further processed through a key derivation function (e.g., SHA-256) to derive other derived shared keys between SIDF and UE (e.g., encryption keys and MAC keys in ECIES). One of these other derived shared keys is generally used for encryption and is called an ephemeral encryption key. As applied to the embodiments of the present disclosure, one of these other derived shared keys may be used, for example, to generate a SUCI from a SUPI. Additionally, in some embodiments, another of the derived shared keys (e.g., a MAC key in ECIES), a new key further derived from one of the derived shared keys, or yet another key derived from the ephemeral shared key may be used as the provisioning key. In some embodiments where the SIDF has the provisioning key or is able to obtain / derive the provisioning key, the SIDF may also compute the MAC or MAC-P.

[0092] The PKPF 10 is a function in the home network 3 that is responsible for provisioning the private key. According to certain embodiments, the PKPF may be co-located with the AUSF 5, and in particular in at least some embodiments where the provisioning key is derived from a home network master key that is created based on a primary authentication between the UE and the network. In other embodiments, the PKPF may be co-located with other 5GC entities, such as the UDM 7. According to still other embodiments, the PKPF is its own separate entity. In some embodiments, the SIDF 6 and the PKPF are implemented together as a single function and do not need to transfer the provisioning key. In some other embodiments, the PKPF may obtain the provisioning key from the SIDF. The PKPF may also obtain the MAC / MAC-P from the SIDF.

[0093] 13 illustrates an example UE registration process in which UE1 does not have a valid private key. For example, an end user may insert a new USIM / UICC into the UE, and the new USIM / UICC does not include a private key.

[0094] According to the example shown in FIG. 13, UE1 sends a registration request to AMF / SEAF4 and includes the SUCI in the request (step 1). Since the UE does not have a private key initially in this scenario, the UE uses a null scheme or null encryption method to create the SUCI. The null scheme is implemented such that it returns the same output as the input, and the null scheme is applied to both encryption at the UE and decryption by SIDF6. Furthermore, since the UE does not have a private key (which the home network may choose freely depending on the embodiment), an explicit or implicit indicator that the actual private key is missing from the UE may be used according to a particular embodiment. For example, as described above, the SUCI may use a null encryption scheme for the encryption part, which may implicitly signal that the private key is missing. Alternatively, the “lost private key” indicator may be, for example, a standardized or well-known public key identifier value, a flag and / or a message type indicator (e.g., a registration request of type “privacy provisioning” or “pre-initial registration”).

[0095] Upon receiving the registration request, the AMF / SEAF 4 requests UE authentication from the AUSF 5 / PKPF 10 (step 2). The AUSF sends the SUCI (and a "lost private key" indicator, if one was included in the authentication request) to the SIDF 6 (step 3). According to an embodiment where the SIDF is co-located in the UDM 7 (e.g., the Nxx message is an N13 message), the same message can then be used to request an authentication vector / proof from the UDM.

[0096] SIDF6 sees that the SUCI is in the clear and that UE1 has lost the private key. According to this example, SIDF has a local policy that all SUCI must be protected using ECIES. Therefore, SIDF returns the SUPI to AUSF (step 4) along with a request to provision the UE with an ECIES private key. In some embodiments, the response includes multiple private keys to be provisioned to the UE. According to an embodiment where SIDF is co-located in UDM7, the same message can then be used to return the authentication vector / proof to AUSF5.

[0097] According to an embodiment in which the AUSF 5 has not yet received the authentication vector / certificate from the UDM 7, the AUSF 5 may request said authentication vector / certificate from the UDM before initiating authentication with the UE (not shown). Alternatively, according to an embodiment in which the AUSF has already received the authentication vector / certificate from the UDM, the AUSF and the UE exchange authentication messages using said authentication vector / certificate (step 5). Alternatively, the AUSF may delegate authentication to the AMF / SEAF 4.

[0098] According to this example, the PKPF 10 is co-located with the AUSF 5. Thus, upon successful authentication, the AUSF / PKPF creates a provisioning key that can be used to protect private key provisioning messages to UE 1, i.e., without the need to exchange signaling to transfer the provisioning key. According to other embodiments in which the AUSF and PKPF are not co-located, the AUSF may request that the provisioning key be generated by the PKPF, and the PKPF may transfer the provisioning key to the AUSF in response (not shown).

[0099] The AUSF5 / PKPF10 protects the private key(s) (received from the SIDF6 in step 4) with the provisioning key (step 6) by computing a MAC (e.g., as described above with respect to FIG. 12) and constructing a MAC-P. In some embodiments, the private key may also be encrypted. In some embodiments, the AUSF / PKPF may receive a MAC and / or a MAC-P from the SIDF, as described above, particularly in at least some embodiments where the provisioning key is based on an ephemeral shared key, e.g., in the EICES scheme. In particular, the SIDF may have generated the MAC and / or MAC-P, as described above.

[0100] The AUSF 5 then returns the SUPI, the secret key(s), and the MAC-P to the AMF / SEAF 4 (step 7). In some embodiments, the SUPI, the secret key(s), and / or the MAC-P are sent to the AMF / SEAF in the same registration related message flow to register the UE 1 with the wireless communication network 30. In some embodiments, the SUPI, the secret key(s), and / or the MAC-P are sent to the AMF / SEAF in a separate message flow (not shown).

[0101] According to an embodiment in which AUSF5 delegated authentication of UE1 to AMF / SEAF4, AMF / SEAF may authenticate the UE at this point (not shown). In such an embodiment, AMF / SEAF may have previously received the SUPI, secret key(s) and MAC-P directly from SIDF6, for example in step 4.

[0102] The AMF / SEAF4 accepts UE1's registration and forwards the secret key(s) and MAC-P to the UE, e.g., in a registration accept message (step 8). The UE then attempts to verify the MAC and, if successful, stores the secret key(s). To verify the MAC, the UE creates the same provisioning key that the AUSF5 / PKPF10 created before. In other words, when the UE generates an expected MAC and then compares the expected MAC with the received MAC, the MAC is verified if the expected MAC is found to be the same as the received MAC.

[0103] In some embodiments, UE1 then detaches from the network (step 9) in order to initiate a new registration procedure, e.g., using a provisioned secret key to conceal UE1's subscriber identity, according to one of the embodiments described above. Detaching and re-registering in this manner, for example, may prevent an attacker from linking the SUPI to the UE's temporary identifier.

[0104] UE1 may need to be provisioned with a secret key, in some embodiments, due to expiration or revocation of a secret key previously provisioned to the UE. Figure 14 illustrates an exemplary UE registration process in which the UE's secret key needs to be updated, for example, for some security or operational reasons. Some reasons why a previously provisioned secret key may need to be updated, according to various embodiments, may be that the previously provisioned secret key has reached (or is reaching) its expiration date, security in the wireless communication network 30 has been compromised in some way, and / or the secret key is subject to periodic updates.

[0105] According to the example of Figure 14, UE1 sends a registration request to AMF / SEAF4 (step 1). The registration request includes a SUCI. In this example, since the UE has a private key, the UE uses an encryption scheme or method (e.g., ECIES) to create a SUCI, for example according to one of the embodiments described above.

[0106] The AMF / SEAF 4 requests UE authentication from the AUSF 5 / PKPF 10 (step 2). The AUSF sends a SUCI to the SIDF 6 (step 3). As in the previous example, according to some embodiments where the SIDF is co-located with the UDM 7, the same message can then be used to request an authentication vector / proof from the UDM.

[0107] The SIDF 6 finds out that the SUCI was encrypted with a secret key that needs to be updated. For example, the SIDF may detect that the secret key has expired or is about to expire, or that the secret key is invalid for any other reason, as previously described. The SIDF returns the SUPI to the AUSF 5 (step 4) together with a request to provision the UE with an updated ECIES secret key. According to some embodiments, the response may include several secret keys. Furthermore, according to some embodiments where the SIDF is co-located in the UDM, as previously described, the same message may be used to return the authentication vector / proof to the AUSF.

[0108] The AUSF 5 and UE 1 exchange authentication messages (step 5) using the authentication vector / certificate received from the UDM 7. As described in the previous example, the AUSF may have already received the required authentication vector / certificate from the UDM in step 4 (e.g., in some embodiments where the SIDF 6 is co-located in the UDM), or the AUSF may request such authentication vector / certificate from the UDM before initiating authentication with the UE.

[0109] According to an embodiment in which the PKPF 10 is co-located with the AUSF 5, the AUSF / PKPF may create a provisioning key that is used to protect private key provisioning messages to UE 1 as a result of successful authentication. For example, the authentication procedure may include creating a home network master key that may be used to derive the provisioning key. Alternatively, in an embodiment in which the PKPF and AUSF are not co-located, the AUSF and PKPF may exchange the provisioning key through appropriate messaging (not shown).

[0110] The AUSF5 / PKPF10 protects the private key(s) (received from the SIDF6 in step 4) with the provisioning key (step 6), e.g., by computing a MAC and constructing a MAC-P, e.g., according to the example shown in Figure 14. As described above, in some embodiments, the AUSF / PKPF may receive the MAC and / or MAC-P from the SIDF, as described above, particularly in at least some embodiments where the provisioning key is based on an ephemeral shared key, e.g., in the EICES scheme. In particular, the SIDF may have generated the MAC and / or MAC-P, as described above.

[0111] After successful authentication, the AUSF 5 sends the SUPI, secret key(s) and MAC-P to the AMF / SEAF 4, for example in the same registration relationship message flow (step 7). Other embodiments may use separate message flows for one or more of the SUPI, secret key(s) or MAC-P. Also, as previously described, the AUSF may have delegated the authentication of the UE to the SEAF, in which case the SUPI, secret key(s) and MAC-P may have already been returned to the SEAF in step 4, and the AUSF performs the authentication as previously described.

[0112] The AMF / SEAF4 accepts the registration of UE1 and forwards the secret key(s) and MAC-P to the UE, e.g., in a registration accept message (step 8). The UE creates the same provisioning key from the primary authentication as the AUSF5 / PKPF10 created, and verifies the MAC in the message. If the verification is successful, the UE stores the secret key(s). Also, the old secret key can be removed.

[0113] Also according to one example, AUSF5 generates a MAC and a MAC-P and sends the secret key(s) and the MAC-P to UE1 via UDM7, which forwards the secret key(s) and the MAC-P to AMF, which then forwards the secret key(s) and the MAC-P to UE1. In one such example, the AUSF may be a home public land mobile network AUSF, and the AMF may then be a visited public land mobile network (VPLMN) AMF. In such a case, authentication may be delegated by the AUSF to the VPLMN AMF.

[0114] As previously described, a MAC may be calculated based on the secret key (e.g., as shown in FIG. 4) and the provisioning key to generate MAC-P (e.g., as shown in FIG. 12). In some embodiments where multiple secret keys have been provisioned to UE1, the same MAC may be calculated over all of the secret keys sent in the same message.

[0115] Figure 15 shows an example of how the secret key and MAC-P relate to each other and which parameters are used as input to the MAC calculation (or expected MAC (XMAC) as appropriate). As shown in Figure 15, the provisioning key and the secret key are both used to generate a MAC, which may then be used in combination with another secret key to update the MAC, etc., until all secret keys have been processed. Once all secret keys have been processed, the secret key(s) and MAC may be sent to the UE.

[0116] In view of all of the above, one or more of the devices or functions described above may be implemented using the exemplary hardware shown in FIG. 16. The exemplary hardware includes processing circuitry 11 and communication circuitry 12. The processing circuitry is communicatively coupled to the communication circuitry, for example, via one or more buses. The processing circuitry may comprise one or more microprocessors, microcontrollers, hardware circuits, discrete logic circuits, hardware registers, digital signal processors (DSPs), field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), or combinations thereof. For example, the processing circuitry may be programmable hardware capable of executing software instructions stored in memory circuitry 13, for example, as a machine-readable computer program 133. The memory circuitry of various embodiments may comprise any non-transitory machine-readable medium, whether volatile or non-volatile, known or that may be developed in the art, including, but not limited to, solid-state media (e.g., SRAM, DRAM, DDRAM, ROM, PROM, EPROM, flash memory, solid-state drives, etc.), removable storage devices (e.g., secure digital (SD) cards, miniSD cards, microSD cards, memory sticks, thumb drives, USB flash drives, ROM cartridges, universal media disks), fixed drives (e.g., magnetic hard disk drives), etc., in whole or in any combination. According to a particular embodiment in which hardware is used to implement the UE1, the memory circuitry may comprise a tamper-resistant secure hardware component 8 that provides secure storage, such as a 5G-USIM and / or UICC 8a.

[0117] The communications circuitry 12 may be a controller hub configured to control hardware input and output (I / O) data paths. Such I / O data paths may include data paths for exchanging signals over a wireless communications network 30. For example, the communications circuitry may comprise a transceiver configured to send and receive communication signals within and / or between the UE 1, the serving network 2, and / or the home network 3, e.g., over air, electrical, and / or optical media.

[0118] Communications circuitry 12 may be implemented as a single physical component or as multiple physical components arranged in series or separately, any of which may be communicatively coupled to any other or may communicate with any other via processing circuitry 11. For example, communications circuitry may include transmitter circuitry configured to send out communication signals and receiver circuitry configured to receive communication signals (not shown).

[0119] According to certain embodiments, the hardware illustrated in FIG. 16 may be configured with multiple components. These components may include multiple communicatively coupled hardware units and / or software modules. One or more of the hardware units may be, for example, part of the processing circuitry 11. One or more of the software units may be, for example, stored in the memory circuitry 13 and executed by the processing circuitry. For example, the hardware as illustrated in FIG. 16 may be configured with the exemplary components illustrated in FIG. 17 to be used to implement an authentication server 14 in the home network 3 of the UE 1 (e.g., AMF, SEAF4, AUSF5) and obtain a subscription identifier, such as a SUPI, of the UE. The components in FIG. 17 include a determining unit or module 15 and an interfacing unit or module 16. The determining unit or module is configured to determine which deciphering server 19 to use to decipher the encrypted part of the SUCI and is configured to determine, based on the information received from the UE, which of a plurality of deciphering servers should be used to decipher at least a part of the subscription ciphering identifier (SUCI) in which the subscription identifier is encrypted. The interfacing unit or module is configured to send the SUCI to the determined deciphering server and to receive the subscription identifier, e.g., SUPI, in response. In other words, the interfacing module is also configured to receive the SUCI generated by the UE, the SUCI comprising an encrypted part in which at least a part of the SUPI is encrypted and a plaintext part, the plaintext part comprising a home network identifier and an encryption scheme identifier identifying an encryption scheme used by the UE to encrypt the SUPI in the SUCI.

[0120] Such an authentication server 14 may additionally or alternatively be configured with exemplary components shown in Figure 18 for provisioning UE1. The components in Figure 18 include an obtaining unit or module 17 and a sending unit or module 18. The obtaining unit or module is configured to obtain a message authentication code (MAC) based on a provisioning key specific to UE1 and a secret key of the UE's home network 3. The sending unit or module is configured to send the secret key and the MAC to the UE.

[0121] Such an authentication server 14 may additionally or alternatively be further configured to implement any of the methods described herein with respect to the authentication server, e.g., using any of the authentication server hardware or software components described above. Other hardware consistent with the example shown in FIG. 16 may be used to implement a deciphering server 19 (e.g., SIDF6) for providing the authentication server 14 with the subscription identifier of the UE1, and may be configured with the exemplary components shown in FIG. 19. The components in FIG. 19 include a receiving unit or module 20, a decrypting unit or module 21, and a sending unit or module 22. The receiving unit or module is configured to receive a SUCI from the authentication server, the SUCI comprising an encrypted portion in which at least a portion of the SUCI is encrypted, and a plaintext portion, the plaintext portion comprising a home network identifier and an encryption scheme identifier used by the UE to encrypt the SUPI in the SUCI and identifying an encryption scheme supported by the deciphering server. The deciphering unit or module is configured to decipher at least a portion of the SUCI using an encryption scheme indicated by the encryption scheme identifier to obtain the SUPI. The sending unit or module is configured to send the SUPI to the authentication server.

[0122] Such a deciphering server 19 may additionally or alternatively be configured with exemplary components shown in FIG. 20 for provisioning UE1. The components in FIG. 20 include a generating unit or module 23 and a sending unit or module 24. The generating unit or module is configured to generate a subscription persistent identifier (SUPI) and a secret key for the UE in response to receiving from the authentication server 14 a subscription concealment identifier (SUCI) of the UE indicating that the UE lacks a valid secret key. The sending unit or module is configured to send the SUPI and the secret key to the authentication server. Thus, the term "deciphering server" may also be referred to as a SUCI deciphering server.

[0123] Such a deciphering server 19 may additionally or alternatively be further configured to implement any of the methods described herein with respect to the deciphering server, for example using any of the deciphering server hardware or software components described above. Still other hardware consistent with the example shown in Fig. 16 may be used to implement the UE 1 to securely inform the wireless communication network 30 of the subscription identifier and may be configured with the exemplary components shown in Fig. 21. The components in Fig. 21 include a generating unit or module 25 and a sending unit or module 26. The generating unit or module is configured to generate a SUCI, the SUCI comprising an encrypted portion in which at least a portion of the SUPI is encrypted, and a plaintext portion, the plaintext portion comprising a home network identifier and an encryption scheme identifier that identifies an encryption scheme used by the UE to encrypt the SUPI in the SUCI. The sending unit or module is configured to send the SUCI to the authentication server 14 for forwarding the SUCI to a deciphering server 19 capable of deciphering the SUPI.

[0124] Such a UE 1 may additionally or alternatively be configured with exemplary components shown in Figure 22 to obtain a secret key. The components in Figure 22 include a receiving unit or module 27 and a verifying unit or module 28. The receiving unit or module is configured to receive a secret key and a message authentication code (MAC) from the authentication server 14. The verifying unit or module is configured to verify the integrity of the secret key by generating a provisioning key and using the provisioning key and the secret key to regenerate the MAC received from the authentication server, where the provisioning key is a shared secret between the UE and the authentication server.

[0125] Such a UE1 may additionally or alternatively be further configured to perform any of the methods described herein with respect to the UE, for example using any of the UE hardware or software components described above.

[0126] Various methods and processes described herein may be implemented in ways that vary in some details from the broad description given above. For example, although the steps of various processes or methods described herein may be shown and described as being in a sequence or chronological order, any such process or method steps are not limited to being performed in a particular sequence or order unless otherwise indicated. In fact, the steps in such processes or methods may generally be performed in a variety of different sequences and orders and still fall within the scope of the present disclosure. The embodiments described herein should be considered in all respects as illustrative and not restrictive. In particular, all changes that come within the meaning and range of equivalence of the enumerated embodiments below are intended to be embraced herein.< / mcc> < / mnc>

Claims

1. A method implemented by an authentication server (14) in a home network (3) of a user equipment (UE) (1) for obtaining a network access identifier (NAI), the method comprising: receiving a subscription ciphering identifier (SUCI), the SUCI comprising: an encrypted portion in which at least a portion of the NAI is encrypted; a plaintext portion comprising a home network identifier for the home network (3), a public key identifier for the public key of the home network (3), and an encryption scheme identifier that identifies the encryption scheme used by the UE (1) to encrypt the NAI in the SUCI; receiving a subscription ciphering identifier (SUCI); determining a decryption server (19) to use for decrypting the encrypted portion of the SUCI; Sending the SUCI to the deciphering server (19); receiving the NAI in response; A method comprising:

2. The method of claim 1 , wherein the encryption scheme is a null encryption scheme.

3. The method of claim 1 or 2, further comprising receiving the SUCI from the UE (1) as part of a registration procedure for registering the UE (1) with a wireless communication network (30).

4. The method of claim 1 , further comprising receiving the SUCI from the UE (1) via an authentication request from a Security Anchor Function.

5. The method according to any one of claims 1 to 4, further comprising sending in the same message to the determined deciphering server (19) the SUCI and a request for an authentication vector for authenticating the UE (1).

6. 6. The method of claim 1, wherein the encryption scheme is an Elliptic Curve Integrated Encryption Scheme (ECIES) and the plaintext portion of the SUCI comprises an ephemeral public key of the UE (1) for use in the ECIES.

7. A method implemented by a deciphering server (19) for providing a network access identifier (NAI) to an authentication server (14), the method comprising: receiving a Subscription Concealment Identifier (SUCI) from the authentication server (14), the SUCI comprising an encrypted portion in which at least a portion of the NAI is encrypted, and a plaintext portion, the plaintext portion comprising a home network identifier for a home network (3) of the user equipment (UE) (1), a public key identifier for a public key of the home network (3), and an encryption scheme identifier used by the UE (1) to encrypt the NAI in the SUCI and identifying an encryption scheme supported by the deciphering server (19); decrypting the encrypted portion of the SUCI using the encryption scheme indicated by the encryption scheme identifier to obtain the NAI; Sending said NAI to said authentication server (14); A method comprising:

8. A method implemented by a user equipment (UE) (1), the method comprising: generating a Subscription Unmasking Identifier (SUCI), the SUCI comprising: an encrypted portion, in which at least a portion of a network access identifier (NAI) is encrypted; a plaintext portion comprising a home network identifier for a home network (3) of the UE (1), a public key identifier for the home network (3), and an encryption scheme identifier that identifies an encryption scheme used by the UE (1) to encrypt the NAI in the SUCI; generating a subscription concealment identifier (SUCI), sending said SUCI to an authentication server (14) in said home network for forwarding said SUCI to a deciphering server (19) capable of deciphering said NAI from said SUCI; A method comprising:

9. 9. The method of claim 8, wherein the SUCI is transmitted in a request to register with a wireless communication network (30).

10. The method of claim 8 or 9, wherein generating the SUCI comprises using a tamper-resistant secure hardware component (8) of the UE (1) to generate the SUCI.

11. 11. The method of claim 8, wherein sending the SUCI to the authentication server (14) comprises sending the SUCI to the authentication server (14) in response to an Identifier Request message received from an Authentication and Mobility Management Function (AMF) (4) as part of a procedure for registering the UE (1) in a wireless communication network (30).

12. The method according to any one of claims 8 to 11, wherein the encryption scheme is a null encryption scheme.

13. An authentication server (14) for a home network (3) of a user equipment (UE) (1) for obtaining a network access identifier (NAI), said authentication server (14) comprising: and a processing circuit element (11) and a memory circuit element (13), the memory circuit element (13) containing instructions executable by the processing circuit element (11), whereby the authentication server (14) receiving a subscription ciphering identifier (SUCI), the SUCI comprising: an encrypted portion in which at least a portion of the NAI is encrypted; a plaintext portion comprising a home network identifier for the home network (3), a public key identifier for the home network (3), and an encryption scheme identifier that identifies an encryption scheme used by the UE (1) to encrypt the NAI in the SUCI; and receiving a subscription ciphering identifier (SUCI); determining a decryption server (19) to use for decrypting the encrypted portion of the SUCI; Sending the SUCI to the deciphering server (19); receiving the NAI in response; [0023] An authentication server (14).

14. A deciphering server (19) for providing a network access identifier (NAI) to an authentication server (14), said deciphering server (19) comprising a processing circuit element (11) and a memory circuit element (13), said memory circuit element (13) containing instructions executable by said processing circuit element (11), whereby said deciphering server (19) receiving a Subscription Concealment Identifier (SUCI) from the authentication server (14), the SUCI comprising an encrypted portion in which at least a portion of the NAI is encrypted, and a plaintext portion, the plaintext portion comprising a home network identifier for a home network (3) of the user equipment (UE) (1), a public key identifier for the home network (3), and an encryption scheme identifier used by the UE (1) to encrypt the NAI in the SUCI and identifying an encryption scheme supported by the deciphering server (19); decrypting the encrypted portion of the NAI using the encryption scheme indicated by the encryption scheme identifier to obtain the NAI; Sending said NAI to said authentication server (14); a deciphering server (19) operable to:

15. A user equipment (UE) (1), comprising: generating a Subscription Concealment Identifier (SUCI), the SUCI comprising an encrypted portion in which at least a portion of a Network Access Identifier (NAI) is encrypted, and a plaintext portion, the plaintext portion comprising a home network identifier for a home network (3) of the UE (1) and an encryption scheme identifier identifying an encryption scheme used by the UE (1) to encrypt the NAI in the SUCI; sending said SUCI to an authentication server (14) in said home network for forwarding said SUCI to a deciphering server (19) capable of deciphering said NAI from said SUCI; [0023] User Equipment (UE) (1).

Images