Methods, systems, and computer-readable media for mitigating 5g roaming spoofing attacks

Abstract

A roaming impersonation attack can be initiated in the N32-c handshake procedure used for inter-PLMN communication in 5G networks. An example solution described herein mitigates N32-c roaming impersonation attacks using a SEPP by cross-verifying the sender attribute present in the N32-c handshake security capabilities exchange message against the endpoint identity in the X.509v3 certificate shared during the TLS handshake and the remote SEPP identity configured in the local database of the SEPP.

Description

[0001] Priority Statement

[0002] This application claims priority to U.S. Patent Application Serial No. 17 / 129,441, filed December 21, 2020; U.S. Patent Application Serial No. 17 / 095,420, filed November 11, 2020; Indian Provisional Patent Application Serial No. 202041047779, filed November 2, 2020; and Indian Provisional Patent Application Serial No. 202041041754, filed September 25, 2020, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0003] This article describes topics related to enhancing security in 5G communication networks. More specifically, it describes methods, systems, and computer-readable media for mitigating 5G roaming spoofing attacks. Background Technology

[0004] In 5G telecommunications networks, network nodes that provide services are called producer network functions (NFs). Network nodes that consume services are called consumer NFs. A network function can be either a producer NF or a consumer NF, depending on whether it is consuming or providing services.

[0005] A given producer NF can have multiple service endpoints, where a service endpoint is a contact point used for one or more NF instances hosted by the producer NF. A service endpoint is identified by a combination of Internet Protocol (IP) address and port number, or by a fully qualified domain name that resolves to an IP address and port number on the network node hosting the producer NF. An NF instance is an instance of the producer NF that provides a service. A given producer NF can include more than one NF instance. It should also be noted that multiple NF instances can share the same service endpoint.

[0006] Producer NFs register with the Network Functions Store (NRF). The NRF maintains service profiles of available NF instances that identify the services supported by each NF instance. Consumer NFs can subscribe to receive information about producer NF instances that have registered with the NRF.

[0007] Besides consumer NFs, another type of network node that can subscribe to receive information about NF service instances is the Service Communication Agent (SCP). The SCP subscribes to the NRF and obtains reachability and service profile information about producer NF service instances. Consumer NFs connect to the Service Communication Agent, which load balances traffic between producer NF service instances providing the required services, or directly routes traffic to the destination producer NF instance.

[0008] Besides SCPs, other examples of intermediate proxy nodes or groups of network nodes that route traffic between producer and consumer NFs include Secure Edge Protection Proxies (SEPPs), Serving Gateways, and nodes in 5G Serving Mesh. SEPPs are network nodes used to protect control plane traffic exchanged between different 5G Public Land Mobile Networks (PLMNs). Therefore, SEPPs perform message filtering, policing, and topology hiding on all Application Programming Interface (API) messages.

[0009] A vulnerability in the current 5G network architecture lies in the N32 interface, which is the interface between SEPPs. As noted above, SEPPs act as security screening nodes for the Public Land Mobile Network (PLMN). The N32 control or N32-c interface is used to exchange control messages with remote SEPPs. Initiating communication on the N32-c interface involves a Transport Layer Security (TLS) handshake process to establish a TLS connection. Communication initiation also involves an N32-c security capability negotiation process, which involves the exchange of N32-c messages. During the N32-c security capability negotiation process, there is no authentication of the remote endpoint. The remote endpoint also does not authenticate the identity of the initiating SEPP. Due to the lack of authentication on the N32-c interface, initiating and responding SEPPs are vulnerable to impersonation attacks, where a third party impersonates one end of the N32-c communication to gain unauthorized access to the PLMN.

[0010] Given these and other difficulties, there is a need for methods, systems, and computer-readable media to mitigate 5G roaming spoofing attacks. Summary of the Invention

[0011] A method for mitigating 5G roaming spoofing attacks includes obtaining a first identifier of a first node from a Transport Layer Security (TLS) message from a first node by a Security Edge Protection Agent (SEPP). The method also includes obtaining a second identifier of the first node from an N32-c Security Capability Negotiation message from the first node by the SEPP. The method further includes comparing the first identifier and the second identifier of the first node. The method also 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 with the first node's Public Land Mobile Network (PLMN) in response to determining that the second identifier of the first node is invalid.

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

