Method, system, and computer-readable medium for mitigating 5G roaming spoofing attacks

Abstract

Roaming spoofing attacks can be launched during the N32-c handshake procedure used for inter-PLMN communications in 5G networks. One example solution described herein utilizes a SEPP to mitigate N32-c roaming spoofing attacks by cross-validating sender attributes in the N32-c handshake security capabilities exchange message against the endpoint's identity in the X.509v3 certificate shared during the TLS handshake and the identity of the remote SEPP configured in the SEPP's local database.

Description

Technical Field

[0001] Claims of Priority This application claims the benefit of priority of U.S. Patent Application No. 17 / 129,441, filed on December 21, 2020, U.S. Patent Application No. 17 / 095,420, filed on November 11, 2020, Indian Provisional Application No. 202041047779, filed on November 2, 2020, and Indian Provisional Application No. 202041041754, filed on September 25, 2020, and incorporates by reference all of their disclosures herein.

[0002] Technical Field The subject matter described herein relates to improving security in 5G communication networks. In particular, the subject matter described herein relates to methods, systems, and computer-readable media for mitigating 5G roaming spoofing attacks.

Background Art

[0003] Background In a 5G telecommunications network, a network node that provides a service is referred to as a producer NF (network function). A network node that uses a service is referred to as a consumer NF. A network function can be either a producer NF or a consumer NF depending on whether it is using or providing a service.

[0004] A given producer NF may have multiple service endpoints. Here, a service endpoint is a connection point of one or more NF instances hosted by the producer NF. A service endpoint is identified by a combination of an IP (Internet Protocol) address and a port number, or a fully qualified domain name that is translated into an IP address and a port number on the network node hosting the producer NF. An NF instance is an instance of a producer NF that provides a service. A given producer NF may include two or more NF instances. Note that multiple NF instances can share the same service endpoint.

[0005] The producer NF is registered with the NRF (Network Function Repository Function). The NRF holds service profiles of available NF instances that identify the services supported by each NF instance. A consumer NF can subscribe to receive information about producer NF instances registered with the NRF.

[0006] In addition to the consumer NF, another type of network node that can subscribe to receive information about NF service instances is the SCP (Service Communicatio n Proxy). The SCP subscribes via the NRF and obtains reachability and service profile information regarding producer NF service instances. The consumer NF SCP connects to SCP which distributes the traffic load among producer NF service instances that provide the requested service, or directly routes the traffic to the destination producer NF instance.

[0007] In addition to the SCP, examples of intermediate proxy nodes or other groups of network nodes for routing traffic between a producer NF and a consumer NF include a SEPP (Security Edge Protection Proxy), a service gateway, and nodes in a 5G service mesh. The SEPP is a network node used to protect control plane traffic exchanged between different 5G PLMNs (Public Land Mobile Networks). Thus, the SEPP performs message filtering, policing, and topology hiding for all API (Application Programming Interface) messages.

[0008] In the current 5G network architecture, there is one vulnerability on the N32 interface, which is the interface between SEPPs. As described above, the SEPP functions as a security screening node for the PLMN (Public Land Mobile Network). The N32 control or N32-c interface is used to exchange control messages with a remote SEPP. The start of communication on the N32-c interface includes a TLS (Transport Layer Security) handshake procedure to establish a TLS connection. Also, the start of communication includes an N32-c security function negotiation procedure. The N32-c security function negotiation procedure includes the exchange of N32-c messages. During the N32-c security function negotiation procedure, the identity of the remote endpoint is not verified. Also, the remote endpoint does not verify the identity of the initiating SEPP. Since verification is not performed on the N32-c interface, the initiating SEPP and the responding SEPP are vulnerable to impersonation attacks where a third party impersonates one end of the N32-c communication to gain unauthorized access to the PLMN.

[0009] In view of these and other problems, there is a need for methods, systems, and computer-readable media for mitigating 5G roaming impersonation attacks. SUMMARY OF THE INVENTION

Means for Solving the Problem

[0010] Overview A method for mitigating 5G roaming spoofing attacks involves the SEPP (Security Edge Protection Proxy) obtaining a first identifier of a first node from a TLS (Transport Layer Security) message from the first node. This method further involves the SEPP obtaining a second identifier of the first node from an N32-c security function negotiation message from the first node. The method further includes comparing the first identifier and the second identifier of the first node. The method further includes determining that the first identifier and the second identifier do not match, and in response, determining that the second identifier of the first node is invalid. The method further includes blocking communication between the first node and a PLMN (Public Land Mobile Network) in response to determining that the second identifier of the first node is invalid.

