Patent Description:
The present disclosure relates generally to wireless networking. More particularly, the present disclosure relates to international mobile subscriber identity (IMSI) catchers, and, more particularly, to a subscriber permanent identifier (SUPI) catcher for use in <NUM> networks which associates SUPI and subscriber concealed identifier (SUCI).

An IMSI Catcher is an eavesdropping device used for intercepting mobile phone traffic and tracking location data of mobile phone users. In <NUM>, when user equipment (UE) initially attaches to a long-term evolution (LTE) network (e.g., turning on the UE), it sends its IMSI to the network for authentication to have itself identified. One can therefore associate a mobile phone user to its IMSI and track the IMSI activity in the network traffic to obtain location data for the user.

In <NUM> networks the IMSI is replaced by a subscription permanent identifier (SUPI) that is also a representative value for the UE. However, <NUM> users do not send the SUPI in clear mode but rather send an encrypted value known as subscriber concealed identifier (SUCI), as defined in 3GPP TS <NUM> (see, e.g., Security architecture and procedures for <NUM> System, 3GPP TS <NUM> version <NUM>. <NUM> Release <NUM>, August <NUM>, the contents of which are incorporated by reference in their entirety). This makes it very complicated for catchers to find the right user identifier especially since the SUCI could change at any time due to a refreshing parameter embedded in the encryption mechanism. <NPL> describes obtaining SUPI from SUCI in a <NUM> network.

There is therefore a need for an IMSI/SUPI catcher for use in <NUM> networks.

According to an aspect, there is provided subject matter of independent claims. Dependent claims define some embodiments.

One or more examples of implementations are set forth in more detail in the accompanying drawings and the description of embodiments.

The present disclosure relates to systems and methods for international mobile subscriber identity (IMSI) catchers, and, more particularly, to a subscriber permanent identifier (SUPI) catcher for use in <NUM> networks which associates SUPI and subscriber concealed identifier (SUCI). Systems and methods for detecting a subscriber permanent identifier (SUPI) from a subscriber concealed identifier (SUCI) include steps of receiving the SUCI that is a representative of user equipment (UE) of interest and that is encrypted; checking association data with the received SUCI to determine a corresponding SUPI, wherein the association data includes a mapping of a plurality of SUCIs to a plurality of SUPIs and is maintained over time based on monitoring messages in a <NUM> core network; and providing the corresponding SUPI. The steps can further include updating the association data based on monitoring exchanges on both sides of an access and mobility management function (AMF) associated with the <NUM> core network.

Again, the present disclosure relates to systems and methods for international mobile subscriber identity (IMSI) catchers, and, more particularly, to a subscriber permanent identifier (SUPI) catcher for use in <NUM> networks which associates SUPI and subscriber concealed identifier (SUCI).

For homeland security, law enforcement, etc., there is a product called an IMSI catcher that act like a fake cell tower to intercept communications (calls, text messages, Internet traffic, and more) from a targeted UE, then relay to the target cell tower of the network operator. This solution allows also to check for the presence of a perpetrator in a specific area or even figure out their exact location without the need for operator cooperation. This type of procedures is also known as a man-in-the-middle (MitM) attack and those products are normally sold to law enforcement agencies. This product is based on catching IMSIs that are not encrypted on the <NUM>, <NUM> and <NUM> networks. Instead, they are transmitted in plain text over the air. So, although calls and texts are encrypted in <NUM>, the user's meta data - identity and location - is not.

However, the arrival of <NUM> implies a significant challenge to this type of product due to encrypted user identifiers. <NUM> created a new kind of identifier, the SUPI (subscription permanent identifier), but UEs do not send the SUPI over the air. Instead, they send an encrypted key called a SUCI (subscription concealed identifier) and this blinds the IMSI catchers completely and prevents them obviously from working independently away from operators.

In <NUM> Networks, the first registration uses a concealed SUPI for security purpose. The concealed SUPI (aka SUCI) is generated by using a public key of network. The public keys are stored to SIM card and never seen or exchanged between equipment involved in <NUM>. During this first registration, the UE and the Network negotiate a <NUM>-global unique temporary identifier (GUTI) that will be used for further registrations. So, if a system that supervises a <NUM> network is unable to get the SUPI (aka IMSI) from the SUCI during the first registration, it will be almost impossible to track users in <NUM> network based on the SUPI.