[0013] According to another aspect of the subject matter described in this article, certificates include X.509 certificates.

[0014] According to another aspect of the subject described herein, obtaining the first identifier of the first node includes extracting the fully qualified domain name (FQDN) of the first node from the subject alternate name field of the X.509 certificate.

[0015] According to another aspect of the subject matter described herein, SEPP is a response SEPP in the N32-c security capability negotiation process, and wherein 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 capability negotiation message.

[0016] According to another aspect of the subject matter described herein, SEPP is the initiating SEPP in the N32-c security capability negotiation process, and the acquisition of 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 capability negotiation message.

[0017] According to another aspect of the subject matter described herein, a method for mitigating 5G roaming security attacks includes the following steps: the SEPP obtains a first identifier of the second node from a TLS handshake message from the second node; obtains a second identifier of the second node from an N32-c security capability 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; locates the matching identifier in the peer SEPP database; and allows communication between the PLMN and the second node in response to the determination that the first identifier and the second identifier of the second node match and that the matching identifier exists in the peer SEPP database.

[0018] According to another aspect of the subject matter described herein, a method for mitigating 5G roaming security attacks includes obtaining a first identifier of the second node from a TLS handshake message from the second node by the SEPP, obtaining a second identifier of the second node from an N32-c security capability negotiation message from the second node by the SEPP, 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 and failing to locate the matching identifier in the peer SEPP database, and blocking 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 the matching identifier does not exist in the peer SEPP database.

[0019] According to another aspect of the subject matter described herein, a system for mitigating 5G roaming spoofing attacks includes a Security Edge Protection Agent (SEPP) comprising at least one processor and memory. The system also includes a 5G roaming spoofing attack mitigation module implemented by at least one processor and configured to obtain a first identifier of a first node from a Transport Layer Security (TLS) message from a first node, obtain a second identifier of the first node from an N32-c Security Capability Negotiation message from the first node, compare the first identifier and the second identifier of the first node, 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, and in response to determining that the second identifier of the first node is invalid, block communication with the Public Land Mobile Network (PLMN) of the first node.

[0020] According to another aspect of the subject described in this article, the 5G roaming spoofing attack mitigation module is configured to obtain the first identifier of the first node from the certificate contained in the TLS certificate message.

[0021] According to another aspect of the subject described in this article, the 5G roaming spoofing attack mitigation module is configured to obtain the first identifier of the first node by extracting the fully qualified domain name (FQDN) of the first node from the subject alternate name field of the certificate.

[0022] According to another aspect of the subject matter described herein, SEPP is a response SEPP in the N32-c security capability negotiation process, 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 capability negotiation message.

[0023] According to another aspect of the subject matter described herein, SEPP is the initiating SEPP in the N32-c security capability negotiation process, 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 capability negotiation message.

[0024] According to another aspect of the subject matter described herein, a 5G roaming spoofing attack mitigation module is configured to 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 capability 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, perform a lookup in the peer-to-peer SEPP database using one of the first identifier and the second identifier of the second node, locate the matching identifier in the peer-to-peer SEPP database, and allow communication with the PLMN of the second node in response to determining that the first identifier and the second identifier of the second node match and that the matching identifier exists in the peer-to-peer SEPP database.

[0025] According to another aspect of the subject matter described herein, a 5G roaming spoofing attack mitigation module is configured to 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 capability 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, perform a lookup in the peer SEPP database using one of the first identifier and the second identifier of the second node and fail to locate the matching identifier in the peer SEPP database, and 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 the matching identifier does not exist in the peer SEPP database.

[0026] According to another aspect of the subject matter described herein, a non-transitory computer-readable medium is provided having executable instructions stored thereon, which, when executed by a computer's processor, control the computer to perform steps. The steps include obtaining a first identifier of a first node from a Transport Layer Security (TLS) message from a first node by a Security Edge Protection Agent (SEPP). The steps also include obtaining a second identifier of the first node from an N32-c Security Capability Negotiation message from the first node by the SEPP. The steps further include 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. The steps also include blocking communication with the first node's Public Land Mobile Network (PLMN) in response to determining that the second identifier of the first node is invalid.

