# 國科會大專院校研究計畫

## 題目:Free5GC與Open5GS核心網路安全性之比較與分析 Comparative Security Analysis of Free5GC and Open5GS Core Networks

### (一)摘要:
核心網路在行動通訊系統扮演重要的角色，其承載了極大的控制平面以及用戶平面的流量，可知其內含有複雜的功能性與高承載，再加上未來網路架構將逐漸往軟體化及開源化方向發展，在公開原始碼的情況之下，許多漏洞都將浮現於大眾眼前，正因如此，開源免不了成為網路攻擊者具有吸引力的攻擊媒介。如今已有Free5GC與Open5GS兩大重要的開源 5G 核心網路平台。核心網路將有可能成為攻擊者的攻擊目標，例如，AMF與gNB之間的溝通，其兩者的溝通之間存在NGAP標準化通訊協定，在Free5GC中，一旦傳輸信息並不符合核心網路在行動通訊系統扮演重要的角色標準化規定，核心網路收到時將會存在崩潰的風險，這十分容易被攻擊者視作攻擊管道。然而Free5GC存在的漏洞風險並非完全適用於Open5GS，因為兩者之間的程式語言不盡相同，產生出的漏洞類型亦存在差異。本研究計畫旨在透過自行架設Free5GC與Open5GS，進行連線模擬，並嘗試將已知在Free5GC的漏洞與攻擊手法重現甚至改寫至 Open5GS，深入探討不同核心網路間可能遭受的攻擊模式，進一步探索相關防禦機制，以提高核心網路的通訊安全性，也藉此提高自我的核心網路理論與實作能力。

**關鍵字**:Free5GC、Open5GS、核心網路、O-RAN security、3GPP、O-RAN Alliance

### 英文摘要: (看要不要)

### (二)研究動機

核心網路（Core Network, CN）為行動通訊架構中的關鍵組成部分，5G 網路中，核心網路負責整個系統的運作與管理，其角色不僅是處理控制面與用戶面的流量，還包括提供網路存取、認證及資源分配等多項關鍵功能。因此，其安全性與穩定性會直接影響整個網路的可靠性。

隨著 SDR 與開源軟體的普及，實作 RAN 的成本大幅降低。其中，核心網路扮演著不可或缺的角色，是構建可用 RAN 的關鍵之一。而隨著開源軟體的發展，開源核心網路的數量也不斷增加，透過合法的開源網站分享原型、工具及程式碼，並允許大家共同使用或編輯，促進核心網路開發及專案整合。不僅提高了專案升級的速度，同時也增強了漏洞修復的能力。然而，開源的特性同時讓攻擊者更容易分析程式碼並尋找潛在漏洞，提升核心網路面臨的資安風險[19]。攻擊者可能利用這些漏洞傳遞惡意或不符合標準化規範的訊息至核心網路，導致核心網路癱瘓，造成訊息洩漏或其他損失。

本次研究將聚焦於行動通訊的資安問題，並嘗試透過架設基地台來探討信令交換或底層通訊相關的議題，以挖掘可能的漏洞。由於在 5G 核心網路中，存取和移動管理功能(Access and Mobility Management Function, AMF)具備透過 N1 介面與使用者設備（UE）進行雙向溝通的能力，且能直接影響 UE 的連線管理，因此極可能成為攻擊目標。基於此，本研究將探討 AMF 在信令交換過程中潛在的安全弱點，為 5G 網路核心系統的防護策略提供實證。