<FIG> is a diagram of SUPI concealment at a UE <NUM> and SUPI de-concealment at a subscription identifier de-concealing function (SIDF) at a unified data management (UDM) <NUM>. A SUPI is a <NUM> globally unique identifier allocated to each subscriber and defined in 3GPP specification TS <NUM>. The SUPI includes a mobile country code (MCC) and the next two or three form the mobile network code (MNC) identifying the network operator. The remaining (nine or ten) digits are known as mobile subscriber identification number (MSIN) and represent the individual user of that particular operator. The SUPI is concealed at the UE <NUM> via an asymmetric encryption algorithm, such as elliptic curve integrated encryption scheme (ECIES) which is used to encrypt the MSIN. Of note, the SUCI could change at any time due to a refreshing parameter embedded in the encryption mechanism. The SIDF is a service offered by UDM <NUM> to resolve SUPI from the SUCI, as defined in ETSI TS <NUM><NUM>, e.g., <NUM> Security Assurance Specification (SCAS) for the Unified Data Management (UDM) network product class, <NPL>, the contents of which are incorporated by reference in their entirety.

Of note, an IMSI catcher is a product/solution that operates in <NUM>, <NUM>, and <NUM> networks. In <NUM>, the equivalent product/solution can be referred to as a SUPI catcher.

Based on the fact the SUPI is encrypted as the SUCI over-the-air, there is a need to coordinate monitoring with the mobile network operator (MNO) to decrypt the SUCI. Since the MNO controls the security and privacy of the IMSI from the subscriber identify module (SIM) to the network, lawful intercept can still work with agents to monitor approved criminal targets.

In various embodiments, the present disclosure includes an approach that removes the dependency of the law enforcement agencies on operators by allowing them to capture requested details using over-the-top-provider (OTTP) components. The monitoring solution can capture and process the traffic without the need to get the operators approval to access data per session or per user.

<FIG> is a network diagram of a SUPI catcher <NUM> that implements a SUCI catch procedure through a fake base station <NUM> and uses an enrichment mechanism <NUM> in a core network <NUM> to obtain the real SUPI, from the SUCI. The SUPI catcher <NUM> (which could also be referred to as an IMSI catcher) is connected to an access and mobility management function (AMF) <NUM> of an operator. The AMF <NUM> is one of the control plane network functions (NF) of the <NUM> core network (5GC). The AMF <NUM> is also connected to an authentication server function (AUSF) <NUM> which performs authentication with a UE <NUM>. Of note, the UE <NUM> uses a SUCI <NUM> over-the-air to the SUPI catcher <NUM>, and the AMF <NUM> is configured to perform the SIDF to obtain a corresponding SUPI <NUM>.

The SUPI catcher <NUM> can be a fake base station or the like that is attached to the network as a genuine base station and interfaces with the operator core network <NUM>. The setup of the SUPI catcher <NUM> as a base station is performed in a first step. A second step involves deploying an evolved software capture via the enrichment interface <NUM> that can obtain the SUCI <NUM> and SUPI <NUM> on both sides of the AMF <NUM> to create a matrix that associates each SUCI <NUM> (or updated SUCI <NUM> based on the encryption) with the relevant SUPI <NUM>. The enrichment mechanism <NUM> is based on exchanges with tickets between processing units (PU) through a message bus (e.g., Apache Kafka) topics.

A summary of the present disclosure includes:.

The approach described herein to obtain the SUPI <NUM> of the UE <NUM> and its associated traffic does not require any changes to the existing network design. This solution is important to homeland security agencies as well as service monitoring. The present disclosure uses OTTP components to remove the dependency of the law enforcement agencies on operators by allowing them to capture requested details. The monitoring solution can capture and process the traffic without the need to get the operators approval to access data per session or per user.

