3、标量加密扩展概述：K扩展的由来、版本演进（Zk*系列）、与向量加密扩展的区别、适用场景与硬件开销

RISC-V 的加密扩展（Cryptography Extensions）是 RISC-V 国际基金会为应对现代计算安全需求而制定的标准指令集扩展。其中，标量加密扩展（Scalar Cryptography Extensions）以 "K" 为前缀命名，旨在为嵌入式、边缘计算及通用处理器提供高效、侧信道友好的密码学原语支持。本章将系统梳理 K 扩展的诞生背景、Zk* 子集的版本演进脉络，并深入对比其与向量加密扩展（Vector Cryptography Extensions）在指令语义、数据并行度、硬件实现成本及适用场景上的本质差异。同时，我们将从芯片设计者的视角，剖析引入 K 扩展所需的硬件开销（面积、时序、功耗）以及在实际 SoC 集成中的关键决策点。

上图从三个维度勾勒了本章的核心内容：左侧展示了 K 扩展从草案到标准化的演进路径，中间对比了标量与向量加密扩展在数据通路和设计目标上的本质差异，右侧则概括了典型应用场景与硬件开销的初步印象。接下来，我们将逐一深入展开这些主题。

3.1 K 扩展的由来与设计哲学

RISC-V 的加密扩展并非凭空诞生，而是源于 2018 年 RISC-V 基金会安全常设委员会（Security Standing Committee）发起的密码学扩展任务组（Cryptography Extensions Task Group）。该任务组的核心使命是：为 RISC-V 架构定义一套高效、安全且可扩展的密码学指令集，以满足从低功耗嵌入式到高性能计算平台的广泛需求。

在设计之初，任务组面临一个关键抉择：是设计一套类似 ARMv8-A 中 AESD/AESE 那样的专用密码学协处理器指令，还是采用更通用的基础指令组合？最终，他们选择了后者，并确立了三条核心设计原则：

• 基础指令优先：优先提供如 32 位旋转、字节置换、逐位置位/清零等基础操作，而非直接提供完整的 AES 轮函数。这使得编译器可以灵活组合出多种密码算法，同时保持硬件实现简洁。
• 侧信道安全考量：所有指令的延迟必须是固定的、与数据无关的（constant-time），避免因数据值不同导致执行时间差异，从而抵御时序侧信道攻击。这一要求直接催生了 Zkt（数据无关执行时间）扩展。
• 可组合性：K 扩展被拆分为多个子扩展（Zbkb、Zbkc、Zbkx、Zkn、Zkr、Zkt），允许芯片设计者根据目标应用选择性地实现子集，避免为不需要的功能支付面积和功耗代价。

这种设计哲学与 ARM 的 Cryptography Extension 形成鲜明对比——ARM 直接提供 AES/SHA 的硬件加速指令，而 RISC-V 则更倾向于提供"密码学积木"，让软件（或硬件库）来搭建算法。这种差异在后续的版本演进中体现得尤为明显。

3.2 Zk* 系列版本演进与子集划分

K 扩展的版本演进经历了从草案到稳定版的多个阶段，其子集划分也经历了多次调整。理解这些演进过程，有助于我们把握 RISC-V 密码学生态的成熟度。

值得注意的是，在 v1.0.1 版本中，原本属于 K 扩展的 Zbkb（位操作）、Zbkc（无进位乘法）、Zbkx（交叉置换）被划归到 B 扩展（Bit Manipulation）的旗下。这一调整的动机是：这些指令并非密码学专用，而是通用的位操作，放在 B 扩展中可以让非密码学应用也受益。然而，对于密码学实现而言，它们仍然是 K 扩展的"隐含依赖"——任何实现 Zk 的处理器必须同时支持这些基础指令。

当前 RISC-V 官方定义的标量加密扩展族包括：

• Zkne：AES 加密/解密指令（aes32esi、aes32esmi 等），支持 AES-128/192/256 的轮函数加速。
• Zknh：SHA-2 系列指令（sha256sig0、sha512sig1 等），加速 SHA-256/384/512 的消息调度和压缩函数。
• Zkr：熵源指令（pollentropy），提供硬件真随机数生成器接口。
• Zkt：数据无关执行时间保证，确保上述指令的执行周期不依赖于操作数。
• Zbkb/Zbkc/Zbkx：基础位操作指令，作为密码学实现的"积木"。

