TECHNICAL FIELD

[0001] The disclosed subject matter relates to subscription identification in networks.

BACKGROUND

[0002] When connecting to a Fifth Generation (5G) serving network, a User Equipment (UE) must identify its subscription to the network, in part to enable a Unified Data Management (UDM) in a home network to obtain credentials for authentication. In the UDM, each subscription is associated with a corresponding permanent identifier of type Subscription Permanent Identifier (SUPI). To preserve user privacy, the UE may identify the subscription, not by sending the SUPI to the network, but instead by sending a temporary identifier of a type called a Subscription Concealed Identifier (SUCI). The SUCI identifier is a randomized encryption of the subscription’s SUPI. Because encryption is randomized, each transmitted SUCI is for all practical purposes indistinguishable from any other SUCI in the eyes of an eavesdropper. The SUCI is encrypted with the public key of the home network in which the UDM resides, and the home network can therefore decrypt it to obtain the corresponding SUPI. [0003] Once the UE is identified and authenticated, the UDM passes the associated subscription’s SUPI to the SEAF/AMF in the serving network. The SEAF/AMF is the function in the serving network that controls the security of the UE during its connection. Used this way, the UDM acts as a translation service, translating SUCIs into SUPIs for SEAF/AMF functions. [0004] As long as the UE and the SEAF/AMF maintain the session state, the Security Anchor Function (SEAF) / Access and Mobility Management Function (AMF) will confidentially assign the UE a temporary identifier (GUTI, Globally Unique Temporary UE Identity), which is updated regularly. Messages between the SEAF/AMF and the UE use GUTI to identify the UE until session state is removed.

[0005] Before the UDM passes the SUPI to the SEAF/AMF, the UE is authenticated. However, for the purpose of the disclosed subject matter, we ignore that aspect. Hence, we can view the UDM as a type of identity resolution server despite its other capabilities.

[0006] We say that the UE is “authenticated”. In reality, the process is more complicated because the UE comprises two parts, the Mobile Equipment (ME) and the Universal Subscriber Identity Module (USIM). Both parts play roles in the authentication and in the SUCI computation. The distinction between which part of the UE performs the SUCI computation is irrelevant for purposes of the disclosed subject matter, so the description herein takes the viewpoint that the UE is a compound device performing the operations. Whether these operations, or parts thereof, are performed in the USIM or in the ME may be as described in Third Generation Partnership Project (3GPP) Technical Specification (TS) 33.501 (see, e.g., V17.5.0).

[0007] The nature of SUCI, i.e., a randomized encryption of the subscription’s SUPI, motivates many discussions in different 3GPP feature studies that are to use SUCI as pseudonyms identification of the subscription for various service requests towards the network. That is, such use of SUCI is not limited to UE authentication procedure as part of UE connecting to the 5G Core (5GC) as mentioned in 3GPP TS 33.501.

[0008] In the example of the security procedure for 5G Proximity Services (ProSe) (see, e.g., 3GPP TS 33.503 V0.3.0), a 5G ProSe Remote UE can provide a SUCI as part of 5G ProSe UE- to-Network Relay Communication setup procedure, as shown in step 3 of the Figure (FIG.) 1, which is a reproduction of FIG. 6.3.3.2.2-1 from 3GPP TS 33.503. The 5G ProSe Remote UE's SUCI is further sent to the ProSe Key Management Function (PKMF) of the 5G ProSe Remote UE via to a 5G ProSe UE-to-Network Relay, in steps 4a and 4b. The PKMF of the 5G Prose Remote UE needs to ask the network, i.e. UDM / Subscription Identifier De-concealing Function (SIDE), to de-conceal SUCI and get a SUPI before the PKMF of the 5G Prose Remote UE is able to proceed with the rest of procedures, see FIG. 1. Further description of the procedure of FIG. 1 can be found in Section 6.3.3.2.2 of 3GPP TS 33.503.

SUMMARY

[0009] Systems and methods are disclosed herein for privacy preserving subscription identification that can be used by several different services. In some embodiments, a method performed in a wireless communication device for identification comprises determining a domain of a service access point associated to the domain, obtaining or computing a concealed identifier for the wireless communication device based on at least an identifier associated with the wireless communication device and a domain identifier of the domain, and transmitting a service access message to the service access point, the service access message comprising the concealed identifier. In this manner, service access points are separated into different domains, ensuring that concealed identifiers (e.g., SUCIs) generated for one domain cannot be resolved by service access points from another domain, thus preventing compromised service access points from one domain to use the identity resolution function as a general purpose translation service. [0010] In some embodiments, the concealed identifier enables the service access point to obtain the identifier and associate the identifier with the wireless communication device.

[0011] In some embodiments, obtaining or computing the concealed identifier comprises associating the domain identifier for the domain with the identifier associated with the wireless communication device, computing a cryptographic binding token based on the domain identifier and the identifier associated with the wireless communication device, and encoding the cryptographic binding token into the concealed identifier.

[0012] In some embodiments, the concealed identifier is a type of SUCI computed based on a plaintext block that comprises the domain identifier for the domain.

[0013] In some embodiments, the concealed identifier is a type of SUCI computed based on a MAC computation that covers (e.g., is based on) the domain identity for the domain.

