深度解析 3GPP TR 21.918：22.1 IETF DTLS protocol profile for AKMA and GBA (用于AKMA和GBA的IETF DTLS协议剖析) & 22...

好的，我们继续解读TR 21.918的后续章节。

深度解析 3GPP TR 21.918：22.1 IETF DTLS protocol profile for AKMA and GBA (用于AKMA和GBA的IETF DTLS协议剖析) & 22.2 IETF OSCORE protocol profiles for GBA and AKMA (用于GBA和AKMA的IETF OSCORE协议剖析)

本文技术原理深度参考了3GPP TR 21.918 V18.0.0 (2025-03) Release 18规范中，关于“22.1 IETF DTLS protocol profile for AKMA and GBA”和“22.2 IETF OSCORE protocol profiles for GBA and AKMA”的核心章节。本文将合并解读这两个高度相关的章节，旨在为读者深入剖析5G-Advanced如何将其强大的、基于SIM卡的认证能力，延伸到海量的、轻量级的物联网（IoT）应用中，为物联网通信提供端到端的安全保障。

在物联网的世界里，安全是永恒的基石。数以亿计的传感器、控制器、摄像头连接在网络中，任何一个节点的安全漏洞，都可能引发灾难性的后果。传统的物联网安全，大多依赖于设备预置的密钥或证书，部署复杂、难以管理，且难以与运营商级的安全体系联动。

为了解决这一难题，3GPP早已定义了两套强大的“应用层认证框架”：

• GBA (Generic Bootstrapping Architecture): 通用引导架构，诞生于3G/4G时代，允许UE和网络应用功能（NAF）基于USIM卡的认证，派生出一个共享的应用层会话密钥。
• AKMA (Authentication and Key Management for Applications): 5G时代GBA的“升级版”，架构更简洁，更适应服务化的5GC。它允许UE和应用功能（AF）基于5G主认证，派生出一个共享的AKMA密钥（Ka）。

GBA和AKMA的强大之处在于，它们将物联网应用的安全，锚定在了经过数十亿用户验证的、运营商级的SIM/USIM认证体系之上。然而，GBA/AKMA本身只是一个密钥派生框架，它只负责生成“钥匙”，但并不规定这把“钥匙”该如何用来锁门——即，如何在具体的应用协议中，使用这个派生出来的密钥来保障通信安全。

为了填补这一空白，Release 18的22.1和22.2章节，正是要为两把“万能钥匙”（GBA和AKMA），配上两把业界领先的“安全锁”——DTLS和OSCORE。

今天，我们的主角，是一家领先的智能楼宇解决方案提供商的首席安全官，黄工。他负责的系统，需要在楼宇内部署数千个基于CoAP协议的、资源受限的温湿度传感器。他必须确保这些传感器上传的数据，既能防止被窃听，又能防止被篡改。让我们跟随黄工的探索，看看DTLS和OSCORE是如何在GBA/AKMA的赋能下，为他的物联网帝国构建起坚不可摧的安全防线的。

1. 轻量级的“安全隧道”：DTLS over GBA/AKMA (解读 22.1)

黄工首先评估的是DTLS (Datagram Transport Layer Security)。DTLS是标准TLS协议的“UDP版本”，它能够在不可靠的数据报传输（如UDP）之上，提供与TLS类似的点到点（Point-to-Point）信道安全，包括加密、完整性保护和身份认证。这非常适合基于UDP的物联网协议，如CoAP。

IETF DTLS is currently specified as one choice for providing security for the Lightweight M2M standard. The work on IETF DTLS protocol profile for AKMA and GBA provides the details on how to provide secure DTLS connection between the UE and an Application Function (AF) in the network.

传统的DTLS握手，依赖于复杂的、基于X.509证书的公钥密码体系，这对于黄工那些计算和存储能力都极其有限的传感器来说，过于“沉重”。