The evolved software capture to obtain the SUCI and SUPI can be also attached to both sides of the UDM <NUM>, as well as or in addition to the AMF <NUM>, to create a matrix that associates each SUCI <NUM> (or updated SUCI <NUM> based on the encryption) with the relevant SUPI <NUM>. This use case can is more relevant to roaming model when catcher <NUM> equipment is located on a third-party operator and SUCIs are exchanged via SEPP or maybe through SCP exchanges.

The <NUM> core interfaces can be encrypted with TLS1. <NUM> to improve their resiliency in a cloud native design as part of service-based architecture (SBI) model. In another model, the evolved software capture and enrichment mechanism could benefit from new decryption solutions to capture message exchanges in clear mode especially in fully encrypted SBI interfaces in live networks. Various decryption mechanisms could be used to decrypt SBI interfaces considering the type of <NUM> core deployment and hosting domain (for example, using eBPF, extended Berkeley Packet Filter).

There can be various probes in the <NUM> network for various service assurance functions and the like. As described herein, a probe can be a virtual network function (VNF), such as compliant with ETSI/MANO and ONAP standards, deployed in the cloud. In an embodiment, there can be a probe to supervise the <NUM> network that needs to get the IMSI (SUPI) to track UEs.

In the 3GPP specification, there is a procedure in the Service Based Architecture between the UDM (Unified Data Management) and UDR (User Data Repository) that uses the SUCI in the request and gets the SUPI in the response because the SUPI is the main identity used in the <NUM> core network <NUM>. The basic issue with this procedure is that the probe needs to capture this exchange so it must access deep in the <NUM> core network <NUM>. Moreover, to avoid a security breach, some customers colocalizes these two network functions (UDM and UDR) in a unique network function so this procedure is not visible in the <NUM> core network <NUM>.

One implementation of a probe, using the 3GPP specification, can implement the hypertext transfer protocol (HTTP)/<NUM> Request/Response Correlation between the UDM and the AUSF. To remove the issue with colocalized network functions, the probe can implement the correlation between two HTTP/<NUM> procedures using a correlation key named AuthCtxId. This can include a limitation due to HTTP/<NUM> load balancing that prevents a good association between SUCI and SUPI. There can be a ticket exchange between HTTP/<NUM> processing units (PU) to allow the two procedures to be processed by different PUs.

As is described herein, the existing probes are used to provide the enrichment mechanism <NUM> to enrich the SUPI catcher <NUM>. The probes can be software, network functions, etc. that are configured to monitor and process data to a message bus (e.g., Apache Kafka). The enrichment mechanism <NUM> is based on monitoring the exchanges on the message bus.

<FIG> is a network diagram of the <NUM> core network <NUM> connected to an enhanced capture service (ECS) <NUM> which provides data to a stream processing system <NUM>. Those skilled in the art will recognize <FIG> is a logical diagram of functions and interconnectivity. The <NUM> core network <NUM> includes one or more base stations <NUM>, i.e., gNodeB in <NUM>, the AUSF <NUM>, and a session management function (SMF) <NUM>, each being connected to the AMF <NUM>. The ECS <NUM> can be a virtual network function (VNF), probe, virtual probe (i.e., a probe implemented as a VNF), etc. The ECS <NUM> is connected to and/or configured to monitor communications between the base stations <NUM> and the AMD <NUM>, the AUSF <NUM> and the AMF <NUM>, the SMF <NUM> and the AMF <NUM>, and the like. The ECS <NUM> provides the monitored communications to the stream processing system <NUM>.

The stream processing system <NUM> performs stream processing (also known as event stream processing, data stream processing, or distributed stream processing) which is a programming paradigm which views data streams, or sequences of events in time, as the central input and output objects of computation. Stream processing systems aim to expose parallel processing for data streams and rely on streaming algorithms for efficient implementation. The software stack for these systems includes components such as programming models and query languages, for expressing computation; stream management systems, for distribution and scheduling; and hardware components for acceleration including floating-point units, graphics processing units, and field-programmable gate arrays.