[0014] In some embodiments, the concealed identifier is a type of SUCI computed based on a new key K’ that is derived from a Eph shared key wherein K’ is used to compute a MAC over at least the domain identity for the domain and the MAC is included in the concealed identifier. [0015] In some embodiments, the concealed identifier is a type of SUCI computed based on a new key K’ that is derived from a Eph shared key wherein K’ is used to compute a MAC over at least the domain identity for the domain and the MAC and the domain identity are included in the concealed identifier.

[0016] Corresponding embodiments of a wireless communication device are also disclosed. [0017] Embodiments of a method performed by a service access points are also disclosed. In some embodiments, a method performed by a service access point for wireless communication device identification comprises receiving a first message from a wireless communication device, the first message comprising a concealed identifier of the wireless communication device. The method further comprises transmitting a second message comprising the concealed identifier to an identity resolution function, receiving a third message comprising a deconcealed identifier corresponding to the concealed identifier, associating the deconcealed identifier with the wireless communication device, and providing service to the wireless communication device based on the association of the deconcealed identifier with the wireless communication device.

[0018] In some embodiments, providing the service comprises providing the service under an assumption that the identity resolution server associates the wireless communication device with the deconcealed identifier.

[0019] In some embodiments, the second message comprising the concealed identifier further comprises an identifier for a domain to which the service access point is associated.

[0020] Embodiments of a method performed by an identity resolution function are also disclosed. In some embodiments, a method performed by an identity resolution function comprise receiving a first message from a service access point, the first message comprising a concealed identifier. The method further comprises determining a domain associated with the service access point and verifying that the concealed identifier is computed based on at least the domain associated with the service access point from which the first message is received. The method further comprises, responsive to verifying that the concealed identifier is computed based on at least the domain associated with the service access point from which the first message is received, computing a deconcealed identifier associated to the concealed identifier and transmitting a second message comprising the deconcealed identifier to the service access point.

[0021] Embodiments of a network that that implements a service access point or an identity resolution function are also disclosed herein.

BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain the principles of the disclosure.

[0023] FIG. 1 is a reproduction of FIG. 6.3.3.2.2-1 from 3GPP TS 33.503.

[0024] FIG. 2 illustrates one example of a cellular communications system according to some embodiments of the disclosed subject matter.

[0025] FIGs. 3 and 4 illustrate example embodiments in which the cellular communication system of FIG. 2 is a Fifth Generation (5G) System (5GS).

[0026] FIG. 5 illustrates a system in accordance with some embodiments of the disclosed subject matter.

[0027] FIG. 6 illustrates a signaling flow showing identification of device to IRF as well as to SAP in accordance with some embodiments of the disclosed subject matter. Authentication of the device towards the IRF may be required before the IRF releasing the SUPI’, but that is out of scope of the disclosed subject matter, which focuses on identification.

[0028] FIG. 7 illustrates the legacy computation of SUCI and is a reproduction of a corresponding figure from 3GPP TS 33.501, clause C.3.2.

[0029] FIGs. 8, 9, and 10 are schematic block diagrams of a network node according to some embodiments of the disclosed subject matter.

[0030] FIGs. 11 and 12 are schematic block diagrams of a wireless communication device according to some embodiments of the disclosed subject matter.

DETAIEED DESCRIPTION

[0031] The embodiments set forth below represent information to enable those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. Upon reading the following description in light of the accompanying drawing figures, those skilled in the art will understand the concepts of the disclosure and will recognize applications of these concepts not particularly addressed herein. It should be understood that these concepts and applications fall within the scope of the disclosure.

[0032] Radio Node: As used herein, a “radio node” is either a radio access node or a wireless communication device.

[0033] Radio Access Node: As used herein, a “radio access node” or “radio network node” or “radio access network node” is any node in a Radio Access Network (RAN) of a cellular communications network that operates to wirelessly transmit and/or receive signals. Some examples of a radio access node include, but are not limited to, a base station (e.g., a New Radio (NR) base station (gNB) in a Third Generation Partnership Project (3GPP) Fifth Generation (5G) NR network or an enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), a high-power or macro base station, a low-power base station (e.g., a micro base station, a pico base station, a home eNB, or the like), a relay node, a network node that implements part of the functionality of a base station or a network node that implements a gNB Distributed Unit (gNB-DU)) or a network node that implements part of the functionality of some other type of radio access node.

[0034] Core Network Node: As used herein, a “core network node” is any type of node in a core network or any node that implements a core network function. Some examples of a core network node include, e.g., a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), a Home Subscriber Server (HSS), or the like. Some other examples of a core network node include a node implementing an Access and Mobility Function (AMF), a User Plane Function (UPF), a Session Management Function (SMF), an Authentication Server Function (AUSF), a Network Slice Selection Function (NSSF), a Network Exposure Function (NEF), a Network Function (NF) Repository Function (NRF), a Policy Control Function (PCF), a Unified Data Management (UDM), or the like.

[0035] Communication Device: As used herein, a “communication device” is any type of device that has access to an access network. Some examples of a communication device include, but are not limited to: mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or Personal Computer (PC). The communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless or wireline connection.

