# Assignment 2 Study Note
###### tags: `Wireless Communications`

## A table comparing the security threat mentioned in all reference

| Threat | Security Considerations of Open RAN | O-RAN Security Task Group | A guide to 5G network security | 5G Security: Forward Thinking | Securing the 5G Era | Security Considerations for the 5G Era |
| -------- | -------- | -------- | -------- | -------- | -------- | -------- |
| O-RAN LLS 7-2x | v | | | | | |
| SS7 and Diameter Protocol | | | | | | v |
| E2E | | | | | | v |
| IMSI | | | | | | v |
| DDoS | | | | v | v | |
| 2G/3G Downgrade Attack | | | | | | v |
| Man-in-the-Middle Attacks | | v | v | v | v | v |
| LTE Roaming | | | | | | v|
## Security Considerations of Open RAN

### RAN virtualization

An **Open RAN** has open interoperable interfaces, RAN virtualization, and support for big data and AI-enabled RAN.

Providers deploying an Open RAN can choose between a between a 3GPP or O-RAN architecture.

Figure 1 below shows the comparison of the 3GPP andO-RAN architectures.

**vRAN** refers to the virtualization of RAN functions, particularly the higher layer and lower layer function of the baseband unit.

With vRAN, 5G becomes softwaredefined and programmable, generating additional RAN architecture flexibility, platform harmonization and operational simplification.

**O-RAN** refers to the Open RAN standardized by the O-RAN Alliance. The O-RAN Alliance has four main objectives: Open Interfaces, Virtualization, Intelligence, and Interoperability.

### O-RAN security risks
The O-RAN architectural diagram is shown in Figure 2 below. Security measures should be taken to address security risks specific to O-RAN deployments. These security measures include the following recommendations:
* Protect expanded threat surface.
* Close security vulnerabilities associated with Near-RT RIC .
* Address threat to trust chain introduced by decoupling of functions.
* Ensure management interfaces are secured according to industry best practices.
* Practice a higher level of due diligence for exposure to public exploits from use of Open Source code.
* Implement defenses from physical attacks.


:::spoiler
#### O-RAN背景
#### 什麼是RAN
無線電接取網路(Radio Access Network)
* 無線電信系統的一部分，通過無線電磁波將設備連上網路
* 例如：手機、智慧手錶
* RAN是無線電信的主要組成

#### 存在問題
目前RAN存在幾個主要問題：
1. 綁定供應商，電信營運商連接和部屬多個RAN設備的選擇有限，在此情況下，源管理且充分利用有限頻譜具有挑戰性。
2. 網路節點間的協調有限，影響RAN元件的整合優化與控制。
3. RAN的重構彈性有限，無法微調以利支援不同部屬及不同流量配置。

#### 什麼是O-RAN
開放式無線接取網路技術(Open Radio Access Network)
* 開放介面及軟硬體，阻止網路供應上的壟斷，不同供應上的設備得以互通，進而降低建置成本，並提供電信業者更多選擇。
* 將RAN的網路架構開放，依照功能來進行元件的區分。(似單體式架構依照工作範疇拆分成一個個的微服務)
* 而這一個個的元件再藉由O-RAN Alliance做規範的標準開放介面進行連接。
* 就是他讓下世代的5G網路智慧化(AI)，依需求自動調節網路資源。
:::
### LTE RAN vs O-RAN

在4G的LTE RAN架構中，首先是基帶單元(BBU)，他負責訊號處理及網路存取的工作；再來是無先寬頻頭端設備(RRU)，具備像是ADC/DAC的轉換器以及RF射頻設備。

而RRU底下連接BBU介面的叫做CPRI(無線基站通用介面)，但雖說是「通用」，但其實每間廠商的CPRI都是「專有的」。

RAN的全部組件源於同一家供應商。

ex: NOKIA的BBU不能跟愛立信的RRU接再一起。

因此5G RAN的開放源就出現了！
#### Open-Fronthual
為了防止出現廠商壟斷的情況，就要做硬體上面的切片，讓不同的供應商製造元件。

但要如何分配？
所以要考慮RAN如何解耦(RAN Disaggregation)。那O-RAN要如何分開BBU及RRU？

於是要依照功能來進行切分，也就是所謂(Function Split)。分成8個option並以新的介面Open-Fronthual(O-FH)來切開DU(分佈單元)和RU(無線電單元)。

