Patent Description:
This section introduces aspects that may be helpful to facilitating a better understanding of the inventions.

Fourth generation (<NUM>) wireless mobile telecommunications technology, also known as Long Term Evolution (LTE) technology, was designed to provide high capacity mobile multimedia with high data rates particularly for human interaction. Next generation or fifth generation (<NUM>) technology is intended to be used not only for human interaction, but also for machine type communications in so-called Internet of Things (loT) networks.

While <NUM> networks are intended to enable massive loT services (e.g., very large numbers of limited capacity devices) and mission-critical loT services (e.g., requiring high reliability), improvements over legacy mobile communication services are supported in the form of enhanced mobile broadband (eMBB) services intended to provide improved wireless Internet access for mobile devices.

In an example communication system, user equipment (<NUM> UE in a <NUM> network or, more broadly, a UE) such as a mobile terminal (subscriber) communicates over an air interface with a base station or access point referred to as a gNB in a <NUM> network or an eNB (evolved Node B) in an LTE network. The access point (e.g., gNB/eNB) is illustratively part of an access network of the communication system. For example, in a <NUM> network, the access network is referred to as a <NUM> System and is described in <NUM> Technical Specification (TS) <NUM>, VO. <NUM>, entitled "Technical Specification Group Services and System Aspects; System Architecture for the <NUM> System,". In an LTE network, the access network is an Evolved Universal Terrestrial Radio Access Network (E-UTRAN). In general, the access point (e.g., gNB/eNB) provides access for the UE to a core network (CN), which then provides access for the UE to other UEs and/or a data network such as a packet data network (e.g., Internet).

Privacy is an important consideration in any communication system. Privacy is broadly addressed in <NPL>,". In particular, TR <NUM> identifies subscription (UE) privacy as one of the most important security areas to be addressed in <NUM> networks.

"<NPL> relates to security aspects in <NUM> systems, and teaches that, during an authentication procedure, an identity of a user equipment is validated by comparing the identity to a revocation list.

<CIT> relates to the use of partially encrypted identifiers in a communication system, and teaches that a network is authenticated by a trusted entity. The network sends a public key along with a certificate signed by the trusted entity, which the user equipment uses to determine whether the network can be trusted by the user equipment.

<CIT> relates to management of authentication cookie encryption pairs, where a key server generates encryption keys having a validity period, and provides keys to a registration authority. The key server may receive a request for validity of a given key, and determine the validity of that key based on the validity period. <CIT> discloses performing hierarchical encryption of a message containing identification information of a mobile user with keys at different encryption levels.

Illustrative embodiments provide techniques for providing subscriber privacy in communication systems.

In one or more methods according to illustrative embodiments, one or more cryptographic key pairs are provisioned in a home network of a communication system for utilization by subscribers of the home network to conceal subscriber identifiers provided to one or more access points in the communication system. The one or more cryptographic key pairs are managed utilizing an element or function in the home network of the communication system. Managing the one or more cryptographic key pairs comprises receiving one or more requests for subscriber identifier decryption related to one or more of the cryptographic key pairs, wherein each of the one or more requests comprises an encrypted subscriber identifier and a cryptographic key pair identifier identifying a cryptographic key pair used to encrypt the subscriber identifier; determining a validity of a given cryptographic key pair identified by the cryptographic key pair identifier for each respective request; decrypting the encrypted subscriber identifier based on the determining, wherein the decrypting is performed utilizing a private key associated with the cryptographic key pair identifier for each respective request; and providing a response comprising a decrypted subscriber identifier to each respective request based on the determining and the decrypting, wherein at least one of the responses comprises information related to one or more updates for one or more cryptographic key pairs.

In one or more other methods according to illustrate embodiments, one or more public keys associated with one or more cryptographic key pairs are stored in user equipment, the cryptographic key pairs being provisioned by a home network of a communication system for use by subscribers of the home network to conceal subscriber identifiers provided to one or more access points in the communication network. An element or function of the home network of the communication system is interfaced for management of the one or more public keys stored in the user equipment. The interfacing comprises providing one or more requests related to one or more of the cryptographic key pairs, wherein each of the one or more requests comprises an encrypted subscriber identifier and a cryptographic key pair identifier identifying a cryptographic key pair used to encrypt the subscriber identifier; and receiving a response to each respective request based on a determination of a validity of a given cryptographic key pair identified by the cryptographic key pair identifier and a decryption of the encrypted subscriber identifier utilizing a private key associated with the cryptographic key pair identifier, wherein at least one of the responses comprises information related to one or more updates for one or more cryptographic key pairs.