[0036] Wireless Communication Device: One type of communication device is a wireless communication device, which may be any type of wireless device that has access to (i.e., is served by) a wireless network (e.g., a cellular network). Some examples of a wireless communication device include, but are not limited to: a User Equipment device (UE) in a 3GPP network, a Machine Type Communication (MTC) device, and an Internet of Things (loT) device. Such wireless communication devices may be, or may be integrated into, a mobile phone, smart phone, sensor device, meter, vehicle, household appliance, medical appliance, media player, camera, or any type of consumer electronic, for instance, but not limited to, a television, radio, lighting arrangement, tablet computer, laptop, or PC. The wireless communication device may be a portable, hand-held, computer-comprised, or vehicle-mounted mobile device, enabled to communicate voice and/or data via a wireless connection.

[0037] Network Node: As used herein, a “network node” is any node that is either part of the RAN or the core network of a cellular communications network/system.

[0038] Note that the description given herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used. However, the concepts disclosed herein are not limited to a 3GPP system. [0039] Note that, in the description herein, reference may be made to the term “cell”; however, particularly with respect to 5G NR concepts, beams may be used instead of cells and, as such, it is important to note that the concepts described herein are equally applicable to both cells and beams.

[0040] There exist certain challenges with existing solutions. In some scenarios, there are UE connections via less trusted service access points. The SEAF/AMF, the security anchor function in the serving network, holds especially sensitive information about subscribers, such as root keys for the connection and the SUPI. Therefore, it is also assumed to have stronger protection against attacks than many other functions, e.g., its implementation is assumed particularly well scrutinized for implementation vulnerabilities.

[0041] The UE can connect to the 5G network via other access points than the regular gNB/SEAF/AMF path, e.g., via self-backhauling relay nodes or via WiFi. While WiFi may be treated as a so-called untrusted access, which is carefully integrated with 5G, other possibilities are being discussed.

[0042] Other than 5G network connectivity, a UE can also access certain specific services that are provided or enabled by AS/AF (Application Server, Application Function). These AS/AF can be deployed either by the Mobile Network Operator (MNO) or a 3 ^rd party service provider. When accessing these services, the identification of UE towards the AS/AF could be yet provided by the 5G network, e.g. based on its subscription identifier SUPI. For example, there may be a 5G ProSe Remote UE utilizing connectivity provided by 5G ProSe UE-to-Network Relay Communication service, via another 5G Prose UE-to-Network Relay. In this example, the 5G ProSe Remote UE needs to identify itself to the network offering the 5G ProSe UE-to- Network Relay Communication service. As mentioned above, the 5G ProSe Remote UE can then use SUCI as its identification.

[0043] There are also situations where the UE identifies itself to application layer services such as Generic Bootstrapping Architecture (GBA) and Internet Protocol (IP) Multimedia Subsystem (IMS). In these situations, the UE does not use the SUPI or the SUCI mechanism but resorts to other service- specific identifiers and privacy enhancing mechanisms.

[0044] For example, the UE identifies itself towards the Boot Strapping Function (BSF) in the GBA by either an IP Multimedia Private Identity (IMPI), which is a long-term identifier from the IMS framework, or a special temporary identifier TMPI. The relation between TMPI and IMPI is managed by the BSF itself without the need for a translation service.

[0045] Each IMS device has a private identifier (IMPI) and a public identifier (IMPU). These are fixed, and there is no privacy enhancement like the SUCI. Every time the UE presents the IMPI, privacy is at risk. However, it is less of an issue for IMS compared to 5G radio access because IMS traffic is encrypted by the radio link-layer protection - something which is not possible when the UE transmits the SUCPSUPI.

[0046] Different subsystems in 3GPP networks use different long-term identifiers. In addition, they use different temporary identifiers and mechanisms to hide these using temporary identifiers. They also provide different degrees of privacy protection.

[0047] A common method for identifying the subscription would harmonize subsystems in 3GPP. Granted, this would take time to accomplish in standardization.

[0048] An important problem with a single solution for all subsystems is that some of them operate in nodes that are located in less trustworthy places and may be implemented in nodes have varying degree of security assurance.

[0049] Systems and methods are disclosed herein that provide a solution(s) to the aforementioned and/or other challenges. Embodiments are disclosed herein that provide a solution for privacy preserving subscription identification that can be used by several different services and not only for the case when a UE connects to the 5G core network via regular radio access as is the case today.

[0050] One exemplary technical benefit is that the same solution can be used for several services, harmonizing the design, and at the same time ensure that if servers in one domain are compromised, they cannot use the UDM as a general SUCI-to-SUPI translator to resolve SUCIs generated for a different domain. The latter is especially useful to avoid that they collect SUCIs transmitted for 5G access and later resolve these with the UDM to track which users where at in a certain location. [0051] In some embodiments, the SUCI is bound to the specific domain in which the UE intends to use it. This binding is integrated in the existing SUCI generation construction. In some embodiments, a new type of SUCI is proposed, so that the regular SUCIs and the new SUCIs can be separated in a backwards compatible way.

[0052] In some embodiments, a UE identifies its subscription towards services it connects to by presenting a new type of SUCI, referred to herein as SUCI’, to a service access point belonging to a domain. Similar to SUCI, SUCI’ is computed from SUPI. SUCI’ is however securely bound to the service domain to which the UE intends to connect. Upon reception of a request to resolve the SUCI’, the UDM verifies that request comes from the domain bound to the SUCI’, and only returns the SUPI if the verification succeeds.