In an embodiment, the stream processing system <NUM> utilizes Apache Kafka, although other implementations are also contemplated. The foregoing description assumes the stream processing system <NUM> is Apache Kafka for illustration purposes. The stream processing system <NUM> includes a raw data collection component <NUM> that streams the raw data to processing units (PU) <NUM>, <NUM>, specifically an N1N2 PU <NUM> and a service based interface (SBI) PU <NUM>. The N1 interface is a transparent interface from the UE <NUM> to the AMF <NUM>. The N2 interface is the control plane interface between an Access Network - NG-RAN or non-3GPP WLAN - and the <NUM> core network <NUM>. The data from the PUs <NUM>, <NUM> is provided to an enrichment function <NUM>, and various events <NUM> are detected based thereon.

The enrichment function <NUM> is configured to perform data enrichment which is a process of merging data from the PUs <NUM>, <NUM>. Enriching Data from numerous sources via joins is a fundamental process in streaming data (and traditional databases). In an embodiment, enrichment is based on exchanges with tickets between processing unit (PU) through message bus (e.g., Kafka) topics. Tickets are produced by the PUs <NUM>, <NUM> as soon as the event <NUM> is ready. Tickets are consumed by the PUs <NUM>, <NUM> when they are received. There is a delay between producing and consuming to counteract Kafka's latency.

The ECS <NUM> is responsible to load balance frames between the PUs <NUM>, <NUM> from the same interfaces. For the SBI, it can use the Internet Protocol (IP) addresses and the Transmission Control Protocol (TCP) ports in ascending order to create the load balancing key. For Stream Control Transmission Protocol (SCTP), it can use the lowest SCTP Verification Tag between uplink and downlink and the SCTP Ports in ascending order to create the load balancing key.

The following are example enrichment topics via the stream processing system <NUM>:.

As is described herein, the data enrichment can be used to obtain data for the association of SUCI to SUPI.

<FIG> are flow diagrams that illustrate examples for the signaling in the enrichment mechanism, including Intra-SBI enrichment: AUSF example (<FIG>), Intra-SBI enrichment: SMF example (<FIG>), Intra-N1N2 enrichment: idle Mobility (<FIG>), Intra-N1N2 enrichment: Soft Mobility (<FIG>), Intra-N1N2 enrichment: Hard Mobility (<FIG>), and Inter-interface enrichment: SBI/N1N2 (<FIG>). Of note, these examples use the PUs <NUM>, <NUM> and focus on intra-PU enrichment as well as inter-PU enrichment.

In <FIG>, there is a UE authentication request with the SUCI (step <NUM>-<NUM>), and this authentication request (SUCI) is provided to the SBI PU <NUM>-<NUM>. There is a UE authentication response with a RAND, AUTN, and token from the AUSF <NUM> to the AMF <NUM> (step <NUM>-<NUM>), leading to an authentication event (SUCI) (step <NUM>-<NUM>). In data enrichment <NUM>, there can be a ticket token for the SUCI (step <NUM>-<NUM>). In another example, there is a <NUM> Authentication and Key Management <NUM>-AKA request (step <NUM>-<NUM>) which is provided to the SBI PU <NUM>-<NUM>. There is an AKA confirmation response (step <NUM>-<NUM>), leading to an AKA confirmation event (SUCI/SUPI) (step <NUM>-<NUM>). In data enrichment <NUM>, there can be a ticket for the SUCI/SUPI (step <NUM>-<NUM>).

In <FIG>, there is a SM context create request (step <NUM>-<NUM>) that is provided to the SBI PU <NUM>-<NUM>, and there is a SM context create response (step <NUM>-<NUM>) that least to a SM context create event (SUPI, permanent equipment identifier (PEI)) (step <NUM>-<NUM>). In data enrichment <NUM>, there can be a ticket token for the SUPI (step <NUM>-<NUM>) and for the SUPI/PEI (step <NUM>-<NUM>). In another example, there is a SM context modify request (step <NUM>-<NUM>), SM context modify response (step <NUM>-<NUM>), leading to a SM context modify event (step <NUM>-<NUM>).

