NR 5G 安全要求和功能

安全要求和功能

一般安全要求

缓解和降低攻击请求

攻击者可以通过使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算法应该是不同的。