[0027] The subject matter described herein can be implemented using hardware, software, firmware, or any combination thereof. Thus, as used herein, the terms “function,” “node,” or “module” refer to hardware used to implement the described features, which may also include software and / or firmware components. In one exemplary embodiment, the subject matter described herein can be implemented using a computer-readable medium having computer-executable instructions stored thereon, which, when executed by a computer’s processor, control the computer to perform steps. Exemplary computer-readable media suitable for implementing the subject matter described herein include non-transitory computer-readable media, such as disk storage devices, on-chip memory devices, programmable logic devices, and application-specific integrated circuits (ASICs). Furthermore, computer-readable media implementing the subject matter described herein can reside on a single device or computing platform, or can be distributed across multiple devices or computing platforms. Attached Figure Description

[0028] The subject matter described herein will now be explained with reference to the accompanying drawings, in which:

[0029] Figure 1 This is a network diagram illustrating an exemplary 5G network architecture;

[0030] Figure 2 This is a message flow diagram illustrating the exchange of Transport Layer Security (TLS) and N32-c messages between SEPPs;

[0031] Figure 3 This is a network diagram illustrating hackers impersonating SEPP;

[0032] Figure 4 This is a message flow diagram illustrating identity verification as presented in the N32-c messages exchanged between SEPPs;

[0033] Figure 5 This diagram illustrates the SEPP blocking message response when authentication fails on the N32-c interface.

[0034] Figure 6 This diagram illustrates the SEPP blocking message being sent when authentication fails on the N32-c interface.

[0035] Figure 7 This is a block diagram illustrating an exemplary architecture of SEPP for mitigating 5G roaming spoofing attacks; and

[0036] Figure 8 This is a flowchart illustrating an exemplary method for mitigating 5G roaming spoofing attacks. Detailed Implementation

[0037] This article describes methods, systems, and computer-readable media for mitigating 5G roaming spoofing attacks. Figure 1 This is a block diagram illustrating an exemplary 5G system network architecture.

[0038] Figure 1 The architecture includes NRF 100 and SCP 101, which can reside within the same Household Public Land Mobile Network (HPLMN). As described above, NRF 100 maintains profiles of available producer NF service instances and their supported services, and allows consumer NFs or SCPs to subscribe to and be notified of new / updated producer NF service instance registrations. SCP 101 also supports service discovery and producer NF instance selection. SCP 101 can perform load balancing for connections between consumer and producer NFs. Furthermore, using the methods described herein, SCP 101 can perform selection and routing based on preferred NF locations.

[0039] NRF 100 is a repository of service profiles for NF or producer NF instances. To communicate with a producer NF instance, a consumer NF or SCP needs to obtain an NF or service profile or a producer NF instance from NRF 100. An NF or service profile is a JavaScript Object Notation (JSON) data structure defined in 3GPP Technical Specification (TS) 29.510. An NF or service profile definition includes at least one of a Fully Qualified Domain Name (FQDN), an Internet Protocol (IP) version 4 (IPv4) address, or an IP version 6 (IPv6) address. Figure 1 In this context, any node (except NRF 100) can be either a consumer NF or a producer NF, depending on whether it is requesting or providing services. In the illustrated example, the nodes include a Policy Control Function (PCF) 102 that performs policy-related operations in the network, a User Data Management (UDM) function 104 that manages user data, and an Application Function (AF) 106 that provides application services. Figure 1 The nodes illustrated also include a Session Management Function (SMF) 108 that manages the session between Access and Mobility Management Function (AMF) 110 and PCF 102. AMF 110 performs mobility management operations similar to those performed by the Mobility Management Entity (MME) in a 4G network. The Authentication Server Function (AUSF) 112 performs authentication services for User Equipment (UE) seeking network access, such as User Equipment (UE) 114.