In <FIG>, there is a registration from the base station <NUM>-<NUM> to the AMF <NUM> (step <NUM>-<NUM>) which leads to a registration event (SUCI, GUTI, SUPI) (step <NUM>-<NUM>). In data enrichment <NUM>, there can be a ticket token for the SUPI, GUTI (step <NUM>-<NUM>). In <FIG>, there is a registration from the base station <NUM>-<NUM> to the AMF <NUM> (step <NUM>-<NUM>) which leads to a registration event (SUCI, GUTI, SUPI) (step <NUM>-<NUM>). In data enrichment <NUM>, there can be a ticket token for the SUPI, GUTI (step <NUM>-<NUM>) and for the SUPI/AMD NGAP Id (step <NUM>-<NUM>).

In <FIG>, there is a registration from the base station <NUM>-<NUM> to the AMF <NUM>-<NUM> (step <NUM>-<NUM>) which leads to a registration event (SUCI, GUTI, SUPI) (step <NUM>-<NUM>). In data enrichment <NUM>, there can be a ticket token for the SUPI, GUTI (step <NUM>-<NUM>). In another example, there is a handover required from the base station <NUM>-<NUM> to the AMF <NUM>-<NUM> (step <NUM>-<NUM>) which leads to a handover required event (step <NUM>-<NUM>). In data enrichment <NUM>, there can be a ticket for the SUPI, hash (step <NUM>-<NUM>).

In <FIG>, there is a registration request from the base station <NUM> to the AMF <NUM> (step <NUM>-<NUM>) that is provided to the PU <NUM>. There is UE authentication between the AMF <NUM> and the AUSF <NUM> (step <NUM>-<NUM>) which leads to a UE authentication event (step <NUM>-<NUM>). In data enrichment <NUM>, there can be a ticket token for the SUCI (step <NUM>-<NUM>). Next, there is authentication between the base station <NUM> and the AMF <NUM> (step <NUM>-<NUM>), leading to AKA confirmation between the AMF <NUM> and the AUSF <NUM> (step <NUM>-<NUM>), and an AKA confirmation event (step <NUM>-<NUM>). In data enrichment <NUM>, there can be a ticket for the RAND/SUPI/Kseaf (step <NUM>-<NUM>) and for the SUPI/SUCI (step <NUM>-<NUM>).

<FIG> is a network diagram of the <NUM> core network <NUM>, including the UDM <NUM>, connected to the enhanced capture service (ECS) <NUM> which provides data to the stream processing system <NUM>. Again, the ECS <NUM> captures the raw frames and sends them through a Kafka topic to the PUs <NUM>, <NUM>. Each PU <NUM>, <NUM> writes and reads enrichment tickets in Kafka Topics. Each PU <NUM>, <NUM> writes enriched events in a Kafka topic. The ECS <NUM> loads balances the frames among the SBI PU <NUM> by TCP connections. One TCP connection is identified by using the IP addresses and the TCP Ports in ascending order (direction is not used).

<FIG> are flow diagrams of various example approaches for associating SUPIs and SUCIs, such as implemented through the ECS <NUM>, the stream processing system <NUM>, etc. Variously, <FIG> present non-limiting examples of data enrichment to continually maintain an association between SUPIs and SUCIs for identifying UEs <NUM>, such as via the SUPI catcher <NUM>.

<FIG> is an example embodiment of associating SUPIs and SUCIs by correlation between HTTP/<NUM> Request/response. The correlation between Request and Response is as follows: AUSF IP + UDM IP + AUSF TCP Port + UDM TCP Port + HTTP2 Stream Id as key. According to the 3GPP Specifications, the AUSF <NUM> should request the SUPI associated with a SUCI from the UDM <NUM> by using the UE Auth Data Procedure. It is a simple algorithm that only performs correlation between a request and response of the same procedure. In the UE Auth Data Request, the path in the HTTP/<NUM> header uses the following format "/nudm-ueau/v1/suci-{value}/security-information/generate-auth-data" where value is the SUCI as string. When the SBI PU <NUM> receives this frame, it extracts the SUCI in the path and stores the association SUCI/Request correlation key. In the body of the response, there is a JavaScript Object Notation (JSON) Object that contains a member named "supi" which contains the SUPI with the following format "imsi-{value}" where value is the IMSI as string. When the response frame is received, the SBI PU <NUM> searches for the associated SUCI by using the Response correlation key. Then it decodes the JSON object in the body looking for the key member named "supi". Finally, it associates the SUCI with the SUPI and generates an enrichment ticket. For this processing, there is only one interface to decode. Its limitations include the HTTP2 header compression could lead to unreadable value for the path in the request => No SUCI and the capture point in <NUM> Core between AUSF and UDM is not always available due to collocated equipment.

