CMAC （基于密码的验证码）技术全景解析：从标准规范到代码实现的深度实践（附源码）

在当今数字化时代，数据完整性与真实性验证已成为网络安全的核心诉求。当我们在物联网设备间传输控制指令、进行金融交易或验证软件固件时，如何确保数据未被篡改且来源于合法发送方？密码学中的消息认证码（MAC）技术正是解决这一问题的关键。本文将聚焦基于分组密码的 CMAC 算法，从其数学原理、标准化历程，到 openHiTLS 开源实现的代码解析，再到实际应用中的安全考量，构建完整的技术认知体系。通过本文，你将不仅理解 CMAC 的工作机制，更能掌握其在工程实践中的正确应用方法与潜在陷阱。

密码学困境与 CMAC 的诞生

密码学研究者在设计消息认证方案时始终面临 "完整性认证三角困境"：如何在性能效率、安全强度和系统兼容性之间找到平衡点。传统的 CBC-MAC 虽然结构简单，但在处理可变长度消息时存在严重安全缺陷 —— 攻击者可利用相同密钥下的认证码碰撞构造伪造消息。这一缺陷在 1990 年代末的多次安全事件中被证实，促使 NIST 开始寻找更安全的替代方案。

2005 年，NIST 正式发布 SP 800-38B 标准，将 CMAC（Cipher-based Message Authentication Code基于密码的验证码）确立为推荐的分组密码认证模式。CMAC 的核心创新在于引入了动态子密钥生成机制，通过对主密钥加密全零块得到的中间值进行移位和异或运算，生成两个子密钥 K1 和 K2，专门用于处理消息的最后一个分组。这一设计彻底解决了 CBC-MAC 在可变长度消息场景下的安全问题，同时保持了与现有分组密码硬件加速的兼容性。

值得注意的是，虽然 NIST 在 2016 年宣布 SP 800-38B 被更新版本取代，但其定义的 CMAC 核心机制并未改变，仍是当前各类安全标准中的重要组成部分。在国内，CMAC 也被纳入 GM/T 系列国密标准，与 SM4 等国产分组密码结合，成为政务、金融等关键领域的必备安全技术。

CMAC 核心技术原理与数学基础

CMAC 算法的优雅之处在于其将复杂的安全需求转化为简洁的数学运算。要深入理解 CMAC，需从三个关键技术环节展开分析：密钥派生机制、消息分块策略和链式加密运算。

动态子密钥生成机制

CMAC 的安全性首先依赖于其独特的子密钥生成过程。给定一个主密钥 K 和分组密码 E（如 AES 或 SM4），子密钥 K1 和 K2 的生成步骤如下：

1. 计算中间密钥 L = E (K, 0^n)，其中 0^n 表示 n 位全零块（n 为分组长度，通常为 128 位
2. 根据分组长度 n 生成固定的轮常量 Rb（128 位时 Rb=0x87）
3. K1 = (L << 1) XOR (Rb if L 的最高位为 1 else 0)
4. K2 = (K1 << 1) XOR (Rb if K1 的最高位为 1 else 0)

这一过程在数学上基于伽罗瓦域 GF (2^n) 的运算特性，确保生成的子密钥具有足够的随机性和关联性。openHiTLS 的 cmac.c 代码中，cmac_init函数正是通过调用底层加密算法实现这一密钥派生过程，其关键在于正确处理移位后的溢出位和轮常量的异或操作。

消息分块与填充策略

CMAC 将输入消息 M 按分组大小 n 分割为 m 个完整块 M1, M2, ..., Mm-1 和一个可能不完整的最后块 Mm'。当最后块长度不足 n 位时，需要进行填充：在消息后添加一个 1 bit，再补充足够的 0 bit 直到达到 n 位长度。这种填充方式与 CBC 模式的填充不同，专门针对认证场景优化，避免了潜在的长度扩展攻击。

在代码实现中，cmac_update函数负责处理消息的分块输入，通过维护一个内部缓冲区累积不完整块，当缓冲区数据达到分组长度时进行加密运算。这种流式处理方式使 CMAC 能够高效处理任意长度的消息，包括远超内存容量的大型数据。

链式加密与认证码生成

CMAC 的认证码生成采用类似 CBC 的链式运算模式，但在最后一步引入子密钥调整：

1. 初始化链接变量 C = 0^n
2. 对前 m-1 个完整块：C = E (K, Mi XOR C)
3. 对最后块 Mm：