[0011] According to another aspect of the subject matter described herein, obtaining the first identifier of the first node from the TLS message includes obtaining the first identifier from a certificate included in the TLS certificate message.

[0012] According to another aspect of the subject matter described herein, the certificate includes an X.509 certificate. According to another aspect of the subject matter described herein, obtaining the first identifier of the first node is the alias of the subject of the X.509 certificate Expansion including extracting the FQDN (Fully Qualified Domain Name) of the first node.

[0013] According to another aspect of the subject matter described herein, the SEPP is the responding-side SEPP in the N32-c security function negotiation procedure, and obtaining the second identifier of the first node includes extracting the second identifier of the first node from the sender attribute of the SecNegotiateReqData information element of the N32-c security function negotiation message.

[0014] According to another aspect of the subject matter described herein, the SEPP is the initiating SEPP in the N32-c security function negotiation procedure, and obtaining the second identifier of the first node includes extracting the second identifier of the first node from the sender attribute of the SecNegotiationRspData information element of the N32-c security function negotiation message.

[0015] According to another aspect of the subject matter described herein, a method for mitigating 5G roaming security attacks includes the SEPP obtaining the first identifier of the second node from a TLS handshake message from the second node, obtaining the second identifier of the second node from an N32-c security function negotiation message from the second node, comparing the first identifier and the second identifier of the second node, determining that the first identifier and the second identifier match, performing a lookup in the peer SEPP database using one of the first identifier and the second identifier of the second node to find a matching identifier in the peer SEPP database, and permitting communication between the PLMN and the second node in response to determining that the first identifier and the second identifier of the second node match and that a matching identifier exists in the peer SEPP database.

[0016] According to another aspect of the subject matter described herein, a method for mitigating 5G roaming security attacks includes the SEPP obtaining a first identifier of a second node from a TLS handshake message from the second node, the SEPP obtaining a second identifier of the second node from an N32-c security function negotiation message from the second node, comparing the first identifier and the second identifier of the second node, determining that the first identifier and the second identifier match, performing a lookup in a peer SEPP database using one of the first identifier and the second identifier of the second node and not finding a matching identifier in the peer SEPP database, and in response to determining that the first identifier and the second identifier of the second node match and that there is no matching identifier in the peer SEPP database, blocking inter-PLMN communication from the second node.

[0017] According to another aspect of the subject matter described herein, a system for mitigating 5G roaming impersonation attacks includes a SEPP (Security Edge Protection Proxy) that includes at least one processor and a memory. The system further includes a 5G roaming impersonation attack mitigation module implemented by the at least one processor. The 5G roaming impersonation attack mitigation module obtains a first identifier of a first node from a TLS (Transport Layer Security) message from the first node, obtains a second identifier of the first node from an N32-c security function negotiation message from the first node, compares the first identifier and the second identifier of the first node, determines that the first identifier and the second identifier do not match, and in response thereto, determines that the second identifier of the first node is invalid, and in response to determining that the second identifier of the first node is invalid, is configured to block inter-PLMN (Public Land Mobile Network) communication with the first node.

[0018] According to another aspect of the subject matter described herein, the 5G roaming impersonation attack mitigation module is configured to obtain the first identifier of the first node from a certificate included in a TLS certificate message.

[0019] According to another aspect of the subject matter described herein, the 5G roaming spoofing attack mitigation module is configured to obtain a first identifier of a first node by extracting the FQDN (Fully Qualified Domain Name) of the first node from an alias of the subject of a certificate. Expansion

[0020] According to another aspect of the subject matter described herein, the SEPP is the responder-side SEPP in the N32-c security function negotiation procedure, and the 5G roaming spoofing attack mitigation module is configured to obtain a second identifier of the first node by extracting the second identifier of the first node from the sender attribute of the SecNegotiateReqData information element of the N32-c security function negotiation message.

[0021] According to another aspect of the subject matter described herein, the SEPP is the initiating-side SEPP in the N32-c security function negotiation procedure, and the 5G roaming spoofing attack mitigation module is configured to obtain a second identifier of the first node by extracting the second identifier of the first node from the sender information element attribute of the SecNegotiateRspData information element of the N32-c security function negotiation message.

