TI SHA/MD5硬件加速器实战：HMAC密钥处理、数据填充与操作模式详解

1. 项目概述与核心价值

在嵌入式系统，尤其是那些对实时性和功耗有严苛要求的物联网终端、网络设备中，实现高效且安全的数据完整性校验与身份认证是一个基础且关键的挑战。纯软件实现的哈希算法（如SHA-1、SHA-256、MD5）在处理大量数据或高频次的小数据包时，会显著消耗CPU资源，增加系统延迟和功耗。这正是硬件加速器存在的意义——将计算密集型任务卸载到专用电路，让主处理器得以“喘息”，专注于业务逻辑。

德州仪器（TI）在其许多微控制器和处理器中集成了SHA/MD5硬件加速器模块，它不仅仅是一个简单的“计算器”。它深度集成了对HMAC（基于哈希的消息认证码）协议的原生硬件支持，这意味着开发者可以直接在硬件层面完成HMAC所需的“密钥-数据”混合计算流程，而非在软件中拼接多个哈希操作，从而在提升性能的同时，也减少了因软件实现不当可能引入的安全隐患。

本文将从一线嵌入式开发者的视角，深入剖析TI SHA/MD5加速器的实战编程。我不会重复手册里那些寄存器位的简单定义，而是聚焦于几个最容易让人“踩坑”的核心环节：HMAC密钥的预处理与加载、数据块的填充（Padding）机制，以及如何根据你的应用场景在轮询（Polling）、中断（Interrupt）和DMA三种操作模式中做出最优选择。理解这些细节，你才能真正驾驭这块硬件，让它成为你系统安全架构中可靠且高效的基石。

2. 硬件加速器工作原理与模式解析

在开始写代码之前，我们必须先理解这块硬件是怎么“想问题”的。它本质上是一个状态机，我们通过配置寄存器来驱动它完成一系列固定的操作。核心的寄存器不多，但每一个位的设置都至关重要。

2.1 核心寄存器组与功能映射

加速器的操作围绕几组关键寄存器展开，理解它们的角色是编程的基础：

1. 控制与状态寄存器：

   • SHAMD5_MODE：这是“大脑”。你在这里选择算法（SHA-1, SHA-256, MD5）、决定是否进行HMAC密钥处理、是否使用算法初始常量、是否关闭哈希（即触发填充）。
   • SHAMD5_LENGTH：这是“指令”。写入待处理数据的字节长度，这个动作本身会触发硬件开始处理当前已写入输入缓冲区的数据。
   • SHAMD5_IRQSTATUS：这是“信号灯”。通过查询INPUT_READY和OUTPUT_READY位，你可以知道硬件是“饿了”（等待输入数据）还是“饱了”（计算结果已就绪）。

2. 数据输入寄存器(SHAMD5_DATA0_IN到SHAMD5_DATA15_IN)：

   • 这是一个16个32位寄存器组成的FIFO缓冲区，总共64字节，正好对应一个哈希运算的数据块（Block）。无论你处理什么数据，都必须以64字节为单位（或最后一个不足64字节的块）喂给硬件。数据必须按小端（Little-Endian）格式写入。

3. 摘要（Digest）寄存器：这是最容易混淆的地方，因为它一身兼多职。

   • 外摘要寄存器(SHAMD5_ODIGEST_A到SHAMD5_ODIGEST_H)：在普通哈希模式下，它们被忽略。在HMAC模式下，它们用于存放经过处理的“外密钥”（Outer Key Pad）。当启用HMAC密钥处理时，它们则被用作低256位HMAC密钥的输入缓冲区。
   • 内摘要寄存器(SHAMD5_IDIGEST_A到SHAMD5_IDIGEST_H)：在普通哈希模式或HMAC续算模式下，它们用于存放初始或中间的哈希状态（Context）。在HMAC密钥处理模式下，它们则被用作高256位HMAC密钥的输入缓冲区。计算完成后，最终的哈希结果或HMAC值也从这里读取。

关键理解：摘要寄存器在密钥处理阶段是“输入缓冲区”，在计算阶段是“上下文存储器”，在完成阶段是“结果输出区”。它的角色完全由SHAMD5_MODE寄存器中的HMAC_KEY_PROC和ALGO_CONSTANT等位动态定义。

2.2 HMAC的硬件实现原理