[0053] While not being limited to or by any particular advantage, embodiments of the disclosed subject matter may provide a number of advantages of existing solution(s). Three example advantages that may be provided by embodiments of the disclosed subject matter are as follows:

• Embodiments of the disclosed subject matter separate service access points into different domains, ensuring that SUCIs generated for one domain cannot be resolved by service access points from another domain, thus preventing compromised service access points from one domain to use the identity resolution function as a general purpose SUCI-to- SUPI translation service.

• Embodiments of the disclosed subject matter provide a uniform and privacy preserving method based on the existing SUCI scheme for subscriber identification to essentially any service in 5G and beyond. This harmonizes the identification process, and services such as GBA, IMS, 5G ProSe UE-to-Network Relay Communication can migrate towards the common scheme.

• Embodiments of the disclosed subject matter may allow different domains to obtain different SUPI-like identifiers. This improves user privacy further, especially when the identity resolution function and/or the device have very different levels of trust in different domains.

[0054] FIG. 2 illustrates one example of a cellular communications system 200 in which embodiments of the disclosed subject matter may be implemented. In the embodiments described herein, the cellular communications system 200 is a 5G system (5GS) including a Next Generation RAN (NG-RAN) and a 5G Core (5GC); however, the disclosed subject matter may be extended to other types of wireless communications systems. In this example, the RAN includes base stations 202-1 and 202-2, which in the 5GS include NR base stations (gNBs) and optionally next generation eNBs (ng-eNBs) (e.g., LTE RAN nodes connected to the 5GC), controlling corresponding (macro) cells 204-1 and 204-2. The base stations 202-1 and 202-2 are generally referred to herein collectively as base stations 202 and individually as base station 202. Likewise, the (macro) cells 204-1 and 204-2 are generally referred to herein collectively as (macro) cells 204 and individually as (macro) cell 204. The RAN may also include a number of low power nodes 206-1 through 206-4 controlling corresponding small cells 208-1 through 208- 4. The low power nodes 206-1 through 206-4 can be small base stations (such as pico or femto base stations) or RRHs, or the like. Notably, while not illustrated, one or more of the small cells 208-1 through 208-4 may alternatively be provided by the base stations 202. The low power nodes 206-1 through 206-4 are generally referred to herein collectively as low power nodes 206 and individually as low power node 206. Likewise, the small cells 208-1 through 208-4 are generally referred to herein collectively as small cells 208 and individually as small cell 208. The cellular communications system 200 also includes a core network 210, which in the 5G System (5GS) is referred to as the 5GC. The base stations 202 (and optionally the low power nodes 206) are connected to the core network 210.

[0055] The base stations 202 and the low power nodes 206 provide service to wireless communication devices 212-1 through 212-5 in the corresponding cells 204 and 208. The wireless communication devices 212-1 through 212-5 are generally referred to herein collectively as wireless communication devices 212 and individually as wireless communication device 212. In the following description, the wireless communication devices 212 are oftentimes UEs, but the disclosed subject matter is not limited thereto.

[0056] FIG. 3 illustrates a wireless communication system represented as a 5G network architecture composed of core Network Functions (NFs), where interaction between any two NFs is represented by a point-to-point reference point/interface. FIG. 3 can be viewed as one particular implementation of the system 200 of FIG. 2.

[0057] Seen from the access side the 5G network architecture shown in FIG. 3 comprises a plurality of UEs 212 connected to either a RAN 202 or an Access Network (AN) as well as an AMF 300. Typically, the R(AN) 202 comprises base stations, e.g. such as eNBs or gNBs or similar. Seen from the core network side, the 5GC NFs shown in FIG. 3 include a NSSF 302, an AUSF 304, a UDM 306, the AMF 300, a SMF 308, a PCF 310, and an Application Function (AF) 312.

[0058] Reference point representations of the 5G network architecture are used to develop detailed call flows in the normative standardization. The N 1 reference point is defined to carry signaling between the UE 212 and AMF 300. The reference points for connecting between the AN 202 and AMF 300 and between the AN 202 and UPF 314 are defined as N2 and N3, respectively. There is a reference point, Ni l, between the AMF 300 and SMF 308, which implies that the SMF 308 is at least partly controlled by the AMF 300. N4 is used by the SMF 308 and UPF 314 so that the UPF 314 can be set using the control signal generated by the SMF 308, and the UPF 314 can report its state to the SMF 308. N9 is the reference point for the connection between different UPFs 314, and N14 is the reference point connecting between different AMFs 300, respectively. N15 and N7 are defined since the PCF 310 applies policy to the AMF 300 and SMF 308, respectively. N12 is required for the AMF 300 to perform authentication of the UE 212. N8 and N10 are defined because the subscription data of the UE 212 is required for the AMF 300 and SMF 308.

[0059] The 5GC network aims at separating UP and CP. The UP carries user traffic while the CP carries signaling in the network. In FIG. 3, the UPF 314 is in the UP and all other NFs, i.e., the AMF 300, SMF 308, PCF 310, AF 312, NSSF 302, AUSF 304, and UDM 306, are in the CP. Separating the UP and CP guarantees each plane resource to be scaled independently. It also allows UPFs to be deployed separately from CP functions in a distributed fashion. In this architecture, UPFs may be deployed very close to UEs to shorten the Round Trip Time (RTT) between UEs and data network for some applications requiring low latency.