[0022] According to another aspect of the subject matter described herein, the 5G roaming spoofing attack mitigation module obtains a first identifier of a second node from a TLS handshake message from the second node, obtains a second identifier of the second node from an N32-c security function negotiation message from the second node, compares the first identifier and the second identifier of the second node, determines that the first identifier and the second identifier match, performs a lookup in the peer SEPP database using one of the first identifier and the second identifier of the second node, searches for a matching identifier in the peer SEPP database, and in response to determining that the first identifier and the second identifier of the second node match and a matching identifier exists in the peer SEPP database, is configured to permit PLMN-to-PLMN communication with the second node.

[0023] According to another aspect of the subject matter described herein, the 5G roaming spoofing attack mitigation module obtains a first identifier of a second node from a TLS handshake message from the second node, obtains a second identifier of the second node from an N32-c security function negotiation message from the second node, compares the first identifier and the second identifier of the second node, determines that the first identifier and the second identifier match, performs a lookup in the peer SEPP database using one of the first identifier and the second identifier of the second node, fails to find a matching identifier in the peer SEPP database, and in response to determining that the first identifier and the second identifier of the second node match and no matching identifier exists in the peer SEPP database, is configured to block PLMN-to-PLMN communication from the second node.

[0024] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium storing executable instructions is provided. The executable instructions, when executed by a processor of a computer, control the computer to perform steps. The steps include a step in which a SEPP (Security Edge Protection Proxy) obtains a first identifier of a first node from a TLS (Transport Layer Security) message from the first node. The steps further include a step in which the SEPP obtains a second identifier of the first node from an N32-c security function negotiation message from the first node. The steps further include a step of comparing the first identifier and the second identifier of the first node, and a step of determining that the first identifier and the second identifier do not match, and in response thereto, determining that the second identifier of the first node is invalid. The steps further include a step of blocking communication between the first node and a PLMN (Public Land Mobile Network) in response to determining that the second identifier of the first node is invalid.

[0025] The subject matter described in this specification may be implemented in hardware, software, firmware, or any combination thereof. Thus, the terms "function," "node," or "module," as used herein, refer to hardware (which may also include software and / or firmware components) for implementing the described features. In one exemplary embodiment, the subject matter described in this specification may be implemented using a computer-readable medium storing computer-executable instructions. When executed by a processor of a computer, the instructions control the computer to perform steps. Exemplary computer-readable media suitable for implementing the subject matter described in this specification include non-transitory computer-readable media such as disk storage devices, chip storage devices, programmable logic circuits, and application-specific integrated circuits. In addition, the computer-readable media for implementing the subject matter described in this specification may be located on one device or one computing platform, or may be distributed among multiple devices or multiple computing platforms.

[0026] Reference is now made to the accompanying drawings to describe the subject matter described in this specification.

Brief Description of the Drawings

[0027]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Mode for Carrying Out the Invention

[0028] Detailed Description The subject matter described herein relates to a method, system, and computer-readable medium for mitigating 5G roaming spoofing attacks. FIG. 1 is a block diagram showing an exemplary 5G system network architecture. The architecture of FIG. 1 includes an NRF100 and an SCP101 that may be located in the same HPLMN (Home Public Land Mobile Network). As described above, the NRF100 holds profiles of available producer NF service instances and the services they support, enabling a consumer NF or SCP to subscribe to new / updated producer NF service instances or be notified about the registration of new / updated producer NF service instances. Also, the SCP101 may support service detection and selection of producer NF instances. The SCP101 may perform load balancing for connections between a consumer NF and a producer NF. In addition, using the techniques described herein, the SCP101 may perform preferred selection and routing based on the location of the NF.

[0029] The NRF100 is a repository of service profiles of NFs or producer NF instances. To communicate with a producer NF instance, a consumer NF or SCP has to obtain the NF or service profile, or the producer NF instance, from the NRF100. The NF or service profile is a JSON (JavaScript (registered trademark) Object Notation) data structure defined in 3GPP (registered trademark) (Third Generation Partnership Project) TS (Technical Specification) 29.510. The definition of the NF or service profile includes at least one of a FQDN (Fully Qualified Domain Name), an IPv4 (IP (Internet Protocol) version 4) address, or an IPv6 (IP version 6) address. In Figure 1, all nodes (other than the NRF100) can be either a consumer NF or a producer NF, depending on whether they are a requesting-side service or a providing-side service. In the illustrated example, these nodes include a PCF (Policy Control Function) 102 that performs policy-related operations in the network, a UDM ( Unified Data Management) function 104 that manages user data, and an AF (Application Function) 106 that provides application services. The nodes shown in Figure 1 further include an SMF (Session Management Function) 108 that manages the session between the AMF (Access And Mobility Management Function) 110 and the PCF 102. The AMF 110 performs mobility management operations similar to those performed by the MME (Mobility Management Entity) in a 4G network. The AUSF (Authentication Server Function) 112 performs authentication services for UEs (User Equipments), such as a UE 114 that wants to access the network.