假設現在今天Fronthual愈往左切(ex:在option)，RU無線電單元功能就愈多，那麼多功能要塞在RU上面，在製作上就會有困難，而不同廠商的互通信也會變得困難。
如果愈往右切CU(ex:在option 8)分布單元的功能就愈多，雖然RU功能少，但5G傳輸量大，要做基頻處理(快速傅立葉轉換 or 要確保資料沒錯誤，要做錯誤檢查)，資料量大要做快速資料傳輸，需要足夠的寬頻，才會傳得快。所以需要衡量，ITU有挑選三個方案，但最後由Split Option 7.2脫穎而出，就是將原本CPRI介面fronthual，Physical Layer資料傳輸的部分，使用eCPRI取代CPRI。
##### Open Fronthual 採用Split Option 7.2規格
主要考慮的兩個點：
1. 能耗
* 如果RU功能愈多，相對能耗就愈多。
* 使O-RU盡可能簡單、更小、更省電
2. 資料需求(option 1~8)
* 考量位元速率、資料傳輸，open-fronthaul 切在數字愈大(ex:option 8)，RU功能少研發更簡單。
* 但介面傳輸量會提高，對於延遲要求也會增加
* 最後就是把Open-Fronthual 切在H-PHY, L-PHY的中間，解耦DU, RU。

以下就是O-RAN架構

#### Open RAN vs 3GPP

圖1是O-RAN架構的主要變化，如果我們比較O-RAN聯盟與3GPP，可以在圖片中看到基於3GPP的架構和O-RAN架構下層拆分之間的主要比較（LLS）7-2X。引入新節點： RAN智能控制器（RAN Intelligent Controller, RIC）和服務管理和編排（Service Management & Orchestrator, SMO）、引入前傳（FrontHaul）拆分、引入新介面。

將傳統 CPRI 與 eCPRI 接口進行比較的一個不同之處在於，eCPRI 能夠有效使用基於數據包的傳輸技術，並允許通過以太網技術承載 RAN 有效載荷。 O-RU 接口的更高層是在 eCPRI 之上實現的，具有幾個不同的 LLS 選項來拆分 O-RU 和 O-DU 之間的功能。

#### O-RAN LLS 7-2x
When having two different vendors, the O-RU and the O-DU needs to be managed as different entities.

* the possibilities to reach the northbound systems beyond the O-DU through the Open Fronthaul interface become a possible attack vector in this split architecture.
* access to the O-DU configuration could possibly be achieved via the Open Fronthaul interface, depending upon the design of the hardware-software system and how different functions are segregated in the node.
* An adversary could, in such case, either harm the node, create a performance issue by manipulation of parameters, or reconfigure the node and disable the over-the-air ciphers with the purpose of eavesdropping or other type of breaches.
#### Near-RT RIC
The Near-RT-RIC also has potential security vulnerabilities, such as the following:
* Near-RT RIC signaling conflicts with gNodeB
* Near-RT RIC xApps signaling can conflict
* xApp Root of Trust
* UE identification in the RIC

## O-RAN Security Task Group
Several STG efforts illustrate how this approach is creating an open, interoperable, and secure system by design.

The STG recognizes that an unprotected management interface provides an easily exploitable vulnerability in the RAN. Thus, the O-RAN management interfaces, the O1 interface and the Open Fronthaul M-plane, must be protected using industry security best practices such as TLS and/or SSH with strong ciphers, mutual authentication using X.509 certificates, access controls that can be integrated with an operator’s identity lifecycle management platforms, robust logging that can be integrated with an operator’s centralized logging platform, and input validation. Similar analysis is being performed on the other O-RAN defined interfaces: A1, E2, O2 and Open Fronthaul CUS-plane.

## A guide to 5G network security
While 3GPP security mechanisms provide reliable links for non-malicious bad radio conditions (see below) they do not protect against all possible threats, for instance DDoS and radio jamming.

Protecting against DDoS attacks and radio jamming is something that is left for implementation and deployment.

5G function element deployments (vertical security)
* NFVi (virtualized or cloud native)
* Appliance based functions
* Distributed clouds and edge computing
## 5G Security: Forward Thinking
For instance, mobile Internet of Things (IoT) devices require lightweight security while high-speed mobile services demand high efficient mobile security. The network based hop-by-hop security approach may not be efficient enough to build differentiated end-to-end (E2E) security for different services.

As IoT is gaining momentum, more people will be able to remotely operate or "talk" to networked devices, for instance, instructing facilities at a smart home to get up. Therefore, there is a need of a more stringent authentication method to prevent unauthorized access to IoT devices.