基於開源平台的核心網路環境，Free5GC 和 Open5GS 作為學術研究與實驗性應用的重要工具，由於架構和使用語言的差異，導致 Free5GC 存在的漏洞並非適用於 Open5GS。身為兩個常用且重要的開源 5G 核心網路平台，有必要來比較這兩者的漏洞情況，分析 Free5GC 的攻擊手法在 Open5GS 中是否適用，又或者 Open5GS 是否有其他漏洞風險，以驗證攻擊模式的普適性與平台特定性，為未來設計更安全的核心網路提供實證依據。Open5GS 與 Free5GC 在使用場景上各有側重，研究這兩者的漏洞風險，有助於不同應用場景下的安全部署策略。在此背景下，深入研究核心網路的安全性風險同時兼具了重要的學術與實務價值。特別是在 5G 乃至未來 6G 技術發展中，保障核心網路的穩定性與安全性是推動技術普及的重要前提。

### (四)文獻探討:
**4-1.核心路架構以及部分節點功能**
文獻[1]裡面提到5G 核心網路（Core Network）是 5G 通信系統的核心組成部分，負責管理用戶設備（UE）與網路資源之間的交互，以及用戶平面（User Plane）和控制平面（Control Plane）的通信。與傳統網路相比，5G 核心網採用 Service Based Architecture，因為其中的每個網路功能（Network Function, NF）是以微服務的形式進行通信，所以讓裡面的網路元件部署變得更為靈活、網路能力更開放。其中[2]Service Based Architecture如下圖

我們知道，網路功能包括接入與移動性管理功能（AMF）、會話管理功能（SMF）、用戶平面功能（UPF）、策略控制功能（PCF）、統一數據管理（UDM）以及認證伺服器功能（AUSF）。這些功能通過標準化介面進行互動，確保網路資源的高效分配和用戶的體驗。

在文獻[2]跟[3]中能得知圖片中部分節點的功能，NG-RAN 通過介面 N2 與接入和行動功能 （AMF） 連接，透過 N3 與使用者平面功能 （UPF） 連接，主要功能是轉發和路由，而 SMF（會話管理功能）和數據網路又通過 N4 介面和UPF連接。SMF 負責創建更新並刪除工作階段。它還使用UPF和IP位址分配管理會話上下文。AMF 負責訪問控制、註冊、移動性管理，並通過 N5 介面連接到控制平面。NSSF 為使用者設備選擇網路切片實例。NEF 可以安全地為第三方應用程式打開網路。NRF 負責的是維護由其他網路功能提供的服務更新記錄。UDM 可以生成身份驗證憑證，並根據訂閱數據授權訪問。AUSF 負責 3GPP 訪問和非 3GPP 訪問。控制平面的策略規則由PCF構建。AF 與 3GPP 核心網路連接，用於流量路由、策略框架交互等。

**4-2.核心網路安全問題**
根據文獻[4] 所述，5G 核心網路的服務化架構（SBA）中，網路功能（Network Functions, NFs）之間的通信主要依賴於 HTTP/2 協議。雖然 HTTP/2 在傳輸效率與多路複用等方面提供了性能優勢，但其協定複雜度也帶來潛在安全風險。歐盟網路與資訊安全局（ENISA）在其 5G 安全威脅報告[8] 中強調，伴隨 5G SBA 與微服務化技術的整合，若認證或授權流程出現疏漏，惡意攻擊者即可能利用 HTTP/2 的多路複用機制，對核心網路功能發動大規模拒絕服務（DoS）攻擊或攔截關鍵流量。此外，3GPP 在 TS 33.501[9] 第 4 與第 6 章中亦明確規範了 5G 系統的安全架構與保護程序，指出各 NF 間的 API 介面與服務註冊機制必須經嚴謹控管；若未妥善實作 HTTP/2 流控或限制 Flow ID 資源，攻擊者可透過大量偽造 Flow 或強行佔用流量資源，使合法 NF 無法獲取必要的通訊資源。另一方面，若同一 TCP 連接中被惡意插入具有 closed stream identifier 的 Flow，也易導致伺服器在處理流程上發生錯誤或崩潰[6]。

