企业官网建设流程全解析

离线支付终端这个方向，我在几个小规模商用项目里反复折腾过，从最早用裸机跑简单校验，到后来把安全链路一层层垒起来，踩过的坑比写过的代码还多。STM32做离线支付终端，核心矛盾从来都不是"能不能跑起来"，而是"跑起来之后数据能不能信"。一台设备脱离网络独立完成交易，意味着所有信任都得在本地建立——交易金额不能被篡改、交易记录不能被伪造、存储介质被拆走之后数据不能裸奔。这三个问题对应下来，就是多层加密体系和HMAC-SHA256完整性验证要解决的事。标题里提到的"多层加密"不是堆砌算法，而是按数据敏感度和攻击面分层设防；HMAC-SHA256也不是随便挂个校验，它承担的是"防篡改+防伪造"的双重职责。这篇内容适合正在做嵌入式安全终端、离线交易设备、或者任何需要在资源受限MCU上落地完整性保护的同行参考，不管你是刚接触STM32安全开发的新手，还是想优化现有方案的老手，下面这些拆解和实操细节应该都能对上你的需求。

1. 整体方案设计与分层思路拆解

1.1 为什么离线终端必须做"多层"而不是"一层"

很多人第一反应是：既然要加密，那就把所有数据用一个AES密钥加密完事，完整性用CRC校验一下不就行了。这个思路在小项目里能跑，但放到支付终端上就是灾难。原因在于攻击面是分层的，单一防护只能挡住一个层面的问题。

我拿实际场景拆给你看。一台离线支付终端，数据流转大致经过这几个位置：交易数据在RAM里生成、写入外部Flash或EEPROM做持久化、通过串口或USB和上位机/读卡器交互、最后可能还要通过蓝牙或NFC做近场传输。每一个位置对应的威胁模型完全不同——RAM里的数据面临的是调试接口被接、内存被dump；外部存储面临的是芯片被拆下来直接读；通信链路面临的是抓包重放；而交易记录本身面临的是事后篡改抵赖。

单一AES加密能解决存储机密性，但解决不了通信链路上的重放攻击，也解决不了"密文被替换成另一段合法密文"这种完整性攻击。CRC32能发现随机错误，但它是线性的，攻击者可以构造碰撞，完全挡不住恶意篡改。所以多层设计的逻辑是：机密性用对称加密分层覆盖，完整性用带密钥的HMAC统一兜底，密钥本身再用设备唯一标识做派生保护。这三层各管一段，互相不替代。

具体分层我习惯这么划：

这个表不是拍脑袋定的。AES-CTR选它而不是CBC，是因为CTR模式加解密同构、不需要填充、可以按块随机访问，对Flash这种按页读写的介质特别友好，而且它天然支持流式处理，交易数据边生成边加密不用攒整块。HMAC-SHA256选它而不是单纯SHA256，是因为裸哈希没有密钥，攻击者篡改数据后重新算一遍哈希就通过了，HMAC把密钥掺进哈希过程，没有密钥就算不出正确摘要。密钥分散则是为了把"一锅端"的风险拆开，每台设备的实际加密密钥由主密钥和设备UID经过KDF派生，这样即使某台设备被逆向出密钥，也推不出其他设备的密钥。

1.2 STM32平台上的资源约束与算法取舍

在PC上谈加密随便选，在STM32上就得算账。我用的主控是STM32F4系列（带FPU、168MHz、192KB RAM、1MB Flash），这个配置在离线支付终端里算中档，再低就得认真权衡了。先把几个关键算法的资源开销摆出来，这些数据是我实测的，不是手册抄的：

看到RSA那一行你就明白了，离线终端里做非对称签名不是不行，但每次几百毫秒的延迟在交易场景里体验很差，而且20KB+的Flash占用对小容量型号是硬伤。所以我的取舍是：对称加密和HMAC走软件实现（或用STM32的CRYPTO外设加速），非对称只用在设备初始化阶段的密钥协商或固件签名验证上，不放在每笔交易的实时路径里。F4系列部分型号带硬件加密外设（AES/HASH加速），有的话一定要用，AES硬件加速能把单块耗时压到1us以内，SHA-256也能快3-5倍，这对交易响应时间帮助很大。