Advantageously, illustrative embodiments enable network elements or functions to manage subscriber identifier privacy.

While these techniques can be applied to various communication networks, they are particularly suitable for <NUM> and next generation communication networks.

Further embodiments are provided in the form of non-transitory computer-readable storage medium having embodied therein executable program code that when executed by a processor causes the processor to perform the above steps. Still further embodiments comprise apparatus with a processor and a memory configured to perform the above steps.

These and other features and advantages of embodiments described herein will become more apparent from the accompanying drawings and the following detailed description.

Embodiments will be illustrated herein in conjunction with example communication systems and associated techniques for providing privacy management in communication systems. It should be understood, however, that the scope of the claims is not limited to particular types of communication systems and/or processes disclosed. Embodiments can be implemented in a wide variety of other types of communication systems, using alternative processes and operations. For example, although illustrated in the context of wireless cellular systems utilizing 3GPP system elements such as an LTE Evolved Packet Core (EPC) and a 3GPP next generation system (<NUM>), the disclosed embodiments can be adapted in a straightforward manner to a variety of other types of communication systems including, but not limited to, WiMAX systems and Wi-Fi systems.

As mentioned above, privacy of subscription identifiers when communicating over the air interface between the user equipment and the network access point has been a significant issue for <NUM>/<NUM>/<NUM> networks. Efforts have been made in <NUM> networks to address this significant issue.

For example, it is known that malicious actors attempt to learn subscriber identifiers either by passively (passive catcher) eavesdropping over the air interface between the UE and the gNB/eNB, or actively (active catcher) requesting the subscriber identifier.

Solutions to provide privacy over the air interface can be generally grouped in three solution classes:.

Note that, in one example, an International Mobile Subscriber Identity (IMSI) is a permanent subscription identifier (subscriber identity) of a UE. In one embodiment, the IMSI is a fixed <NUM>-digit length and consists of a <NUM>-digit Mobile Country Code (MCC), a <NUM>-digit Mobile Network Code (MNC), and a <NUM>-digit Mobile Station Identification Number (MSIN).

Note also that in an LTE network, the home subscriber server/function is called a Home Subscriber Server (HSS), and in a <NUM> network it is called User Data Management (UDM) which may also comprise an Authentication and Security Function (AUSF) and an Authentication Credential Repository and Processing Function (ARPF) as part of the UDM function.

While illustrative embodiments are described herein from the perspective of the second solution class (i.e., the home network public key based solution), alternative embodiments may be implemented for one or more other solution classes. See 3GPP TS <NUM> and 3GPP TR <NUM>.

In the home network public key based solution, the home operator provides its public key to all home network subscribers. A network subscriber uses the public key of the home operator to encrypt its subscriber identity. In the case of an IMSI, the MSIN provides the subscriber identity. Only the MSIN portion of the IMSI needs to be encrypted. The MNC and MCC portions of the IMSI provide routing information, used by the serving network to route to the correct home network. The home HSS is the only entity that can decrypt the encrypted subscriber identity, as the home HSS possesses the private key that corresponds to the public key used by the network subscriber in encrypting the subscriber identity. Once the IMSI is identified, HSS/AuC (where AuC is the Authentication Center part of the HSS) will create authentication vectors (AVs) based on the distinct shared root key K between a user (subscriber) and the HSS/AuC. Similarly, in the <NUM> network, the UDM/ARPF creates the AVs requested via AUSF. AUSF and UDM could be co-located for optimization reasons.

An operator in a network may have implementations that utilize multiple HSSs, allowing the operator to manage distinct sets of users in different HSSs/UDMs. Because of the multiple HSSs, a Server Location Function (SLF) is implemented in front of a set of HSSs. The SLF analyses the authentication request for a user received from a Mobility Management Element (MME) (in an LTE network) or Access and Mobility Management Function (AMF) (in a <NUM> network) and routes it to the correct HSS.

By way of example only, operation of the SLF is described in 3GPP TS <NUM> (Section <NUM>: "User identity to HSS resolution") entitled "<NUM>rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol (Release <NUM>),".