3.3 标量加密扩展与向量加密扩展的深度对比

RISC-V 同时定义了标量（K）和向量（V 扩展中的加密子集）两套密码学指令，它们并非简单的"低端/高端"之分，而是在设计目标、数据并行度、硬件实现和适用场景上有着本质区别。

数据通路差异：标量 K 扩展在通用寄存器（GPR）上操作，数据位宽为 XLEN（32 或 64 位）。例如，AES 轮函数指令 aes32esmi 一次处理 32 位数据，一个 AES 轮需要 4 条指令完成（对应 State 矩阵的 4 列）。而向量加密扩展（如 vaesdf.vs）在向量寄存器上操作，数据位宽为 VLEN（通常为 128/256/512 位），一条指令即可处理整个 AES State（128 位）甚至多个 State 并行。

吞吐量与延迟权衡：向量扩展的吞吐量显著高于标量——在 VLEN=128 时，向量 AES 的吞吐量是标量的 4 倍；VLEN=256 时达到 8 倍。但向量扩展的指令延迟更高（因为数据通路更长），且需要额外的向量寄存器文件（增加面积和功耗）。标量 K 扩展则提供最低的延迟（通常 1-2 个周期完成一条轮函数指令），适合对延迟敏感的场景，如 TLS 握手中的逐包加密。

硬件开销对比：从芯片面积角度看，标量 K 扩展仅需在 ALU 数据通路上增加少量逻辑（约 5K-15K 门，取决于是否包含 SBox 硬件），而向量加密扩展需要额外的向量 ALU 和寄存器文件（通常增加 50K-200K 门）。对于成本敏感的 IoT 芯片，标量 K 扩展几乎是唯一现实的选择。

软件生态差异：标量 K 扩展的软件支持更为成熟——OpenSSL、mbedTLS 等主流密码学库均已针对 Zkne/Zknh 做了优化。向量加密扩展的软件优化仍在发展中，且需要编译器自动向量化或手写汇编支持，门槛较高。

3.4 适用场景分析与硬件开销量化

选择标量 K 扩展还是向量加密扩展，本质上是在吞吐量、面积、功耗和软件复杂度之间做权衡。以下从三个典型场景展开分析。

场景一：低功耗 IoT 安全节点（如智能门锁、传感器节点）

此类设备通常采用单核 MCU（如 RV32IMC），主频 50-100 MHz，Flash 和 SRAM 资源紧张。加密需求主要是 AES-128 用于链路加密、SHA-256 用于固件完整性校验。此时，标量 K 扩展是理想选择：仅增加约 8K 门面积（约占总芯片面积的 1-2%），即可获得比纯软件实现快 5-10 倍的加解密速度。更重要的是，Zkt 扩展保证了固定执行时间，使得侧信道防护变得简单——无需额外的随机延时或掩码操作。

场景二：车载安关（如 T-Box、域控制器）

车载场景对安全等级要求极高（ISO 26262 ASIL-B/D），同时需要处理多条安全通信通道（如 SecOC、TLS）。此时，标量 K 扩展可以作为硬件安全模块（HSM）的补充加速器，与专用密码学引擎协同工作。例如，HSM 中的 AES 引擎处理高速数据流，而 CPU 上的 K 扩展用于处理密钥协商、证书验证等低频但延迟敏感的操作。这种异构架构在面积和功耗上比单纯依赖向量扩展更优。

场景三：边缘 AI 服务器（如智能路由器、边缘计算节点）

此类设备需要处理大量并发 TLS 连接，对吞吐量要求极高。如果芯片已经集成了 V 向量扩展（用于 AI 推理加速），那么复用向量单元实现加密扩展是合理的——几乎不增加额外面积。但如果芯片没有 V 扩展，单独为加密功能引入向量单元则显得浪费，此时标量 K 扩展配合多核并行（每个核处理不同连接）可能是更经济的选择。

3.5 案例拆解：在 RV32 内核中集成 Zkne 的完整流程