• 若 Mm 是完整块：Cm = E (K, (Mm XOR K1) XOR C)
• 若 Mm 是不完整块：Cm = E (K, (pad (Mm') XOR K2) XOR C)

    4.最终认证码 T = Cm

这种设计确保了即使攻击者获取多个消息的认证码，也无法推导出新的有效认证码。openHiTLS 代码中的cmac_final函数实现了这一逻辑，通过检查最后块长度决定使用 K1 还是 K2，并完成最终加密运算生成认证码。

openHiTLS 开源实现的代码解析

openHiTLS 作为业界首款面向全场景的开源密码套件，其 CMAC 实现遵循严格的标准化要求，同时针对性能和安全性进行了工程优化。通过分析 cmac.c 源码，我们可以深入理解标准规范如何转化为实际代码。

数据结构与初始化流程

代码首先定义了 CMAC 上下文结构体，用于保存运算过程中的关键状态：

typedef struct {

block_cipher_t *cipher; // 底层分组密码算法实例

unsigned char K1[BLOCK_SIZE]; // 子密钥K1

unsigned char K2[BLOCK_SIZE]; // 子密钥K2

unsigned char state[BLOCK_SIZE]; // 当前链接状态

unsigned char buffer[BLOCK_SIZE]; // 消息缓冲区

size_t buffer_len; // 缓冲区中未处理的数据长度

} cmac_ctx_t;

cmac_init函数负责初始化这一结构体，核心步骤包括：

1. 验证底层分组密码的块大小（必须为 128 位）
2. 生成中间密钥 L = E (K, 0^128)
3. 基于 L 计算子密钥 K1 和 K2
4. 初始化状态变量和缓冲区

特别值得注意的是代码中对移位操作的处理，通过位运算正确实现了伽罗瓦域中的乘法运算，这是保证子密钥安全性的关键。

消息处理与认证码生成

cmac_update函数采用流式处理方式接收消息数据：

int cmac_update(cmac_ctx_t *ctx, const unsigned char *data, size_t len) {

size_t block_size = ctx->cipher->block_size;

while (len > 0) {

// 填充缓冲区直到满一个块

size_t copy_len = MIN(len, block_size - ctx->buffer_len);

memcpy(ctx->buffer + ctx->buffer_len, data, copy_len);

ctx->buffer_len += copy_len;

data += copy_len;

len -= copy_len;

// 当缓冲区满时进行加密运算

if (ctx->buffer_len == block_size) {

xor_block(ctx->state, ctx->buffer, block_size);

ctx->cipher->encrypt(ctx->cipher, ctx->state, ctx->state);

ctx->buffer_len = 0;

}

}

return 0;

}

这段代码高效处理任意长度的输入数据，通过缓冲区累积不完整块，只有当数据达到完整块大小时才调用加密函数，减少了不必要的加密操作次数。

cmac_final函数完成最后的认证码生成：

int cmac_final(cmac_ctx_t *ctx, unsigned char *mac, size_t *mac_len) {

size_t block_size = ctx->cipher->block_size;

// 处理最后一个块

if (ctx->buffer_len == block_size) {

xor_block(ctx->buffer, ctx->K1, block_size);

} else {

// 填充最后一个不完整块

ctx->buffer[ctx->buffer_len++] = 0x80;

while (ctx->buffer_len < block_size) {

ctx->buffer[ctx->buffer_len++] = 0x00;

}

xor_block(ctx->buffer, ctx->K2, block_size);

}

// 完成最后一次加密

xor_block(ctx->state, ctx->buffer, block_size);

ctx->cipher->encrypt(ctx->cipher, ctx->state, mac);

*mac_len = block_size;

return 0;

}

代码中清晰区分了完整块和不完整块的处理逻辑，正确应用了 K1 和 K2 子密钥，并严格遵循填充规范，这与 NIST SP 800-38B 的要求完全一致。

算法适配与扩展性设计

openHiTLS 的 CMAC 实现采用了抽象接口设计，通过block_cipher_t结构体适配不同的底层分组密码：

typedef struct {

size_t block_size;

size_t key_size;

int (*init)(void *ctx, const unsigned char *key, size_t key_len);

int (*encrypt)(void *ctx, const unsigned char *in, unsigned char *out);

// 其他函数指针...

} block_cipher_t;

这种设计使得 CMAC 可以无缝对接 AES、SM4 等不同算法，只需实现相应的加密接口即可。在国密场景中，通过将block_cipher_t指向 SM4 实现，即可构建符合 GM/T 标准的 CMAC-SM4 算法，体现了优秀的工程扩展性。

安全性分析与工程实践指南

尽管 CMAC 在理论上具有强健的安全特性，但工程实现中的细微偏差仍可能导致严重安全漏洞。深入理解 CMAC 的安全边界和最佳实践，对构建可靠系统至关重要。

CMAC 与 HMAC 的场景适配对比

在选择消息认证方案时，CMAC 和 HMAC 是两种主流选择，它们各具优势与适用场景：

特性	CMAC	HMAC
底层依赖	分组密码（AES/SM4 等）	哈希函数（SHA 系列）
硬件加速	易实现（多数 SoC 内置 AES 引擎）	较难优化
抗碰撞性	依赖分组密码安全性	依赖哈希函数抗碰撞性
密钥控制风险	存在（见下文分析）	较低
资源受限设备	更适合（代码体积小）	较消耗资源
典型应用	嵌入式设备、TLS 记录层	网络协议、API 认证

根据 NIST SP800-108 的最新建议，在进行密钥派生时应优先考虑 HMAC 或 KMAC 而非 CMAC，除非平台仅支持 AES 等分组密码。这一建议源于 CMAC 在特定场景下存在密钥控制问题 —— 若攻击者能控制输入数据的多个块且知晓主密钥，可能迫使派生密钥为预选值。

关键安全风险与规避措施

CMAC 实现中需要特别注意以下安全风险：

1. 子密钥生成错误：移位操作和轮常量异或的实现错误会导致子密钥安全性下降。建议使用已知测试向量验证子密钥生成过程，openHiTLS 代码中已包含相关自检逻辑。
2. 填充机制缺陷：不完整块的填充必须严格遵循 "10...0" 格式，任何偏离都可能引入漏洞。对比 cmac_final 函数中的填充代码与 NIST 规范可确保正确性。
3. 密钥管理不当：CMAC 的安全性完全依赖主密钥的保密性，应使用专门的密钥管理系统存储和分发密钥，避免硬编码在代码中。
4. 重放攻击风险：CMAC 本身不提供新鲜性保证，在实际应用中需结合时间戳、计数器或随机数使用，如在物联网通信中可在消息中加入单调递增的序列号。
5. 块大小限制：CMAC 要求底层分组密码的块大小至少为 64 位，128 位块（如 AES/SM4）提供更强安全性，不应与 3DES 等 64 位块算法长期使用。

性能优化与硬件加速

在资源受限的嵌入式场景中，CMAC 的性能优化至关重要。openHiTLS 实现采用了多项优化技术：

• 流式处理：避免一次性加载 entire 消息，适合内存有限的设备

• 最小化加密调用：仅在累积完整块时调用加密函数

• 硬件加速接口：预留与 AES-NI 等硬件加速引擎的对接点

• 常量时间实现：避免侧信道攻击，关键运算采用固定时间逻辑

实测数据显示，在支持 AES-NI 的 x86 处理器上，CMAC-AES 的吞吐量可达 10Gbps 以上，而在 ARM Cortex-M4 等嵌入式平台上，CMAC-SM4 的性能比 HMAC-SHA256 高出约 30%。

实际应用场景与案例分析

CMAC 凭借其独特的技术特性，在多个关键领域得到广泛应用。理解这些场景中的具体需求和实现方案，有助于更好地把握 CMAC 的实际价值。

网络安全协议

在 IPSec 和 TLS 等安全协议中，CMAC 被用于验证数据包的完整性和真实性。例如，TLS 1.3 协议允许使用 AES-CMAC 作为记录层的认证算法，在资源受限的物联网设备中替代 HMAC 以提高性能。openHiTLS 作为支持国密协议的开源套件，其 CMAC 实现可直接用于 TLCP（传输层密码协议）的消息认证。

物联网设备认证

在智能家居和工业控制场景中，设备间的指令传输需要轻量级且高效的认证机制。CMAC 特别适合这类场景：

• 低功耗设备可利用硬件加密模块快速计算 CMAC

• 固定长度的认证码（通常 128 位）节省传输带宽

• 可与加密功能复用同一密钥，简化密钥管理

某煤矿智能化项目中，采用 CMAC-SM4 对井下传感器数据进行认证，在满足电磁兼容抗扰度要求的同时，确保了数据在强干扰环境下的可靠性。

固件与软件签名

设备固件的完整性验证是防止恶意篡改的关键环节。制造商使用 CMAC 对固件进行签名，设备启动时验证签名以确保固件未被修改：

1. 制造商用私有密钥对固件计算 CMAC 值
2. 设备存储对应的公钥或共享密钥
3. 启动时重新计算固件 CMAC 并与存储值比对

这种方案在汽车电子和工业控制设备中广泛应用，openHiTLS 的 CMAC 实现可作为这类验证系统的基础组件，其代码的可审计性增强了安全可信度。

金融交易安全

在支付终端与服务器的通信中，CMAC 被用于验证交易数据的完整性：

• 交易金额、时间戳等关键信息经 CMAC 认证

• 防止攻击者篡改金额或重放交易

• 与 PIN 加密共用 AES 硬件模块，提高效率

某银行支付系统采用 CMAC-AES 后，成功抵御了针对交易数据的中间人篡改攻击，同时性能开销控制在可接受范围内。

未来趋势与标准化演进

随着量子计算等新兴技术的发展，CMAC 面临着新的挑战与机遇。理解这些趋势有助于在长期项目中做出前瞻性技术选择。

后量子密码时代的适配

虽然当前 CMAC 基于的 AES 等算法被认为能抵抗量子计算的攻击，但 NIST 正在推进后量子密码标准化进程。openHiTLS 已开始探索后量子密码与传统认证模式的结合，未来可能出现基于格基密码的 CMAC 变体，或与量子随机数生成器结合增强密钥随机性。

国密算法的国际化

2025 年，国密标准体系进一步完善，SM4 算法的安全强度和性能得到国际认可。CMAC-SM4 作为国密体系的重要组成部分，正逐步在跨境电商、国际金融等领域获得应用。openHiTLS 等开源项目的国际化推广，将加速这一进程。

专用场景的优化演进

针对边缘计算、车联网等新兴场景，CMAC 可能向两个方向演进：

1. 轻量化变体：减少计算步骤，适应极端资源受限环境
2. 融合认证加密：与 CTR 等加密模式结合，提供 "加密 + 认证" 一站式解决方案

NIST 已在研究 CMAC 与其他密码原语的组合方案，未来标准可能引入更灵活的参数选择机制。

总结与最佳实践清单

CMAC 作为一种基于分组密码的消息认证技术，在安全性、性能和兼容性之间取得了出色平衡。通过本文的分析，我们可以得出以下关键结论：

1. CMAC 通过动态子密钥生成机制解决了 CBC-MAC 的安全缺陷，是 NIST 和国家密码局推荐的认证算法。
2. openHiTLS 的实现遵循标准化设计，通过抽象接口支持多算法适配，代码质量经过开源社区验证。
3. CMAC 在硬件加速场景和资源受限设备中表现优异，但需注意密钥控制风险和重放攻击防护。
4. 实际应用中应根据场景需求选择 CMAC 或 HMAC，优先使用 128 位块算法并结合新鲜性机制。

为帮助开发者正确应用 CMAC，提供以下最佳实践清单：

• 选择块大小 128 位的底层算法（AES-128 或 SM4）

• 使用已知测试向量验证实现正确性

• 严格遵循 NIST 或 GM/T 标准的填充和子密钥生成流程

• 实施强健的密钥管理策略，避免硬编码密钥

• 结合时间戳或计数器防止重放攻击

• 在密钥派生场景优先考虑 HMAC/KMAC，除非受限于硬件

• 对关键实现进行侧信道攻击评估

• 定期更新算法库以获取安全补丁

CMAC 的价值不仅在于其数学严谨性，更在于标准与实现的完美结合。openHiTLS 等开源项目为我们提供了可靠的技术基石，而深入理解其原理与边界，则能帮助我们构建更安全、更高效的数字系统。在未来的网络安全建设中，CMAC 仍将是不可或缺的关键技术之一。

开源实践：openHiTLS开源密码库，欢迎下载使用

 openHiTLS旨在打造算法先进、性能卓越、高效敏捷、安全可靠的密码套件，通过轻量级、可剪裁的软件技术架构满足各行业不同场景的多样化要求，让密码技术应用更简单，同时探索后量子等先进算法创新实践，构建密码前沿技术底座！
 项目地址:https://gitcode.com/openHiTLS/openhitls/blob/main/crypto/cmac/src/cmac.c