SLF provides user identity (IMSI)-to-HSS resolution using a locally maintained subscriber profile database and routes Diameter messages containing the user authentication requests, as a Diameter proxy to the chosen HSS. Note that, in <NUM>, similar functionality would also be requested if <NUM> core network protocols are different from Diameter, e.g., using http-proxies. In the following descriptions, it is assumed that the SLF is covering both the DRA (Diameter Routing Agent) based solution as per <NUM> or any other proxy related solution dependent on protocol decisions for the <NUM> core network.

It is realized herein that the <NUM> UE and the HSS/UDM of its home network (public land mobile network or PLMN) share a long-term identifier (e.g., subscriber permanent identifier or SUPI), such as IMSI, and a long-term key K. As mentioned above, a home PLMN has a public key, which it has made available to the UE. Since this is a relationship between the operator and its subscribers, this can be a raw public key, i.e., no need for certificates (global public key infrastructure (PKI)).

Thus, in the home network (HN) centric long-term identifier (e.g., SUPI) privacy solution, the HN operator provides one public key used for encrypting the long-term identifier over the air to all of its subscribers. According to this solution:.

3GPP SA3 has decided to deploy SUPI/IMSI privacy from <NUM> onwards. However, there have been further discussions about whether this solution could be used in <NUM>.

Whenever the UE is asked to provide its identity, it sends the encrypted identity and the HSS/UDM will retrieve the real identity. It is assumed that the HSS/UDM has a secure execution environment to decrypt any received request.

In a simple implementation, HSS/UDM could try to decrypt the encrypted identity with one private key; if not successful, HSS/UDM would just use another private key to decrypt the encrypted identity, and so on. However, this is not an efficient solution. As such, illustrative embodiments provide an indication of which key pair is in use by the introduction of a key pair indicator, e.g., flag, field, identifier, or some other identification. More particularly, a key pair indicator is uniquely assigned to a given public/private privacy key pair. Then, a given key pair indicator is advantageously used by the UE to indicate which public key was used to encrypt its permanent identifier, and by the HSS/UDM or other network element/function as will be explained to efficiently decide which private key will be selected/used for decryption.

In one illustrative key provisioning embodiment, one or more cryptographic public/private key pairs are generated as follows:.

In one illustrative authentication embodiment, a usage methodology for the provisioned key pair and key pair indicator may comprise:.

It is to be appreciated that, in alternative embodiments, instead of the HSS/UDM performing the above-enumerated steps/functions, the steps/functions can be performed by the SLF completely, or some combination of sharing the steps/functions can be implemented between the HSS/UDM and SLF. Still further, other network elements/functions (other than HSS/UDM or SLF) can be configured to perform the above-enumerated and other steps. Alternatively, rather than a separate HSM, message decryption itself can be performed in the HSS/UDM or SLF if a secure execution environment is available therein.

While no more than two public/private key pairs are typically needed (one current, and one for future), embodiments are not intended to be limited to two key pairs (e.g., operator-specific implementations with more than two key pairs are contemplated). The initial provisioning of the UICC (or Mobile Equipment (ME)) would benefit if two public keys (including the key pair indicator) are stored. Since the home network (HN) operator replaces one public key by another public key (including the key pair indicator), UICC storage capacity is configured for at least two public keys. If one public key is disabled, it could be overwritten by the newly provided public key. By keeping two public keys in storage, a UE could react immediately in case of a failure message, i.e., switch to the other public key.

One public/private key pair may not be sufficient for stable operation (update/expiry/etc.), thus the illustrative embodiments provide a privacy management solution for several key pairs. Given the above-described privacy management embodiments, a wide variety of network configurations can be employed to implement these features. <FIG> depict some of these network configurations. However, it is to be appreciated that embodiments are not limited to the network configurations illustrated herein or otherwise described below.

<FIG> shows a communication system <NUM> within which illustrative embodiments are implemented. It is to be understood that the elements shown in communication system <NUM> are intended to represent main functions provided within the system, e.g., UE access functions, mobility management functions, authentication functions, serving gateway functions, etc. As such, the blocks shown in <FIG> reference specific elements in LTE and <NUM> networks that provide these main functions. However, other network elements may be used to implement some or all of the main functions represented. Also, it is to be understood that not all functions of an LTE or <NUM> network are depicted in <FIG>. Rather, functions that facilitate an explanation of illustrative embodiments are represented. Subsequent figures depict some additional elements/functions.

