1 Introduction
1.1 The First Generation (1G)
1.2 The Second Generation (2G)
1.3 The Third Generation (3G)
1.4 The Fourth Generation (4G)
1.5 On the Scope of the Preliminary Threat Analysis
2 Features of the 3GPP-based 5G System Architecture
2.1 5G New Radio
2.2 The SDN/NFV and MANO Aspects of the Core Network
2.3 The Web-based Technological Foundation
2.3.1 Representational State Transfer (REST) Technologies
2.3.2 JavaScript Object Notation (JSON)
2.3.3 Transport Layer Security (TLS)
2.3.4 Javascript Object Signing and Encryption (JOSE)
2.3.5 Authorization and Delegation Using OAuth 2
2.4 Roaming and the Service Based Architecture
2.4.1 The Service Based Interfaces
2.4.2 The Security Edge Protection Proxy (SEPP)
2.4.3 The SEPP and N32 Roaming Interface
3 The Service Based Architecture at Large
3.1 The Critical Infrastructure Perspective
3.1.1 Impact Potential
3.1.2 Inherent Risks of Complex Systems
-
The system is complex
-
The system is tightly coupled
-
The system has catastrophic potential
3.2 Data Exchange in SBA
3.3 The Risks of Using JSON
3.3.1 Abstract Syntax Notation No.1 (ASN.1)
3.3.2 JSON Text Based Data
stdint.h
definition, which explicitly defines the integer type (signed or unsigned) and the number of bytes used in the representation. But, there is no easy way to distinguish between different integer types in, like uint_16
and int32_t
, in JSON. The problem is pervasive.However, while the results were disappointing, the outcome of the publication has also been that several of the flaws have been fixed. But, while the authors of the modules and libraries can fix implementation flaws, they cannot be expected to fix inherent design problems.As a final word, I keep on wondering why “fragile” formats such as HTML, CSS and JSON, or “dangerous” languages such as PHP or JavaScript became so immensely popular. This is probably because they are easy to start with by tweaking contents in a text editor, because of too liberal parsers or interpreters, and seemingly simple specifications. But sometimes, simple specifications just mean hidden complexity.
3.4 Challenges to using OAuth 2.0
3.5 The Web-based Development and Deployment Model
3.5.1 Design
3.5.2 Implementation (and Testing)
3.5.3 Deployment and Operations
4 The N32 Roaming Interface
4.1 Overview over the Roaming Model
-
cSEPP has as a business relationship with cIPX.
-
pSEPP has as a business relationship with pIPX.
4.2 The N32-interface
4.3 The Risks of Using JSON in an Inter-Vendor Environment
4.4 Security by Ignorance?
5 High-Level Threats and Risks of 5G
5.1 Risk Assessment on Cybersecurity in 5G networks
-
The risks associated with the key innovations (like softwarization).
-
The role of suppliers and associated dependencies (supply chain).
-
Increased exposure to attacks and more potential entry points.
-
Increased sensitivity of base stations and management functions.
-
Threats to availability and integrity (larger societal dependency).
5.2 The 5G Threat Landscape
5.2.1 The ENISA 5G Threat Landscape Report
-
Threats associated with the SDN/NFV and MANO paradigms.
-
Network slicing is investigated.
-
The individual network functions is briefly investigated.
-
The new 5G RAN is investigated.
-
Multi-access Edge Computing described.
-
The security architecture is briefly explained.
-
The 5G physical infrastructure described.
5.2.2 A Noteworthy Omission
5.3 High-level SBA Threats
-
SBA is a new design This implies that there are undetected design flaws and shortcomings.
-
A new design implies new implementations New implementations are highly likely to introduce new implementation flaws.
-
Use of JSON is a liability Different implementations will use different JSON libraries. There is a considerable chance that there will be inconsistencies, and these may lead to security problems.
-
Authorization and OAuth 2.0 Use of authorization is new to the 3GPP core network signaling system. There is therefore a considerable chance that there will be wrongful or inappropriate use. This affects both the design requirements and the realization of the requirements. Furthermore, it is well known that there are problems with some of the OAuth 2.0 implementations.
-
The Telecom industry is not prepared for a web regime There are undoubtedly Telecom vendors and operators that are well prepared. However, we can safely assume that many will be less than well prepared.
-
Unsecured connections Appropriate use of TLS will solve this problem. But, use of TLS is up to the discretion of the operator, and the Telecom industry has a poor track record in this area. Many operators will likely get their act together and set up TLS, but even this may not be sufficient. Digital certificates must be managed properly and the TLS implementation must be kept up-to-date. Some operators may opt to not deploy TLS. This will save them money and operational complexity, albeit at the cost of being exposed to all kinds of intrusions.
5.4 High-level N32 Threats
-
The N32 trust model The corresponding roaming partner must be inevitably be trusted to some extent. The IPX operators must be fully trusted.
-
Complexity and clarity The N32 interface is a quite complex. The language is informal, and the structure of TS 33.501 section 13 is somewhat ad-hoc [13]. It is hard to ascertain consistency and completeness when there is no formally specified requirements.
-
JSON inconsistencies Inherent incompatibilities in a JSON library could be exposed in processing in a multi-operator environment, which would be a typical scenario for the N32 interface.
-
JOSE The JOSE standard is quite complex, with plenty of opportunities to use it in an inappropriate way. The standard may also have additional problems, which is being alluded to by several pundits. That being said, no actual flaw or exploit has been demonstrated.
6 Web Threat Categories and the Associated Security Measures
6.1 Web Application Vulnerabilities
6.2 Threat Categories
6.3 Associated Security Measures (Non-Roaming)
6.3.1 Masquerade
6.3.2 Eavesdropping
6.3.3 Integrity Violations
6.3.4 Message Data Validity
6.3.5 Authorization and Access Rights.
6.3.6 Availability and Reliability
6.3.7 Accountability and Attributability
6.4 Associated Security Measures (Roaming)
-
The so-called PRINS solution (use of JOSE) This scheme, using JOSE and permitting upto two IPX’es, is defined in Section 13.2 in TS 33.501 [13]. The N32-c (control plane) is to be handled with TLS protection. The actual security of PRINS will vary, suffice to say that there must be a high level of trust in the IPX operators. It will also be difficult to guarantee the level of threat protection actually provided.
-
Use of TLS This is for the cases where one has a one-to-one connection between operators. OAuth 2 is not used for roaming cases, and it is the SEPPs that needs to handle (roaming-related) policy aspects in this case.
-
“Reserved”
6.5 Security Assurance
7 Discussion
-
TLS must be deployed and used.
-
The TLS certificates should indicate the actual SBA node type.
-
Message data validation schemes must be developed and deployed to alleviate JSON’s many shortcomings.
-
OAuth 2 must be deployed and used. Policy decision must be applied.
-
NWDAF must be deployed and used. Logging must be used.
-
N32: TLS (or IPsec) must be used for direct inter-operator signalling
-
N32: PRINS profiles must be verified for cases with IPX operators.
-
N32: Policy profiles (and logging) must be developed (both TLS and PRINS).