[0060] The core 5G network architecture is composed of modularized functions. For example, the AMF 300 and SMF 308 are independent functions in the CP. Separated AMF 300 and SMF 308 allow independent evolution and scaling. Other CP functions like the PCF 310 and AUSF 304 can be separated as shown in FIG. 3. Modularized function design enables the 5GC network to support various services flexibly.

[0061] Each NF interacts with another NF directly. It is possible to use intermediate functions to route messages from one NF to another NF. In the CP, a set of interactions between two NFs is defined as service so that its reuse is possible. This service enables support for modularity. The UP supports interactions such as forwarding operations between different UPFs.

[0062] FIG. 4 illustrates a 5G network architecture using service-based interfaces between the NFs in the CP, instead of the point-to-point reference points/interfaces used in the 5G network architecture of FIG. 3. However, the NFs described above with reference to FIG. 3 correspond to the NFs shown in FIG. 4. The service(s) etc. that a NF provides to other authorized NFs can be exposed to the authorized NFs through the service-based interface. In FIG. 4 the service based interfaces are indicated by the letter “N” followed by the name of the NF, e.g. Namf for the service based interface of the AMF 300 and Nsmf for the service based interface of the SMF 308, etc. The NEF 400 and the NRF 402 in FIG. 4 are not shown in FIG. 3 discussed above. However, it should be clarified that all NFs depicted in FIG. 3 can interact with the NEF 400 and the NRF 402 of FIG. 4 as necessary, though not explicitly indicated in FIG. 3.

[0063] Some properties of the NFs shown in FIGs. 3 and 4 may be described in the following manner. The AMF 300 provides UE-based authentication, authorization, mobility management, etc. A UE 212 even using multiple access technologies is basically connected to a single AMF 300 because the AMF 300 is independent of the access technologies. The SMF 308 is responsible for session management and allocates Internet Protocol (IP) addresses to UEs. It also selects and controls the UPF 314 for data transfer. If a UE 212 has multiple sessions, different SMFs 308 may be allocated to each session to manage them individually and possibly provide different functionalities per session. The AF 312 provides information on the packet flow to the PCF 310 responsible for policy control in order to support QoS. Based on the information, the PCF 310 determines policies about mobility and session management to make the AMF 300 and SMF 308 operate properly. The AUSF 304 supports authentication function for UEs or similar and thus stores data for authentication of UEs or similar while the UDM 306 stores subscription data of the UE 212. The Data Network (DN), not part of the 5GC network, provides Internet access or operator services and similar.

[0064] An NF may be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.

[0065] FIG. 5 illustrates a system 500 in accordance with some embodiments of the disclosed subject matter. In this example, the system 500 is or includes a 5GS. As illustrated, the system 500 includes a wireless communication device (WCD) 502 (e.g., a UE), a set of Service Access Points (S APs) 504- 1 though 504-4 (generally referred to herein individually as SAP 504 and collectively as SAPs 504), and an Identity Resolution Function (IRF) 506 (e.g., a UDM). Note that while only a single WCD 502 is shown, the system 500 may include many WCDs 500. Also, while four SAPs 504-1 through 504-4 are illustrated, there may be any number of one or more SAPs 504. Further, in some embodiments, the WCDs 502 are mobile devices (e.g., UEs), and the IRF 506 is a UDM, and the SAPs 504-1 through 504-4 are service access points that provide services in a mobile network.

[0066] The SAPs 504-1 through 504-4 are partitioned into domains 508-1 and 508-2 (generally referred to herein individually as domain 508 and collectively as domains 508). While two domains are shown in this example, there may be any number of two or more domains. Each domain 508 may contain one or more SAPs 504. Different domains 504 may represent different service types, e.g., ProSe, GBA, or IMS. Domains 504 may present different network types, e.g. EPC, 5GC, SNPN, or the like. Domains 504 may also represent geographical areas, Application Server/Function, which services are appropriate for certain UE types or for certain subscriptions, or the like.

[0067] A special service type is network access. While the description provided herein is provided in the 5G network setting, it should be clear that any network access setting is equally suitable.

[0068] As described above, the SUCI mechanism enhances user privacy when their devices connect to the 5G radio access service. In FIG. 5, this legacy functionality is represented by the legacy UDM functionality 510.

[0069] FIG. 5 also shows that IRF 506 includes new proposed functionality for a domain separated SUCI mechanism, which is referred to in the example of FIG. 5 as enhanced domain aware UDM functionality 512. The new type of SUCI disclosed herein is distinguished herein from the legacy SUCI by naming it SUCI’; however, SUCI’ is only one example name and should be understood as encompassing this new disclosed identity regardless of its name. While the IRF 506 is, in some embodiments, collocated with the UDM, it is to be understood that the IRF 506 may be located elsewhere (e.g., in a new NF or incorporated into another existing NF), possibly using the UDM as a backend. When the UDM acts as a backend for the IRF 506, the IRF 506 behaves as a proxy-translator for SUCI’-to-SUPI, and the UDM can reject direct requests from the SAPs 504.

[0070] Because a legacy UDM is not necessarily aware of the SUCI’ domain separation, a new separate SUCI’ type is introduced herein. This type allows legacy UDMs to reject resolution requests for SUCI’, since it would be of an unrecognizable format and type. It also allows the legacy UDM, or a filtering function added in front of it, to reject requests not coming from authorized SEAF/AMF or SAP functions. Authorization and authentication of SEAF/AMF and SAP functions can be based on the existing Service Based Architecture (SB A).