[0040] The Network Slice Selection Function (NSSF) 116 provides network slicing services for devices seeking access to specific network capabilities and characteristics associated with a network slice. The Network Exposure Function (NEF) 118 provides an application programming interface (API) for application functions seeking information about Internet of Things (IoT) devices and other UEs attached to the network. NEF 118 performs functions similar to the Service Capability Exposure Function (SCEF) in 4G networks.

[0041] Radio Access Network (RAN) 120 connects User Equipment (UE) 114 to the network via a radio link. This can be achieved using a g-Node B (gNB). Figure 1 (Not shown in the image) or other wireless access points to access the radio access network 120. The User Plane Function (UPF) 122 can support various proxy functions for user plane services. An example of such proxy function is the Multipath Transmission Control Protocol (MPTCP) proxy function. The UPF 122 can also support performance measurement functions that can be used by the UE 114 to obtain network performance measurements. Figure 1 The diagram also shows data network (DN) 124, through which the UE accesses data network services, such as Internet services.

[0042] SEPP 126 filters incoming traffic from another PLMN and performs topology hiding for traffic leaving the home PLMN. SEPP 126 can communicate with the SEPP in the secure external PLMN that manages the external PLMN. Therefore, traffic between NFs in different PLMNs may pass through two SEPP functions, one for the local PLMN and the other for the external PLMN.

[0043] As mentioned above, one problem with existing 5G architectures is that the N32-c handshake does not verify the remote endpoint identity. Without endpoint identity verification, a malicious SEPP can attempt to impersonate another SEPP and launch a security attack. The responding SEPP does not verify whether the N32 handshake message was received from a legitimate initiating SEPP. Similarly, the initiating SEPP does not verify whether the N32-c handshake message was sent to a legitimate responding SEPP. The subject described in this paper addresses these and other difficulties by cross-verifying the SEPP's N32-c identity using TLS layer identity and peer SEPP identities stored in a peer SEPP database maintained by the initiating and responding SEPPs.

[0044] Figure 2 The diagram illustrates the handshake that occurs between SEPPs on the N32 interface. Figure 2In the N32 interface, the initiator of SEPP 126A and the responder of SEPP 126B exchange TLS handshake messages and N32-c security capability negotiation messages. The TLS handshake involves the exchange of certificates, which can be used to verify the sender's identity at the TLS layer and are difficult to impersonate. However, there is no cross-verification between the identity exchanged during the TLS handshake and the identity exchanged during the N32-c security capability negotiation message exchange. Therefore, both the initiator of SEPP 126A and the responder of SEPP 126B are vulnerable to roaming spoofing attacks. Roaming spoofing is an attack in which an attacker impersonates a node in a network in which a mobile subscriber is roaming. In the case of impersonating a node during the N32-c security capability negotiation process, the attacker impersonates the SEPP serving the network in which the subscriber is roaming.

[0045] Figure 3 The illustration shows an example of a hacker, SEPP 300, posing as a legitimate SEPP agent. Figure 3 In this scenario, SEPP 126A, located in PLMN1, might believe it is communicating with its peer SEPP 126B, located in PLMN2. However, a hacker SEPP 300 could impersonate the legitimate SEPP 126B and establish N32-c communication with SEPP 126A. Once such communication is established, the hacker SEPP 300 could potentially obtain confidential subscriber information from PLMN1 and / or launch other types of attacks against PLMN1, such as denial-of-service attacks.

[0046] To avoid or reduce the possibility of successful spoofing attacks on the N32-c interface, SEPP 126A and 126B can cross-authenticate N32-c identities using TLS identities, and can also use a configured peer-to-peer SEPP database to authenticate N32-c identities using peer-to-peer SEPP authentication. Figure 4 The illustration shows an exemplary cross-validation that can be performed by initiating SEPP 126A and responding to SEPP 126B. (Reference) Figure 4 The initiator of SEPP 126A and the responder of SEPP 126B can exchange TLS handshake messages via the N32-c interface to establish a TLS connection. The TLS handshake involves the exchange of greeting messages between the client and server, followed by the exchange of certificate messages. The certificate message contains the sender's X.509 certificate. The sender's identity is contained within the X.509 certificate and is difficult to forge because the X.509 certificate is signed by a Certificate Authority.