[0030] The NSSF (Network Slice Selection Function) 116 provides a network slicing service for devices that want to access specific network functions and characteristics related to network slices. The NEF (Network Exposure Function) 118 provides an API (Application Programming Interface) for application functions that want to obtain information about IoT (Internet of Things) devices and other UEs attached to the network. The NEF 118 performs a function similar to the SCEF (Service Capability Exposure Function) in a 4G network.

[0031] The RAN (Radio Access Network) 120 connects the UE (User Equipment) 114 to the network via a wireless link. The radio access network 120 can be accessed using a gNB (g-NodeB) (not shown in FIG. 1) or other wireless access points. The UPF (User Plane Function) 122 can support various proxy functions related to user plane services. An example of such a proxy function is the MPTCP (Multipath Transmission Control Protocol) proxy function. The UPF 122 can also support a performance measurement function. The performance measurement function can be used by the UE 114 to obtain measurement values of network performance. FIG. 1 also shows a DN (Data Network) 124 to which the UE accesses data network services such as Internet services.

[0032] SEPP126 filters the received traffic from another PLMN and performs topological concealment of the traffic going out from the home PLMN. SEPP126 can communicate with the SEPP in the external PLMN that manages the security of the external PLMN. Thus, the traffic between NFs in different PLMNs can cross two SEPP functions, namely, the SEPP function for the home PLMN and the SEPP function for the external PLMN.

[0033] As described above, one problem with the existing 5G architecture is that the N32-c handshake does not verify the ID of the remote endpoint. If the ID of the endpoint is not verified, a malicious SEPP may impersonate the identity of another SEPP to launch a security attack. The responding SEPP does not verify whether it has received the N32 -c handshake message from the legitimate initiating SEPP. Similarly, the initiating SEPP does not verify whether the N32-c handshake message is sent to the legitimate responding SEPP. The subject matter described herein addresses these and other issues by cross-verifying the N32-c identity of the SEPP with the identity of the TLS layer and the peer SEPP identity stored in the peer SEPP database maintained by the initiating SEPP and the responding SEPP.

[0034] Figure 2 is a diagram showing the occurrence of handshakes between SEPPs on the N32 interface. In Figure 2, the initiating SEPP 126A and the responding SEPP 126B exchange TLS handshake messaging and N32-c security function negotiation messaging on the N32 interface. The TLS handshake includes the exchange of certificates. The certificate can be used to verify the identity of the sender in the TLS layer and is difficult to forge. However, there is no cross-verification between the identity exchanged during the TLS handshake and the identity exchanged during the N32-c security function negotiation messaging. As a result, both the initiating SEPP 126A and the responding SEPP 126B are vulnerable to roaming impersonation attacks. A roaming impersonation attack is an attack in which an attacker poses as a node in a network where a mobile phone subscriber is roaming. If an attacker impersonates the identity of a node during the N32-c security function negotiation procedure, the attacker can impersonate the identity of the SEPP that provides services to the subscriber in the network where the subscriber is roaming.

[0035] Figure 3 is a diagram showing an example of a hacker SEPP 300 that emulates a legitimate SEPP. In Figure 3, the SEPP 126A located in PLMN1 believes it is communicating with the peer SEPP 126B located in PLMN2. However, there is a possibility that the hacker SEPP 300 is emulating the legitimate SEPP 126B to establish N32-c communication with the SEPP 126A. Once such communication is established, the hacker SEPP 300 will be able to obtain confidential subscriber information from PLMN1 and / or be able to cause other types of attacks such as DoS (Denial of Service) attacks on PLMN1.

[0036] To avoid or reduce the likelihood of a spoofing attack succeeding on the N32-c interface, SEPPs 126A and 126B can cross-verify the N32-c identity with the TLS identity and can further verify the N32-c identity with the peer SEPP identity using a configured peer SEPP database. FIG. 4 is a diagram showing an exemplary cross-verification that the initiating SEPP 126A and the responding SEPP 126B can perform. Referring to FIG. 4, the initiating SEPP 126A and the responding SEPP 126B exchange TLS handshake messages on the N32-c interface to establish a TLS connection. The TLS handshake includes the exchange of a client hello message and a server hello message, followed by the exchange of certificate messages. The certificate message includes the sender's X.509 certificate. The sender's identity is included in the X.509 certificate and is difficult to spoof because it is signed by a certificate authority.

