📚 课程目录第3章轻量级密码学

轻量级密码学：嵌入式TLS的四大支柱

嵌入式TLS实现，说白了就是在一堆资源受限的芯片上跑安全协议。你想想看，一个Cortex-M4内核的MCU，主频可能才200MHz，RAM只有几百KB，却要完成握手、加密、认证全套动作。这时候选什么密码算法，直接决定了你的设备能不能跑起来。

我个人习惯把这四个算法称为「嵌入式TLS的四大支柱」——AES-GCM、ChaCha20-Poly1305、ECDHE密钥交换、Ed25519签名。它们各有各的脾气，选错了，要么性能崩盘，要么安全翻车。

核心观点：嵌入式环境没有「万能算法」，只有「最合适的组合」。轻量级不等于弱安全，而是用更少的资源达到同等级别的安全强度。

AES-GCM：硬件加速的宠儿

AES-GCM是TLS 1.3的默认加密套件。它把AES加密和GHASH认证揉在一起，一次搞定机密性和完整性。为什么嵌入式设备喜欢它？因为很多MCU内置了AES硬件加速器，跑GCM模式几乎不费CPU。

我在项目中遇到过一个问题：某款芯片的AES引擎只支持ECB/CBC模式，不支持GCM的计数器模式。结果我们不得不在软件里模拟CTR模式，性能直接腰斩。嗯，这里要注意——选型时一定要确认硬件是否原生支持GCM。

实战技巧：如果你的芯片有AES加速器但没GCM专用指令，可以用「AES-CTR + GHASH软件实现」的组合。CTR模式用硬件加速，GHASH用查表法优化，性能比纯软件快3-5倍。

AES-GCM的核心参数：

密钥长度：128位（推荐）、192位、256位。嵌入式场景128位足够，别浪费算力。
Nonce（IV）：96位，每次加密必须唯一。重复nonce等于自杀——攻击者可以恢复密钥流。
认证标签：128位。可以截断到64位或32位节省带宽，但我不建议这么做。截断后碰撞概率上升，安全边界变窄。

// AES-128-GCM 加密示例（使用mbedTLS API）
mbedtls_gcm_context ctx;
unsigned char key[16] = {0x2b, 0x7e, 0x15, 0x16, ...};
unsigned char nonce[12] = {0x00, 0x01, 0x02, 0x03, ...};
unsigned char plaintext[64] = "Hello, TLS!";
unsigned char ciphertext[64];
unsigned char tag[16];

mbedtls_gcm_init(&ctx);
mbedtls_gcm_setkey(&ctx, MBEDTLS_CIPHER_ID_AES, key, 128);
mbedtls_gcm_crypt_and_tag(&ctx, MBEDTLS_GCM_ENCRYPT,
                          sizeof(plaintext), nonce, 12,
                          NULL, 0,           // 附加认证数据（AAD）
                          plaintext, ciphertext,
                          tag, sizeof(tag));
mbedtls_gcm_free(&ctx);

警告：千万不要在多个TLS会话中复用同一个nonce！我曾经见过一个产品，因为随机数生成器种子没初始化，每次重启后nonce都一样。结果两个会话的加密数据被截获后，攻击者直接异或出了明文。血的教训。

ChaCha20-Poly1305：无硬件加速时的救星

ChaCha20-Poly1305是Google设计的流加密方案，专门针对没有AES加速器的设备。它的核心思想很简单：用ChaCha20生成密钥流，再用Poly1305做消息认证码。两个算法都是纯软件友好的，不需要查表，不需要硬件支持。

我记得第一次在Cortex-M0上跑ChaCha20-Poly1305时，心里还挺没底的。结果一测，加密64字节数据只用了不到2000个CPU周期，比同平台上的AES-128-GCM快了将近4倍。为什么？因为AES-GCM的GHASH需要GF(2^128)乘法，在没硬件加速的芯片上就是噩梦。

对比项	AES-128-GCM	ChaCha20-Poly1305
硬件依赖	需要AES加速器或查表	纯软件，无特殊指令需求
32位MCU性能	中等（依赖查表优化）	优秀（原生32位运算）
代码体积	较大（查表需要4KB+）	较小（约2KB）
专利限制	无（AES已公开）	无（完全公开）
抗侧信道	查表实现易泄露	常数时间实现简单

你想想看，如果你的设备是Cortex-M0或者RISC-V的低端核，没有AES扩展指令，那ChaCha20-Poly1305几乎是不二之选。Google在Android和Chrome里都把它作为备选方案，不是没道理的。

// ChaCha20-Poly1305 加密示例（使用WolfSSL API）
#include <wolfssl/options.h>
#include <wolfssl/wolfcrypt/chacha20_poly1305.h>

byte key[32] = {0x00, 0x01, 0x02, ...};
byte nonce[12] = {0x00, 0x00, 0x00, ...};
byte aad[16] = {0x01, 0x02, ...};
byte plaintext[128] = "Embedded TLS data";
byte ciphertext[128];
byte authTag[16];

wc_ChaCha20Poly1305_Encrypt(key, nonce, aad, sizeof(aad),
                            plaintext, ciphertext, sizeof(plaintext),
                            authTag);