Accordingly, as shown, communication system <NUM> comprises user equipment (UE) <NUM> that communicates via an air interface <NUM> with an access point (eNB/gNB) <NUM>. The UE <NUM> may be a mobile station, and such a mobile station may comprise, by way of example, a mobile telephone, a computer, or any other type of communication device. In an LTE-V2X implementation, one or more UEs may be deployed in a given vehicle. The term "user equipment" as used herein is therefore intended to be construed broadly, so as to encompass a variety of different types of mobile stations, subscriber stations or, more generally, communication devices, including examples such as a combination of a data card inserted in a laptop or other equipment (e.g., vehicle). Such communication devices are also intended to encompass devices commonly referred to as access terminals.

In one embodiment, UE <NUM> is comprised of a UICC and an ME. The UICC is the user-dependent part of the UE and contains at least one Universal Subscriber Identity Module (USIM) and appropriate application software. The USIM securely stores the IMSI number and its related key, which are used to identify and authenticate subscribers to access networks. The ME is the user-independent part of the UE and contains terminal equipment (TE) functions and various mobile termination (MT) functions.

The access point <NUM> is illustratively part of an access network of the communication system <NUM>. Such an access network may comprise, for example, an E-UTRAN or <NUM> System (or mixed) having a plurality of base stations and one or more associated radio network control functions. The base stations and radio network control functions may be logically separate entities, but in a given embodiment may be implemented in the same physical network element, such as, for example, a base station router or femto cellular access point.

The access point <NUM> in this illustrative embodiment is operatively coupled to a mobility management function <NUM>. In an LTE network, the function is typically implemented by a Mobility Management Element (MME), while in a <NUM> network the function is implemented by an Access and Mobility Management Function (AMF). Although not expressly shown, a Security Anchor Function (SEAF) can be implemented with the AMF connecting a UE with the mobility management. A mobility management function, as used herein, is the element or function in the core network (CN) part of the communication system that manages, among other network operations, access and authentication operations with the UE (through the access point <NUM>).

The MME/AMF <NUM> in this illustrative embodiment is operatively coupled to an SLF <NUM>. In illustrative embodiments, SLF <NUM> is configured to respond to indicators that are sent in messages it receives. As described above, SLF <NUM> may simply forward the encrypted information to the appropriate home network of UE <NUM> to have the corresponding HSS/UDM decrypt (or cause to be decrypted by an HSM) the identity (consulting the key pair indicator provided by the UE). Thus, as shown, SLF <NUM> is operatively coupled to a plurality of HSSs/UDMs <NUM>-<NUM>, <NUM>-<NUM>,. These HSSs/UDMs represent the home networks of UEs that may attach to the communication system <NUM>. SLF <NUM> is configured to provide the UE information to the appropriate HSS/UDM <NUM>.

The access point <NUM> is also operatively coupled to a serving gateway function <NUM> (e.g., Serving Gateway (SGW) in an LTE network, and Session Management Function (SMF) in a <NUM> network), which is operatively coupled to a Packet Data Network (PDN) Gateway (PGW) <NUM>. PGW <NUM> is operatively coupled to a Packet Data Network, e.g., Internet <NUM>. MME/AMF <NUM> and SLF <NUM> may be considered part of a CN. MME/AMF <NUM> and SLF <NUM> can also be part of a serving network. Further typical operations and functions of such network elements are not described here since they are not the focus of the illustrative embodiments and may be found in appropriate 3GPP LTE or <NUM> documentation.

It is to be appreciated that this particular arrangement of system elements is an example only, and other types and arrangements of additional or alternative elements can be used to implement a communication system in other embodiments. For example, in other embodiments, the system <NUM> may comprise authentication elements, as well as other elements not expressly shown herein.

Accordingly, the <FIG> arrangement is just one example configuration of a wireless cellular system, and numerous alternative configurations of system elements may be used. For example, although only single UE, eNB/gNB, MME/AMF, SLF, SGW/SMF and PGW elements are shown in the <FIG> embodiment, this is for simplicity and clarity of description only. A given alternative embodiment may of course include larger numbers of such system elements, as well as additional or alternative elements of a type commonly associated with conventional system implementations.