文獻[5] 中，Positive Technologies 的報告著重於網路存儲庫功能（NRF）及核心網路其他關鍵功能（如統一數據管理 UDM、訪問和移動管理功能 AMF 等）所可能存在的安全風險，包括使用者身份驗證漏洞、核心用戶配置檔洩露，以及偽造協定數據單元（PDU）會話等問題。基於他們對 GPRS 隧道協定（GTP）協定的深入分析：由於 GTP 本身欠缺對用戶實際位置的驗證機制，家庭網路無法有效區分來自訪客網路中使用者之「location set」信號的真實性，進而讓攻擊者可偽造位置資訊，於漫遊環境中發動計費詐欺、攔截或重放攻擊。此類風險不僅適用於 5G NSA 場景，同樣也可能影響 5G SA，只要網路仍依賴 GTP 進行封包隧道傳輸，就存在受攻擊的可能性[8]。

[7] 也提到，5G 認證和密鑰協議（AKA）雖然透過 SUCI（Subscription Concealed Identifier）及增強鑑權流程等方式來保護用戶隱私，但若無進一步防禦機制，一旦在無線通道中發生 SQN 不匹配攻擊或 SUCI 重放攻擊，便可能造成核心網路的鑑權流程混亂，使攻擊者有機會繞過安全機制。NIST 的行動通訊安全指南[11] 對此有更系統性的歸納，SP 800-187 全文闡述了 LTE 核心與 5G NSA 間架構銜接時的安全需求與漏洞，特別強調鑑權過程中主密鑰派生（KDF）與隨機數（nonce）生成的時效管控。該指南指出，若對 KDF 與 nonce 的生存時間與重複使用次數缺乏嚴格限制，攻擊者可透過攔截或重播 5G 流量的方式混淆核心網路的鑑權回應，進一步造成用戶隱私洩露或網路服務中斷。

至於 GTP 與 5G 網路互連安全層面，ETSI 在其 TS 129 281 V16.7.0[10] 中詳細定義了 GTP 協定在 4G/5G 環境中的技術需求與協定交互過程，並特別指出若核心網路對漫遊連結或跨營運商傳輸的封包檢驗不足，攻擊者可經由偽造位址及攔截訊號，繞過既有的邊界防護。在此情況下，攻擊者能利用 GTP Control Plane（GTP-C）與 GTP User Plane（GTP-U）多重層面上的弱點，執行位置偽造、惡意流量注入或攔截等攻擊。該規範也建議業者採取多層防禦（defense in depth）與位置核查策略（location-based validation），例如在核心網路與邊界防火牆間進行訊號合法性檢查以及漫遊連結稽核，一旦偵測到可疑的 GTP 請求或流量應立即封鎖或隔離，以降低大規模攻擊對 5G 核心網路的威脅。

