加密机制与漏洞分析 · 第 2 册：对称加密深度剖析 - 勒索软件研究 - 迪妙网络空间安全学院

一、对称加密在勒索软件中的角色与工程约束

对称密码负责勒索软件中 99% 以上的加密运算量。攻击者对它的核心诉求按优先级排序是：速度、速度，还是速度——必须在备份系统响应、EDR 告警升级、管理员断网之前完成加密"收网"。由此衍生出三条清晰的技术演进线索：硬件加速（AES-NI）、软件高效流密码（ChaCha20/Salsa20）、以及以间歇加密（Intermittent Encryption）为代表的"少加密一点"哲学。

线索一：AES-NI 硬件加速

AES 自 FIPS 197 标准化后成为操作系统与 CPU 的原生能力（AES-NI 指令集，单核吞吐可达数 GB/s）。LockBit 等家族直接调用系统 CryptoAPI，利用 AES-NI 将单文件加密压到毫秒级。

线索二：流密码的软件效率

ChaCha20/Salsa20 基于 ARX（加法-旋转-异或）结构，无需硬件指令即可在纯软件实现中达到接近 AES-NI 的吞吐，且天然免疫时序侧信道——这是 Conti、BlackCat、Akira 等新一代家族，尤其 Rust 系家族偏爱它的根本原因。

线索三：间歇加密

只加密文件的部分区块（头部、定距分块或按比例抽样），在"看起来完全不可用"与"加密耗时"之间取得攻击者视角的最优平衡——代价是留下可恢复的明文分块，成为数据恢复与检测的突破口。

三大原语对比（交互式标签页）

AES：事实标准的分组密码

规范：NIST FIPS 197（2001）标准化，分组长度 128 位，密钥 128/192/256 位，SPN 结构、10–14 轮。勒索软件几乎全部使用 AES-256，配合 CryptEncrypt 等系统 API 时默认走 CBC 模式（NIST SP 800-38A）[01][02]。

典型用法：WannaCry 为每个文件生成 16 字节的 AES-128 密钥并以 CBC 模式加密，随后用内置 RSA-2048 公钥封装该密钥——这是教科书式的混合加密，无任何公开实现缺陷[19]。LockBit 2.0/3.0 采用 AES-256-CBC，并对文件头部区块实施部分加密以换取速度。

分析要点：① IV 是否随机且与密钥一同封装；② 分组填充（PKCS#7）处理是否完整——Ryuk 解密器曾在大文件恢复时错误截断最后一个字节，毁掉 VHDX/数据库文件，说明填充与长度记账是最易出错的工程细节[23]；③ 是否复用密钥与 IV 对（CBC 下 IV 重复不直接泄露明文，但结合固定前缀会产生模式泄露）；④ 调用栈中 BCryptEncrypt 的批量特征可用于 EDR 行为检测。

ChaCha20：Rust 时代的主流选择

规范：IETF RFC 8439（2018）定义 ChaCha20-Poly1305。20 轮 ARX 结构，256 位密钥 + 96 位 nonce + 32 位计数器，生成与明文等长的密钥流后异或。纯软件实现吞吐高、常数时间、无查表——在缺少 AES-NI 的 ESXi/ARM/容器中优势明显[04]。

典型用法：Conti 以 ChaCha20 加密数据、X25519 封装密钥；BlackCat/ALPHV 将 ChaCha20（或 AES）作为可选项；Akira 使用 ChaCha20（部分后续版本的公开报告采用轮数缩减的 ChaCha8 提速），封装层采用 RSA-4096（CISA 通报确认）；其 C++/Boost 异步加密实现与泄露的 Conti 源码存在显著相似性[17][18][25]。

分析要点：流密码的本质是一次一密的工程化——密钥流复用即灾难：两个明文用同一密钥流加密后异或，即得两明文的异或值，可被已知明文/ crib-dragging 技术击穿。Hive 正是栽在自研"双密钥流 XOR"设计上（第 4 册详析）[13][14]。分析时应重点核对：nonce 空间与计数器溢出保护、每文件密钥是否独立、密钥流偏移是否被复用。

// 密钥流复用的数学形态（"一次一密"纪律被违反的直接后果） C1 = P1 ⊕ KS // 文件1：密文 = 明文 ⊕ 密钥流 C2 = P2 ⊕ KS // 文件2：复用同一密钥流 KS（nonce/计数器纪律失效） C1 ⊕ C2 = P1 ⊕ P2 // 密钥流相消：两密文异或 = 两明文异或 // 只要其中一份明文可猜（系统文件、模板、已知格式头），另一份随即泄漏—— // Hive 案例中对海量"明文+密文"对求解 XOR 方程组，正是这一路线的工程化实现。

Salsa20：老牌流密码的双面故事

规范：Bernstein 设计（2005），入选 eSTREAM 最终组合流密码，至今无对完整 20 轮的有效攻击[05][06]。REvil/Sodinokibi、GandCrab、DarkSide 均采用 Salsa20 作为数据加密原语，封装层分别使用 Curve25519 或 RSA。