<FIG> is a second example embodiment of associating SUPIs and SUCIs by correlation between HTTP/<NUM> Request/response using a specific key named "authCtxId" that is present in the response of the procedure of <FIG> and in the request of the second procedure. According to the 3GPP Specifications, during Authentication the AMF <NUM> should interact with the AUSF <NUM> to get the ciphering key associated with the SUCI. The first procedure allows the AMF <NUM> to get from the AUSF <NUM> the inputs for testing the UE <NUM> (RAND + AUTN). The AMF <NUM> provides them to the UE <NUM> through the N1N2 interface. Then the UE <NUM> computes the RES and send it to the AMF <NUM> through the N1N2. The AMF <NUM> sends this RES to the AUSF <NUM> that replies with the Key and the SUPI. So two procedures are involved between the AMF <NUM> and the AUSF <NUM>, the UE-authentication and the <NUM>-aka-confirmation. The correlation between each Request and Response is as follows: AMF IP + AUSF IP + AMF TCP Port + AUSF TCP Port + HTTP2 Stream Id as key. In the UE-authentication request, the SUCI is stored in a member named "supiOrSuci" contains in the JSON object embedded in the body. When the SBI PU receives this frame, it extracts the SUCI in the body and stores the association SUCI with Request correlation Key. In the UE-authentication Response, there is a field in the header named "location" that contains an URI with the following format "{apiRoot}/nausf-auth/v1/ue-authentications/{authCtxld}/<NUM>-aka-confirmation" where apiRoot could be empty, an IP Address or a Full Qualified Domain Name and authCtxId is a random and unique Identifier generated by the AUSF. When the SBI PU receives this frame, it uses the Response correlation key to get the SUCI. Then it extracts the AuthCtxtld and the IP Address for the "<NUM>-aka-confirmation" procedure (shortened as <NUM>-aka IP Address). In a first version, if the apiRoot is empty or a fully qualified domain name (FQDN), the <NUM>-aka IP Address is the AUSF IP Address, else <NUM>-aka IP Address is the IP Address in the apiRoot. In a second version, the <NUM>-aka IP Address is always the AUSF IP Address. Finally, the SBI PU stores the association between SUCI and AuthCtxId + <NUM>-aka IP Address. In the <NUM>-aka-confirmation Request, the path used in the header is a substring from the "location" field seen in the UE-authentication Response. The format of the path is then "/nausf-auth/v1/ue-authentications/{authCtxld}/<NUM>-aka-confirmation". When the SBI PU receives this frame, it parses the path to extract the AuthCtxId and add the destination IP Address to create a key and to search for an associated SUCI. If the SUCI is found, it stores the associated SUCI with the Request correlation key. In the <NUM>-aka-confirmation Response, the SUPI is then mandatory and is in the body as a member named "supi" in the embedded JSON object. When the SBI PU receives this frame, it uses the Response correlation key to get the SUCI. Finally, it associates the SUCI with the SUPI and generates an enrichment ticket.

This second example embodiment has a capture point at the AMF <NUM> not in the <NUM> core network <NUM>. It only has one interface to decode. Its limitations include the following: Location and path parsing for AuthCtxId could be costly. The correlation between two procedures is based on a string search. If the two procedures do not use the same IP addresses, the correlation could fail due to load balancing algorithm in SBI Pipelines. <FIG> shows the interaction between N1N2 and SBI for the second example embodiment.

