企业官网建设流程全解析

• 密码学
• 网络安全

本文围绕 openHiTLS 仓库中的 SECURITY.md 展开，系统解读该项目安全策略的两条主线：§1 责任范围（哪些组件、哪些漏洞类型在威胁模型之内，哪 9 类影响明确排除）与§2 侧信道承诺（对密钥派生数据的常数时间编程承诺及其边界）。读完本文，你不仅能拿到一份可直接对照仓库源码的"安全边界清单"，还能理解这些承诺在代码层面如何兑现——从ConstTimeMemcmp常数时间比较、BN 常量时间标志位，到构建系统默认的-O2优化级别与基于 Valgrind 的常数时间验证流程（ctvalgrind）。

说明：SECURITY_zh.md 是该策略的中文翻译版，仅供阅读参考；若两版分歧，以英文版 SECURITY.md 为准。漏洞报告、严重性评估、协调披露（CVE / embargo）流程不在本文档范围内，由项目官方的漏洞管理渠道负责。

1. 责任范围（Scope）

1.1 哪些组件在范围内

策略明确覆盖本仓库发布的全部生产代码，与仓库目录结构一一对应：

策略还声明：后续新增的模块自动纳入范围。这意味着安全边界与仓库的main分支保持同步演进，不存在"游离在策略之外的新目录"。

1.2 范围内的六大类漏洞

策略把以下问题列为候选漏洞，这与代码库中可见的防御性设计相互印证：

1. 内存安全：任何可由攻击者可控输入触达的代码路径上的缓冲区溢出/下溢、越界读写、use-after-free、double-free、空指针解引用、未初始化读、类型混淆。仓库中大量畸形输入解析逻辑（如 crypto/rsa/src/rsa_padding.c 对 ASN.1 结构的逐段校验）正是这一类的防护现场。
2. 密码学正确性缺陷：签名验证失效、MAC 伪造、弱密钥生成、nonce 复用、KEM 解封装失败处理错误。仓库为关键 KEM 提供成对一致性自校验，例如 crypto/mlkem/src/ml_kem.c#L806 的 pairwise check 使用常数时间比较封装/解封装两侧共享密钥，失败即返回CRYPT_MLKEM_PAIRWISE_CHECK_FAIL。
3. 协议层缺陷（TLS 1.2 / 1.3 / TLCP / DTLCP）：状态机混淆、跨协议攻击、降级攻击、证书验证绕过、握手中途异常完成、扩展误用。tls/handshake/ 下按状态机拆分的收发模块即对应这一层的实现。
4. PKI 处理缺陷：X.509 / CSR / CRL / PKCS#12 / CMS 解析器崩溃、死循环、内存泄漏，或接受本应拒绝的畸形结构。pki/x509_verify/ 与 pki/cms/ 是主要的解析与验证实现。
5. 侧信道：处理密钥派生数据的代码上的侧信道，即本文 §2 详述的承诺。
6. 输入校验缺陷：使攻击者可控数据破坏内部状态的校验缺失。

1.3 范围外的九类影响（不会获得 CVE）

以下影响类型不属于项目的威胁模型，不会走 CVE / embargo 流程，但仍可能作为普通 bug 修复：

1. 只影响openhitlsCLI 自身的拒绝服务——使任意子命令因未处理信号崩溃、在 CLI 前端耗尽内存、在畸形输入文件上挂起、或仅打印错误输出而无密码学后果。策略的理由很明确：CLI 面向互操作性测试、密钥生成与运维操作，不是生产服务端、也不是常驻服务。若一个漏洞同时影响 CLI 与库，库那部分的影响仍在范围内，只有"仅影响 CLI 自身"的部分被排除。
2. API 误用——以 API 契约明确禁止的方式调用函数，或调用本就未设计用于接收攻击者可控输入的 API；头文件与 docstring 中明示的前置条件属于契约的一部分。
3. 同系统时序侧信道——攻击者必须已在同一物理主机上执行代码才能利用的时序侧信道（覆盖粒度见 §2）。
4. 物理攻击——功耗分析、电磁辐射、故障注入、glitch 等，需要平台层面缓解。
5. CPU / 微架构 / 硬件缺陷——Spectre 类、Rowhammer、不可靠 DRAM、损坏的 RNG 源等；此类报告按"加固请求"处理，不作为 openHiTLS 的 CVE。
6. 需要主机上已有代码执行能力的攻击——内核级被攻破、任意内存写、或信任锚被破坏（撒谎的 CA、行为异常的 HSM、恶意第三方密码模块）。由损坏的信任锚导致的错误信任决策是信任锚损坏的预期后果，不是 openHiTLS 的漏洞。
7. 直接杀死进程即可实现的拒绝服务——如kill -9、OOM killer、不引起内存损坏的文件描述符耗尽，以及其他影响不超过运维者本来就能对自己造成的攻击。
8. 规范合规输入引发的资源耗尽——上游规范未对某参数（如 KDF 迭代次数、递归深度）规定上限时，由合法字段值过大导致的资源过度消耗；接受不可信输入的部署方需自行设置上限。
9. 下游补丁引入的漏洞——不在本仓库中的补丁（如发行版特有的补丁），应报告给相应下游厂商。