还有一个容易被忽略的点：栈空间。HMAC-SHA256的软件实现里，SHA-256的压缩函数会用到不小的局部变量，如果栈给得太小（比如默认的1KB），跑起来会莫名其妙HardFault。我一般把主栈设到2KB以上，加密相关任务单独给栈，别和主循环挤在一起。

1.3 数据流与信任边界的划分

方案设计里最容易被跳过、但出事最多的，是信任边界没划清楚。什么叫信任边界？就是"数据从哪个点开始被认为是可信的"。在离线终端里，我的划分是这样的：

交易数据在MCU内部RAM中生成的那一刻起，就进入可信域，此后每一次离开MCU（写外部存储、发通信口）都必须带着完整性标签；而任何从外部进来的数据（读卡器输入、上位机下发的指令），在通过HMAC验证之前一律视为不可信。

这个边界一旦定下来，代码结构就清晰了：所有出站数据走一个统一的"封装-加密-签名"管道，所有入站数据走一个统一的"验签-解密-解析"管道。管道之外不允许有裸数据流动。我见过不少项目，主流程里东一句AES加密、西一句CRC校验，最后某个分支忘了加校验，整条链就漏了。把管道收敛成两个函数入口，是保证不漏的最笨也最有效的办法。

2. 多层加密体系的核心细节与实操要点

2.1 AES-CTR分块加密的落地实现

先说加密层。选CTR模式除了前面说的随机访问和流式处理优势，还有一个实际考量：它不需要 padding，密文长度和明文严格相等。支付终端里交易记录是变长的（金额、时间、卡号摘要、商品码长度不一），用CBC就得处理填充，填充还引入额外的边界bug，CTR直接省掉这层麻烦。

CTR的原理说白了就是把一个递增的计数器用AES加密成密钥流，然后和明文逐字节异或。加密和解密是同一个操作，代码可以复用。这里的关键是计数器（nonce + counter）的管理，这是CTR模式唯一的命门：同一个密钥下，计数器绝对不能重复，一旦重复，两段密文的异或就等于两段明文的异或，机密性直接崩掉。

我的做法是：nonce用8字节，由设备UID的低6字节加2字节随机数组成，counter用8字节从0开始递增。每笔交易生成一个新的nonce，nonce本身不保密，跟着密文一起存。这样即使同一设备连续交易，nonce也不同，计数器不会撞。代码骨架大概是这样：