It is also to be noted that while <FIG> illustrates system elements as singular functional blocks, the various subnetworks that make up the <NUM> network are partitioned into so-called network slices. Network slices (network partitions) comprise a series of function sets (i.e., function chains) for each corresponding service type using network function virtualization (NFV) on a common physical infrastructure. The network slices are instantiated as needed for a given service, e.g., eMBB service, massive IoT service (e.g., V2X service), and mission-critical IoT service. A network slice or function is thus instantiated when an instance of that network slice or function is created. In some embodiments, this involves installing or otherwise running the network slice or function on one or more host devices of the underlying physical infrastructure. UE <NUM> is configured to access one or more of these services via eNB/gNB <NUM>.

<FIG> shows a block diagram of an overview of a system <NUM> for providing privacy management in an illustrative embodiment. System <NUM> is shown comprising privacy management element/function (PM) <NUM> and network element/function <NUM>. It is to be appreciated that network element/function <NUM> represents a network element/function that is configured to interact with PM <NUM> in order to implement privacy management within the communication system of <FIG>. For example, network element/function <NUM> may be a User Data Repository (UDR), or some other network element/function that may be used in accordance with the embodiments described herein. In illustrative embodiments, the PM <NUM> is resident in one or more HNs.

The PM <NUM> comprises a processor <NUM> coupled to a memory <NUM> and interface circuitry <NUM>. The processor <NUM> of the PM <NUM> includes a privacy management processing module <NUM> that may be implemented at least in part in the form of software executed by the processor. The processing module <NUM> performs privacy management described in conjunction with subsequent figures and otherwise herein. The memory <NUM> of the PM <NUM> includes a privacy management storage module <NUM> that stores data generated or otherwise used during privacy management. The PM <NUM> further comprises components <NUM> configured to implement the privacy management. Further details regarding the components <NUM> will be discussed with reference to <FIG>.

The network element/function <NUM> comprises a processor <NUM> coupled to a memory <NUM> and interface circuitry <NUM>. The processor <NUM> of the network element/function <NUM> includes a privacy management processing module <NUM> that may be implemented at least in part in the form of software executed by the processor <NUM>. The processing module <NUM> performs privacy management described in conjunction with subsequent figures and otherwise herein. The memory <NUM> of the network element/function <NUM> includes a privacy management storage module <NUM> that stores a mapping of key pair indicators to public/private key pairs and related data generated or otherwise used during key management and authentication operations.

The processors <NUM> and <NUM> of the respective PM <NUM> and network element/function <NUM> may comprise, for example, microprocessors, application-specific integrated circuits (ASICs), digital signal processors (DSPs) or other types of processing devices, as well as portions or combinations of such elements.

The memories <NUM> and <NUM> of the respective PM <NUM> and network element/function <NUM> may be used to store one or more software programs that are executed by the respective processors <NUM> and <NUM> to implement at least a portion of the functionality described herein. For example, authentication operations and other functionality as described in conjunction with subsequent figures and otherwise herein may be implemented in a straightforward manner using software code executed by processors <NUM> and <NUM>.

A given one of the memories <NUM> or <NUM> may therefore be viewed as an example of what is more generally referred to herein as a computer program product or still more generally as a processor-readable storage medium that has executable program code embodied therein. Other examples of processor-readable storage media may include disks or other types of magnetic or optical media, in any combination. Illustrative embodiments can include articles of manufacture comprising such computer program products or other processor-readable storage media.

The memory <NUM> or <NUM> may more particularly comprise, for example, an electronic random access memory (RAM) such as static RAM (SRAM), dynamic RAM (DRAM) or other types of volatile or non-volatile electronic memory. The latter may include, for example, non-volatile memories such as flash memory, magnetic RAM (MRAM), phase-change RAM (PC-RAM) or ferroelectric RAM (FRAM). The term "memory" as used herein is intended to be broadly construed, and may additionally or alternatively encompass, for example, a read-only memory (ROM), a disk-based memory, or other type of storage device, as well as portions or combinations of such devices.

The interface circuitries <NUM> and <NUM> of the respective PM <NUM> and network element/function <NUM> illustratively comprise transceivers or other communication hardware or firmware that allows the associated system elements to communicate with one another in the manner described herein.