[0047] Therefore, 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 Internet Engineering Task Force (IETF) Request for Comments (RFC) 5246 and includes the exchange of certificate messages between the two ends of a TLS connection. The structure of the TLS handshake message (including the certificate message) defined in IETF RFC 5246 is as follows:

[0048]

[0049]

[0050] As shown in the TLS handshake message structure, one of the defined handshake message types is the certificate message, which contains the client's or server's certificate, depending on whether the sender is acting as a client or a server. When establishing secure TLS communication via the N32-c interface, bidirectional TLS or m-TLS is used, where both ends of the TLS connection receive and verify the other end's X.509 certificate. IETF RFC 5246 indicates that the certificate type must be X.509v3 unless otherwise explicitly negotiated. The examples described herein use X.509v3 certificates, but the subject matter described herein is not limited to verifying the sender's N32-c identity using only the sender's identity extracted from X.509v3. The X.509v3 certificate format is defined in IETF RFC 3280. According to IETF RFC 3280, one extension or parameter that can be included in an X.509v3 certificate is the Subject Alternate Name extension. The Subject Alternate Name extension is defined as follows:

[0051] The Subject Alternate Name extension allows you to bind additional identities to the subject of a certificate. Defined options include internet email addresses, DNS names, IP addresses, and Uniform Resource Identifiers (URIs). Other options exist, including fully local definitions. Multiple name formats and multiple instances of each format can be included. The Subject Alternate Name (or Issuer Alternate Name) extension is required whenever such an identity is bound to a certificate; however, the DNS name can be represented in the subject field using the domainComponent property, such as... Section 4.1.2.4 As described in [the text].

[0052] Because the subject alternate name is considered to be explicitly bound to the public key, all parts of the subject alternate name need to be verified by the CA.

[0053] As noted above, the Subject Alternate Name extension for an X.509v3 certificate can include a DNS name, IP address, or a URI that identifies the certificate's subject and is verified by the Certificate Authority. Because the Subject Alternate Name is verified by the Certificate Authority, it is difficult to spoof. 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 this cross-validation, the initiating SEPP 126A and responding SEPP 126B can extract identities from the N32-c message and compare these identities with those extracted from the X-509 certificate shared during the TLS handshake. If the identities match, SEPP 126A and 126B can perform further verification steps by comparing the identities extracted from either the N32-c message or the TLS message with a configured database of peer SEPP identities. If either verification fails, SEPP can block inter-PLMN communication with the remote node, identifying the remote node as an attacker.

[0054] Return to Figure 4 After exchanging TLS handshake messages and establishing a TLS connection between initiating SEPP 126A and responding SEPP 126B, initiating SEPP 126A sends an HTTP POST message to responding SEPP 126B. The HTTP POST message includes a SecNegotiateReqData information element, which contains a sender information element including the sender's FQDN. Responding SEPP 126B receives the HTTP POST message, extracts the sender's FQDN from the SecNegotiateReqData information element, and compares it with the sender's authentication FQDN obtained from the sender's X.509 certificate. In this case, it is assumed that the identities match. Therefore, in the next step, responding SEPP 126B performs a lookup of the sender's identity in the peer SEPP database maintained by responding SEPP 126B. Assuming the identity that initiated SEPP 126A exists in the peer SEPP database of the response SEPP 126B, from the perspective of the response SEPP 126B, both authentications have passed. Therefore, the response SEPP 126B will allow inter-PLMN communication from the initiator SEPP 126A.

[0055] continue Figure 4 The message stream, in response to SEPP 126B, sends an HTTP 200 OK message to the initiating SEPP 126A. The HTTP 200 OK message includes an N32-cSecNegotiateRspData information element containing sender attributes. Figure 5In this example, the sender attribute carries the FQDN of the response SEPP 126B. The initiating SEPP 126B receives the HTTP 200 OK message, extracts the sender's FQDN from the sender attribute of the SecNegotiateRspData information element, and compares this FQDN with the FQDN for the sender extracted from the TLS certificate message. In this case, it is assumed that the FQDNs match. Therefore, the initiating SEPP 126A performs a further verification step to determine whether the sender's identity exists in the peer SEPP database maintained by the initiating SEPP 126A. In this example, it is assumed that the sender's identity exists, and therefore, the initiating SEPP 126A allows inter-PLMN communication with the responding SEPP 126B.

