安全要求和功能
一般安全要求
緩解和降低攻擊請求
攻擊者可以通過使UE和網絡實體分別認爲對方不支持安全功能來嘗試降低攻擊，即使雙方實際上都支持該安全功能。 應確保在上述意義上可以防止出價下降。
身份驗證和授權
5G系統應滿足以下要求。
用戶認證：服務網絡應在UE與網絡之間的認證和密鑰協商過程中認證訂購永久標識符（SUPI）。服務網絡認證：UE應通過隱式密鑰認證認證服務網絡標識符。
注 1： 這裏“隱式密鑰認證”的含義是通過在後續過程中成功使用由認證和密鑰協議產生的密鑰來提供認證。
注 2： 前述要求並不意味着UE在服務網絡內認證特定實體，例如AMF。
UE授權：服務網絡應通過從歸屬網絡獲得的用戶簡檔授權UE； UE授權基於經過身份驗證的SUPI。
由歸屬網絡提供網絡授權：應向UE提供保證，確保它連接到由歸屬網絡授權爲UE提供服務的服務網絡。 這種授權是“隱含的”，因爲它是由成功的身份驗證和密鑰協議運行所暗示的。
接入網絡授權：應向UE提供保證，確保它連接到由服務網絡授權爲UE提供服務的接入網絡。 這種授權是“隱含的”，因爲它是由成功建立接入網絡安全所暗示的。 此接入網絡授權適用於所有類型的接入網絡。
未經認證的緊急服務：爲了滿足某些地區的監管要求，5G系統應支持未經認證的接入用於緊急服務。 此要求適用於所有ME，僅適用於存在未經認證的緊急服務的監管要求的服務網絡。 位於禁止未經認證的緊急服務的地區的服務網絡不得支持此功能。
與密鑰相關的5GC和5G-RAN要求
5GC和5G-RAN應允許使用加密和完整性保護算法，用於具有128位長度密鑰的AS和NAS保護。 網絡接口應支持256位密鑰的傳輸。
用於UP，NAS和AS保護的密鑰應取決於使用它們的算法。
對UE的要求
一般要求
UE和ng-eNB之間的加密和完整性保護的支持和使用與TS 33.401 [10]中規定的UE和eNB之間的加密和完整性保護的支持和使用相同。
PEI應安全地存儲在UE中，以確保PEI的完整性。
用戶數據和信令數據機密性
UE應支持在UE和gNB之間加密用戶數據。
UE將根據gNB發送的指示激活用戶數據的加密。
UE應支持RRC和NAS信令的加密。
UE應實現以下加密算法：
- NEA0,128-NEA1,128-NEA2，如本文件附件D中所定義。
UE可以實現以下加密算法：
- 128-NEA3，如本文件附件D中所定義。
如果UE支持連接到5GC的E-UTRA，則它應實現TS 33.401 [10]中規定的加密算法。
UE和gNB之間的用戶數據的機密性保護是可選的。
RRC信令的機密性保護和NAS信令是可選的。
只要法規允許，就應該使用保密措施。
用戶數據和信令數據完整性
UE應支持UE和gNB之間用戶數據的完整性保護和重放保護。
UE應根據gNB發送的指示激活用戶數據的完整性保護。
UE應支持RRC和NAS信令的完整性保護和重放保護。
UE應實現以下完整性保護算法：
NIA0,128-NIA1,128-NIA2，如本文件附件D中所定義。
UE可以實現以下完整性保護算法：
128-NIA3，如本文件附件D中所定義。
如果UE支持連接到5GC的E-UTRA，則它應實現TS 33.401 [10]中規定的完整性算法。
UE和gNB之間的用戶數據的完整性保護是可選的。
注 ： 用戶平面的完整性保護增加了數據包大小的開銷，並增加了UE和gNB中的處理負載。
除以下情況外，必須使用RRC信令和NAS信令的完整性保護：
除TS 24.501 [35]中明確列出的那些之外的所有NAS信令消息都應受到完整性保護。
除了未經驗證的緊急呼叫之外，除了在TS 38.331 [21]中明確列出的那些作爲例外的那些之外的所有RRC信令
消息應該使用與NIA0不同的完整性保護算法進行完整性保護。
UE應實現NIA0以實現NAS和RRC信令的完整性保護。 NIA0僅允許使用第10.2.2節中規定的未經認證的緊急會話。
安全存儲和處理用戶憑據
以下要求適用於存儲和處理用於接入 5G網絡的用戶憑證：
用戶憑證應使用防篡改安全硬件組件在UE內進行完整性保護。
用戶憑證（即K）的長期密鑰應使用防篡改安全硬件組件在UE內受到機密性保護。
用戶憑證的長期密鑰永遠不會在防篡改安全硬件組件的外部清晰可用。
使用用戶憑證的認證算法應始終在防篡改安全硬件組件內執行。
應該可以根據防篡改安全硬件組件的相應安全要求執行安全評估/評估。
注 ： 用於防篡改安全硬件組件的安全評估的安全評估方案超出了3GPP規範的範圍。
用戶隱私
UE應支持5G-GUTI。
除路由信息外，不應通過5G-RAN以明文形式傳送SUPI，例如移動國家代碼（MCC）和移動網絡代碼（MNC）。
歸屬網絡公鑰應存儲在USIM中。
保護方案標識符應存儲在USIM中。
ME應支持零方案。
如果歸屬網絡尚未在USIM中配置歸屬網絡公鑰，則不提供初始註冊過程中的SUPI保護。 在這種情況下，ME應使用零方案。
根據USIM指示的歸屬運營商的決定，SUCI的計算應由USIM或ME執行。
注 1： 如果該指示不存在，則計算在ME中。
如果是未經認證的緊急呼叫，則不需要SUPI的隱私保護。
在USIM中供應和更新歸屬網絡公鑰應由歸屬網絡運營商控制。
注 2： 歸屬網絡公鑰的提供和更新超出了本文檔的範圍。 它可以使用例如空中下載（OTA）機制來實現。
用戶隱私啓用應在用戶的歸屬網絡的控制之下。
在NAS安全上下文建立後，UE只應在NAS協議中發送PEI，除非在緊急註冊期間不能建立NAS安全上下文。
路由指示符應存儲在USIM中。 如果USIM中不存在路由指示符，則ME應將其設置爲TS 23.003 [19]中定義的默認值。
對gNB的要求
一般要求
安全要求適用於所有類型的gNB；可以在其他3GPP規範中定義對特定類型的gNB的更嚴格的要求。
用戶數據和信令數據機密性
gNB應支持在UE和gNB之間加密用戶數據。
gNB應根據SMF發送的安全策略激活用戶數據的加密。
gNB應支持RRC信令的加密。
gNB應實現以下加密算法：
- NEA0,128-NEA1,128-NEA2，如本文件附件D中所定義。
gNB可以實現以下加密算法：
- 128-NEA3，如本文件附件D中所定義。
UE和gNB之間的用戶數據的機密性保護是可選的。
RRC信令的機密性保護是可選的。
只要法規允許，就應該使用保密措施。
用戶數據和信令數據完整性
gNB應支持UE和gNB之間的用戶數據的完整性保護和重放保護。
gNB應根據SMF發送的安全策略激活用戶數據的完整性保護。
gNB應支持RRC信令的完整性保護和重放保護。
gNB應支持以下完整性保護算法：
- NIA0,128-NIA1,128-NIA2，如本文件附件D中所定義。
gNB可以支持以下完整性保護算法：
- 128-NIA3，如本文件附件D中所定義。
UE和gNB之間的用戶數據的完整性保護是可選的，不得使用NIA0。
注 ： 用戶平面的完整性保護增加了數據包大小的開銷，並增加了UE和gNB中的處理負載。 NIA0將增加32位MAC的不必要開銷，沒有安全優勢。
除了未經驗證的緊急呼叫之外，除了在TS 38.331 [21]中明確列出的那些作爲例外的那些之外的所有RRC信令
消息應該使用與NIA0不同的完整性保護算法進行完整性保護。
在未經認證的緊急會話支持不是監管要求的部署中，應在gNB中禁用NIA0。
gNB設置和配置的要求
通過O＆M系統設置和配置gNB應由gNB進行認證和授權，以便攻擊者無法通過本地或遠程接入修改gNB設置和軟件配置。
對於gNB，應支持TS 33.310 [6]中爲基站指定的證書註冊機制。 關於是否使用註冊機制的決定由運營商決定。
O＆M系統與gNB之間的通信應保密，完整和重播，以防止未經授權的各方。 應支持gNB與運營商信任的5G核心或O＆M域中的實體之間的安全關聯。 這些安全關聯機構應相互認證。 安全關聯應根據TS33.210 [3]和TS 33.310 [5]實現。
gNB應能夠確保授權軟件/數據更改嘗試。
gNB應使用授權數據/軟件。
啓動過程的敏感部分應在安全環境的幫助下執行。
應確保向gNB傳輸軟件的機密性。
應確保軟件向gNB傳輸的完整性保護。
gNB軟件更新應在安裝前進行驗證。
gNB內部密鑰管理的要求
5GC爲gNB提供用戶特定會話密鑰材料，其還保存用於認證和安全關聯設置目的的長期密鑰。 保護所有這些密鑰非常重要。 以下要求適用：
以明文形式存儲或處理密鑰的gNB部署的任何部分都應受到保護，以免受到物理攻擊。 如果不是，則將整個實體放置在物理上安全的位置，然後將在安全的環境中存儲和處理明文中的密鑰。 存儲在gNB任何部分的安全環境中的密鑰永遠不會離開安全環境，除非按照此規範或其他3GPP規範完成。
處理gNB的用戶平面數據的要求
以明文形式存儲或處理用戶平面數據的gNB部署的任何部分都應受到保護，以免受到物理攻擊。 如果不是，則將整個實體放置在物理上安全的位置，然後將在安全的環境中存儲和處理明文中的用戶平面數據。
處理gNB的控制平面數據的要求
以明文形式存儲或處理控制平面數據的gNB部署的任何部分都應受到保護，免受物理攻擊。 如果不是，則將整個實體放置在物理上安全的位置，然後以安全的環境存儲和處理明文中的控制平面數據。
對gNB安全環境的要求
安全環境在gNB內邏輯定義。 它確保所有敏感信息和操作的保護和保密，防止任何未經授權的接入或暴露。
以下列表定義了安全環境的要求：
安全環境應支持敏感數據的安全存儲，例如長期加密機密和重要配置數據。
安全環境應支持敏感功能的執行，例如用戶數據的解密/解密以及使用長期祕密的協議內的基本步驟（例如，在認證協議中）。
安全環境應支持執行引導過程的敏感部分。
應確保安全環境的完整性。
只有授權的接入才能被授予安全環境，即在其中存儲和使用的數據，以及在其中執行的功能。
gNB F1接口的要求
下面給出的要求適用於使用TS 38.470 [31]中定義的F1接口的具有分離DU-CU實現的gNB。 信令流量（即TS38.470 [31]中定義的F1-C接口管理流量和TS 38.472 [32]中定義的F1-C信令承載和用戶平面數據都可以在給定DU與其CU之間的F1接口上發送。
F1-C接口應支持機密性，完整性和重播保護。
通過CU-DU 鏈路承載的所有管理流量應保持完整性，機密性和重播保護。
gNB應支持用戶平面的gNB DU-CU F1-U接口[33]的機密性，完整性和重放保護。
通過CU-DU 鏈路承載的F1-C和管理流量應獨立於F1-U流量進行保護。
注 ： 上述要求允許對CU-DU上的所有其他流量（例如，F1-C上的流量）不同地保護F1-U（包括關閉或打開F1-U的完整性和/或加密）。
gNB E1接口的要求
下面給出的要求適用於具有拆分DU-CU實現的gNB，特別是使用TS 38.460 [41]中定義的E1接口在CU-CP和CU-UP之間的開放接口。
CU-CP和CU-UP之間的E1接口應具有機密性，完整性和重放保護
對ng-eNB的要求
ng-eNB的安全要求如TS 33.401 [10]中針對eNB所規定。
對AMF的要求
信令數據機密性
AMF應支持NAS信令的加密。
AMF應支持以下加密算法：
- NEA0,128-NEA1,128-NEA2，如本文件附件D中所定義。
AMF可能支持以下加密算法：
- 128-NEA3，如本文件附件D中所定義。
機密性保護NAS信令是可選的。
只要法規允許，就應該使用保密措施。
信令數據完整性
AMF應支持NAS信令的完整性保護和重放保護。
AMF應支持以下完整性保護算法：
- NIA-0,128-NIA1,128-NIA2，如本文件的附錄D中所定義。
AMF可能支持以下完整性保護算法：
- 128-NIA3，如本文件附件D中所定義。
在未經認證的緊急會話的支持不是監管要求的部署中，AMF應在AMF中禁用。
除TS 24.501 [35]中明確列出的那些之外的所有NAS信令消息都應該使用與NIA-0不同的算法進行完整性保護，緊急呼叫除外。
用戶隱私
AMF應支持使用SUCI觸發主要認證。
AMF應支持將5G-GUTI分配給UE。
AMF應支持將5G-GUTI重新分配給UE。
AMF應能夠從UE和歸屬網絡確認SUPI。 如果此確認失敗，AMF將拒絕向UE提供服務。
對SEAF的要求
安全錨功能（SEAF）通過服務網絡中的AMF提供認證功能。 SEAF應滿足以下要求：
- SEAF應支持使用SUCI的主要認證。
對UDM的要求
一般要求
用於認證和安全關聯設置目的的長期密鑰應受到保護，免受物理攻擊，並且永遠不會離開UDM的安全環境。
與UDM和SIDF相關的用戶隱私相關要求
SIDF負責撤銷SUCI，並應滿足以下要求：
- SIDF應是UDM提供的服務。
- SIDF將基於用於生成SUCI的保護方案從SUCI解析SUPI。
用於保護用戶隱私的歸屬網絡密鑰應受到保護，以免受UDM中的物理攻擊。
當私有/公共密鑰對用於用戶隱私時，UDM應保存密鑰標識符。
用於用戶隱私的算法應在UDM的安全環境中執行。
對AUSF的要求
認證服務器功能（AUSF）應處理3GPP 接入和非3GPP 接入的認證請求。
如果VPLMN發送了SUCI的認證請求，AUSF應僅在認證確認後向VPLMN提供SUPI。
AUSF應通知UDM已成功或不成功的用戶認證。
核心網絡安全
信任邊界
對於本子條款中的一組要求，假設移動網絡運營商將其網絡細分爲信任區域。 假設不同運營商的子網位於不同的信任區域。 跨越信任邊界的消息應遵循本文件第5.9.2節的要求，如果不是由TS 33.210 [3]中規定的NDS / IP端到端保護的話。
服務註冊，發現和授權的安全要求
基於NF服務的發現和註冊應支持機密性，完整性和重播保護。
NRF應能夠確保NF發現和註冊請求得到授權。
基於NF服務的發現和註冊應能夠在一個管理/信任域中隱藏來自不同信任/管理域中的實體的可用/支持的NF的拓撲（例如，在被訪問的NF和歸屬網絡之間）。
NF服務請求和響應流程應支持NF消費者和NF生產者之間的相互認證。
每個NF都應驗證所有傳入的消息。 根據協議規範和網絡狀態無效的消息應被NF拒絕或丟棄。
NRF安全要求
網絡存儲庫功能（NRF）從NF實例接收NF發現請求，將所發現的NF實例的信息提供給NF實例，並維護NF配置文件。
以下基於NRF服務的體系結構安全性要求適用：
- 請求服務的NRF和NF應相互認證。
- NRF可以向NF提供認證和授權，以在彼此之間建立安全通信
NEF安全要求
網絡曝光功能（NEF）支持將網絡功能的功能外部暴露給應用功能，應用功能通過NEF與相關的網絡功能進行交互。
NEF和應用功能之間的接口應滿足以下要求：
- 應支持NEF和應用功能之間通信的完整性保護，重放保護和機密性保護。
- 應支持NEF和應用功能之間的相互認證。
- 內部5G核心信息（如DNN，S-NSSAI等）不得發送到3GPP運營商域之外。
- NEF不應將SUPI發送到3GPP運營商域之外。
NEF應能夠確定應用功能是否被授權與相關的網絡功能進行交互。
e2e核心網互聯安全的要求
一般要求
本子條款包含子條款5.9.2和5.9.3的共同要求。
e2e核心網互聯安全解決方案應滿足以下要求。
該解決方案應支持應用層機制，用於由中間節點添加，刪除和修改消息元素，除了本文檔中描述的特定消息元素。
注 ： 這種情況的典型示例是IPX提供商修改消息以用於路由目的。
該解決方案應爲源文件和目標網絡之間的端到端提供本文檔中標識的特定消息元素的機密性和/或完整性。
爲滿足此要求，SEPP-cf [2]，第6.2.17條應存在於專用於處理e2e核心網互連安全的源和目標網絡的邊緣。 在源PLMN和目的地PLMN的兩個SEPP之間提供消息元素的機密性和/或完整性。
目標網絡應能夠確定發送根據前一個項目保護的特定消息元素的源網絡的真實性。 爲滿足此要求，目標網絡中專用於處理e2e核心網互連安全的SEPP可以確定源網絡的真實性。
該解決方案應該對3GPP定義的網絡元素產生最小的影響和增加。
解決方案應該使用標準安全協議。
解決方案應涵蓋用於漫遊目的的接口。
解決方案應考慮性能和開銷的考慮因素。
解決方案應包括防止重放攻擊。
解決方案應包括算法協商和防止降價攻擊。
解決方案應考慮密鑰管理的操作方面。
安全邊緣保護代理（SEPP）的要求
SEPP應充當非透明代理節點。
SEPP應保護屬於使用N32接口的不同PLMN的兩個NF之間的應用層控制平面消息。
SEPP應在漫遊網絡中與SEPP進行密碼套件的相互認證和協商。
SEPP將處理密鑰管理方面，涉及設置在兩個SEPP之間保護N32接口上的消息所需的加密密鑰。
SEPP應通過限制外部各方可見的內部拓撲信息來執行拓撲隱藏。
作爲反向代理，SEPP應提供單點接入並控制內部NF。
接收SEPP應能夠驗證發送的SEPP是否被授權在接收的N32消息中使用PLMN ID。
SEPP應能夠清楚地區分用於認證對等SEPP的證書和用於認證執行消息修改的中間體的證書。
注 1：例如，通過實施單獨的證書存儲，可以實現這種區分。
SEPP應丟棄格式錯誤的N32信令消息。
SEPP應實施速率限制功能，以保護自身和隨後的NF免受過度CP信號的影響。 這包括SEPP到SEPP信令消息。
SEPP應實現反欺騙機制，以實現源和目標地址和標識符（例如FQDN或PLMN ID）的跨層驗證。
注 2：這種反欺騙機制的示例如下：如果消息的不同層之間存在不匹配或者目的地地址不屬於SEPP自己的PLMN，則丟棄該消息。
保護屬性
完整性保護應適用於通過N32接口傳輸的所有屬性。
機密性保護應適用於SEPP的數據類型加密策略（第13.2.3.2節）中指定的所有屬性。 無論數據類型加密策略如何，通過N32接口發送時，以下屬性應受機密性保護：
- 認證向量
- 密碼材料
- 位置數據，例如小區 ID和物理小區 ID
通過N32接口發送時，以下屬性還應受到機密性保護： - SUPI
可見性和可配置性
安全可見性
雖然通常安全功能應對用戶或應用流程透明，但對於某些事件以及根據用戶或應用流程的關注，應提供以下安全功能操作的更高可見性：
- AS機密性:( AS機密性，機密性算法，承載信息）
- AS完整性:( AS完整性，完整性算法，承載信息）
- NAS機密性:( NAS機密性，機密性算法）
- NAS完整性:( NAS完整性，完整性算法）
UE應按照每個PDU會話粒度向UE中的應用流程（例如，通過API）提供上述安全信息。
服務網絡標識符應可用於UE中的應用流程。
安全可配置性
安全配置允許用戶在UE上配置某些安全功能設置，允許用戶管理其他功能或使用某些高級安全功能。
應提供以下可配置性功能：
- 如TS 33.401 [10]所述，在沒有認證的情況下向XIM授予或拒絕接入。
算法要求和算法選擇
算法標識符值
加密算法標識符值
所有標識符和名稱均適用於5G NAS和新無線。 關於AS能力，連接到5GC的E-UTRAN的標識符和名稱在TS 33.401 [10]中規定,爲每個加密算法分配一個4位標識符， 定義了以下加密算法值：
“0000 2 ”NEA0 空加密算法;
“0001 2 ”128-NEA1 基於128位SNOW 3G的算法;
“0010 2 ”128-NEA2 基於128位AES的算法; 和
“0011 2 ”128-NEA3 基於128位ZUC的算法。
128-NEA1基於SNOW 3G（參見TS 35.215 [14]）。
128-NEA2基於CTR模式下的128位AES [15] [16]。
128-NEA3基於128位ZUC（參見TS 35.221 [18]）。
完整性算法標識符值
所有標識符和名稱均適用於5G NAS和新無線。 關於AS能力，連接到5GC的E-UTRAN的標識符和名稱在TS 33.401 [10]中規定，用於5G的每個完整性算法將被分配一個4位標識符；定義了以下完整性算法值：
“0000 2 ”NIA0 空完整性保護算法;
“0001 2 ”128-NIA1 基於128位SNOW 3G的算法;
“0010 2 ”128-NIA2 基於128位AES的算法; 和
“0011 2 ”128-NIA3 基於128位ZUC的算法。
128-NIA1基於SNOW 3G（參見TS 35.215 [14]）。
128-NIA2基於CMAC模式下的128位AES [15] [17]。
128-NIA3基於128位ZUC（參見TS 35.221 [18]）。
算法選擇的要求
a) RRC_Connected中的UE和服務網絡應商定用於的算法
- RRC信令和用戶平面的加密和完整性保護（在UE和gNB之間使用）
- RRC信令的加密和完整性保護以及用戶平面的加密（在UE ng-eNB之間使用）
- NAS加密和NAS完整性保護（在UE和AMF之間使用）
b) 服務網絡應選擇依賴的算法 - UE的UE安全功能，
- 配置的當前服務網絡實體的允許安全功能列表
c) 如果UE支持連接到5GC的E-UTRAN，UE安全功能應包括用於NAS級別的NR NAS算法，用於AS層的
NR AS算法和用於AS級別的LTE算法。
注 ： 如果UE支持連接到5GC的E-UTRAN和NR，則UE 5G安全功能包括LTE和NR算法。
d) 每個選定的算法應以受保護的方式指示給UE，以確保UE保證算法選擇的完整性不受操縱。
e) 應保護UE安全功能免受“降低攻擊”。
f) 在給定的時間點，所選擇的AS和NAS算法應該是不同的。