GBA/AKMA的赋能: 22.1章节的核心，就是定义了如何将DTLS的认证过程，从“基于证书”，切换到“基于GBA/AKMA派生的对称密钥”。

The AKMA WID introduced a method of generating keys (AKMA key)… The AKMA DTLS protocol profiles provides the details on how to use the newly introduced AKMA key to provide secure DTLS connection… The GBA WID introduced a method of generating keys (GBA key)… The GBA DTLS protocol profiles provides the details on how to use the newly introduced GBA key…

• 流程:

  1. 密钥派生: 传感器（UE）首先通过标准的5G或4G流程，完成GBA/AKMA认证，与云端的应用后台（NAF/AF）共享了一个会话密钥（Ks_NAF或Ka）。
  2. DTLS-PSK握手: 随后，传感器向AF发起DTLS连接。在握手过程中，它不再交换证书，而是使用一种称为**PSK（Pre-Shared Key，预共享密钥）**的密码套件。
  3. 密钥验证: 传感器和AF都将第一步中派生出的GBA/AKMA密钥，作为这个“预共享密钥”，来相互认证对方的身份，并从中派生出用于加密和完整性保护的会话密钥。

• 优势:

  • 轻量级: 整个握手过程只涉及对称密码运算，计算开销极低，非常适合资源受限的物联网设备。
  • 安全: 安全性继承自运营商级的SIM/USIM认证，远高于设备预置的简单密码。
  • 动态性: 密钥是会话级的，每次认证都会生成新的密钥，避免了静态密钥泄露带来的风险。

通过这个巧妙的“嫁接”，黄工的传感器，可以在不增加任何复杂硬件（如安全芯片）的前提下，轻松地与云端建立起一条端到端加密的DTLS“安全隧道”。

2. “对象级”的安全保护：OSCORE over GBA/AKMA (解读 22.2)

DTLS虽然强大，但它是一种“信道级”的安全。无论传输的数据是重要还是不重要，它都会对整个UDP/IP隧道进行加密，存在一定的开销。对于某些追求极致效率的物联网场景，业界提出了一种更轻量级、更灵活的安全机制——OSCORE (Object Security for Constrained RESTful Environments)。

The Generic Bootstrap Architecture (GBA) and the Authentication and Key Management for Applications (AKMA) features enable a User Equipment (UE) and an (Network) Application Function or (N)AF to authenticate each other and share a common secret key… This work item specified the … OSCORE as an application protocol for GBA and AKMA.

OSCORE与DTLS的核心区别在于：

• DTLS: 在传输层工作，保护的是IP报文，构建的是一个“安全隧道”。
• OSCORE: 在应用层工作，保护的是CoAP消息本身（即“对象”），提供的是“对象级”的安全。

OSCORE的工作方式: OSCORE不会加密整个IP包头，它只对CoAP消息的Payload（载荷）和一部分关键的Option（选项）进行加密和完整性保护。它将安全相关的信息，紧凑地编码在一个新的CoAP Option中。

GBA/AKMA的再次赋能: 22.2章节的核心，与22.1如出一辙，都是定义了如何使用GBA/AKMA派生的密钥，来作为OSCORE安全上下文（Security Context）的主密钥（Master Secret）。

The integration of OSCORE as an application protocol included the specification of the application session request/response between the UE and the (N)AF for both GBA and AKMA procedures… The key shared between the UE and (N)AF … is used for bootstrapping the OSCORE Master Secret Key…

• 流程:

  1. 密钥派生: 同样，传感器首先通过GBA/AKMA，与AF共享一个会话密钥。
  2. 安全上下文建立: 传感器和AF都使用这个共享密钥，作为“种子”，按照OSCORE规范（RFC 8613）中定义的密钥派生函数（KDF），各自独立地计算出一套完整的安全上下文，包括Sender ID, Recipient ID, AEAD加密算法，以及用于加密和认证的主密钥等。
  3. 安全通信: 之后，双方发送的每一条CoAP消息，都会使用这套安全上下文，进行逐条的加密和签名。