[0056] Figure 5 The illustration shows the scenario where the hacker SEPP 300 initiated the SEPP process regarding N32-c security capabilities. Figure 5 In the example, the hacker SEPP 300 initiates a TLS handshake with the response SEPP 126B. SEPP 126B extracts the X.509 certificate from the TLS handshake message and then extracts the identity presented by the hacker SEPP 300 from the certificate. The hacker SEPP 300 transmits the identity to the response SEPP 126B in the N32-c SecNegotiateReqData information element of the N32-c Security Capability Negotiation message, which in the example shown is an HTTP POST message. SEPP 126B extracts the identity presented by the hacker SEPP 300 in the N32-c SecNegotiateReqData information element of the N32-c Security Capability Negotiation message and compares the identity extracted from the SecNegotiateReqData information element with the identity extracted from the certificate obtained from the TLS message. In this case, the identities do not match. Therefore, the response SEPP 126B determines that an authentication failure has occurred. Therefore, SEPP 126B is used to block further communication from the hacker SEPP 300.

[0057] Figure 6 The illustration shows the SEPP initiating the N32-c security capability negotiation transaction, where the SEPP performing TLS and N32-c identity cross-authentication is executed. Figure 6In the example shown, SEPP 126A initiates receiving TLS and N32-c messages from the hacker SEPP 300. SEPP 126A then retrieves an X.509 certificate from one of the TLS handshake messages. SEPP 126A extracts an 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 capability negotiation message. In the example shown, this identity is an HTTP 200 OK message. In this case, the identities do not match. Therefore, SEPP 126A blocks further communication from the hacker SEPP 300.

[0058] Figure 7 This is a block diagram illustrating an exemplary architecture of SEPP 126A or 126B. SEPP 126A or 126B includes at least one processor 700 and memory 702. SEPP 126A or 126B also includes a 5G roaming impersonation mitigation module 704, which performs the steps described herein to cross-verify the identity in an N32-c message using the identity extracted from the TLS message. SEPP 126A or 126B also includes a peer SEP database 706 configured with the identities of peer SEPPs that allow inter-PLMN communication. The 5G roaming impersonation mitigation module 704 may be implemented by the processor 700 and may also perform cross-checking of the N32-c identity presented by the remote node against the peer SEPP identities stored in the database 706. If the identity of the remote node presented in the N32-c security capability negotiation message does not exist in the database 706, or if the cross-check with the TLS identity fails, then the 5G roaming impersonation mitigation module 704 may block inter-PLMN communication with the remote node. If both identity cross-checks pass, the 5G roaming impersonation mitigation module 704 can allow PLMN-to-PLMN communication with remote nodes.

[0059] Figure 8 This is a flowchart illustrating an exemplary method for mitigating 5G call attacks. (Reference) Figure 8 In step 800, SEPP obtains a first identifier from the TLS message received from the first node. For example, initiating or responding to SEPP 126A or 126B, the identity of the sending node can be extracted from the "Alternate ID" field of the X.509 certificate in the TLS message received from the sending node. The TLS message may be a certificate message exchanged with the remote node as part of the TLS handshake process used to establish a TLS connection with the remote node.

[0060] In step 802, the SEPP obtains the second identifier of the first node from the N32-c security capability negotiation message from the first node. For example, if the SEPP is the initiating SEPP for the N32-c security capability negotiation transaction, then the initiating SEPP can extract the N32c identity from the sender ID attribute of the N32-c SecNegotiateRspData information element in the HTTP 200 OK message from the remote node. If the SEPP is the responding SEPP for the N32-c security capability negotiation transaction, then the responding SEPP can extract the N32c identity from the sender ID attribute of the N32-c SecNegotiateReqData information element in the HTTP POST message from the remote node. Tables 1 and 2 shown below correspond to Tables 6.1.5.2.2.1 and 6.5.1.2.2 of 3GPP TS 29.573, which illustrate the attributes that may be included in the SecNegotiateReqData and SecNegotiateRspData information elements as part of the N32-c security capability negotiation.