[0071] In some embodiments, the SBA is extended to provide this functionality. SBA transactions are protected by the TLS protocol using certificate-based authentication. Applying best current practices, this solves the issue of identifying and authenticating the requesting function. For authorization, the filtering function logically groups SEAF/AMF and SAPs 504 into domains 508. This grouping can for example be pre-configured or obtained from an external policy node. Because each request can be tied to the identity of the requestor (via the identification and authentication provided by TLS), the filtering function can verify whether the requestor is part of the domain 508 that the SUCI’ belongs to, or in case the request includes a legacy SUCI, whether the requestor is of type AMF/SEAF. The filtering function may further verify whether an AMF/SEAF is allowed to resolve a SUCI at all. The filtering function may either reject requests, or forward information about the verification result to the UDM. The filtering function may also be part of the IRF 506 or updated UDM. Again, the IRF 506 may be part of the UDM.

[0072] Threats and Risks. Protecting the SUPI is important for privacy. This is the reason for sending a SUCI in its place at registration for network access in 5G. In today’s systems, it is only the SEAF/AMF that can resolve the SUCI into a SUPI by performing a UE authentication procedure via AUSF/UDM. By adding a new uniform and generic resolution capability to other SAPs, the risk that a malicious actor obtains a SUCI sent over the air and resolves it via the UDM increases.

[0073] SAPs may be maliciously implemented, act out of ignorance or convenience, or have exploitable flaws that make them vulnerable to become tools for SUCI-to-SUPI resolution. Not all SAPs may follow equally strong security assurance requirements as SEAF/AMF and could therefore be more susceptible to exploit.

[0074] A UDM resolving any request as if it came from a trustworthy SEAF/AMF would be vulnerable to attacks from possibly misbehaving SAPs.

[0075] The WCD 502 must be aware of which domain 508 it intends to connect to and ensure that it binds the SUCI’ to that domain 508. Failing to do so risks producing a SUCI’ that can be misused by a compromised SAP 504 of a different domain.

[0076] Adversary Model. Insider threats. The IRF 506 is assumed to not intentionally disclose the SUPI to unauthorized parties. The SAPs 504 are assumed to not attack other SAPs in the same domain 508, e.g., by impersonating them towards the IRF 506. However, SAPs 504 of one domain 508 may attempt to impersonate service nodes of other domains.

[0077] As a side note, in one alternative embodiment, the mechanism can prevent attacks from SAPs against other SAPs in the same domain by also binding the SUCI’ to an SAP identifier of the associated SAP 504. Such an identifier may be available to the WCD 502 and the IRF 506 for some services but cannot be expected to the present for all services. The binding of the SAP identifier could be performed in the same way as binding to the domain, which is described in more detail below. The IRF 506, if the binding of the SAP identifier does not match the identity that the IRF 506 associates with the SAP 504 (e.g., based on the SBA security, or TLS certificates), the IRF 506 rejects the request. The identifier that is bound in the SUCI’ may not be identical to the identifier the IRF 506 uses for the SAP, but both identifiers point to the same entity.

[0078] Outsider threats. Adversaries are assumed to have access to the SUCI-to-SUPI resolution interface of the IRF 506; they are assumed to have access to the response interface of the SAPs 504, and to the device-facing interface of the SAPs 504. Adversaries are further assumed to have access to the radio interface of the WCD 502.

[0079] Signaling. For legacy use of SUCI, i.e., when registering for 5G radio access, the device uses a SUCI as today. Since this is well known, it is not described further. FIG. 6 shows the signaling flow for device identification to IRF 506 and SAP 504 in accordance with one example embodiment of the disclosed subject matter. For this example, the SAP is SAP 504-3 in domain 508-2.

[0080] As illustrated, the WCD 502 determines a domain identity for the domain 508-2 of the SAP 504-3 (step 600). The WCD 502 may determine the domain identity in any desired manner. While details regarding some example embodiments are described below, as one example, the WCD 502 determines the domain identity of the SAP 504-3 by receiving the domain identity or information indicative of the domain identity from the SAP 504-3 (e.g., via a broadcast notification). The WCD 502 obtains or computes a SUCI’ that is bound to the domain 508-2 (e.g., obtains or computes the SUCI’ based on the domain identity determined in step 600) (step 602). In should be noted that, in some embodiments, the WCD 502 is a UE, which includes a ME and USIM. In step 602, the ME may compute the SUCI’ directly or obtain the SUCI’ by calling a function of the USIM, where the USIM computes the SUCI’ and returns the SUCI’ to the ME. Both of these variations fall within the scope of step 602. Details regarding various embodiments for how the SUCI’ is computed and bound to the domain 508-2 are described below. The WCD 502 sends the SUCI’ to the SAP 504-3 (step 604), and the SAP 504-3 sends a request including the SUCI’ to the IRF 506 (step 606). The IRF 506 determines the domain 508-2 associated with the SAP 504-3 and verifies the SUCI’ (step 608). More specifically, the IRF 506 determines whether the SUCI’ is received from an SAP that is in the domain 508-2 to which the SUCI’ is bound. If so, the SUCI’ is verified; otherwise, the request is rejected. Assuming that the SUCI’ is verified, the IRF 506 computes a respective SUPI (or SUPF as described below) based on the SUCI’ (step 610) and returns the SUPI to the SAP 504- 3 (step 612). The SAP 504-3 may then use the SUPI or SUPI’ to perform one or more operational tasks associated to the operation of the SAP 504-3. For example, the SAP 504-3 may associate the SUPI or SUPI’ with the WCD 502 (step 614) and provide service to the WCD 502 based on the association of the SUPI or SUPI’ with the WCD 502 (e.g., under the assumption that the IRF 506 associates the WCD 502 with the SUPI or SUPI’) (step 616).