<FIG> is a third example embodiment of associating SUPIs and SUCIs by adding an enrichment ticket to share SUCI and AuthCtxId between the SBI PU <NUM>. In this embodiment, the IP Address was removed in the correlation key between procedures to avoid an issue in case of multiple addresses for the AUSF <NUM>. When the UE-authentication response is received, the SBI PU <NUM> writes an enrichment ticket for the association AuthCtxId with SUCI. When a SBI PU receives the ticket, it stores this association. When a SBI PU receives the <NUM>-aka-confirmation request, it extracts the AuthCtxId from the path and stores it with the Request Correlation key. When the SBI PU receives the <NUM>-aka-confirmation response, it uses the Response correlation key to get the AuthCtxId and extracts the SUPI. Then it waits during several milliseconds (this delay is configurable) to allow AuthCtxId ticket to arrive. After this wait, the SBI PU searches for the SUCI associated with the AuthCtxId. Finally, it associates the SUCI with the SUPI and generates an enrichment ticket. The capture point is at the AMF <NUM> is not in the <NUM> core network <NUM>. It has only one interface to decode. It addresses the Load balancing limitation of the second example embodiment. Its limitations include Location and path parsing for AuthCtxId could be costly. The correlation between two procedures is based on string search. The delay between the <NUM>-aka-confirmation response and the AuthCtxId ticket should be lower than the configured delay.

<FIG> is a fourth example embodiment of associating SUPIs and SUCIs by a correlation between N1N2 and SBI based on RES. The N1N2 correlation key to link uplink messages in N1N2 uses the RAN-UE-NGAP-ID + SCTP Port + SCTP Verification Tag. The Registration Request message in N1N2 contains the SUCI in the Mobile Identity field. The N1N2 PU extracts it and indexes it with the N1N2 Correlation Key. The Authentication Response contains the RES generated by the UE. The N1N2 PU uses the N1N2 correlation key to get the SUCI and then generates a ticket with the SUCI and the RES. In <NUM>-aka-confirmation Request message contains the same RES in the member "resStar" in the JSON object embedded in the body. The SBI PU extract the Res and associate it with the Request Correlation key. When the SBI PU receives the <NUM>-aka-confirmation response, it uses the Response correlation key to get the RES and extracts the SUPI. Then it waits during several milliseconds (this delay is configurable) to allow RES ticket to arrive. After this wait, the SBI PU searches for the SUCI associated with the RES. Finally, it associates the SUCI with the SUPI and generates an enrichment ticket. The capture point is at the AMF not in the <NUM> Core. There is only one message to process in SBI (<NUM>-Aka-Confirmation response). There are only two messages to process in N1N2 (Registration Request and Authentication Response). Its limitations include: there is a correlation between two interfaces which could cause synchronization issues. The delay between the <NUM>-aka-confirmation response and the RES ticket should be lower than the configured delay.

<FIG> is a flow diagram of an example approach for associating SUPIs and SUCIs, implementing based on AUSF to UDM communications. The foregoing examples described an AMF <NUM> based embodiment. Those skilled in the art will recognize there can be embodiments located in other areas, such as the UDM <NUM>. It is possible to capture AUSF to UDM communication, using the 3GPP specifications.

<FIG> is a flowchart of a process <NUM> for detecting a subscriber permanent identifier (SUPI) from a subscriber concealed identifier (SUCI). The process <NUM> contemplates implementation as a method having steps, via a processing device, the cloud, virtual network functions, and the like, and as instructions stored in a non-transitory computer-readable medium where the instructions, when executed, cause one or more processors to implement the steps.

The process <NUM> includes receiving the SUCI that is a representative of user equipment (UE) of interest and that is encrypted (step <NUM>); checking association data with the received SUCI to determine a corresponding SUPI, wherein the association data includes a mapping of a plurality of SUCIs to a plurality of SUPIs and is maintained over time based on monitoring messages in a <NUM> core network (step <NUM>); and providing the corresponding SUPI (step <NUM>).

The process <NUM> can further include updating the association data based on monitoring one or more of i) exchanges on both sides of an access and mobility management function (AMF) associated with the <NUM> core network and ii) on communication between unified data management (UDM) and an authentication server function (AUSF) (<NUM>). A SUCI changes for a corresponding SUPI based on any changes in associated encryption.