为了将上述概念落到实处，我们以一个实际的 SoC 集成案例来展示 K 扩展的硬件实现路径。假设我们有一个基于 RV32IMC 的 MCU 内核，主频 100 MHz，目标是在不显著增加面积的前提下，将 AES-128 的软件实现速度提升 8 倍以上。

初始状态与目标：纯软件 AES-128 在 100 MHz 下吞吐量约为 5 Mbps（约 2000 周期/块）。目标是通过硬件加速达到 40 Mbps（约 250 周期/块），同时面积增加不超过 10K 门。

关键决策与实施步骤：

1. 选择子集：仅实现 Zkne 中的 aes32esmi（加密轮）和 aes32dsmi（解密轮）指令，不实现完整的 Zkn 族。因为目标仅需 AES-128，无需 SHA-2 指令。
2. SBox 实现方案：采用 4 个 8x8 查找表（每个表 256 字节，共 1KB ROM），实现字节替换。在 28nm 工艺下，1KB ROM 面积约 3K 门，访问延迟约 1.5 ns（满足 10 ns 周期要求）。
3. 数据通路集成：在 ALU 旁增加一个 32 位 AES 轮函数单元，复用现有的寄存器文件写回端口。指令译码逻辑增加对 aes32esmi 的识别，将其映射到新单元。
4. 时序优化：将 SBox 查找表分为两级流水线（地址译码 + 数据输出），使关键路径缩短至 6 ns，留出 4 ns 余量给寄存器建立时间。
5. 验证与测试：使用 NIST 测试向量验证硬件 AES 结果，并运行 100 万次随机数据对比软件模型。

结果与复盘：最终实现面积增加 8.5K 门（含 SBox ROM 和轮函数逻辑），AES-128 单块加密耗时 220 周期（含加载/存储开销），吞吐量达到 45 Mbps，满足目标。复盘发现，SBox ROM 的面积占比达 60%，如果未来需要支持 AES-192/256，可以复用同一 SBox，面积不会线性增加。此外，Zkt 属性天然满足——所有 AES 指令执行周期固定为 1 个周期，无需额外设计。

3.6 常见误区与总结复盘

在 K 扩展的落地过程中，设计团队常陷入以下误区，值得警惕：

• 误区一：认为 K 扩展是完整的密码学解决方案。实际上，K 扩展只提供轮函数加速，密钥扩展、模式运算（如 CBC/CTR/GCM）仍需软件实现。设计者应评估软件开销，避免"硬件加速了轮函数，但模式运算成为新瓶颈"。
• 误区二：忽略 Zkt 的重要性。某些实现为了省面积，将 AES 指令设计为可变周期（如根据数据值跳过某些操作），这破坏了常数时间保证，引入了侧信道漏洞。在安全等级要求高的场景，Zkt 是强制要求。
• 误区三：混淆标量与向量扩展的适用边界。在 VLEN=128 的向量处理器上，向量 AES 的吞吐量确实远超标量，但向量扩展的启动开销（配置 vtype、加载向量寄存器）在短数据块场景下可能抵消其吞吐优势。对于 16 字节的单个 AES 块，标量 K 扩展的延迟反而更低。
• 误区四：忽视熵源指令的物理实现难度。Zkr 的 pollentropy 指令需要硬件 TRNG 支持，而 TRNG 的随机性质量（符合 NIST SP 800-90B）需要大量验证。如果芯片没有模拟设计能力，建议跳过 Zkr，使用软件随机数生成器（如基于 SHA-256 的 DRBG）。

总结：标量 K 扩展是 RISC-V 生态中一项务实且高效的密码学加速方案。它通过提供基础密码学原语，在极低的硬件开销下实现了显著的性能提升，同时通过 Zkt 保证了侧信道安全。与向量加密扩展相比，它更适合资源受限的嵌入式场景，而向量扩展则面向高性能吞吐需求。芯片设计者应根据目标应用的数据块大小、吞吐量要求、面积预算和侧信道安全等级，综合选择实现 K 扩展的哪个子集，以及是否需要与向量扩展协同使用。随着 RISC-V 在安全关键领域的渗透，K 扩展将成为嵌入式处理器不可或缺的组成部分。