HMAC的公式是HMAC(K, m) = H((K ⊕ opad) || H((K ⊕ ipad) || m))。软件实现需要手动进行异或、拼接和两次哈希调用。硬件加速器将此流程固化：

1. 密钥处理阶段（HMAC_KEY_PROC = 1）：你将原始密钥写入内外摘要寄存器（模拟K ⊕ ipad和K ⊕ opad的预处理结果）。硬件内部会完成与固定常量（ipad/opad）的异或操作，并计算生成最终的“内摘要”和“外摘要”预计算值。这一步是关键，它避免了软件进行繁琐的填充和第一次哈希。
2. 内哈希阶段：硬件使用上一步生成的“内摘要”作为初始状态，对你输入的消息（m）进行哈希计算。
3. 外哈希阶段（HMAC_OUTER_HASH = 1）：内哈希结果自动作为数据块，在“外摘要”的初始状态下进行第二次哈希，直接产出最终的HMAC值。

这种硬件流水线将多次内存搬运和计算合并，极大地提升了效率。但便利性的代价是，你必须严格遵守硬件对密钥格式和加载顺序的要求。

3. HMAC密钥处理的实战细节与陷阱规避

这是使用该加速器时最需要精细操作的环节，手册中的说明比较分散，我结合调试经验将其梳理成可操作的步骤。

3.1 密钥长度处理：512位边界问题

硬件要求HMAC密钥必须精确地以512位（64字节）块的形式呈现。这引出了三种情况：

情况一：密钥等于512位这是最简单的情况。你只需要将密钥数据按小端格式，分割成32位的字，依次写入SHAMD5_ODIGEST_A-H（低256位）和SHAMD5_IDIGEST_A-H（高256位）即可。总共16个寄存器，正好64字节。

情况二：密钥小于512位这是常见情况，比如你的AES-128密钥是128位（16字节）。硬件不会自动帮你补零！你必须手动补零。

• 操作：将你的密钥数据放在低地址位开始填充。例如，一个16字节的密钥，你应将其写入SHAMD5_ODIGEST_A（字节0-3）、SHAMD5_ODIGEST_B（字节4-7）、SHAMD5_ODIGEST_C（字节8-11）、SHAMD5_ODIGEST_D（字节12-15）。然后，你必须显式地将SHAMD5_ODIGEST_E到SHAMD5_IDIGEST_H这12个寄存器全部写入0。即使它们“可能”不被算法用到（如MD5只用A-D），你也必须写。这是硬件的强制要求。

// 示例：加载一个128位（16字节）的HMAC密钥，并补零至512位 uint32_t hmac_key[4] = {0x01234567, 0x89ABCDEF, 0xFEDCBA98, 0x76543210}; // 你的密钥 // 1. 写入低256位区域（ODIGEST） SHAMD5->ODIGEST_A = hmac_key[0]; SHAMD5->ODIGEST_B = hmac_key[1]; SHAMD5->ODIGEST_C = hmac_key[2]; SHAMD5->ODIGEST_D = hmac_key[3]; // 补零 SHAMD5->ODIGEST_E = 0; SHAMD5->ODIGEST_F = 0; SHAMD5->ODIGEST_G = 0; SHAMD5->ODIGEST_H = 0; // 2. 写入高256位区域（IDIGEST），全部补零 SHAMD5->IDIGEST_A = 0; // ... 直到 IDIGEST_H = 0;

情况三：密钥大于512位例如，你使用一个1024位的密钥。硬件不支持直接处理。你必须先在软件中（或利用加速器的哈希模式）对这个大密钥进行一次哈希运算，得到一个固定长度的摘要（如SHA-256产生256位摘要），然后将这个摘要作为新的“密钥”，并按照“情况二”的方法，补零至512位后，再加载到加速器中进行HMAC密钥处理。

踩坑记录：我曾遇到一个诡异的认证失败问题，最终排查发现是密钥长度恰好是64字节，但团队误以为需要补零，在密钥末尾多加了零，导致实际密钥被改变。记住：等于64字节，不补零；小于64字节，必须补零至64字节；大于64字节，先哈希再补零。

3.2 密钥预计算与复用：性能优化关键

手册里提到一个非常重要的优化点：如果同一个HMAC密钥需要对多个不同的消息进行认证，反复进行密钥处理阶段是浪费的。因为密钥处理阶段本身需要完成一个哈希块的运算。