The monitoring exchanges can be via a probe that captures data on the both sides of the AMF and via identifying specific messages on a message bus configured to receive the exchanges from the probe. The monitoring exchanges can include capturing raw frames, stream processing the raw frames, and identifying events via the stream processing. The monitoring exchanges can include identifying the mapping based on correlating a hypertext transfer protocol <NUM> (HTTP/<NUM>) request and response. The monitoring exchanges can include identifying the mapping based on a presence of a specific key in a response.

The monitoring exchanges can include monitoring events in a stream processing system connected to one or more probes in the <NUM> core network. The updating can be based on enrichment events caused in the stream processing system based on correlation of tickets therein.

The receiving can be via catcher equipment that is configured as a base station interfacing with a <NUM> network associated with the <NUM> core network.

<FIG> illustrates an example of an apparatus of an embodiment. The apparatus <NUM> comprises one or more transceivers <NUM> configured to receive and transmit in the <NUM> NR cellular radio network and one or more processors <NUM> configured to cause performance of the apparatus <NUM>. The transceivers may receive and transmit is a wired or wireless manner with network elements of the radio network and/or user equipment of the network.

In an embodiment illustrated, the one or more processors <NUM> comprise one or more memories <NUM> including computer program code <NUM>, and one or more microprocessors <NUM> configured to execute the computer program code <NUM> to cause the performance of the embodiments described above.

In an alternative embodiment, the one or more processors <NUM> comprise a circuitry configured to cause the performance of the apparatus <NUM>.

A non-exhaustive list of implementation techniques for the one or more microprocessors <NUM> and the one or more memories <NUM>, or the circuitry includes, but is not limited to: logic components, standard integrated circuits, application-specific integrated circuits (ASIC), system-on-a-chip (SoC), application-specific standard products (ASSP), microprocessors, microcontrollers, digital signal processors, special-purpose computer chips, field-programmable gate arrays (FPGA), and other suitable electronics structures.

It will be appreciated that some embodiments described herein may include one or more generic or specialized processors ("one or more processors") such as microprocessors; central processing units (CPUs); digital signal processors (DSPs): customized processors such as network processors (NPs) or network processing units (NPUs), graphics processing units (GPUs), or the like; field programmable gate arrays (FPGAs); and the like along with unique stored program instructions (including both software and firmware) for control thereof to implement, in conjunction with certain non-processor circuits, some, most, or all of the functions of the methods and/or systems described herein. Alternatively, some or all functions may be implemented by a state machine that has no stored program instructions, or in one or more application-specific integrated circuits (ASICs), in which each function or some combinations of certain of the functions are implemented as custom logic or circuitry. Of course, a combination of the aforementioned approaches may be used. For some of the embodiments described herein, a corresponding device in hardware and optionally with software, firmware, and a combination thereof can be referred to as "circuitry configured or adapted to," "logic configured or adapted to," etc. perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. on digital and/or analog signals as described herein for the various embodiments.

Moreover, some embodiments may include a non-transitory computer-readable storage medium having computer-readable code stored thereon for programming a computer, server, appliance, device, processor, circuit, etc. each of which may include a processor to perform functions as described and claimed herein. Examples of such computer-readable storage mediums include, but are not limited to, a hard disk, an optical storage device, a magnetic storage device, a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), Flash memory, and the like. When stored in the non-transitory computer-readable medium, software can include instructions executable by a processor or device (e.g., any type of programmable circuitry or logic) that, in response to such execution, cause a processor or the device to perform a set of operations, steps, methods, processes, algorithms, functions, techniques, etc. as described herein for the various embodiments.

Claim 1:
A method (<NUM>) for detecting a subscriber permanent identifier, SUPI, (<NUM>) from a subscriber concealed identifier, SUCI, (<NUM>), the method (<NUM>) comprising steps of:
receiving (<NUM>) the SUCI (<NUM>) that is a representative of user equipment, UE, (<NUM>) of interest and that is encrypted; characterized by
checking (<NUM>) association data with the received SUCI (<NUM>) to determine a corresponding SUPI (<NUM>), wherein the association data includes a mapping of a plurality of SUCIs to a plurality of SUPIs and is maintained over time based on monitoring messages in a <NUM> core network (<NUM>); and
providing (<NUM>) the corresponding SUPI (<NUM>).