性能优化：ChaCha20的核心是quarter-round函数，可以用汇编手写优化。我在STM32F4上做过实验，手写汇编版本比C版本快2.5倍。如果你做产品，建议把核心循环用汇编重写。

ECDHE密钥交换：前向安全的基石

ECDHE（椭圆曲线Diffie-Hellman Ephemeral）是TLS 1.3里唯一的密钥交换算法。它保证了前向安全性——就算服务器私钥泄露了，之前记录的会话也无法被解密。

为什么用「临时」密钥？因为每次握手都生成一对新的临时密钥对，用完就丢。这样即使攻击者拿到了长期私钥，也无法解密历史会话。我在做IoT网关时，就遇到过客户要求必须支持前向安全，否则不给过审。ECDHE是唯一的选择。

嵌入式场景下常用的曲线：

secp256r1（P-256）：最广泛支持，NIST标准，几乎所有TLS库都支持。
X25519：Curve25519的变体，设计更安全，实现更简单，没有专利限制。
secp384r1（P-384）：更高安全等级，但计算量是P-256的3倍以上，嵌入式慎用。

我个人习惯在嵌入式设备上优先用X25519。为什么？因为它的实现是常数时间的，天然抗侧信道攻击。而P-256的实现如果不小心，很容易通过时间或功耗泄露密钥信息。

避坑指南：ECDHE的随机数质量直接决定密钥安全。我曾经在一个项目里发现，芯片的硬件随机数生成器（TRNG）在刚上电时输出的前几个字节有偏置。结果导致临时私钥不够随机，被攻击者预测出来。解决方案是：每次握手前先读一批随机数做「热身」，丢弃前32字节。

Ed25519签名：小而美的认证方案

Ed25519是基于Curve25519的签名算法。它的签名只有64字节，公钥32字节，私钥32字节。相比传统的ECDSA（P-256签名需要64字节，公钥65字节），Ed25519在嵌入式场景下优势明显。

我记得第一次在Zigbee网关里集成Ed25519时，发现它的验证速度比ECDSA快了将近10倍。为什么？因为Ed25519的验证过程不需要模逆运算，而ECDSA需要。模逆在嵌入式芯片上就是性能杀手。

对比项	ECDSA P-256	Ed25519
公钥大小	65字节（未压缩）	32字节
签名大小	64字节	64字节
签名速度	中等	快（约2倍）
验证速度	慢（需模逆）	快（约10倍）
侧信道抗性	需额外防护	天然常数时间
标准状态	FIPS 186-4	RFC 8032

Ed25519还有一个隐藏优势：它支持批量验证。如果你需要同时验证多个签名（比如固件升级时验证多个分区的签名），批量验证可以把总时间压缩到单个验证的1.2倍左右。这个特性在OTA场景下非常实用。

// Ed25519 签名与验证示例（使用libsodium）
#include <sodium.h>

unsigned char pk[crypto_sign_PUBLICKEYBYTES];  // 32字节
unsigned char sk[crypto_sign_SECRETKEYBYTES];  // 64字节
unsigned char message[] = "Firmware v2.1.0";
unsigned char signed_message[sizeof(message) + crypto_sign_BYTES];
unsigned long long signed_len;

// 生成密钥对
crypto_sign_keypair(pk, sk);

// 签名
crypto_sign(signed_message, &signed_len,
            message, sizeof(message), sk);

// 验证
unsigned char unsigned_message[sizeof(message)];
unsigned long long unsigned_len;
if (crypto_sign_open(unsigned_message, &unsigned_len,
                     signed_message, signed_len, pk) == 0) {
    // 验证成功
}

工程建议：Ed25519的私钥是64字节，但前32字节是种子，后32字节是公钥。很多库允许只存储种子（32字节），然后从种子派生出完整私钥和公钥。这样能节省Flash空间，尤其适合批量生产时预置密钥。

如何选择？一个实用的决策框架

说了这么多，到底怎么选？我总结了一个简单的决策树：

芯片有AES-GCM硬件加速吗？
- 有 → 用AES-128-GCM + ECDHE(X25519) + Ed25519
- 没有 → 用ChaCha20-Poly1305 + ECDHE(X25519) + Ed25519
需要FIPS认证吗？
- 需要 → 只能用AES-GCM + ECDSA P-256（FIPS 140-3要求）
- 不需要 → 优先Ed25519，性能更好
RAM非常紧张（<32KB）？
- 用ChaCha20-Poly1305，它的状态只有64字节，而AES-GCM需要至少4KB查表空间

我的推荐组合：对于绝大多数嵌入式TLS 1.3场景，我建议用「ChaCha20-Poly1305 + X25519 + Ed25519」。这个组合没有专利限制，纯软件实现，代码体积小，性能优秀。除非你的客户明确要求AES或FIPS，否则这个组合能覆盖90%的嵌入式设备。

嗯，这四个算法讲完了。它们各自有擅长的场景，也有需要注意的坑。选型时别只看性能数据，还要考虑你的芯片特性、认证需求、以及团队对算法的熟悉程度。毕竟，再好的算法，实现错了也是白搭。