[0081] In some embodiments, the WCD 502 binds the domain 508-2, to which the SAP 504-3 belongs, to the SUCI’ by a cryptographic computation. The computation is such that the IRF 506 can verify that the WCD 502 generated the SUCI’ for the specific domain 508-2 and that the SAP 504-3 from which IRF 506 received the resolution request in step 606 are a match. Here, the word “match” is used because it may be the case that the WCD 502 refers to the domain 508-2 by one identifier and the IRF 506 refers to the domain 508-2 by another identifier. What matters is that the IRF 506 can deduce that the intended domain is the same. For example, one SAP may announce a service as “Vegan restaurants in this area, brought to you by BrandName A”, and the WCD 502 binds the SUCI’ to this identifier. Another SAP announces a service “Notifications when celebrities posts on social media about this location, brought to you by BrandName B”, and the WCD 502 binds the SUCI’ to that identifier. However, the IRF 506 may know that both these brands and their services are instances of a single mobile operator’ s services, all operated from the same server farm. The IRF 506 knows this domain as “Operator C’s sever farm”. In this case the SUCI’ can be considered bound to the same domain even though different identifiers were used by the WCD 502 when computing the SUCI’ and the IRF 506 when verifying it.

[0082] From hereon, the domain identifier used by the WCD 502 is referenced by the letter D. [0083] SUCI’ computation and verification. The SUCI’ computation can be based on the existing legacy SUCI computation shown in FIG. 7, which is reproduced from 3GPP TS 33.501, Clause C.3.2. As discussed above, the computation can be done in the WCD 502 and the verification in the IRF 506.

[0084] In some embodiments, binding the domain identifier to the SUCI’ requires a key. This key is preferably obtained from the generation procedure for the SUCI used in legacy 5G. The embodiments are described in reference to FIG. 7.

[0085] In a first embodiment, D is part of the plaintext block of the SUCI computation, and the binding derives from that Message Authentication Code (MAC) function. The verification comprises checking the MAC and that D in the plaintext block corresponds to the domain identifier for the SAP from which the request was received.

[0086] In a second embodiment, D is covered by the MAC computation, but not included in the plaintext block. The verification comprises computing the MAC using the domain identifier for the SAP from which the request was received.

[0087] In a third embodiment, a new key K’ is derived from the Eph shared key in FIG. 7. K’ is used to compute a MAC over at least D and include this in the Final output in FIG. 7. The verification comprises deriving the key K’ in the same way, computing the MAC locally in the same way except that the domain of the SAP sending the resolution request is used, match that the received MAC matches the locally computed MAC.

[0088] A fourth embodiment is equal to the third embodiment except that the WCD 502 also includes D in the Final output, and the verification process uses that D during its local computation of the MAC. The verification process also verifies that the domain of the SAP sending the request matches D.

[0089] SUPI’ computation. So far, only the SUPI has been discussed as a long-term identifier.

It may, for privacy reasons, be preferable that different service domains learn different identifiers for the WCD 502. For example, while some services may require the SUPI for lawful intercept reasons, some services may be operated in unregulated business environments, and it may be better to provide them with an identifier they cannot connect to the SUPI itself. Thus, in some embodiments, different identifiers for the WCD 502 are used for different domains 508. [0090] Taking this idea one step further, in some embodiments, different SAPs 504 within the same domain 508 may be provided with different identifiers for the WCD 502. In yet another embodiment, different identifiers for the WCD 502 may be provided to the same SAP 504 at different times or procedure runs.

[0091] To allow this flexibility, the IRF 506 computes an identifier SUPI’ in step 610, which it returns to the SAP 504 in step 612. This allows the function computed to be the identify function, in which case the SUPI’ not only is identical to the SUPI, but it is the SUPI. The identify function is introduced here just to get a uniform presentation, an IRF computing the identity function could be implemented by doing no computation and just return the SUPI as is. [0092] Examples of computing SUPI’ (in step 610) are:

• SUPI itself as discussed above;

• encrypt the SUPI under some key o The key may be global and would then allow the IRF to deanonymize the SUPI’ at a later stage if needed, e.g., for lawful intercept reasons.

• generating a random value; if the value space is large enough, e.g., 256 bits, and the generation is a pseudorandom generator (PRNG) or a pseudorandom function (PRF) or a key derivation function (KDF) or a hash function, then collisions are unlikely enough to avoid problems; the IRF may keep a table mapping the random value to the SUPI; the IRF may generate the value using the SUPI as a seed to the PRNG or input to the PRF, KDF or hash function;

• GPSI

• Etc.