优化策略：

1. 首次使用：完整执行一次HMAC操作（包含密钥处理）。在操作完成后，不要立即覆盖摘要寄存器。此时，SHAMD5_IDIGEST_A-H中保存的是最终的HMAC结果，但这个结果对我们复用密钥没用。我们需要的是预计算好的内外摘要状态。
2. 获取预计算值：实际上，在密钥处理模式（HMAC_KEY_PROC=1）下，执行一次“空消息”的HMAC计算（仅密钥处理，不输入实际消息数据），并在计算完成后读取内外摘要寄存器，得到的就是预处理后的(K ⊕ ipad)和(K ⊕ opad)的哈希初始状态。将它们保存到内存中。
3. 后续使用：对于新的消息，不再设置HMAC_KEY_PROC=1。而是：
   • 将保存的“内摘要”预计算值写回SHAMD5_IDIGEST_A-H。
   • 将保存的“外摘要”预计算值写回SHAMD5_ODIGEST_A-H。
   • 设置ALGO_CONSTANT=0（不使用默认常量），HMAC_KEY_PROC=0。
   • 然后正常输入消息数据并触发计算。这样，硬件跳过了耗时的密钥扩展和第一次哈希，直接进入核心运算，性能提升显著。

4. 数据填充与哈希关闭流程详解

哈希算法要求输入数据的总长度必须是512位（64字节）块的整数倍。对于不是整数倍的最后一块，需要进行填充（Padding）。硬件可以自动完成填充，但你需要正确触发它。

4.1 CLOSE_HASH位的核心作用

SHAMD5_MODE.CLOSE_HASH位是这个过程中的指挥官。它的规则很明确：

• CLOSE_HASH = 0：告诉硬件“数据还没完，当前输入的是一个完整的64字节中间块”。硬件处理完后，会保持中间状态，等待下一个数据块。
• CLOSE_HASH = 1：告诉硬件“这是最后一块数据了，可能不足64字节，请帮我补全并完成最终计算”。硬件会自动添加填充字节（包括一个位‘1’、若干个‘0’和表示消息长度的64位数据）。

4.2 填充过程与块数计算

填充规则遵循FIPS标准，但硬件实现有一个关键细节：它至少会增加9个字节的填充。这9字节包括：1个字节的结束位0x80，以及8个字节的消息总长度（位长度）。

这导致了一个重要的边界问题：最后一个数据块的大小决定了是否需要额外增加一个填充块。

• 如果最后一块数据 ≤ 55 字节：填充字节可以全部塞进这最后一个64字节块中。你只需要写入这最后一块数据（哪怕只有1个字节），并设置CLOSE_HASH=1和正确的LENGTH，硬件会在这个块内完成填充和计算。
• 如果最后一块数据在 56 到 63 字节之间：坏消息，这个块剩下的空间（最多8字节）不足以容纳9字节的填充。硬件会自动再申请一个全新的64字节块作为填充块。这意味着，即使你只给了它60字节的数据，它内部实际上会处理两个块：一个60字节的数据块（你提供的）和一个完整的64字节填充块。

这对你有何影响？

1. 性能预估：计算处理时间时，需要考虑可能存在的额外填充块。一个63字节的消息和一个64字节的消息，硬件处理时间可能是一样的（都是两个块）。
2. DMA配置：如果你使用DMA传输数据，当最后一块数据在56-63字节时，硬件在消费完DMA传输的数据后，还会内部生成一个数据块进行处理。你的DMA传输完成中断并不代表整个哈希计算完成，你必须等待OUTPUT_READY标志。
3. 长度寄存器写入：SHAMD5_LENGTH寄存器写入的是你提供的消息的总字节数，而不是块数。硬件会根据这个总长度和CLOSE_HASH位，自行判断如何填充。你永远不需要自己去计算填充字节。

4.3 单次（One-Shot）与多次（Multi-Pass）哈希流程对比

手册中的表格（Table 19-5/19-6）清晰地展示了两种模式，我用更直白的语言解释：

多次传递模式（流式或分块处理）：