For example, biometric identification could be part of the authentication in smart homes.

### 5G Security Goal
#### E2E Security for Vertical Industries
* Differentiated security protection
* Flexibility
* Privacy protection
* Security as service

#### 5G Security Perspectives
* Hybrid Authentication Management
* Authentication by networks only
* Authentication by service providers only
* Authentication by both networks and service providers.
* Diversified Identity Management
* Combination of device identity and service identity
* From device-based management to user-based management
## Securing the 5G Era
5G improves confidentiality and integrity of user and device data. Unlike previous generations of mobile systems 5G:
* Protects the confidentiality of the initial non-access stratum (NAS) messages between the device and the network.
* Introduces a protection mechanism called home control.
* Supports unified authentication across other access network types e.g. WLAN, allowing 5G networks to manage previously unmanaged and unsecured connections.
* Introduces user plane integrity checking, ensuring the user traffic is not modified during transit.
* Enhances privacy protection with the use of public / private key pairs (anchor keys) to conceal the subscriber identity, and derive keys used throughout the service architecture.

### Network Protection
#### Signalling Data Integrity
5G introduces a new network architecture element: the Security Edge Protection Proxy (SEPP).
The SEPP is designed to:

* Provide application layer security and protect against eavesdropping and replay attacks.
* Provide end-to-end authentication, integrity and confidentiality protection via signatures and encryption of all HTTP/2 roaming messages.
* Offer key management mechanisms for setting the required cryptographic keys and performing the security capability negotiation procedures.
* Perform message filtering and policing, topology hiding and validation of JSON objects; including cross-layer information checking with address information on the IP layer.

#### New IT Protocol
The following protocols, schemas and processes will be adopted in 5GC:
* HTTP/2 over N32, replacing Diameter over the S6a reference point
* TLS as an additional layer of protection providing encrypted communication between all network functions (NF) inside a public land mobile network (PLMN)
* TCP as the transport layer protocol as replacement of the SCTP transport protocol.
* RESTful framework with OpenAPI 3.0.0 as the Interface Definition Language (IDL)


As these protocols are used in the wider IT industry, their use will likely:
* Lead to a short vulnerability to exploitation timeline, and higher impact of vulnerabilities located within these protocols.
* Expand the potential pool of attackers. 4G and especially 3G core networks benefit from attackers having little experience with the propriety standards used within them.
## Security Considerations for the 5G Era
### LTE and 5G Non-Standalone Networks
#### 2G/3G Downgrade Attack
Downgrade attacks allow for adversaries to force an LTE connected UE to 2G or 3G, which has significantly less security controls. Ultimately, adversaries could perform man-in-the-middle (MiTM) active attacks and/or a passive (e.g. eavesdropping) attacks to collect sensitive information. A customer experiencing abnormal behavior in their LTE connection could indicate of this type of attack.

#### IMSI Tracking (Privacy)
The IMSI (International Mobile Subscriber Identity) is a unique number that can be captured in the clear over-the-air. High cost Stingrays are no longer required for this attack, because low cost software defined radios (SDRs) can be purchased over the Internet. This could allow bad actors to pursue lower value targets resulting in privacy concerns for the general public. These same, low-cost SDRs would more likely be used by an adversary to track and exploit higher-value targets for various reasons. Adversaries could determine the value of the target based upon the movement of that target.

#### Man-in-the-Middle Attacks
The Access Stratum (AS) over-the-air User Plane traffic is not adequately protected by Integrity Protection security algorithms. This potentially translates to a scenario where a customer’s message and/or communication flow could be intercepted in the middle between the UE and the server. An adversary could manipulate the customer’s message and/or communication flow between the UE and the server.

#### LTE Roaming
LTE roaming is heavily dependent upon the SS7 and Diameter protocols.

Diameter is an authentication and authorization protocol defined in 1988 to supersede the RADIUS protocol. Both the SS7 and Diameter protocols have been used in large scale, and have had known security vulnerabilities that have been the focus of attacks for years.

Diameter and SS7 are vulnerable to eavesdropping including voice calls, reading text messages, and tracking phones. Some LTE roaming mobile network operators and mobile virtual network operators do not support VoLTE, so even if an operator has deployed VoLTE and its customer roams into an MNO/MVNO network that does not support VoLTE, then home networks must use SS7 for voice services for that roaming customer. Many operators have SS7 and/or Diameter firewalls but these firewalls are subject to a number of crossprotocol attacks.