策略对边界报告的处置也做了说明：仅落入 §1.3 的报告会被确认收悉、归类为范围外或普通 bug，并可能公开修复——只是不走 CVE 通道。

2. 侧信道承诺：常数时间编程的边界与落地

openHiTLS 处理由密钥派生而来的数据——私钥、明文、MAC 标签、会话密钥、KEM 解封装结果、PAKE 记录——并承诺对这些代码路径实施常数时间编程。这一承诺在仓库中有清晰、可追溯的实现证据。

2.1 四项承诺

• 密码学原语中不含密钥依赖的控制流：循环边界与分支条件不依赖密钥数据。
• 不含密钥依赖的内存访问：数组下标与表查找不以可能泄漏的方式依赖密钥数据。
• 常数时间比较：任何密钥派生 buffer 的比较一律使用常数时间实现，不在第一个不匹配字节处提前退出。
• 网络可观察的时序：在常见编译器、常见优化级别（-O2、-Os）下、远程攻击者可观察的可利用时序差异，按漏洞处理；平台无法合理缓解的物理时序观测同理。

2.2 承诺如何在源码中兑现

（1）常数时间比较函数。策略中"不在第一个不匹配字节处提前退出"的承诺，在 bsl/include/bsl_bytes.h#L261-L268 由ConstTimeMemcmp兑现：

// if a == b, return 0xffffffff, else return 0 static inline uint32_t ConstTimeMemcmp(const uint8_t *a, const uint8_t *b, uint32_t l) { uint8_t r = 0; for (uint32_t i = 0; i < l; i++) { r |= a[i] ^ b[i]; } return Uint32ConstTimeIsZero(r); }

逐字节异或累加后再做常数时间零判断，全程无提前退出。它在关键验证路径上被广泛使用：

• RSA PKCS#1 v1.5 填充校验，用掩码方式折叠比较结果而不引入数据依赖分支（crypto/rsa/src/rsa_padding.c#L827：*valid &= ConstTimeMemcmp(...)）；
• SM2/SM9 加密的摘要与 MAC 校验（crypto/sm2/src/sm2_crypt.c#L363、crypto/sm9/src/sm9.c#L753-L754）；
• AEAD 模式对 tag 的常数时间比对（crypto/modes/src/modes.c#L158）；
• 后量子算法的密钥/结果比对：ML-KEM pairwise check（crypto/mlkem/src/ml_kem.c#L806）、ML-DSA 公钥一致性检查（crypto/mldsa/src/ml_dsa.c#L629）、Classic McEliece 解码校验（crypto/mceliece/src/mceliece.c#L939-L948，注意它以mask位折叠两个比较结果，是典型的掩码化常数时间写法）、HSS 公私钥比对（crypto/hbs/hss/src/hss_api.c#L119-L125）。

（2）大数运算的常数时间标志位。BN 模块为参与密钥运算的大数提供CRYPT_BN_FLAG_CONSTTIME标志（crypto/bn/include/crypt_bn.h#L58），并在 RSA/SM2 的私钥运算入口处显式开启。以 RSA 为例，CRT 分量p、q、dP、dQ、qInv在加密/解密前统一置位（crypto/rsa/src/rsa_encdec.c#L344-L352），SM2 签名对私钥与模逆也做同样处理（crypto/sm2/src/sm2_sign.c#L569-L581）。这把策略中"循环边界与分支条件不依赖密钥数据"落到了具体数据结构的执行模式上。

（3）对非常数时间回退路径的显式声明。更值得注意的是，仓库在纯 C 回退实现处用SECURITY NOTE注释主动披露了哪些路径不是常数时间的，与策略的诚实边界一致：

• T-box / S-box 版 AES 与表驱动 SM4 均以密钥派生状态索引 1 KB 查表，存在缓存时序风险，注释明确要求"常数时间场景请使用硬件汇编路径"（crypto/aes/src/crypt_aes_tbox.c#L26-L32、crypto/aes/src/crypt_aes_sbox.c#L26-L31、crypto/sm4/src/crypt_sm4.c#L26-L33）；
• 纯 C 的 Shoup 4-bit GHASH 实现明确指出其数据依赖表查找会泄漏 GCM 的哈希子键 H，从而同时破坏认证与机密性，因此它只作为无 GHASH 汇编平台的可移植回退，"MUST NOT be relied upon where constant-time execution is required"（crypto/modes/src/noasm_ghash.c#L24-L46）。