• 优势:

  • 极致轻量: 相比DTLS，OSCORE的协议开销更小，因为它只保护应用层数据，无需处理复杂的握手和记录层协议。
  • 代理友好 (Proxy-friendly): 这是OSCORE的一个核心优势。由于它只加密CoAP的载荷，而保留了大部分CoAP的Option（如Uri-Path, Proxy-Uri）为明文，这使得消息在传输路径上，可以被中间的**缓存代理（Cache Proxy）**所理解和处理。而DTLS隧道对于中间代理来说，则是一个完全不透明的“黑盒子”。

对于黄工的智能楼宇系统，这个“代理友好”特性至关重要。他可以在每层楼部署一个CoAP缓存代理。当多个传感器上报相同的（或可缓存的）数据时，代理可以直接从缓存中回应，而无需每次都请求到远端的云服务器。OSCORE确保了即使在这种有代理的架构下，从传感器到云端的应用数据，依然是端到端加密和保护的。

3. DTLS vs. OSCORE：如何选择？

面对DTLS和OSCORE这两把强大的“安全锁”，黄工该如何选择？

特性	DTLS over GBA/AKMA	OSCORE over GBA/AKMA
安全层级	传输层（信道安全）	应用层（对象安全）
保护对象	整个UDP数据报	CoAP消息的Payload和部分Options
协议开销	相对较大（握手、记录层）	极小（一个新的CoAP Option）
代理支持	不友好（端到端隧道）	友好（保留了CoAP Option明文）
适用场景	需要建立点对点安全隧道的场景，对代理不敏感。	资源极其受限、且需要经过**中间代理（缓存、网关）**的RESTful通信场景。

对于黄工的温湿度传感器系统，考虑到需要经过楼层代理进行缓存和汇聚，OSCORE over GBA/AKMA无疑是更优、更高效的选择。

总结

3GPP TR 21.918的22.1和22.2章节，是5G-Advanced将自身“电信级”安全能力，向广阔的、碎片化的物联网世界进行“赋能”的关键一步。它们成功地在3GPP的**认证框架（GBA/AKMA）与IETF的物联网安全协议（DTLS/OSCORE）**之间，架起了一座标准化的桥梁。

• 通过将GBA/AKMA派生的动态会话密钥，用作DTLS-PSK或OSCORE主密钥，3GPP为资源受限的物联网设备，提供了一条绕开复杂、沉重的公钥证书体系的、轻量级的安全捷径。
• DTLS提供了一种信道级的、点对点的安全隧道方案，简单可靠。
• OSCORE则提供了一种对象级的、更轻量、更灵活、且对代理友好的安全方案，特别适用于分层的、有中间件的物联网架构。

对于像黄工这样的物联网方案提供商，这两章规范，为他提供了一个完整的、可供选择的“安全工具箱”。他可以根据自己应用的不同需求，灵活地选择DTLS或OSCORE作为“安全锁”，并确信这把锁的“钥匙”（GBA/AKMA密钥），是由运营商级的、最可信赖的SIM/USIM安全体系来生成和管理的。

这不仅极大地提升了其物联网方案的安全性，也大大降低了安全部署和管理的复杂度。5G-Advanced，正在通过这种开放、融合的标准化工作，为构建一个真正端到端安全的、可信的万物互联世界，注入最强大的“安全基因”。

---

FAQ - 常见问题解答