[0037] Accordingly, in one example, the sender's identity extracted from the X.509 certificate can be used to cross-verify the sender's N32-c identity. The TLS handshake protocol is defined in RFC (Request for Comments) 5246 of the IETF (Internet Engineering Task Force) and includes the exchange of certificate messages by both ends of the TLS connection. The structure of the TLS handshake messages (including the certificate message) defined in IETF RFC5246 is shown as follows.

[0038]

Table 1

[0039] As shown by the structure of the TLS handshake message, one of the defined types of handshake messages is the certificate message. The certificate message includes the client certificate or the server certificate depending on whether the sender is functioning as a client or a server. When establishing secure TLS communication over the N32-c interface, a common TLS or m-TLS is used where both ends of the TLS connection receive and verify the X.509 certificate of the other end. IETF RFC5246 indicates that the type of certificate must be X.509v3 unless explicitly negotiated. In the examples described herein, X.509v3 certificates are used as an example, but the subject matter described herein is not limited to verifying the sender's N32-c identity using the sender's identity extracted from X.509v3. The format of the X.509v3 certificate is defined in IETF RFC3280. According to IETF RFC3280, an extension or parameter that an X.509v3 certificate may contain is the subject alternative name extension. The subject alternative name extension is defined as follows.

[0040] The subject alternative name extension allows additional identities to be bound to the subject of the certificate. Defined options include Internet email addresses, DNS names, IP addresses, and URIs (Uniform Resource Identifiers). There are also other options that include fully local definitions. Multiple name formats and multiple instances of each name format may be included. Whenever such identities are bound to a certificate, the subject alternative name (issuer alternative name) extension must be used. However, a DNS name may be represented in the subject field using the domainComponent attribute as described in Section 4.1.2.4.

[0041] Since the subject alternative name is ultimately considered to be bound to the public key, all parts of the subject alternative name must be verified by the CA.

[0042] As described above, the subject alternative name extension of an X.509v3 certificate may include a DNS name, an IP address, or a URI that identifies the subject of the certificate and is verified by the certification authority. Since the subject alternative name is verified by the certification authority, it is difficult to forge the subject alternative name. However, simply ensuring that the sender has a valid X.509 certificate does not verify the sender's identity at the N32-c application level. To perform such cross-verification, the initiating side SEPP126A and the responding side SEP P1 26B may extract identities from the N32-c message and compare these identities with the identities extracted from the X-509 certificates shared during the TLS handshake. If these identities match, SEPP126A and 126B may perform a further verification step of comparing the identities extracted from either the N32-c message or the TLS message with the database of configured peer SEPP identities. If any verification fails, the SEPP may block the PLMN communication with the remote node and identify the remote node as an attacker.

[0043] Returning to FIG. 4, after TLS handshake messages are exchanged between the initiating SEPP 126A and the responding SEPP 126B and a TLS connection is established, the initiating SEPP 126A sends an HTTP POST message to the responding SEPP 126B. The HTTP POST message includes a SecNegotiateReqData information element. The SecNegotiateReqData information element includes a sender information element that includes the sender's FQDN. The responding SEPP 126B receives the HTTP POST message, extracts the sender's FQDN from the SecNegotiateReqData information element, and verifies the FQDN against the identity of the sender obtained from the sender's X.509 certificate. In this case, assume that these identities match. Therefore, in the next step, the responding SEPP 126B performs a lookup in the peer SEPP database held by the responding SEPP 126B to search for the identity of the sender. Since it is assumed that the identity of the initiating SEPP 126A exists on the peer SEPP database of the responding SEPP 126B, from the perspective of the responding SEPP 126B, both verifications are successful, and as a result, the responding SEPP 126B permits inter-PLMN communication from the initiating SEPP 126A.

[0044] Continuing to refer to the message flow in FIG. 4, the responder SEPP 126B sends an HTTP 200 OK message to the initiator SEPP 126A. The HTTP 200 OK message includes the N32-cSecNegotiateRspData information element including the sender attribute. In FIG. 5, the sender attribute holds the FQDN of the responder SEPP 126B. The initiator SEPP 126B receives the HTTP 200 OK message, extracts the FQDN of the sender from the sender attribute of the SecNegotiateRspData information element, and compares this FQDN with the FQDN of the sender extracted from the TLS certificate message. Assume that these FQDNs match in this case. Therefore, the initiator SEPP 126A performs a further verification step of determining whether the identity of the sender exists in the peer SEPP database held by the initiator SEPP 126A. Assume that the identity of the sender exists in this example, so the initiator SEPP 126A permits the PLMN - to - PLMN communication with the responder SEPP 126B.