[0093] FIG. 8 is a schematic block diagram of a network node 800 according to some embodiments of the disclosed subject matter. Optional features are represented by dashed boxes. The network node 800 may be, for example, a network node that implements all or part of the functionality of the SAP 504 or IRF 506 or UDM described herein. As illustrated, the network node 800 includes one or more processors 804 (e.g., Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), and/or the like), memory 806, and a network interface 808. The one or more processors 804 are also referred to herein as processing circuitry. The one or more processors 804 operate to provide one or more functions of the network node 800 as described herein (e.g., one or more functions of the SAP 504 or IRF 506 or UDM described herein). In some embodiments, the function(s) are implemented in software that is stored, e.g., in the memory 806 and executed by the one or more processors 804.

[0094] FIG. 9 is a schematic block diagram that illustrates a virtualized embodiment of the network node 800 according to some embodiments of the disclosed subject matter. Again, optional features are represented by dashed boxes. As used herein, a “virtualized” network node is an implementation of the network node 800 in which at least a portion of the functionality of the network node 800 is implemented as a virtual component(s) (e.g., via a virtual machine(s) executing on a physical processing node(s) in a network(s)). As illustrated, in this example, the network node 800 includes one or more processing nodes 900 coupled to or included as part of a network(s) 902. Each processing node 900 includes one or more processors 904 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 906, and a network interface 908. In this example, functions 910 of the network node 800 described herein (e.g., one or more functions of the AMF 300, the SMF 308, or the NSACF 404 described herein) are implemented at the one or more processing nodes 900 or distributed across the two or more processing nodes 900 in any desired manner. In some particular embodiments, some or all of the functions 910 of the network node 800 described herein are implemented as virtual components executed by one or more virtual machines implemented in a virtual environment(s) hosted by the processing node(s) 900.

[0095] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the network node 800 or a node (e.g., a processing node 900) implementing one or more of the functions 910 of the network node 800 in a virtual environment according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non- transitory computer readable medium such as memory).

[0096] FIG. 10 is a schematic block diagram of the network node 800 according to some other embodiments of the disclosed subject matter. The network node 800 includes one or more modules 1000, each of which is implemented in software. The module(s) 1000 provide the functionality of the network node 800 described herein. This discussion is equally applicable to the processing node 900 of FIG. 9 where the modules 1000 may be implemented at one of the processing nodes 900 or distributed across multiple processing nodes 900.

[0097] FIG. 11 is a schematic block diagram of a wireless communication device 1100 (e.g., the WCD 502) according to some embodiments of the disclosed subject matter. As illustrated, the wireless communication device 1100 includes one or more processors 1102 (e.g., CPUs, ASICs, FPGAs, and/or the like), memory 1104, and one or more transceivers 1106 each including one or more transmitters 1108 and one or more receivers 1110 coupled to one or more antennas 1112. The transceiver(s) 1106 includes radio-front end circuitry connected to the antenna(s) 1112 that is configured to condition signals communicated between the antenna(s) 1112 and the processor(s) 1102, as will be appreciated by on of ordinary skill in the art. The processors 1102 are also referred to herein as processing circuitry. The transceivers 1106 are also referred to herein as radio circuitry. In some embodiments, the functionality of the wireless communication device 1100 (e.g., functionality of the WCD 502 or UE) described above may be fully or partially implemented in software that is, e.g., stored in the memory 1104 and executed by the processor(s) 1102. Note that the wireless communication device 1100 may include additional components not illustrated in FIG. 11 such as, e.g., one or more user interface components (e.g., an input/output interface including a display, buttons, a touch screen, a microphone, a speaker (s), and/or the like and/or any other components for allowing input of information into the wireless communication device 1100 and/or allowing output of information from the wireless communication device 1100), a power supply (e.g., a battery and associated power circuitry), etc.

[0098] In some embodiments, a computer program including instructions which, when executed by at least one processor, causes the at least one processor to carry out the functionality of the wireless communication device 1100 according to any of the embodiments described herein is provided. In some embodiments, a carrier comprising the aforementioned computer program product is provided. The carrier is one of an electronic signal, an optical signal, a radio signal, or a computer readable storage medium (e.g., a non-transitory computer readable medium such as memory).

[0099] FIG. 12 is a schematic block diagram of the wireless communication device 1100 according to some other embodiments of the disclosed subject matter. The wireless communication device 1100 includes one or more modules 1200, each of which is implemented in software. The module(s) 1200 provide the functionality of the wireless communication device 212 (e.g., functionality of the WCD 502 or UE) described herein.

[0100] Any appropriate steps, methods, features, functions, or benefits disclosed herein may be performed through one or more functional units or modules of one or more virtual apparatuses. Each virtual apparatus may comprise a number of these functional units. These functional units may be implemented via processing circuitry, which may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as Read Only Memory (ROM), Random Access Memory (RAM), cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory includes program instructions for executing one or more telecommunications and/or data communications protocols as well as instructions for carrying out one or more of the techniques described herein. In some implementations, the processing circuitry may be used to cause the respective functional unit to perform corresponding functions according one or more embodiments of the disclosed subject matter.

[0101] While processes in the figures may show a particular order of operations performed by certain embodiments of the disclosed subject matter, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

[0102] Those skilled in the art will recognize improvements and modifications to the embodiments of the disclosed subject matter. All such improvements and modifications are considered within the scope of the concepts disclosed herein.