在Nokia[12]、Ericsson[13] 與 Qualcomm[14] 各自的 5G 安全白皮書中也強調，為了確保 5G 網路的商用信任度與服務品質，必須在 RAN 與核心網路間實施多層次的檢測機制及彈性的存取控制策略，並持續透過威脅情報共享與動態升級安全策略來因應新型態的攻擊手法。這些建議在實際部署時，不僅能補強 5G 核心網路的防護，也對 6G 等未來網路演進打下更完善的安全基礎。
**4-3.Free5GC 與 Open5GS 相關資料**
文獻[15]針對三種開源 5G 核心網(Open5GS、Free5GC 和 OpenAirInterface）進行網頁技術的滲透測試，提出了針對其潛在漏洞的安全評估。他們使用了Microsoft 開發的一種threat modeling "STRIDE" [16] ，來識別可能影響 5G 核心的威脅，對三種開源 5G 核心網(Open5GS、Free5GC 和 OpenAirInterface）進行測試，以評估它們的安全性。其中他們也使用Nmap、Nikto、Dirbuster and Dirb作為幾種安全工具。下圖是 5G 核心網上測試的攻擊之間的比較:
圖片結果跟文獻提到，Open5GS很容易受到Permissions leakage,NoSQL injections這種暴露的影響，在實驗可實行的攻擊阻擋率約44.4%，則Free5GC阻擋率約77.8%，則OAI因為有多種攻擊手法無法實施，所以無法確定實驗成果有效性，但是以從 Web 技術的角度僅比較Free5GC與Open5GS的話，Free5Gc 是兩者分析中最安全的。

在CVE-2022-43677[17]中也找到相關Free5GC的漏洞，這個漏洞是針對5G基礎設施的，其中裡面內容提到，這是由格式不正確的 NGAP 訊息所引發的漏洞，會在 aper.GetBitString 函數中造成索引範圍錯誤，從而導致 AMF 和 NGAP 解碼器崩潰。在[18]中有說明，之所以會造成崩潰是因為原本過程代碼 （0x0028） 是一條 UEContextModification 消息。這個消息原本是應該從AMF發送到 gNB的。但在這種情況下，卻是從 gNB 發送到 AMF 的。所以當Free5GC收到這個封包，AMF就會崩潰。
在test.go中，有一段程式碼:
此程式碼就是透過TLV的正規表達式，表達不正規的東西，以程式碼為例，這段可能表達的是整段訊息的總長度為 40 byte
然後當中的0x00應該都是T的部分，0x28都是L的部分，其餘都是V
AMF會需要NGAP跟他做溝通，溝通的內容其實就是gNB的UE資訊在接手和換手東西，NGAP需要有正規表達式（TLV），這個漏洞就是看準這個需要正規表達式的原理，將錯誤的格式塞進AMF的功能裡面，讓他執行，導致buffer overflow。

文獻總結:
綜合文獻可知，5G 核心網路在 SBA 架構下不僅帶來靈活與效率，也使得攻擊面更為多元；Free5GC 與 Open5GS 作為目前常用的開源 5G 核心網平台，各自具備不同的程式語言基礎與安全特性。多份研究強調了 Free5GC 在 NGAP、HTTP/2 協定上的已知漏洞，Open5GS 則是在 API 權限與資料庫操作中顯示較高風險。然而，這些漏洞能否「跨平台」重現或改寫仍需實證驗證。
透過文獻也說明，沒有任何一個核心網路平台存在絕對安全。在 CVE-2022-43677[17]、[18] 也說明其道理。部分文獻雖然已使用滲透測試進行評估，然而核心網路層面，特別是訊息解析、協定流程檢驗的深入測試相對較少，跨平台測試更是如此。透過實際發送異常 NGAP / GTP 封包、或改寫 CVE 攻擊流程，有助於檢驗 Open5GS 在控制面與使用者平面遇到攻擊時的應變與防禦能力。

### (五)研究方法:

本研究的方法分為四個主要階段，包括實驗環境建置、目標漏洞選擇與攻擊情境設定、攻擊手法改寫與測試程式開發，以及最終的攻擊測試與壓力負載評估。各階段將透過理論與實際操作並進的方式，確保在不同核心網路平台上能重現相同或類似的安全弱點，進而分析其成因與對系統穩定性的影響。

5-1　實驗環境建置
本階段主要目的在於建立能同時運行 Free5GC 與 Open5GS 的整合環境。硬體方面，預計使用具備至少 8 至 16 核心的 CPU、16GB 記憶體以及 128GB 以上儲存空間的伺服器或虛擬機，以確保在高負載或施加攻擊時仍具備足夠資源。作業系統將選擇 Ubuntu 20.04 或 22.04 LTS，考量到此版本在相容性與長期支援方面較為成熟。完成系統安裝與基礎設定後，分別安裝 Free5GC 與 Open5GS，並將兩者配置於不同虛擬機或容器（如 Docker）內，避免相互干擾或衝突。接著，使用 UERANSIM 作為 UE 模擬工具，驗證兩個平台是否能正常完成 UE 註冊、PDU Session 建立及數據傳輸等基本功能，同時透過核心網路元件（AMF、SMF、UPF、AUSF、UDM 等）日誌檔，觀察是否能正確顯示運作狀態。

5-2　目標漏洞選擇與攻擊情境設定
為了能在多種環境下測試核心網路架構的安全性，第二階段的核心目標是精確鎖定對 5G 核心網路安全具威脅的漏洞與攻擊手法。本研究將參考 Free5GC 已公開的相關漏洞（common vulnerabilities and exposures，CVE），特別是與 NGAP、GTP、HTTP/2 等協定實現有關的弱點，並鎖定可能導致系統崩潰、拒絕服務（DoS）或其他高風險影響的案例。篩選時會優先考慮已有公開的概念驗證程式（PoC），以確保漏洞能真實重現並可在合理時間內完成實驗。同時我們也會針對 Open5GS 的程式架構進行初步分析，確定該漏洞或攻擊向量有機會被移植或改寫，從而比較不同平台在協定實作上的安全性差異。在攻擊情境方面，我們會綜合考量多種攻擊者模型（如惡意 UE、gNB 或外部封包注入工具）設計多元的攻擊情境，包含從控制面（AMF、SMF）到使用者平面（UPF），以確定研究結果能涵蓋核心網路中的關鍵部位。相關攻擊來源除了使用惡意 UE 或 gNB 之外，也可能直接透過 Scapy、pcap-edit 或自行開發的程式語言（Golang、C、Python）生成畸形封包，藉此評估各平台對協定異常的容忍度。

5-3　攻擊手法改寫與測試程式開發
在確認目標漏洞後，首先於 Free5GC 環境中驗證既有攻擊流程的可行性。若社群或 GitHub 上已提供概念驗證（PoC）程式，將先測試並收集相關日誌與系統反應，進一步分析原始碼中與 NGAP、GTP 或 HTTP/2 解碼流程相關的函式（例如 Golang 中的 aper.GetBitString 或其他協定處理模組），找出漏洞觸發的邏輯。此一過程能協助掌握攻擊關鍵點，為移植攻擊至 Open5GS 做好準備。接下來，則針對 Open5GS 的 C 原始碼尋找與前述功能對應的協定處理路徑（如 nas_5gs_xxx.c、ngap-handler.c），重新撰寫或改寫攻擊程式邏輯，使其向 Open5GS 注入不當參數（例如錯誤的封包長度、超範圍索引值、異常型別等）。同時也會開發或優化測試腳本（Python、C 或 Golang），以實際發送畸形封包的方式檢驗是否能成功在 Open5GS 中重現或觸發類似的漏洞。

5-4　攻擊測試與壓力負載評估
為了確保實驗結果的完整性，在攻擊測試前會先驗證 Free5GC 與 Open5GS 在無攻擊干擾下的穩定度，例如同時讓多部 UE 附著並進行資料傳輸，觀察系統是否有潛在錯誤或資源瓶頸。接著，於系統正常運作的情況下，逐步施加不同頻率的惡意封包注入，包括每秒一筆的低強度攻擊，以及每秒百筆以上的高強度攻擊。此時將密切監控 CPU、記憶體使用率、網路封包丟失率與日誌錯誤資訊，判斷是否出現預期或超出預期的故障現象。最後，透過增加 UE 數量（如 10、100、500 等規模）進行負載測試，觀察核心網路在不同壓力下的脆弱度與對攻擊的抵禦能力，並透過紀錄和對比各項性能與錯誤指標，分析 Free5GC 與 Open5GS 各自的優劣勢。此一實驗設計能充分展現兩個平台在面對高壓力與惡意攻擊時的表現差異，亦為後續提出強化建議提供科學化依據。

### (六) 研究進度與規劃(還要再改)

| **階段** | **內容** | **預計時間** |
|----------------------|------------------------------------------------------------------|--------------|
| **第 1 階段**: 環境建置與初步測試 | - 安裝並熟悉 Free5GC、Open5GS 平台<br>- 完成 UE 模擬工具整合與測試 | 1 個月 |
| **第 2 階段**: 漏洞蒐集與分析 | - 透過 CVE 資料庫及文獻蒐集 Free5GC 漏洞<br>- 製作漏洞分析報告與攻擊手法清單 | 1~2 個月 |
| **第 3 階段**: 攻擊手法改寫與實驗 | - 對應程式碼邏輯，進行攻擊手法在 Open5GS 上的移植<br>- 設計並執行跨平台攻擊模擬實驗 | 2 個月 |
| **第 4 階段**: 結果分析與防禦機制探討 | - 分析實驗數據，定位平台差異<br>- 提出修補建議及防禦機制評估 | 2 個月 |
| **第 5 階段**: 成果彙整與報告撰寫 | - 統整整體研究結果並撰寫報告<br>- 提出未來研究建議 | 1~2 個月 |

### (七)預期結果:

1.結果紀錄與資料分析
將透過收集並比對 Free5GC 與 Open5GS 的系統 Logs，以及使用 Wireshark 擷取之封包追蹤檔，來觀察系統在崩潰前後的行為變化與關鍵訊息。這些 Logs 與封包紀錄能夠協助我們釐清在攻擊過程中，哪些模組或服務最容易受到衝擊，並進一步定位可能的漏洞來源。

2.量化攻擊指標
為了更有效量化攻擊影響，本研究會以「攻擊成功率（造成崩潰或重大異常之次數 / 攻擊嘗試次數）」、「系統中斷時長」以及「封包誤碼率」等指標作為主要統計依據，並將這些數據以具體數值形式呈現。透過繪製折線圖或長條圖，則可更直觀地展現「攻擊強度」與「系統異常」之間的關聯程度，使其藉由視覺化呈現出不同攻擊模式的影響規模。

3.綜合分析
此部分將進行跨平台之間的攻擊比較，比較 Free5GC 與 Open5GS 在相同攻擊腳本下的防禦表現。具體觀測指標包括崩潰頻率、UE 連線中斷率以及資源消耗情形等，以量化雙平台在面對類似威脅時的穩定度與效率，進一步釐清哪些攻擊手法能夠在兩者平台之間奏效，又有哪些僅針對單一平台的程式語言或協定實作特性才能觸發漏洞，從而歸納出漏洞的普適性。

### (八)需要指導教授指導的內容:

1.核心網路架構與差異
Golang 與 C 之間的漏洞表現方式不同，如何將 Free5GC 中的漏洞映射到 Open5GS 需要深入的程式碼分析與測試以及在NGAP / GTP 通訊的實作之中，諸多流程細節仍須請教。

2.Free5GC 與 Open5GS 的漏洞驗證與攻擊測試
在漏洞呈現階段，需要測試惡意封包（NGAP/GTP）是否真的能造成核心網崩潰，可能需要設計測試腳本，此涉及 Golang 和 C 語言的低層次網路協議處理，因此在開發與設計方面，需要投入較深入的程式能力。確保所建構攻擊腳本能隨著不同攻擊情境（例如不同流量型態、不同協定層級的惡意封包）進行靈活調整。在此部分，需要教授的指導以協助評估程式架構是否能支援各種壓力測試，同時確認工具所產生的流量、封包參數設定等細節能與實務中的威脅情境相符合。同時也需要教授指導使用 Wireshark監測異常封包，並分析攻擊影響。

3.量化指標與效能評估
成果呈現主要注重於如何量化攻擊所造成的影響，並進一步評估在不同攻擊情境下，系統的穩定度與安全性。為了達成這個目標，首要的關鍵便是選擇合適的量測指標，例如 CPU 使用率、記憶體占用量、網路封包錯誤率等。這些指標能夠充分反映攻擊壓力對系統資源的消耗程度與運作效率的影響。因此，如何從眾多可觀測的參數中挑選最能準確代表攻擊衝擊的指標，仍需與教授進行討論與確認，以確保最終的觀察與分析更具客觀性。

### (九)參考文獻:
[1] "White Paper on 5G Network Technology Architecture", hut-2020 (5G), pp. 5, 2015.
[2] S. Zhou, X. Liu, D. Fu, X. Cheng, B. Fu and Z. Zhao, "5G Core Network Framework Based on Artificial Intelligence," 2020 IEEE Intl Conf on Parallel & Distributed Processing with Applications, Big Data & Cloud Computing, Sustainable Computing & Communications, Social Computing & Networking (ISPA/BDCloud/SocialCom/SustainCom), Exeter, United Kingdom, 2020, pp. 1460-1464, doi: 10.1109/ISPA-BDCloud-SocialCom-SustainCom51426.2020.00219
[3] Javid and S. Khara, "5G Network: Architecture, Protocols, Challenges and Opportunities," 2022 International Conference on Computing, Communication, and Intelligent Systems (ICCCIS), Greater Noida, India, 2022, pp. 1-5, doi: 10.1109/ICCCIS56430.2022.10037605.
[4] X. Hu, C. Liu, S. Liu, W. You and Y. Zhao, "Signalling Security Analysis: Is HTTP/2 Secure in 5G Core Network?," 2018 10th International Conference on Wireless Communications and Signal Processing (WCSP), Hangzhou, China, 2018, pp. 1-6, doi: 10.1109/WCSP.2018.8555612.
[5] Q. Tang, O. Ermis, C. D. Nguyen, A. D. Oliveira and A. Hirtzig, "A Systematic Analysis of 5G Networks With a Focus on 5G Core Security," in IEEE Access, vol. 10, pp. 18298-18319, 2022, doi: 10.1109/ACCESS.2022.3151000.
[6] "HTTP/2: In-depth analysis of the top four faws of the next generation web protocol", 2016.
[7] Z. Yan, C. Gu, Y. Gu and H. Huang, "Security Verification and Improvement of 5G AKA Protocol Based on Petri-net," 2021 IEEE/CIC International Conference on Communications in China (ICCC), Xiamen, China, 2021, pp. 11-16, doi: 10.1109/ICCC52777.2021.9580325.
[8]ENISA, “ENISA Threat Landscape for 5G Networks,” Nov. 2021.:'https://www.enisa.europa.eu/publications/enisa-threat-landscape-for-5g-networks'
[9]3GPP, “TS 33.501, Security architecture and procedures for 5G system(Release17),”
[10]ETSI, “ETSI TS 129 281 V16.7.0: Digital cellular telecommunications system (Phase 2+) (GSM); Universal Mobile Telecommunications System (UMTS); LTE; 5G; GPRS Tunnelling Protocol (GTP) across the Gn and Gp interface and eGTP across S5/S8 and S4; Stage 3 (3GPP TS 29.281 Release 16),” 2021.
[11]NIST, “SP 800-187 Guide to LTE Security,”
[12]Nokia, “Evolving 5G Security to Protect the Future,” 2022.
[13]Ericsson, “The critical role of security in 5G,” 2022.
[14]Qualcomm, “The 5G Security Imperative,” 2022.
[15] F. Giambartolomei, M. Barceló, A. Brighente, A. Urbieta and M. Conti, "Penetration Testing of 5G Core Network Web Technologies," ICC 2024 - IEEE International Conference on Communications, Denver, CO, USA, 2024, pp. 702-707,
[16] A. Shostack, "Experiences threat modeling at microsoft", MODSEC@ MoDELS, vol. 2008, pp. 35, 2008.
[17]CVE-2022-43677:'https://github.com/free5gc/free5gc/issues/402'
[18]Attacks on 5G Infrastructure From User Devices: ASN.1 Vulnerabilities in 5G Cores'https://www.trendmicro.com/en_us/research/23/j/asn1-vulnerabilities-in-5g-cores.html'