[0045] FIG. 5 is a diagram for explaining the case where the hacker SEPP300 is the initiating SEPP regarding the N32-c security function negotiation procedure. In FIG. 5, the hacker SEPP300 starts a TLS handshake with the responder SEPP126B. The responder SEPP126B extracts the X.509 certificate from the TLS handshake message and extracts the identity presented by the hacker SEPP300 in the certificate. The hacker SEPP300 includes the identity in the N32-cSecNegotiateReqData information element of the N32-c security function negotiation message (in the illustrated example, an HTTP POST message) and transmits it to the responder SEPP126B. The responder SEPP126B extracts the identity presented by the hacker SEPP300 in the N32-cSecNegotiateReqData information element of the N32-c security function negotiation message and compares it with the identity extracted from the certificate obtained from the TLS message, which is the identity extracted from the SecNegotiateReqData information element of the N32-c security function negotiation message. In this case, these identities do not match. As a result, the responder SEPP126B determines that the verification has failed. Therefore, the responder SEPP126B blocks subsequent communication from the hacker SEPP300.

[0046] FIG. 6 is a diagram showing a case where the SEPP that executes the cross-verification of the TLS identity and the N32-c identity in the N32-c security function negotiation transaction is the initiating SEPP. In FIG. 6, the initiating SEPP receives a TLS message and an N32-c message from the hacker SEPP 300. The initiating SEPP 126A obtains an X.509 certificate from one of the TLS handshake messages. The initiating SEPP 126A extracts the identity from the X.509 certificate and compares this identity with the identity received from the hacker SEPP 300 in the SecNegotiateRspData information element of the N32-c security function negotiation message (in the illustrated example, an HTTP 200 OK message). In this case, these identities do not match. Therefore, the initiating SEPP 126A blocks subsequent communication with the hacker SEPP 300.

[0047] FIG. 7 is a block diagram showing an exemplary architecture of SEPP126A or 126B. SEPP126A or 126B includes at least one processor 700 and a memory 702. SEPP126A or 126B further includes a 5G roaming spoofing mitigation module 704 that executes these steps described herein to cross-verify the identity in the N32-c message with the identity extracted from the TLS message. SEPP126A or 126B further includes a peer SEP database 706 composed of the identities of peer SEPPs for which inter-PLMN communication is permitted. The 5G roaming spoofing mitigation module 704 may be implemented by the processor 700 and may perform a cross-check of the N32-c identity presented by the remote node in light of the peer SEPP identities stored in the database 706. If the identity of the remote node presented in the N32-c security function negotiation message does not exist in the database 706, or if the cross-check with the TLS identity fails, the 5G roaming spoofing mitigation module 704 may block the inter-PLMN communication with the remote node. If both identity cross-checks are successful, the 5G roaming spoofing mitigation module 704 may permit the inter-PLMN communication with the remote node.

[0048] FIG. 8 is a flowchart showing an exemplary method for mitigating 5G spoofing attacks. Referring to FIG. 8, at step 800, the SEPP obtains a first identifier from the TLS message from the first node. For example, the originating or responding SEPP126A or 126B may extract the identity of the transmitting node from the alternative ID field of the X.509 certificate in the TLS message received from the transmitting node. The TLS message may be a certificate message exchanged with the remote node as part of the TLS handshake procedure used to establish a TLS connection with the remote node.

[0049] In step 802, SEPP obtains the second identifier of the first node from the N32-c security function negotiation message from the first node. For example, if SEPP is the initiating SEPP for an N32-c security function negotiation transaction, the initiating SEPP may extract the N32c identity from the sender ID attribute of the N32-cSecNegotiateRspData information element of the HTTP 200 OK message from the remote node. If SEPP is the responding SEPP for an N32-c security function negotiation transaction, the responding SEPP may extract the N32c identity from the sender ID attribute of the N32-cSecNegotiateReqData information element of the HTTP POST message from the remote node. Tables 1 and 2 shown below correspond to Table 6.1.5.2.2.1 and Table 6.5.1.2.2 of 3GPP TS29.573, which show the attributes that may be included in the SecNegotiateReqData and SecNegotiateRspData information elements, which are part of the N32-c security function negotiation.

[0050]

Table 2