It is apparent from <FIG> that PM <NUM> is configured for communication with network element/function <NUM> and vice-versa via their respective interface circuitries <NUM> and <NUM>. This communication involves PM <NUM> sending data to the network element/function <NUM>, and the network element/function <NUM> sending data to the PM <NUM>. However, in alternative embodiments, other network elements may be operatively coupled between PM <NUM> and network element/function <NUM>. The term "data" as used herein is intended to be construed broadly, so as to encompass any type of information that may be sent between user equipment and a core network via a base station element including, but not limited to, identity data, key pairs, key indicators, authentication data, control data, audio, video, multimedia, etc..

It is to be appreciated that the particular arrangement of components shown in <FIG> is an example only, and numerous alternative configurations may be used in other embodiments. For example, the user equipment and mobility management function can be configured to incorporate additional or alternative components and to support other communication protocols.

Other system elements, such as eNB/gNB <NUM>, MME/AMF <NUM>, SGW/SMF <NUM>, and PGW <NUM>, may each also be configured to include components such as a processor, memory and network interface. These elements need not be implemented on separate stand-alone processing platforms, but could instead, for example, represent different functional portions of a single common processing platform. Such a processing platform may additionally comprise at least portions of an eNB/gNB and an associated radio network control function.

Privacy management performed by PM <NUM> comprises performing privacy key pair management, privacy key pair selection, and decryption. Further details regarding the performance of privacy management will be discussed below with reference to <FIG>.

<FIG> illustrates a block diagram of exemplary components of a PM, such as PM <NUM> from <FIG>. As shown, PM <NUM> comprises Privacy Handling Function (PHF) <NUM>, Key Identity Reconfirmation Function (KIRF) <NUM>, Subscription Identifier Decryption Function (SIDF) <NUM>, Key Request Function (KRF) <NUM> and Key Database (KDB) <NUM>. Although components <NUM>-<NUM> of PM <NUM> are shown as individual components, the components may be implemented in a single component, or as a combination or sub-combinations of components. In one embodiment, at least a portion of the components of PM <NUM> are located within an HSM. For example, at least SIDF <NUM>, KRF <NUM> and KDB <NUM> may be located in HSM <NUM>, as illustrated by the dashed line surrounding these components in <FIG>.

In one embodiment, KDB <NUM> is configured to hold at least a list of tuples comprising a valid (public/private) key identifier PKid and a related private key. Various techniques may be used to provision the KDB <NUM> with this data. PKid identifies the public key that the UE has used to create a concealed identifier.

PHF <NUM> is the management function, by which PM <NUM> interacts with other network functions. In one embodiment, PHF <NUM> is addressed first and invokes other functions of PM <NUM>. Further, PHF <NUM> may be required to handle failures or other unexpected use cases, notify the network elements of success/failure, and may have the UE notified if, e.g., PKid is not valid anymore. PHF <NUM> in some embodiments is responsible for triggering KIRF <NUM>, SIDF <NUM>, and/or other functions that may be added to PM <NUM>.

As mentioned above, PKid identifies the public key, which the UE has used to create the concealed identifier. If PHF <NUM> receives a concealed identifier and PKid, it triggers KIRF <NUM>, using PKid, to obtain information about the validity of the public/private key pair from a privacy data repository. In one embodiment, the privacy data repository is comprised in a UDR. Based on the PKid, the privacy data repository is configured to check for the validity of the public/private key pair and provide a response back to PHF <NUM>. The response may include additional information. Such additional information may include, for example, information that a new PKid is available, information that the PKid is broken and an update is needed, or information that the PKid is invalid and an update is needed. PHF <NUM> may be configured to generate error or subscribe/notify messages for the UE in response to the additional information. In the case that the PKid is invalid, a one-time service with the old PKid may be provided. Interface information may be exchanged between PM <NUM> and the privacy data repository.

KRF <NUM> is an internal logical function of PM <NUM> responsible for requesting the private key from KDB <NUM>. Specifically, SIDF <NUM> is configured to invoke KRF <NUM> to request the private key from KDB <NUM> for a particular PKid. KDB <NUM> finds the private key and sends the private key back to SIDF <NUM>.

