5G中完整性保护流程中的MAC值如何计算？UE和AMF为啥算的不一样？

好的，很高兴能以5G通信自媒体的角度，为您解答关于5G NAS消息完整性保护中“Message Authentication Code”的计算原理问题。

您在抓包中观察到的现象非常准确：UE（用户设备）和AMF（接入与移动性管理功能）确实会各自生成并下发不同的Message

Authentication Code（消息认证码，常简写为MAC）。这背后涉及一套严密的对称加密和完整性保护机制。

接下来，我们将结合3GPP规范和通俗的例子，深入探讨其计算原理以及两者之间的关联。

核心摘要

1. 计算原理：NAS消息的MAC值是使用一个特定的完整性算法，基于共享的完整性密钥（K_NASint）、NAS消息本身、一个递增的序

列号（NAS COUNT）、传输方向等多个输入参数计算出来的一个32位哈希值。

2. 为何值不同：UE发送（上行）和AMF下发（下行）的MAC值必然不同。这是因为尽管双方使用相同的密钥和算法，但计算MAC的关

键输入参数——NAS COUNT（序列号） 和 DIRECTION（方向） 是区分为上行和下行的。上行和下行各有一套独立的COUNT，

DIRECTION比特也不同（上行通常为0，下行为1）。

3. 两者关联性：UE和AMF下发的MAC值虽然不同，但它们紧密关联。这种关联性体现在它们都源自于同一个NAS安全上下文

（Security Context），使用相同的完整性密钥（K_NASint） 和相同的算法。接收方会用与发送方完全相同的输入参数独立计算一

遍MAC值，并与接收到的MAC值进行比对，若一致，则消息验证通过。这是一种对称的验证机制。

Message Authentication Code 计算原理详解

5G NAS消息的完整性保护（Integrity Protection）机制在3GPP TS 33.501规范中有详细定义。其核心目的是确保NAS信令在传输过程中没

有被篡改，并且确认消息确实来自于合法的发送方（UE或AMF）。

1. 完整性算法 (The Algorithm)

5G系统定义了多种NAS完整性算法（NIA - NAS Integrity Algorithm），网络和UE会根据双方都支持的能力来协商选择其中一种使用。

128-NIA1: 基于 SNOW 3G 算法。

128-NIA2: 基于 AES-CMAC 算法，这是目前非常常用的一种。

128-NIA3: 基于 ZUC 算法（祖冲之算法）。

2. 计算MAC的输入参数 (The Inputs)

根据规范 3GPP TS 33.501 V18.9.0 (2025-03) 的 6.4.3.1 章节，计算MAC值需要以下五个核心输入参数：

KEY: 128位的NAS完整性密钥 K_NASint。这个密钥是在UE和AMF完成认证和密钥协商（AKA）流程后，由双方基于更高层的密钥

（K_AMF）独立衍生出来的，是保密的。

COUNT: 32位的NAS序列号。它由一个16位的溢出计数器（NAS OVERFLOW）和一个8位的序列号（NAS SQN）组成。关键点在

于，上行（Uplink）和下行（Downlink）各有一套独立的COUNT值，每次发送消息后都会递增，用于防范重放攻击。

BEARER: 5位的承载ID。对于NAS信令，它被设置为一个固定的值，用于标识这是NAS连接。

DIRECTION: 1位的方向比特。上行消息（UE -> AMF）为0，下行消息（AMF -> UE）为1。这是区分上下行MAC值的直接原因之

MESSAGE: 需要进行完整性保护的NAS消息本身。

3. 计算公式 (The Formula)

我们可以将这个过程概括为以下公式：

MAC = Integrity_Algorithm(KEY, COUNT, BEARER, DIRECTION, MESSAGE)

其中，Integrity_Algorithm 就是双方协商好的NIA算法（例如128-NIA2）。

规范原⽂出处:

根据 3GPP TS 33.501 的 6.4.3.1 NAS input parameters to integrity algorithm 章节：

"The input parameters to the NAS 128-bit integrity algorithms as described in Annex D shall be set as follows.

The KEY input shall be equal to the KNASint key.

The BEARER input shall be equal to the NAS connection identifier.

The DIRECTION bit shall be set to 0 for uplink and 1 for downlink.

The COUNT input shall be constructed as follows: COUNT := 0x00 || NAS COUNT..."

一个通俗易懂的计算举例

假设UE要向AMF发送一条上行的“注册完成（Registration Complete）”消息，并且双方已经协商使用 128-NIA2 (AES-CMAC) 算法。

场景: UE发送上行消息

输入1 (KEY): 共享的完整性密钥 K_NASint，例如 0xABCDEF... (一个128位的密钥，双方都持有)。

输入2 (COUNT): 当前的上行NAS COUNT值，例如 0x00001A (这是一个32位的值)。

输入3 (BEARER): NAS连接标识，例如 0x01。

输入4 (DIRECTION): 方向为上行，所以是 0。

输入5 (MESSAGE): “Registration Complete”消息的全部比特流内容。

计算公式: MAC_Uplink = 128-NIA2 (K_NASint, Uplink_COUNT, BEARER, 0, Registration_Complete_Message)

结果 (y): 计算得出一个32位的MAC值，例如 0xaf8e0794 (这正是您在抓包图片中高亮的值)。

UE会将这条“Registration Complete”消息连同计算出的MAC值 0xaf8e0794 一起发送给AMF。AMF收到后，会使用完全相同的五个输入（它

也知道K_NASint、当前期望的Uplink_COUNT等）独立计算一次MAC，如果结果也是 0xaf8e0794，则验证通过。

场景: AMF回复下行消息

现在，假设AMF要回复一条下行的“PDU会话建立请求（PDU Session Establishment Request）”消息。

输入1 (KEY): 同样的共享密钥 K_NASint 0xABCDEF...。

输入2 (COUNT): 当前的下行NAS COUNT值，例如 0x00002B (注意，这与上行COUNT无关)。

输入3 (BEARER): 同样的NAS连接标识 0x01。

输入4 (DIRECTION): 方向为下行，所以是 1。

输入5 (MESSAGE): “PDU Session Establishment Request”消息的全部比特流内容。

计算公式: MAC_Downlink = 128-NIA2 (K_NASint, Downlink_COUNT, BEARER, 1, PDU_Session_Establishment_Request_Message)

结果 (y): 计算出一个全新的32位MAC值，例如 0xd6d7b5494 (您抓包图片中的另一个值)。

这个例子清晰地表明，即使密钥相同，但由于COUNT和DIRECTION这两个关键参数不同，上下行的MAC值也必然不同，从而完美解释了您

在抓包中的发现。

希望这个结合了规范、原理和实例的解释对您和您的读者有所帮助！