• 场景：数据是实时产生的，或者太大无法一次性放入内存。
• 流程：
  1. 初始化：设置算法，ALGO_CONSTANT=1，CLOSE_HASH=0，LENGTH=64（或当前块大小）。
  2. 写入第一个64字节数据块，触发计算。
  3. 等待INPUT_READY再次变高，写入下一个64字节块，ALGO_CONSTANT=0（后续块不再初始化），CLOSE_HASH=0。
  4. 重复步骤3，直到最后一个块。
  5. 处理最后一个块：写入数据（可能不足64字节），设置CLOSE_HASH=1，LENGTH为剩余字节数。触发最终计算。
• 关键：中间过程的哈希上下文（中间摘要）由硬件在IDIGEST寄存器中自动维护，你无需保存恢复，除非被高优先级任务打断。

单次传递模式：

• 场景：所有数据都在内存中，一次性处理完毕。
• 流程：
  1. 初始化：设置算法，ALGO_CONSTANT=1，CLOSE_HASH=1（因为一次就结束），LENGTH为整个消息的总字节数（比如129字节）。
  2. 开始写入数据。硬件会等待你喂满第一个64字节块，处理它；然后等待第二个64字节块，处理它；最后你写入最后一个字节（第129字节），硬件会自动处理填充并完成计算。
• 注意：即使你设置CLOSE_HASH=1，你仍然需要把数据以64字节为单位写入DATA_IN寄存器。硬件内部会管理缓冲区和块边界。

5. 三种操作模式的选择与编程实战

选择哪种模式取决于你的系统对实时性、CPU占用率和代码复杂度的权衡。

5.1 轮询模式：简单直接，CPU独占

这是最基本的模式，适用于低数据率或对实时性要求不高的场景。

操作流程：

1. 配置算法、密钥（如需）、模式。
2. 写入LENGTH寄存器触发。
3. 循环查询SHAMD5_IRQSTATUS.INPUT_READY位。当它为1时，向SHAMD5_DATA_n_IN写入64字节数据。
4. 重复步骤3，直到所有数据块写入完毕（对于最后一块，写入数据后设置CLOSE_HASH=1）。
5. 循环查询SHAMD5_IRQSTATUS.OUTPUT_READY位，当它为1时，从SHAMD5_IDIGEST寄存器读取结果。

优缺点：

• 优点：实现简单，无需配置中断或DMA。
• 缺点：CPU在等待INPUT_READY和OUTPUT_READY时处于忙等状态，浪费周期，功耗高，无法处理其他任务。

5.2 中断模式：平衡性能与复杂度

这是最常用的模式，适合大多数通用场景。CPU在硬件处理数据时可以被释放出来。

配置与流程：

1. 全局初始化：使能加密模块时钟 (CRYPTOCLKEN)。
2. 配置加速器中断：设置SHAMD5_SYSCONFIG.PIT_EN = 1。在NVIC中使能对应的SHA/MD5中断。
3. 编写中断服务程序：这是核心。
   • 中断触发时机：当一个数据块被处理完，且下一个数据块可以接收时（INPUT_READY），或者整个计算完成时（OUTPUT_READY），硬件会产生中断。通常我们只关心OUTPUT_READY中断来读取结果，而数据写入则在主循环中通过查询INPUT_READY进行，以避免中断过于频繁。
   • ISR内操作：读取SHAMD5_IRQSTATUS判断中断源，清除中断标志（通常通过向相应位写1），然后进行相应操作（如设置标志通知主循环数据可写，或读取最终结果）。
4. 主程序流程：配置并启动哈希后，当需要写入数据时，查询INPUT_READY标志（非阻塞式查询，可以穿插其他任务），当标志有效时写入下一个数据块。

// 简化的中断模式示例框架 volatile bool g_hash_complete = false; void SHA_MD5_IRQHandler(void) { uint32_t status = SHAMD5->IRQSTATUS; if (status & OUTPUT_READY_MASK) { // 计算完成，读取结果 // ... 读取 SHAMD5_IDIGEST_x ... g_hash_complete = true; // 清除中断标志 SHAMD5->IRQSTATUS = OUTPUT_READY_MASK; } // 可能还需要处理 INPUT_READY 中断，但通常用查询更高效 } void main(void) { // 初始化硬件、中断等 // 配置HMAC或哈希 SHAMD5->MODE = ...; // 设置算法、HMAC_KEY_PROC等 SHAMD5->LENGTH = total_len; // 触发开始 while(!g_hash_complete) { if (/* 有数据待处理 */ && (SHAMD5->IRQSTATUS & INPUT_READY_MASK)) { // 向 SHAMD5->DATA0_IN 等寄存器写入64字节数据 // 如果是最后一块，确保MODE中的CLOSE_HASH已设置 } // 此处可以执行其他低优先级任务 __WFI(); // 等待中断，进入低功耗模式 } // 处理g_hash_complete为真后的逻辑 }