typedef struct { uint8_t nonce[8]; uint64_t counter; } ctr_ctx_t; void aes_ctr_crypt(const uint8_t *key, ctr_ctx_t *ctx, const uint8_t *in, uint8_t *out, uint32_t len) { uint8_t keystream[16]; uint8_t block[16]; uint32_t i = 0; while (i < len) { // 组装计数器块：nonce(8B) + counter(8B, 大端) memcpy(block, ctx->nonce, 8); for (int b = 0; b < 8; b++) block[8 + b] = (ctx->counter >> (56 - 8 * b)) & 0xFF; aes_encrypt_block(key, block, keystream); // 单块AES加密 uint32_t n = (len - i < 16) ? (len - i) : 16; for (uint32_t j = 0; j < n; j++) out[i + j] = in[i + j] ^ keystream[j]; ctx->counter++; i += n; } }

这段代码有几个实操要点必须强调。第一，counter要用大端序组装，虽然CTR本身对字节序没强制要求，但统一成大端方便跨平台调试和日志比对。第二，aes_encrypt_block只做加密不做解密，CTR永远只用加密方向，别写成通用AES接口再判断方向，白白多带一份解密代码。第三，nonce生成后要立刻持久化，不能等交易完成再存，否则中途掉电重启后nonce可能复用。我一般把nonce和交易序列号绑在一起存到Flash的独立扇区，上电先读出来判断连续性。

注意：CTR模式下密文被篡改一位，解密后明文对应位也变一位，而且不会报错。这就是为什么CTR必须搭配HMAC使用，加密层本身不提供任何完整性保证，别指望它发现篡改。

2.2 密钥分散与设备唯一性绑定

密钥管理是整套方案里最敏感的部分。最忌讳的做法是所有设备烧同一个AES密钥，那样一台设备被逆向，全网设备沦陷。我的方案是密钥分散：产线烧录一个主密钥（Master Key）到设备的受保护区域，同时读取芯片唯一ID（STM32的96位UID），用KDF（密钥派生函数）算出该设备的实际工作密钥。

派生逻辑我用的是HMAC-SHA256做KDF，简单可靠：

// 设备工作密钥派生：MK为128位主密钥，UID为96位芯片唯一ID void derive_device_key(const uint8_t *mk, const uint8_t *uid, uint8_t *out_key) { uint8_t digest[32]; // 以UID为消息，MK为HMAC密钥 hmac_sha256(mk, 16, uid, 12, digest); memcpy(out_key, digest, 16); // 取前128位作为AES密钥 }

这样每台设备的AES密钥都不同，且无法从一台设备反推另一台。主密钥本身怎么保护？STM32F4没有像F7/H7那样的完整安全存储区，我的做法是把主密钥存在内部Flash的最后一个扇区，配合读保护（RDP Level 1）和调试接口禁用。RDP Level 1能挡住通过调试口读Flash，虽然它不是绝对安全（有已知的降级攻击手法），但在成本敏感的中低端方案里是性价比最高的选择。如果项目预算允许，选带TrustZone的L系列或带OTP密钥区的型号会更稳。

这里有个实操坑我踩过：UID的读取时机。STM32的UID在系统存储区，用*(uint32_t*)0x1FFF7A10这类地址读，但不同型号地址不一样，F4是0x1FFF7A10，F1是0x1FFFF7E8，换型号必须改。更稳妥的做法是用HAL库的HAL_GetUIDw0/1/2()，跨型号兼容。还有，UID读取要在密钥派生之前完成，且派生结果不要缓存到普通RAM里长期驻留，用完就清，减少被dump的窗口。

2.3 存储加密与通信加密的差异化处理

存储加密和通信加密虽然都用AES-CTR，但参数策略要分开。存储场景下数据是持久化的，nonce必须保证跨掉电不重复，所以我把nonce和交易序号绑定，序号单调递增存在Flash里，上电校验序号连续性，发现回退就判定异常。通信场景下数据是瞬时的，nonce可以用随机数，配合接收端的重放窗口做校验。

通信层的防重放我是这么设计的：每条报文带一个4字节序列号和一个4字节时间戳（终端本地RTC），接收端维护一个滑动窗口，序列号在窗口内且时间戳偏差不超过阈值（我设的是±30秒）才接受。序列号单调递增，窗口外的旧报文直接丢弃。这套机制配合HMAC，抓包重放基本没戏——攻击者重放旧报文，序列号过不了窗口；篡改序列号，HMAC验不过。

存储层的加密粒度也值得说一下。我不对整个Flash扇区无差别加密，而是按记录加密：每条交易记录独立生成nonce、独立加密、独立HMAC，记录头里存nonce和HMAC标签。这样读取单条记录不用解密整个扇区，擦写也灵活。代价是每条记录多出8字节nonce加32字节HMAC，存储开销约40字节/条，对支付终端这种记录量不大的场景完全可以接受。

3. HMAC-SHA256完整性验证的完整实现

3.1 HMAC-SHA256的原理拆解与参数选择

HMAC的构造是HMAC(K, m) = H((K' ⊕ opad) || H((K' ⊕ ipad) || m))，其中K'是把密钥处理成块长（SHA-256块长64字节）后的结果，ipad和opad是两个固定常量。这个双层哈希结构的作用是防止长度扩展攻击——裸SHA256存在长度扩展漏洞，攻击者可以在不知道密钥的情况下在消息后追加内容并算出合法哈希，HMAC通过外层再套一次哈希把这个漏洞堵死。

参数选择上，SHA-256输出256位（32字节）摘要，HMAC标签就取完整32字节，不做截断。有人为了省空间截断到16字节，理论上安全性还够（128位抗碰撞），但在支付场景里没必要省这16字节，完整标签更稳妥。密钥长度我用的是32字节（256位），和SHA-256块长匹配，避免K'的填充处理开销。密钥同样走设备派生，不硬编码。

实现上，如果STM32型号带HASH外设（F4的部分型号有），优先用硬件加速；没有的话用成熟的软件实现（我参考的是公开的轻量级SHA-256实现，代码量约4KB）。软件实现里最容易出错的是消息分块和填充：SHA-256要求消息末尾补0x80、补零、最后8字节存原始比特长度（大端）。填充逻辑写错，短消息可能碰巧对，长消息就全错。我建议单独写个测试用例，用标准测试向量（比如"abc"的SHA-256是ba7816bf...）验证填充正确性，别等集成到业务里才发现。

3.2 完整性标签的生成、存储与验证流程

完整的完整性链路分三步：生成、存储、验证。生成在数据封装时做，存储跟着密文走，验证在数据被使用前做。我把这三步收敛成两个函数：

// 封装：加密 + 生成HMAC，输出到out缓冲区 // 格式：[nonce 8B][密文 NB][HMAC 32B] int secure_pack(const uint8_t *key, const uint8_t *plain, uint32_t len, uint8_t *out, uint32_t *out_len) { ctr_ctx_t ctx; gen_nonce(ctx.nonce); // 生成并持久化nonce ctx.counter = 0; memcpy(out, ctx.nonce, 8); aes_ctr_crypt(key, &ctx, plain, out + 8, len); // HMAC覆盖nonce+密文，防止nonce被替换 hmac_sha256(key, 32, out, 8 + len, out + 8 + len); *out_len = 8 + len + 32; return 0; } // 解封：先验HMAC，通过后再解密 int secure_unpack(const uint8_t *key, const uint8_t *in, uint32_t len, uint8_t *plain, uint32_t *plain_len) { if (len < 8 + 32) return -1; uint32_t data_len = len - 8 - 32; uint8_t calc[32]; hmac_sha256(key, 32, in, 8 + data_len, calc); // 常量时间比较，防时序侧信道 if (ct_memcmp(calc, in + 8 + data_len, 32) != 0) return -2; ctr_ctx_t ctx; memcpy(ctx.nonce, in, 8); ctx.counter = 0; aes_ctr_crypt(key, &ctx, in + 8, plain, data_len); *plain_len = data_len; return 0; }

这里有几个设计决策值得展开。HMAC覆盖范围包含nonce，这点很关键：如果只对密文做HMAC，攻击者可以把nonce换掉，虽然解密出来是乱码，但某些场景下乱码也可能触发异常逻辑，覆盖nonce能保证整个报文任何一位被改都验不过。验证必须在解密之前，先验签再解密，验不过直接拒绝，绝不解密不可信数据，这是防御性编程的基本纪律。比较用常量时间函数，普通的memcmp在发现第一个不同字节就返回，攻击者可以通过测量比较耗时逐字节猜出正确HMAC，虽然离线终端上这种攻击实施难度高，但养成习惯没坏处，ct_memcmp就是遍历全部字节、累积异或结果、最后统一判断。

3.3 防重放与防篡改的协同设计

HMAC解决了"数据有没有被改"，但解决不了"这段数据是不是旧的"。攻击者完全可以把昨天的一条合法交易记录原样重放，HMAC照样验得过。所以完整性验证必须和防重放机制协同。

我的协同方案是把序列号纳入HMAC覆盖范围，并在验证时检查序列号单调性。具体来说，交易记录头里有个4字节序列号，封装时序列号参与HMAC计算，解封时先验HMAC（确认序列号没被改），再检查序列号是否大于已处理的最大序列号（确认不是旧记录）。两个检查都过才接受。序列号的最大值存在Flash的独立位置，每次接受新记录后更新，掉电也不丢。

这里有个细节：序列号检查的"大于"判断要防回绕。4字节序列号理论上会溢出，虽然支付终端一辈子也交易不了40亿笔，但代码里还是加个判断，接近最大值时触发密钥轮换或告警，别留理论漏洞。另外，序列号的持久化写入要和记录写入做原子性保证——先写记录再更新序列号，如果中途掉电，重启后发现记录存在但序列号没更新，以记录里的序列号为准做修复。这种掉电一致性问题是离线设备的高频故障点，必须提前设计。

4. 实操过程与关键环节落地

4.1 开发环境搭建与加密库集成

环境这块我走的是STM32CubeIDE + HAL库的路线，加密算法用软件实现（不依赖第三方加密库，避免引入不可控的依赖和许可证问题）。工程结构上，我把安全相关代码单独放一个目录，和业务代码物理隔离：

/project /Core /Src main.c app_payment.c // 业务逻辑 /Secure aes_ctr.c/.h // AES-CTR实现 sha256.c/.h // SHA-256实现 hmac.c/.h // HMAC封装 secure_pack.c/.h // 封装/解封管道 key_mgmt.c/.h // 密钥派生与管理

物理隔离的好处是代码审计时一眼能看出安全边界，也方便后续把Secure目录整体替换成硬件加速版本而不动业务代码。集成顺序我建议是：先单独验证SHA-256（跑标准测试向量），再验证HMAC（用RFC 4231的测试用例），再验证AES-CTR（用NIST的测试向量），最后才组装成secure_pack管道。每一步都单独过测试，别一上来就集成，出了问题根本定位不到是哪层。

编译配置上有个坑：优化等级会影响加密代码的正确性。某些软件实现里用了位操作和临时变量，开-O2/-O3时如果代码写得不够严谨（比如有未定义行为、有依赖求值顺序的表达式），可能被优化出错误结果。我的做法是Secure目录单独设-O1，业务代码-O2，用编译器的per-file选项控制。另外，加密相关的缓冲区如果涉及DMA，要注意cache一致性（F7/H7有cache，F4没有，这点F4省心）。

4.2 交易数据的封装-加密-签名全流程

一笔完整交易的落地流程，我按时间顺序拆给你看。假设用户刷卡、输入金额、确认，终端要生成一条交易记录并持久化。

第一步，组装明文记录。结构体大概是这样：交易序号（4B）、时间戳（4B）、金额（4B，单位分）、卡号摘要（8B，卡号经不可逆摘要处理，不存明文卡号）、商品码（变长，最多16B）、状态标志（1B）。明文总长控制在64字节以内，短报文让HMAC开销占比不至于太高。

第二步，生成nonce并持久化。nonce由设备UID低6字节加2字节随机数（用ADC噪声或RTC抖动做熵源）组成，生成后立刻写入Flash的nonce记录区，写入成功才继续。这一步的持久化是防掉电nonce复用的关键。

第三步，加密。调用aes_ctr_crypt，密钥是设备派生密钥，nonce用刚生成的，counter从0开始。密文长度等于明文长度。

第四步，生成HMAC。对nonce || 密文整体算HMAC-SHA256，密钥同样用设备派生密钥（实际项目中加密密钥和HMAC密钥应该分开派生，用不同的KDF标签，我这里为了简化说明用同一个，正式项目务必分开）。

第五步，组装存储记录。格式为[记录头 4B][nonce 8B][密文 NB][HMAC 32B]，记录头里放序列号和长度。写入Flash时按页对齐，注意Flash写入前必须擦除，擦除粒度是扇区（F4通常16KB-128KB），所以记录存储要按扇区管理，别一条记录一个扇区浪费空间。我的做法是一个扇区存多条记录，扇区写满后整体擦除最旧的扇区（环形日志结构）。

第六步，更新序列号。记录写入成功后，把序列号最大值更新到Flash的元数据区。这一步和第五步的原子性问题前面提过，用"以记录为准"的修复策略兜底。

整个流程走下来，一笔交易的安全处理耗时（不含Flash擦写）在F4上大约2-3ms，其中HMAC占大头（约150us），AES-CTR对64字节约15us，其余是组装和校验开销。Flash擦写才是真正的时间大头，扇区擦除动辄几十到几百毫秒，所以交易响应体验的优化重点在存储策略上，不在加密算法上。

4.3 上电自检与密钥加载顺序

离线终端每次上电都要做安全自检，顺序不能乱。我的上电流程是：

1. 时钟和基础外设初始化（这步不涉及安全）
2. 读芯片UID，派生设备密钥到RAM（用完不清，整个运行期要用，但放在受保护的结构体里）
3. 校验Flash中的密钥元数据完整性（主密钥区带一个HMAC自校验，防止主密钥区被破坏后派生出一堆错误密钥还不自知）
4. 读nonce记录区和序列号元数据，做连续性检查
5. 扫描交易记录区，验证最新若干条记录的HMAC（抽样验证，不用全验，全验上电太慢）
6. 自检通过才进入业务主循环，任何一步失败进入安全锁定状态，只允许维护模式

第3步的主密钥自校验容易被忽略。主密钥存在Flash里，如果因为擦写异常或电压不稳导致某位翻转，派生出来的设备密钥就全错了，但程序不知道，继续用错误密钥加密，数据写进去就再也解不开了。加一个主密钥区的HMAC自校验（校验密钥可以硬编码在代码里，或者用另一段OTP），能在上电时立刻发现密钥损坏，进入维护模式而不是带病运行。

第5步的抽样验证也有讲究。全量验证所有历史记录，记录多了上电要好几秒，体验差。我一般验证最近10条加随机抽3条，既能发现近期篡改，又能以一定概率覆盖历史记录。真要严格审计，可以做个后台任务慢慢全验，不阻塞主流程。

5. 常见问题与排查技巧实录

5.1 加密与HMAC相关的典型故障速查

下面这张表是我在实际项目里遇到过的、以及同行反馈过的高频问题，按现象、可能原因、排查方法整理：

重点说两个我踩得最深的。第一个是nonce复用。早期版本我图省事，nonce在RAM里生成，交易完成后才和记录一起写Flash。结果测试时模拟掉电（交易写完但nonce没写），重启后nonce重新生成，和上一条用了相同值，两段密文一异或，明文规律就暴露了。后来改成nonce先持久化再加密，问题解决。这个坑的教训是：任何影响密码学安全的状态，持久化时机必须早于使用时机。

第二个是HMAC覆盖范围不一致。封装时我HMAC算的是nonce || 密文，解封时某次重构代码不小心改成了只算密文，结果新写入的记录用新逻辑验得过，旧记录用新逻辑全验不过，现场升级后历史数据全废。教训是封装和解封必须共用同一段覆盖范围定义，我后来把覆盖范围的计算抽成一个函数，两边都调它，杜绝手写不一致。

5.2 性能瓶颈定位与优化实录

离线终端对交易响应时间敏感，我做过一轮性能剖析。用GPIO翻转加示波器测各阶段耗时，数据如下（F4@168MHz，64字节交易记录）：

看这个表就明白了，加密算法根本不是瓶颈，Flash擦写才是。nonce持久化和记录写入加起来占了绝大部分时间。优化方向很明确：把nonce、记录、序列号尽量合并到同一次Flash操作里，减少擦除次数；用环形日志结构让擦除均摊到多次交易；如果主控支持，用带独立小扇区的EEPROM模拟或者外挂FRAM做元数据存储，擦写速度快几个数量级。我后来把nonce和序列号元数据放到一个2KB的独立小扇区，每次只改这一小片，擦除时间从几十毫秒降到几毫秒，交易响应明显改善。

HMAC的优化则是另一条线。软件SHA-256在168MHz上处理64字节约150us，如果交易频率高（比如每秒多笔），这个开销会累积。带HASH外设的型号一定要开硬件加速，实测能降到50us以内。没有硬件加速的话，可以考虑对短报文用SHA-256的优化实现（比如预计算中间状态），但收益有限，不如从存储策略上省时间。

5.3 安全加固的额外经验

除了主流程，还有几个加固点值得单独说。调试接口：量产固件必须关闭SWD/JTAG，用选项字节设置，别只在代码里禁用（代码禁用挡不住上电瞬间的连接）。固件完整性：启动时对自身固件算一次HMAC或哈希，和存储的期望值比对，防止固件被替换。这个自校验的密钥不能存在被校验的固件里，得放OTP或独立区域。异常处理：HMAC验证失败、序列号异常这些安全事件要记录到独立的审计日志里，日志本身也要防篡改（用追加式+链式HMAC，每条日志的HMAC覆盖前一条的HMAC，形成链，改一条后面全断）。

还有一个心态上的经验：别自己发明加密协议。我见过有人觉得标准HMAC"太重"，自己设计了个"密钥异或数据再哈希"的方案，看着像HMAC，实际有严重的安全缺陷。密码学原语用标准的、经过公开分析的，组合方式也尽量用成熟模式（比如encrypt-then-MAC，先加密再对密文做MAC，这是被证明安全的组合顺序）。自己拍脑袋的组合，安全性没法保证。

6. 方案扩展与工程化建议

6.1 从单机到批量部署的密钥管理延伸

单台设备跑通只是开始，批量部署时密钥管理会成为真正的挑战。产线要为每台设备烧录主密钥、读取UID、记录派生关系，这套流程要有工装和数据库支撑。我的建议是产线只烧主密钥（所有设备可以相同，也可以分批不同），设备UID和派生密钥的对应关系不入库（因为派生是确定性的，需要时用主密钥加UID重算即可），这样数据库里不存敏感密钥，泄露风险低。主密钥本身按批次管理，一批一密，某批次疑似泄露就整批轮换，影响范围可控。

密钥轮换机制也要提前设计。设备运行久了，或者发生安全事件，需要换密钥。轮换时旧密钥加密的历史数据怎么办？我的做法是密钥带版本号，记录头里存版本号，解密时按版本号选对应密钥。新交易用新密钥，旧记录用旧密钥解，等旧记录全部过期或迁移完再废弃旧密钥。这套机制要在第一版就留好接口，后加会很痛苦。

6.2 面向不同STM32型号的适配取舍

这套方案在不同STM32型号上落地要调整。F1系列（如F103）资源紧张，Flash 64-128KB，RAM 20KB，跑软件AES+SHA256要精打细算，建议砍掉非必要的日志和审计功能，HMAC标签可以考虑截断到16字节省空间。F4系列是甜点区，资源够用，部分型号有硬件加密外设，优先用。L4/L5低功耗系列适合电池供电的便携终端，但要注意低功耗模式下加密外设的时钟管理，别为了省电把加密时钟关了导致算法跑飞。带TrustZone的型号（如L5、U5）可以把密钥和加密操作放进安全区，非安全区代码碰不到密钥，安全性上一个台阶，代价是开发复杂度增加，要划安全/非安全分区、定义安全调用接口。

选型时的一个实用判断：如果项目对安全等级要求高（比如涉及真实资金），优先选带硬件加密+安全存储的型号，软件实现的防护在物理攻击面前终究有限；如果只是做完整性保护和轻量机密性，中端型号加软件实现足够，把省下的成本投入到产线密钥管理和固件安全上，收益更实在。

6.3 测试与验证的工程化落地

安全功能最怕"看起来能用"，必须用测试证明。我一般做三层测试。第一层是算法级单元测试，用标准测试向量验证AES、SHA-256、HMAC的正确性，这层在PC上跑，用同一份源码编译，确保算法实现无误。第二层是管道级集成测试，构造各种边界数据（空数据、最大长度、全零、全FF）走secure_pack/secure_unpack，验证往返一致性和篡改检测（故意改一位，确认验签失败）。第三层是故障注入测试，模拟掉电（在Flash写入的各个时间点断电）、模拟位翻转（用调试器改RAM/Flash内容）、模拟重放（重发旧报文），验证系统的容错和检测能力。

故障注入这层最容易被跳过，但价值最高。我做过一次掉电测试，在记录写入过程中随机断电100次，发现有3次出现了"记录写了一半但序列号已更新"的不一致状态，靠"以记录为准"的修复逻辑救回来了。如果没有这层测试，这种问题到了现场就是数据损坏。测试工具上，掉电模拟可以用可控电源加继电器做，位翻转用调试器手动改，重放用抓包工具重发，都不复杂，关键是肯花时间做。

我个人在实际操作中的体会是，离线支付终端的安全设计，难点从来不在某个算法写得多精妙，而在于每一层防护的边界是否清晰、每一处状态的持久化时机是否正确、每一个异常路径是否有兜底。算法是公开的、实现是成熟的，真正拉开差距的是工程细节——nonce什么时候落盘、HMAC覆盖到哪一位、掉电后怎么修复、密钥怎么轮换。这些东西文档里不会写，只能靠一次次测试和踩坑攒出来。最后再分享一个小技巧：把安全相关的所有状态变更都打上带时间戳的日志（日志本身用链式HMAC保护），出问题时这份日志就是最好的排查依据，比任何调试器都管用。