对部署方的实际含义是：在要求常数时间执行的平台上，应选择启用对应硬件/汇编加速的构建配置，避免落到这些纯 C 回退路径。

2.3 不承诺的内容（边界声明）

策略同样明确划出不承诺的部分：

• 同进程微架构侧信道（L1/L2/L3 cache、BTB、TLB、内存总线争用、port 争用），且仅当攻击者在同一物理核/同一 socket 上运行代码时可利用——需 OS / hypervisor / 硬件缓解；
• 功耗、电磁、声学、热辐射等物理传感器可观测的侧信道——威胁模型包含这些时应使用 TEE、HSM 或屏蔽环境；
• 故障注入（时钟、电压、激光 glitch）——可能随版本增加加固，但加固缺失不算漏洞；
• 仅在罕见编译器/编译选项组合下才出现的时序差异（-O3、-Oz、LTO、罕见 flag 下的自动向量化、私有编译器）。策略建议安全敏感构建使用-O2或-Os；
• 第三方模块中的侧信道——由部署方运行时加载引入。

这里与构建系统形成了呼应：cmake/hitls_compile_options.cmake#L44-L48 在CMAKE_BUILD_TYPE未设置时默认注入-O2（非 Debug 构建另有-D_FORTIFY_SOURCE=2），正好落在策略承诺覆盖的优化级别区间内，避免构建系统"无优化级别"这一默认状态落在承诺之外。

2.4 后量子算法的特别声明

ML-KEM、ML-DSA、SLH-DSA 等后量子算法是相对较新的 NIST 标准/候选实现，其侧信道分析文献仍在成熟中。策略的立场是：对这些代码套用前述标准常数时间规则，但无法保证未来目前未公开的攻击技术不会适用；任何已公开发表的针对这些算法的侧信道技术，将按漏洞处理并据此响应。仓库中这些算法（crypto/mlkem/、crypto/mldsa/、crypto/hbs/）与经典算法共用同一套常数时间比较与 BN 常数时间设施，可见该承诺在实现组织上是一视同仁的。

3. 超出文档承诺的仓库级支撑

策略本身是"声明"，仓库中还可见两层配套工程机制，从源码结构看是承诺的可执行支撑：

1. 常数时间验证开关HITLS_CT_VALIDATION：cmake/hitls_options.cmake#L319 提供该选项（默认 OFF），开启后要求构建环境存在<valgrind/memcheck.h>（缺失时构建直接报错并给出安装提示，见 cmake/hitls_generate_config_h_file.cmake#L25-L33）。它让 bsl/include/bsl_bytes.h#L270-L282 中的HITLS_CT_SECRET_MARK/HITLS_CT_SECRET_UNMARK注解生效——将密钥数据标记为 Valgrind Memcheck 的"未定义内存"，任何依赖这些字节的分支或内存下标都会被告警；未开启时二者为空操作，不进入发布构建。
2. ctvalgrind测试模式：testcode/script/build_sdv.sh#L434-L438 在构建 SDV 测试套件时追加-DHITLS_CT_VALIDATION -O0 -g（关闭优化，防止编译器把常数时间工作折叠掉）；testcode/script/execute_sdv.sh#L315-L326 则在ctvalgrind参数下以valgrind --tool=memcheck --track-origins=yes --error-exitcode=1运行每个测试二进制，把任何常数时间违规变成非零退出码、直接让套件失败。换言之，"承诺不依赖密钥的控制流"在仓库内有一套可运行、可复现的自动化验证路径，而非仅停留在注释层面。

4. 政策版本管理

策略声明自身可能被更新：范围或侧信道承诺的重大变更将通过项目官方渠道公告，最新版本始终是本仓库main分支上的 SECURITY.md。对下游使用者而言，这意味着两件事：

• 引用该策略时，应以所部署版本对应 tag 的SECURITY.md为准，而不是笼统的"当前最新版"；
• 若发现实际行为与策略声明不符（例如某解析路径未做输入长度上限、或某比较使用了非常数时间函数），应结合 §1.3 判断其影响类型，再按项目官方漏洞管理渠道报告。

一句话总结：openHiTLS 的安全策略以"仓库即边界"为原则——组件范围与仓库目录完全对齐、漏洞分类聚焦内存安全/密码正确性/协议/PKI/侧信道/输入校验六类、明确排除 9 类不属于其威胁模型的影响；侧信道承诺以"远程可观察时序"为判据，并在源码中通过ConstTimeMemcmp、BN 常数时间标志、硬件汇编路径优先、ctvalgrind自动化验证四者共同兑现，同时以后量子特别声明保留了随研究演进更新的诚实边界。

• 密码学
• 网络安全