5.3 DMA模式：极致吞吐，解放CPU

当需要处理连续的大数据流（如加解密网络数据包）时，DMA模式是唯一选择。它允许数据在内存和加速器之间自动搬运，完全不需要CPU干预。

配置流程：

1. 全局初始化：使能加密模块时钟和µDMA控制器时钟。
2. 配置µDMA通道：将SHA/MD5加速器的数据输入请求映射到一个µDMA通道。配置该通道为外设到内存或内存到外设的传输模式（通常是内存到外设，因为CPU需要把数据送给加速器）。设置源地址（你的数据缓冲区）、目标地址（SHAMD5_DATA0_IN）、传输数据量（必须是64字节的倍数，最后一块特殊处理）。
3. 使能加速器DMA请求：设置SHAMD5_SYSCONFIG.PDMA_EN = 1。
4. 启动：配置好加速器模式并写入LENGTH后，硬件会拉高INPUT_READY并自动发出DMA请求。µDMA控制器开始搬运第一个64字节数据块。
5. 循环与结束：DMA完成一个块的传输后，硬件开始计算，计算完毕再次拉高INPUT_READY，触发下一次DMA传输，直到所有数据块传输完毕。对于最后一个块，你需要预先设置CLOSE_HASH=1。最终计算完成会触发OUTPUT_READY中断或标志。

DMA模式下的最后一个块处理： 这是DMA模式的一个小难点。因为DMA传输大小通常是预设的。如果消息总长度不是64字节的整数倍，最后一个DMA传输的大小就不是64字节。

• 你需要将最后一个非对齐数据块（比如13字节）通过CPU（或另一个DMA通道）写入DATA_IN寄存器，因为标准的64字节块DMA传输不适用。
• 或者，你可以配置DMA传输总字节数，并在最后一个传输完成后，由CPU来设置CLOSE_HASH位并写入LENGTH（最后一块的真实字节数）来触发最终计算。这需要精细的DMA传输完成中断配合。

经验之谈：对于纯粹的流式哈希（如对整个文件做校验），DMA模式优势巨大。但对于HMAC，尤其是需要复用预计算密钥的场景，数据流可能不连续，中断模式反而更灵活。通常的做法是：使用DMA传输大批量的消息数据块，但用中断来处理启动、密钥加载、最后一块处理以及结果读取这些控制逻辑，形成一种混合模式。

6. 常见问题排查与调试心得

即使理解了原理，实际调试中还是会遇到各种问题。下面是我总结的一些典型故障和排查思路。

6.1 问题速查表

6.2 调试技巧与心得

1. 从简单验证开始：不要一开始就挑战HMAC。先用已知的测试向量（如“abc”的SHA-256值）实现最简单的单次哈希轮询模式，确保数据通路和基本配置是正确的。
2. 善用寄存器快照：在关键步骤（如加载密钥后、触发计算前、计算完成后）读取并打印所有相关的控制寄存器、状态寄存器和摘要寄存器的值。与手册的预期值或你的软件计算结果进行比对。
3. 理解“小端”的含义：这是最常见的错误来源。硬件要求所有数据（密钥、消息）都以小端格式写入32位寄存器。如果你的源数据是大端（网络字节序），必须在写入前进行转换。一个常见的错觉是：我直接把一个uint8_t key[32]数组的地址强转成uint32_t*然后写入，这在小端机器上是对的，因为内存布局本身就是小端。但如果你从网络包或大端设备获取数据，就必须手动交换字节序。
4. 关注DIGEST_COUNT寄存器：这个寄存器反映了硬件内部处理的数据字节数。在调试多块或续算场景时，检查它的值是否符合预期，可以帮助你判断数据块是否被正确计数。
5. 性能权衡：中断模式通常是最佳平衡点。DMA模式虽然高效，但初始化复杂，且对数据流的规整性要求高。对于每秒只需处理几次认证的小数据包，轮询模式可能更简单，代码量更小。选择没有绝对，只有最适合当前场景的。