[0051]

Table 3

[0052] As can be seen from Tables 1 and 2, the sender attribute is an essential parameter of the SecNegotiateReqData information element and the SecNegotiateRspData information element, and includes the FQDN of the SEPP that sends the request or response. It is this FQDN that can be cross-validated with the identity of the TLS layer.

[0053] In step 804, SEPP compares the first identifier and the second identifier of the first node. For example, SEPP may compare the TLS identifier extracted from the X.509 certificate with the N32-c identifier extracted from the SecNegotiateRspData information element or the SecNegotiateReqData information element of the N32-c security function negotiation message.

[0054] In step 806, if these identifiers do not match, the control proceeds to step 808. In step 808, SEPP classifies the second (N32-c) identity of the first node as invalid. Then, the control proceeds to step 810. In step 810, SEPP blocks the inter-PLMN communication from the first node.

[0055] When returning to step 806, if the TLS identity and the N32-c application layer identity match, the control proceeds to step 812. In step 812, SEPP performs a lookup in the peer SEPP database to search for the identity of the first node. Since the TLS layer identity and the N32c (application) layer identity match in step 806, the lookup can be performed using either the TLS layer identity or the N32-c layer identity. A peer SEPP database having the identities of SEPPs permitted to communicate by a given SEPP in the network operator's network can be provisioned by the operator. Such SEPPs are referred to herein as peer SEPPs because they can be associated with the PLMNs of peer network operators.

[0056] In step 814, if the identity exists in the peer SEPP database, the control proceeds to step 816. In step 816, SEPP permits the PLMN communication with the first node. If the identity does not exist in the database, the control proceeds to step 810. In step 810, SEPP blocks the PLMN communication with the first node.

[0057] The subject matter described herein improves the network security between SEPP and PLMN by performing cross-verification of identities exchanged between SEPPs in different network protocol layers. By comparing the N32-c identity with the TLS layer identity that is difficult to forge, the SEPP described herein reduces the possibility of a successful impersonation attack during the N32-c security function exchange procedure. In addition, since the cross-verification steps described herein can be executed by both the initiating side SEPP and the responding side SEPP in the N32 security function negotiation, it reduces the possibility of an attacker successfully impersonating either end of the N32-c connection.

[0058] The entire disclosure content of each of the following documents is incorporated herein by reference. Document 1. IETF RFC5246; The Transport Layer Security (TLS) Protocol, Version 1.2; August 2008 2. IETF RFC3280; Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002. 3. 3GPP TS 29.573; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Public Land Mobile Network (PLMN) Interconnection; Stage 3 (Release 16) V16.3.0 (2020-07) 4. 3GPP TS 33.501; 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Security Architecture and Procedures for the 5G System; (Release 16), V16.3.0 (2020-07). 5. 3GPP TS 29.510; 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; 5G System; Network Function Repository Services; Stage 3 (Release 16), V16.4.0 (2020-07). It will be understood that various details of the presently disclosed subject matter may be changed without departing from the scope of the presently disclosed subject matter. Further, the above description is illustrative only and not restrictive.

Claims

1. A method for mitigating 5G roaming spoofing attacks, comprising: an SEPP (Security Edge Protection Proxy) obtaining a first identifier of the first node from a TLS (Transport Layer Security) message from the first node; the SEPP obtaining a second identifier of the first node from an N32-c security function negotiation message from the first node; comparing the first identifier and the second identifier of the first node; determining that the first identifier and the second identifier do not match, and in response, determining that the second identifier of the first node is invalid; and in response to determining that the second identifier of the first node is invalid, blocking communication between the first node and a PLMN (Public Land Mobile Network).

2. The method according to claim 1, wherein obtaining the first identifier of the first node from the TLS message includes obtaining the first identifier from a certificate included in the TLS certificate message.

3. The method according to claim 2, wherein the certificate includes an X.509 certificate.

4. The method according to claim 3, wherein obtaining the first identifier of the first node includes extracting the FQDN (Fully Qualified Domain Name) of the first node from an alias extension of the subject of the X.509 certificate.

5. The SEPP is a responding-side SEPP in an N32-c security function negotiation procedure, and obtaining the second identifier of the first node includes extracting the second identifier of the first node from the sender attribute of the SecNegotiateReqData information element of the N32-c security function negotiation message. The method according to any one of claims 1 to 4.

6. The SEPP is a starting-side SEPP in an N32-c security function negotiation procedure, and obtaining the second identifier of the first node includes extracting the second identifier of the first node from the sender attribute of the SecNegotiationRspData information element of the N32-c security function negotiation message. The method according to any one of claims 1 to 4.