反面教材：2016 年的 Petya 自实现了一个"缩水版 Salsa20"（社区戏称 Salsa10）：流位置用 32 位变量、旋转操作误用 16 位类型、内部缓冲错误降宽，导致 512 位密钥流中 256 位可预测——Check Point 公开了三处缺陷的技术细节，leo-stone 以遗传算法实现秒级破解[15][16]。同一份源码教训的另一面是 NotPetya 修复了实现 Bug 却擦除了密钥，使受害者付款也无门（第 3 册详析）[20]。

分析要点：流密码实现审计的黄金法则——对照参考实现逐轮核验状态矩阵、轮函数常量（如 expand 32-byte k 常量是否被篡改，NotPetya 将其改为 -1nvald s3ct-id，成为研判其"非求财"意图的密码学证据之一[20]）、nonce 拼接顺序与密钥流偏移。

二、间歇加密（Intermittent Encryption）：提速的双刃剑

间歇加密并非某一种算法，而是一种加密调度策略：只处理文件的部分区块。Pavur 与 Martinović 在 NDSS 2020 的基准研究中系统评估了此类方案，证明其可将加密耗时压缩数倍，同时仍能让文件"不可用"——但安全性损失是可度量、可利用的[07]。

策略类型	机制	代表家族	安全后果
头部加密	仅加密文件起始区块（常见为 4KB 量级）	LockBit 系列（公开样本分析）	文件签名、元数据被破坏即"不可用"，但主体明文可残留
定距分块	按固定步长抽取区块加密（如每 N 字节取 M 字节）	Ryuk（大于 57,000,000 字节≈54.4MB 的文件按 1MB 粒度分块，尾部含加密块计数器）[23]	未加密分块可被拼接恢复，数据库页面级抢救成为可能
比例/档位加密	运营者按"速度—彻底"档位选择加密比例	BlackCat/ALPHV、Akira 的部分配置	低档位留下大量明文，恢复率随档位下降而上升

机制归纳综合 [07][12][23]；各家族具体阈值随版本变化，以样本逆向为准。

为什么攻击者愿意"少加密"

① 时间预算：大型数据库/VHDX 全量加密耗时不可接受；② 规避检测：部分文件熵升幅度低，可绕过基于熵突变的粗粒度检测；③ 心理学：头部损坏足以让系统与业务停摆，受害者感知与全量加密无异。

给防御与恢复的红利

① 数据抢救：未加密分块可拼接出可用文档/数据库页（Ryuk 案例实战中已用于恢复 VHDX/Oracle 文件）[23]；② 已知明文：残留的明文+密文对是密码分析（含解密器 PoC 验证）的关键输入；③ 检测特征：定距加密产生规则的空洞熵模式，可被文件系统遥测识别。

数学直觉：设文件按"每 N 字节加密 M 字节"，则攻击者的时间开销约为全量加密的 M/N，而防御方可恢复的比例约为 (N−M)/N。间歇加密把"加密彻底性"换成"时间"，这笔交易对运营方划算，对数据恢复厂商同样划算——这解释了为何 Ryuk 大文件的部分加密反而成了恢复行业的标准突破口。

三、实现层典型缺陷清单（审计 Checklist）

以下八类缺陷在真实勒索软件中反复出现，是样本审计与解密工具开发的首要检查项。任何一项命中，都可能让"不可破解"变成"可以恢复"。

#	缺陷类型	技术说明	可利用后果	真实案例
1	弱随机数源	用时间戳/GetTickCount/自实现 LCG 播种密钥	密钥空间塌缩至可暴力枚举	CryptoDefense（2014）及历史弱 PRNG 家族[21]
2	密钥流/nonce 复用	多文件共享密钥流或复用 (key, nonce) 对	已知明文异或泄漏，主密钥可恢复	Hive（2022）[13][14]
3	算法误用/降级实现	自实现轮函数时变量位宽、常量、轮数错误	密钥流出现可预测结构，穷举量骤降	Petya "Salsa10"（2016）[15][16]
4	密钥明文驻留内存	封装前的对称密钥/随机数未安全擦除	内存镜像取证可直接提取	应急响应内存捕获规程的密码学依据（第 3 册）
5	密钥落盘残留	密钥/随机数写入临时文件、页面文件或未清零扇区	磁盘级取证可恢复	若干历史家族的取证报告；vss 残留分析实践
6	封装格式缺陷	封装结构可预测、含可推导字段或硬编码公钥	剥离封装直接取回明文密钥	Avast 对 DoNex 加密方案的利用（2024，Recon 披露）
7	部分加密过度	间歇加密比例过低	明文分块可拼接恢复业务数据	Ryuk >54.4MB 大文件的部分加密[23]
8	解密器交付 Bug	长度记账、边界处理错误，且运行后删除原密文	付款者数据二次损毁（攻击者自伤）	Ryuk 解密器截断 Bug（2019，Emsisoft 披露）[22][23]

本表为公开案例归纳，编号与第 4 册案例档案一一对应。

红线提醒：上述审计方法仅适用于授权的样本分析、应急响应与教学演练场景。任何解密工具的开发与发布都应遵循负责任披露原则——先通过执法机关与 No More Ransom 等渠道私下交付，避免打草惊蛇使攻击者连夜修补（第 5 册详述，含 Fabian Wosar 的公开建议与 CryptoDefense 24 小时即被修补的教训）。