[0061] Table 1: Definition of type SecNegotiateReqData

[0062]

[0063] Table 2: Definition of type SecNegotiateRspData

[0064]

[0065] As can be seen from Tables 1 and 2, the sender attribute is a required parameter for the SecNegotiateReqData and SecNegotiateRspData information elements, and it contains the FQDN of the SEPP that sent the request or response. It is this FQDN that can be cross-verified with the TLS layer identity.

[0066] 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 or SecNegotiateReqData information element of the N32-c security capability negotiation message.

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

[0068] Returning to step 806, if the TLS and N32-c application layer identities match, control proceeds to step 812, where the SEPP performs a lookup in the peer-to-peer SEPP database for the identity used by the first node. Since the identities from the TLS layer and the N32-c (application) layer matched in step 806, the lookup can be performed using either the TLS layer or the N32-c layer identity. Network operators can supply SEPP identities to the peer-to-peer SEPP database, allowing a given SEPP in the operator's network to communicate with it. Such SEPPs are referred to herein as peer-to-peer SEPPs because they can be associated with the PLMN of a peer-to-peer network operator.

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

[0070] This paper describes a method to improve network security between SEPPs and PLMNs by performing cross-verification of identities exchanged between SEPPs at different network protocol layers. By comparing N32-c identities with TLS layer identities that are difficult to forge, the SEPPs described in this paper reduce the likelihood of successful spoofing attacks during the N32-c security capability exchange process. Furthermore, because the cross-verification steps described in this paper can be initiated and responded to by the SEPPs in the N32 security capability negotiation, the likelihood of an attacker successfully impersonating either end of the N32-c connection is reduced.

[0071] The publicly available information of each of the following references is incorporated into this paper in its entirety through citation.

[0072] References

[0073] 1.IETF RFC 5246; The Transport Layer Security (TLS) Protocol, Version1.2; August 2008

[0074] 2. IETF RFC 3280; Internet X.509Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, April 2002.

[0075] 3.3GPP TS 29.573; 3 rd Generation Partnership Project; TechnicalSpecification Group Core Network and Terminals; 5G System; Public Land Mobile Network (PLMN) Interconnection; Stage 3 (Release 16) V16.3.0 (2020-07)

[0076] 4.3GPP TS33.501; 3 rd Generation Partnership Project; TechnicalSpecification Group Services and System Aspects; Security Architecture and Procedures for the 5G System; (Release 16), V16.3.0 (2020-07).

[0077] 5.3GPP TS 29.510; 3 rd Generation Partnership Project; TechnicalSpecification Group Core Network and Terminals; 5G System; Network FunctionRepository Services; Stage 3(Release 16),V16.4.0(2020-07).

[0078] It will be understood that various details of the currently disclosed subject matter may be changed without departing from the scope of the currently disclosed subject matter. Furthermore, the foregoing description is for illustrative purposes only and not for limiting purposes.

Claims

1. A method for mitigating 5G roaming spoofing attacks, the method comprising: The Security Edge Protection Agent (SEPP) obtains the first identifier of the first node from the Transport Layer Security (TLS) message from the first node, where the first identifier of the first node is the fully qualified domain name (FQDN) of the first node located in the Subject Alternate Name field of the X.509 certificate in the TLS message. SEPP obtains the second identifier of the first node from the N32-c security capability negotiation message from the first node, wherein the second identifier is the FQDN located in the sender attribute of the SecNegotiateReqData or SecNegotiateRspData information element of the N32-c security capability negotiation message; Compare the first identifier and the second identifier of the first node; When SEPP determines that the first identifier does not match the second identifier: The second identifier of the first node is determined to be invalid; as well as In response to determining that the second identifier of the first node is invalid, communication with the public land mobile network (PLMN) of the first node is blocked; as well as When SEPP determines that the first identifier and the second identifier match: Perform a lookup for the first identifier or the second identifier of the first node in the peer-to-peer SEPP database; as well as If either the first identifier or the second identifier exists in the peer SEPP database, then communication between the first node and the public land mobile network (PLMN) is permitted.

