AES-CBC.

AES-CBC(密码分组链接模式)是 NIST SP 800-38A 定义的传统模式。每个 128 位明文分组在加密前都与上一个密文分组进行 XOR,首个分组使用随机 IV。CBC 只提供机密性而不提供完整性,因此必须配合独立的 MAC 以 encrypt-then-MAC 形式使用。采用 PKCS#7 填充的 CBC 因填充预言攻击(BEAST、Lucky 13、POODLE)而闻名,这些攻击曾被用于 TLS、IPsec 和磁盘加密。现代标准更倾向于 AES-GCM 或 ChaCha20-Poly1305 等 AEAD 模式,但 CBC 在 TLS 1.0/1.1 等遗留协议栈中仍然存在。

填充预言这一类攻击由 Serge Vaudenay 于 2002 年提出:如果服务器通过错误消息、响应时延或行为差异泄露了解密后的 PKCS#7 填充是否有效,攻击者便可在完全不知道密钥的情况下逐字节地恢复明文。该模式随后再次出现:针对 SSL 3.0 的 POODLE(CVE-2014-3566)、作为 TLS MAC-then-encrypt 构造中计时侧信道的 Lucky 13(CVE-2013-0169),以及利用 TLS 1.0 可预测链式 IV 的 BEAST(CVE-2011-3389)。CBC 还具有可延展性:翻转某个密文分组中的一个比特,会使下一个分组中对应的明文比特发生翻转,因此在缺乏完整性保护时,攻击者可以在不被察觉的情况下篡改消息。

因此,正确的用法要求每条消息使用随机且不可预测的 IV,并采用 encrypt-then-MAC 提供完整性(在 RFC 7366 中已为 TLS 标准化),而非遗留的 MAC-then-encrypt 顺序。CBC 仍出现在 IPsec、SSH 和较旧的 TLS 部署中,但 TLS 1.3 已移除所有 CBC 密码套件,转而强制使用 AEAD。在重构遗留系统时,应将 AES-CBC + HMAC 替换为单一的 AEAD 原语(AES-GCM、AES-GCM-SIV 或 ChaCha20-Poly1305),从而一步消除填充预言和 MAC 顺序这两类隐患。

flowchart LR
  IV[随机 IV] --> X1((XOR))
  P1[明文分组 1] --> X1
  X1 --> E1[AES 加密] --> C1[密文分组 1]
  C1 --> X2((XOR))
  P2[明文分组 2] --> X2
  X2 --> E2[AES 加密] --> C2[密文分组 2]