If PKid is determined to be valid, PHF <NUM> is configured to provide PKid and the concealed identifier to SIDF <NUM> for decryption of the concealed identifier. If decryption is successful, SIDF <NUM> provides the long-term identifier to PHF <NUM>. In the case of decryption failure, SIDF <NUM> may provide additional information back to PHF <NUM>, which may result in error messages. PHF <NUM> is configured to generate the response message for the requesting entity. This message may include the long-term identifier and/or the additional information depending on the data received back from SIDF <NUM> and KRF <NUM>.

If PHF <NUM> has a local cache of recently used PKids, PHF <NUM> may immediately invoke SIDF <NUM> without invoking the privacy data repository via KIRF <NUM> beforehand. However, in this case, PHF <NUM> may, in parallel, trigger KIRF <NUM> to check the lifetime/validity from the privacy data repository, since the operator may have updated its database after the data was cached.

Before, during or after an Authentication and Key Agreement (AKA) protocol process, PHF <NUM> may request that KIRF <NUM> check the validity of PKid with the privacy data repository, and provide KDB <NUM> with updated information.

In some embodiments, privacy management as described herein is provided as a standalone function, or PMF. In other embodiments, privacy management is provided as a service, or PMS. Embodiments utilizing PMF are discussed in detail below with reference to <FIG> and <FIG>. Embodiments utilizing PMS are discussed in detail below with reference to <FIG> and <FIG>.

<FIG> illustrates a block diagram of an exemplary system <NUM> implementing privacy management as a standalone function. System <NUM> is illustratively comprised in a <NUM> network. System <NUM> is shown comprising UE <NUM> in communication with (radio) access network ((R)AN) <NUM> and AMF <NUM>. (R)AN <NUM> is in communication with User Plane Function (UPF) <NUM>. UPF <NUM> is in communication with Data Network (DN) <NUM> and Session Management Function (SMF) <NUM>.

System <NUM> further includes interface <NUM> coupled to AMF <NUM> and SMF <NUM>. Additionally, AUSF <NUM>, Network Slice Selection Function (NSSF) <NUM>, Network Exposure Function (NEF) <NUM>, Network Function Repository Function (NRF) <NUM>, Policy Control Function (PCF) <NUM>, UDM <NUM>, Application Function (AF) <NUM>, and PMF <NUM> are coupled to interface <NUM> as shown.

Each element/function of system <NUM> is shown having a respective service interface. Since PMF <NUM> is a standalone function, a new service interface Npmf is needed, which may be invoked directly by other network elements within the environment. Examples of network elements using the service are AUSF <NUM>, UDM <NUM> and/or NRF <NUM>. PMF <NUM> is configured to not be accessible outside the home PLMN. Access rights need to be clearly defined for each network element within the home PLMN for which access to PMF <NUM> is authorized.

<FIG> illustrates a block diagram of an exemplary data storage architecture <NUM> for structured data implementing PMF. As shown, data storage architecture <NUM> comprises PMF front end (FE) <NUM>, UDM FE <NUM>, PCF FE <NUM> and NEF FE <NUM>, which are each in communication with UDR <NUM>. UDR <NUM> is shown comprising subscription data <NUM>, policy data <NUM>, structured data for exposure <NUM>, application data <NUM> and privacy data <NUM>.

Privacy data <NUM> may comprise information accessible only by PMF FE <NUM>. For example, privacy data <NUM> may be accessible by a KIRF component. The KIRF component may be a component of PMF FE <NUM>, or could be a separate service (e.g., a service in UDM FE <NUM>). In one embodiment, PMF FE <NUM> uses service interface Nudr if information from privacy data <NUM> is needed (e.g., KIRF of PMF FE <NUM>). Privacy data <NUM> comprises data sets which may include, for example: (<NUM>) a key identifier for the private/public key pair that the home PLMN operator has generated and from which the public key is used by all home PLMN subscribers to encrypt the SUPI (and from the PMF FE <NUM> to decrypt the resulting concealed identifier); (<NUM>) a validity period for the private/public key pair; and (<NUM>) management information for private/public key pairs (e.g., active, old, not allowed anymore).

In embodiments illustrated in <FIG> and <FIG>, privacy management is implemented as a standalone network function (PMF). However, as mentioned above, privacy management may be offered as a service (PMS) by another network element/function in a <NUM> system.