7. The SEPP obtains the first identifier of the second node from a TLS handshake message from the second node, obtains the second identifier of the second node from an N32-c security function negotiation message from the second node, compares the first identifier and the second identifier of the second node, determines that the first identifier and the second identifier match, performs a lookup in a peer SEPP database using one of the first identifier and the second identifier of the second node, and searches for a matching identifier in the peer SEPP database, and permits inter-PLMN communication with the second node in response to determining that the first identifier and the second identifier of the second node match and that a matching identifier exists in the peer SEPP database, the method according to any one of claims 1 to 6.

8. The SEPP obtains the first identifier of the second node from a TLS handshake message from the second node, the SEPP obtains the second identifier of the second node from an N32-c security function negotiation message from the second node, compares the first identifier and the second identifier of the second node, determines that the first identifier and the second identifier match, performs a lookup in a peer SEPP database using one of the first identifier and the second identifier of the second node and is unable to find a matching identifier in the peer SEPP database, and blocks inter-PLMN communication from the second node in response to determining that the first identifier and the second identifier of the second node match and that a matching identifier does not exist in the peer SEPP database, the method according to any one of claims 1 to 7.

9. A system for mitigating 5G roaming spoofing attacks, comprising a SEPP (Security Edge Protection Proxy) including at least one processor and a memory, and a 5G roaming spoofing attack mitigation module implemented by the at least one processor, the 5G roaming spoofing attack mitigation module obtains the first identifier of the first node from a TLS (Transport Layer Security) message from the first node, Obtain the second identifier of the first node from the N32-c security function negotiation message from the first node, Compare the first identifier of the first node with the second identifier, Determine that the first identifier and the second identifier do not match, and in response, determine that the second identifier of the first node is invalid, A system configured to block communication between the first node and a PLMN (Public Land Mobile Network) in response to determining that the second identifier of the first node is invalid.

10. The 5G roaming spoofing attack mitigation module is configured to obtain the first identifier of the first node from a certificate included in a TLS certificate message, according to the system of claim 9.

11. The certificate includes an X.509 certificate, according to the system of claim 10.

12. The 5G roaming spoofing attack mitigation module is configured to obtain the first identifier of the first node by extracting the FQDN (Fully Qualified Domain Name) of the first node from an alias extension of the subject of the certificate, according to the system of claim 11.

13. The SEPP is a SEPP on the response side in the N32-c security function negotiation procedure, and the 5G roaming spoofing attack mitigation module is configured to obtain the second identifier of the first node by extracting the second identifier of the first node from the sender attribute of the SecNegotiateReqData information element of the N32-c security function negotiation message, according to the system of any one of claims 9 to 12.

14. The SEPP is a SEPP on the start side in the N32-c security function negotiation procedure, and the 5G roaming spoofing attack mitigation module is configured to obtain the second identifier of the first node by extracting the second identifier of the first node from the sender information element attribute of the SecNegotiateRspData information element of the N32-c security function negotiation message, according to the system of any one of claims 9 to 12.

15. The 5G roaming spoofing attack mitigation module is Obtain a first identifier of the second node from a TLS handshake message from the second node, Obtain a second identifier of the second node from an N32-c security function negotiation message from the second node, Compare the first identifier and the second identifier of the second node, Determine that the first identifier and the second identifier match, Execute a lookup in the peer SEPP database using one of the first identifier and the second identifier of the second node, and find a matching identifier in the peer SEPP database, The system according to any one of claims 9 to 14, configured to permit inter-PLMN communication with the second node in response to determining that the first identifier and the second identifier of the second node match and that a matching identifier exists in the peer SEPP database.

16. The 5G roaming spoofing attack mitigation module, Obtain a first identifier of the second node from a TLS handshake message from the second node, Obtain a second identifier of the second node from an N32-c security function negotiation message from the second node, Compare the first identifier and the second identifier of the second node, Determine that the first identifier and the second identifier match, Execute a lookup in the peer SEPP database using one of the first identifier and the second identifier of the second node, and fail to find a matching identifier in the peer SEPP database, The system according to any one of claims 9 to 15, configured to block inter-PLMN communication from the second node in response to determining that the first identifier and the second identifier of the second node match and that a matching identifier does not exist in the peer SEPP database.

17. A computer program comprising executable instructions that, when executed by a processor of a computer, control the computer to execute the method according to any one of claims 1 to 8.

Images