Q1：GBA/AKMA是什么？它们是如何基于SIM卡派生出应用层密钥的？ A1：GBA/AKMA是一套密钥协商框架。其基本流程是：1）UE向网络（BSF for GBA, AUSF/AAnF for AKMA）发起一次认证请求。2）网络与UE的USIM卡之间，运行一次AKA（Authentication and Key Agreement）鉴权流程，这与手机开机时的网络认证过程完全相同。3.）成功后，UE和网络侧都会生成一个相同的根密钥。4）UE向应用服务器（NAF/AF）发起业务请求，并携带一个由网络侧生成的“事务标识符”（B-TID）。5）NAF/AF拿着这个B-TID，向网络（BSF/AAnF）请求与该UE的会话密钥。6）网络使用根密钥和NAF/AF的身份标识，通过密钥派生函数（KDF），计算出一个专用于该UE与该NAF/AF之间本次会话的密钥（Ks_NAF或Ka），并返回给NAF/AF。同时，UE也使用根密钥和NAF/AF的身份标识，在本地计算出完全相同的会用密钥。至此，双方就在没有在空中直接传输密钥的情况下，共享了一个对称密钥。

Q2：DTLS和OSCORE都需要GBA/AKMA吗？我可以直接在设备里预置一个PSK密钥吗？ A2：DTLS-PSK和OSCORE本身不强制要求GBA/AKMA。你完全可以在设备出厂时，为它预置一个静态的PSK密钥，并在服务器端存储这个密钥。这也是一种常见的物联网安全方案。但是，GBA/AKMA的方案相比预置静态密钥，有巨大的优势：1）安全性更高：密钥是基于SIM卡动态生成的，而不是一个可能被批量破解的、固化在设备中的静态密码。2）管理更便捷：你无需为数百万设备管理和分发数百万个不同的静态密钥。所有密钥的管理，都统一收敛到了运营商的SIM卡认证体系中。3）密钥是会话级的：每次认证都会生成新的密钥，大大降低了密钥泄露的风险。

Q3：为什么OSCORE是“代理友好”（Proxy-friendly）的，而DTLS不是？这对物联网应用有什么实际意义？ A3：DTLS加密了从传输层（UDP头之后）开始的所有内容，形成了一个不透明的隧道。中间的代理服务器，完全无法看到隧道内部的CoAP协议信息（如请求的URL路径Uri-Path），因此它无法对请求进行缓存或智能路由。所有请求都必须由代理原封不动地转发到终点的服务器。而OSCORE只加密了CoAP的“敏感”部分（如Payload），但保留了大部分用于路由和缓存的CoAP Option为明文。当一个OSCORE保护的消息到达代理时，代理虽然看不懂Payload，但它能看懂Uri-Path和Cache-Control等Option。这使得代理可以：1）执行缓存：如果发现多个设备都在请求同一个资源（URL相同），并且该资源是可缓存的，代理可以直接从自己的缓存中返回响应，而无需每次都去请求后端服务器，大大降低了延迟和服务器负载。2）执行路由: 代理可以根据Proxy-Uri等Option，将请求智能地路由到不同的后端服务器。

Q4：一个物联网设备，可以同时支持DTLS和OSCORE吗？ A4：可以，但通常不会在同一个会话中同时使用。DTLS和OSCORE是两种可选的、并列的安全机制。一个设备可以根据应用的需求和对端服务器的能力，选择其中一种来使用。例如，与服务器A通信时，可能协商使用DTLS；而与服务器B通信时，则协商使用OSCORE。在协议栈实现上，它们分别作用于不同的层次，是相互独立的。

Q5：实现了这些安全机制后，我的物联网通信就是绝对安全的吗？ A5：它们提供了非常高等级的通信链路安全，但不能保证整个系统的“绝对安全”。DTLS和OSCORE主要解决了数据在传输过程中的机密性（防窃听）和完整性（防篡改）问题。但一个完整的物联网安全体系，还必须考虑其他方面：1）设备自身的安全：设备硬件是否防破解？固件是否可以被恶意刷写？2）应用服务器的安全：云端服务器是否存在漏洞？数据存储是否加密？3）物理安全：传感器是否可能被物理替换或破坏？4）应用逻辑安全：应用本身的逻辑是否存在漏洞，可能被用于发起攻击？因此，DTLS/OSCORE是物联网端到端安全中至关重要的一环，但不是全部。