<FIG> illustrates a block diagram of a portion of a system <NUM> implementing PMS. As shown, PMS <NUM> is co-located within another existing network function <NUM>. That is, existing network function <NUM> may be considered to be a network function that is enhanced with PMS functionality.

<FIG> illustrates a block diagram of an exemplary data storage architecture <NUM> for structured data implementing PMS. As shown, data storage architecture <NUM> comprises UDM FE <NUM>, PCF FE <NUM> and NEF FE <NUM>, which are each in communication with UDR <NUM>. In this illustrative embodiment, PM <NUM> is co-located within UDM FE <NUM> to implement PMS. UDR <NUM> is shown comprising subscription data <NUM>, policy data <NUM>, structured data for exposure <NUM>, application data <NUM> and privacy data <NUM>.

It may be particularly advantageous to co-locate the PM with the existing UDM in order to minimize service requests. In this case, privacy management may be addressed by Nudm. If several subscriber databases are used to hold the complete set of all user's subscription identifier information of one home PLMN, NRF may be used to locate the appropriate UDM instance. <FIG> and <FIG> show tables <NUM> and <NUM>, respectively, illustrating network function (NF) services that may be provided by a UDM enhanced with PMS.

Optionally, multiple UDM instances may be available in the PLMN serving different SUPI subsets. In this case, the UDM selection for subscriber-data related services (see TS <NUM> for subscriber related UDM) must be done using the SUPI. This selection can be done via an NRF (see TS <NUM>). In this case, the SUPI must be available before the first request is sent towards UDM; this is most likely the authentication request (see TS <NUM>). Alternatively, in the case of a service architecture, it is also possible that the AMF would request the decryption service from the UDM or NRF from the home network. This way, the AMF could already send the SUPI when starting an AKA protocol request to the home PLMN UDM (possibly via NRF). NRF can then redirect to the UDM instance.

It is to be appreciated that the naming of identifiers mentioned herein, e.g., IMSI, etc., are for illustrative purposes only. That is, an identifier for a UE may have different names or acronyms in different protocols and standards for different communication network technologies. As such, none of the specific names or acronyms given to these identifiers herein are intended to limit embodiments in any manner.

As indicated previously, the embodiments are not limited to the LTE or <NUM> context and the disclosed techniques can be adapted in a straightforward manner to a wide variety of other communication system contexts including, but not limited to, other 3GPP systems and non-3GPP systems which employ identity (e.g., IMSI or equivalent) in the identity request process.

The processor, memory, controller and other components of a user equipment or base station element of a communication system as disclosed herein may include well-known circuitry suitably modified to implement at least a portion of the identity request functionality described above.

As mentioned above, embodiments may be implemented in the form of articles of manufacture each comprising one or more software programs that are executed by processing circuitry of user equipment, base stations or other elements of a communication system. Conventional aspects of such circuitry are well known to those skilled in the art and therefore will not be described in detail herein. Also, embodiments may be implemented in one or more ASICS, FPGAs or other types of integrated circuit devices, in any combination. Such integrated circuit devices, as well as portions or combinations thereof, are examples of "circuitry" as that term is used herein. A wide variety of other arrangements of hardware and associated software or firmware may be used in implementing the illustrative embodiments.

Claim 1:
A method comprising:
in a home network of a communication system, provisioning one or more cryptographic key pairs for utilization by subscribers of the home network to conceal subscriber identifiers provided to one or more access points in the communication system; and
managing the one or more cryptographic key pairs utilizing an element or function in the home network of the communication system, wherein managing the one or more cryptographic key pairs comprises:
receiving one or more requests for subscriber identifier decryption related to one or more of the cryptographic key pairs, wherein each of the one or more requests comprises an encrypted subscriber identifier and a cryptographic key pair identifier identifying a cryptographic key pair used to encrypt the subscriber identifier;
determining a validity of a given cryptographic key pair identified by the cryptographic key pair identifier for each respective request;
decrypting the encrypted subscriber identifier based on the determining, wherein the decrypting is performed utilizing a private key associated with the cryptographic key pair identifier for each respective request; and
providing a response comprising a decrypted subscriber identifier to each respective request based on the determining and the decrypting, wherein at least one of the responses comprises information related to one or more updates for one or more cryptographic key pairs.