2. The method of claim 1, wherein the TLS message includes a TLS certificate message.

3. The method of claim 1 or 2, wherein the SEPP is a response SEPP in the N32-c security capability negotiation process, and wherein 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 capability negotiation message.

4. The method of claim 1 or 2, wherein the SEPP is an initiating SEPP in the N32-c security capability negotiation process, and wherein 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 capability negotiation message.

5. The method as described in claim 1 or 2, comprising: In response to determining that the first identifier of the first node matches the second identifier and that the matching identifier does not exist in the peer SEPP database, PLMN communication from the first node is blocked.

6. A system for mitigating 5G roaming spoofing attacks, the system comprising: Security Edge Protection Agent (SEPP) includes at least one processor and memory; as well as The 5G roaming spoofing attack mitigation module is implemented by the at least one processor and configured to: Obtain the first identifier of the first node from the Transport Layer Security (TLS) message from the first node, where the first identifier of the first node is the fully qualified domain name (FQDN) of the first node located in the Subject Alternate Name field of the X.509 certificate in the TLS message. Obtain the second identifier of the first node from the N32-c security capability negotiation message from the first node, wherein the second identifier is the FQDN located in the sender attribute of the SecNegotiateReqData or SecNegotiateRspData information element of the N32-c security capability negotiation message; Compare the first identifier of the first node with the second identifier; When the 5G roaming spoofing attack mitigation module determines that the first identifier and the second identifier do not match, the 5G roaming spoofing attack mitigation module is configured as follows: The second identifier of the first node is determined to be invalid; as well as In response to determining that the second identifier of the first node is invalid, communication with the public land mobile network (PLMN) of the first node is blocked; as well as When the 5G roaming spoofing attack mitigation module determines that the first identifier and the second identifier match, the 5G roaming spoofing attack mitigation module is configured as follows: Perform a lookup for the first identifier or the second identifier of the first node in the peer-to-peer SEPP database; as well as If either the first identifier or the second identifier exists in the peer SEPP database, then communication between the first node and the public land mobile network (PLMN) is permitted.

7. The system of claim 6, wherein the TLS message includes a TLS certificate message.

8. The system of claim 6 or 7, wherein the SEPP is a response SEPP in the N32-c security capability negotiation process, and wherein 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 capability negotiation message.

9. The system of claim 6 or 7, wherein SEPP is the initiating SEPP in the N32-c security capability negotiation process, and wherein 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 capability negotiation message.

10. The system of claim 6 or 7, wherein the 5G roaming spoofing attack mitigation module is configured to In response to determining that the first identifier of the first node matches the second identifier and that the matching identifier does not exist in the peer SEPP database, PLMN communication from the first node is blocked.

11. A non-transitory computer-readable medium storing executable instructions thereon, which, when executed by a computer's processor, control the computer to perform the following steps: The Security Edge Protection Agent (SEPP) obtains the first identifier of the first node from the Transport Layer Security (TLS) message from the first node, where the first identifier of the first node is the fully qualified domain name (FQDN) of the first node located in the Subject Alternate Name field of the X.509 certificate in the TLS message. SEPP obtains the second identifier of the first node from the N32-c security capability negotiation message from the first node, wherein the second identifier is the FQDN located in the sender attribute of the SecNegotiateReqData or SecNegotiateRspData information element of the N32-c security capability negotiation message; Compare the first identifier of the first node with the second identifier; When SEPP determines that the first identifier does not match the second identifier: The second identifier of the first node is determined to be invalid; as well as In response to determining that the second identifier of the first node is invalid, communication with the public land mobile network (PLMN) of the first node is blocked; as well as When SEPP determines that the first identifier and the second identifier match: Perform a lookup for the first identifier or the second identifier of the first node in the peer-to-peer SEPP database; as well as If either the first identifier or the second identifier exists in the peer SEPP database, then communication between the first node and the public land mobile network (PLMN) is permitted.

12. The non-transitory computer-readable medium of claim 11, wherein the TLS message includes a TLS certificate message.

Images