SEPP Identity Cross-Validation for 5G N32-C Roaming Spoofing
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The 5G network architecture is vulnerable to roaming spoofing attacks on the N32 interface due to the lack of validation of remote endpoint identities during the N32-c security capability negotiation procedure, allowing malicious entities to impersonate SEPPs and gain unauthorized access to PLMNs.
Innovation Solution
Implementing a method and system where SEPPs cross-validate N32-c identities with TLS identities and peer SEPP identities using a configured database, ensuring that identities match and are present in the database before allowing inter-PLMN communications.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If identity validation is not performed on the N32-c interface, then inter-PLMN communications can be established quickly, but the network becomes vulnerable to spoofing attacks
Solution Approach 1:
The patent applies preliminary action by performing identity validation during the TLS handshake phase, before the N32-c application layer communication begins. The SEPP extracts and validates the remote SEPP's identity from the TLS certificate in advance, comparing it with the identity that will be presented in subsequent N32-c messages. This preliminary validation prevents spoofing attacks without adding complexity to the main communication flow.
Solution Approach 2:
The patent uses the TLS certificate as an intermediary to establish trust between SEPPs. Instead of directly validating N32-c message identities without verification, the system introduces TLS mutual authentication as an intermediary layer that provides cryptographic proof of identity. The TLS certificate acts as a trusted mediator that binds the SEPP's identity to its communication endpoint, enabling secure N32-c communications.
2Reliability
If TLS mutual authentication is implemented, then spoofing attacks are prevented, but the authentication process becomes more complex
Solution Approach 1:
The patent merges the identity validation function into the existing TLS handshake process. Instead of implementing a separate authentication mechanism that would increase operational complexity, the system combines N32-c identity validation with the already-mandated TLS mutual authentication. The SEPP extracts identity information from the TLS certificate during the handshake and uses it to validate the remote endpoint, eliminating the need for separate authentication procedures.
Solution Approach 2:
The patent applies self-service by having the SEPP automatically extract and validate the remote SEPP's identity from the TLS certificate without requiring manual configuration or intervention. The system autonomously performs the validation by comparing the identity in the TLS certificate with the identity presented in N32-c messages, and automatically blocks or allows communications based on this validation, reducing operational complexity.
3Reliability
If identity matching validation is performed, then unauthorized access is blocked, but communication establishment time increases
Solution Approach 1:
The patent performs identity matching validation as a preliminary action during the TLS handshake phase, before N32-c communication begins. By extracting and validating the remote SEPP's identity from the TLS certificate in advance, the system ensures that identity matching is completed before actual business communications start. This preliminary validation prevents unauthorized access without adding time to the operational communication phase.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
Roaming spoofing attacks can be initiated during N32-c handshake procedure used for inter-PLMN communication in 5G network. One example solution described herein uses the SERF to mitigate the N32-c roaming spoofing attacks by cross validating the sender attribute present in N32-c handshake security capability exchange messages against the endpoint identity in the X.509v3 certificate shared during TLS handshake and the remote SERF identity configured in the SEPP's local database.