商用密码应用安全性评估——openHiTLS初识
原创
利刃信安
利刃信安
利刃信安
2026年7月2日 20:00
北京
在小说阅读器读本章
去阅读
商用密码应用安全性评估——openHiTLS初识
摘要
随着《密码法》《商用密码管理条例》等法规落地，商用密码应用安全性评估（简称\"密评\"）已成为政企信息系统合规的刚性门槛。然而，密评整改过程中，\"密码产品选型封闭、算法切换成本高、自研密码模块安全性难以验证\"三大痛点始终困扰从业者。openHiTLS作为业界首款面向全场景的开源密码套件，通过模块化架构、国密全栈支持和形式化验证能力，为密评建设提供了全新解题思路。
一、密评困境与openHiTLS破局
密评的核心要求可归纳为四点：密码算法合规、密码协议合规、密码产品合规、密钥管理合规。在实际落地中，常见困境包括：
- • 选型受限：商用密码产品多为闭源交付，用户无法审查底层实现，与密评\"自主可控\"导向存在张力。
- • 迁移困难：从国际算法（RSA/AES）向国密算法（SM2/SM4）迁移时，应用层需大幅改造，接口不兼容。
- • 验证成本高：自研密码模块要分别通过功能正确性、侧信道安全性等多维度验证，中小企业难以负担。
一套算法丰富、接口统一、安全可验证的开源密码套件，是破解上述困局的可行路径。
2024年12月，由华为、西安电子科技大学、山东大学等15家单位联合宣布openHiTLS正式开源，定位为面向全场景数智安全、独立创新的开源密码套件。它由五个松耦合组件构成：
| 组件 | 职责 | 密评关联度 |
|---|---|---|
| Crypto | 密码算法库（国密/国际/PQC） | ★★★★★ |
| TLS | 安全传输协议（TLS 1.2/1.3/TLCP/DTLCP） | ★★★★★ |
| PKI | 公钥基础设施（证书解析、验证、CRL管理） | ★★★★ |
| Auth | 认证协议（Privacy Pass/SPAKE2+等） | ★★★ |
| BSL | 基础支撑层（内存管理、错误栈、平台抽象等） | ★★ |
组件高度解耦，可按需裁剪——单算法场景可精简至不足10KB，这意味着它既能跑在云服务器上，也能嵌入物联网终端设备。
二、国密全栈：算法、协议与安全验证
密评最核心的诉求是密码算法和协议必须采用国家标准，openHiTLS的覆盖全面：
算法层面：
- • SM2：椭圆曲线公钥密码算法（GB/T 32918），支持加解密、签名验签、密钥交换
- • SM3：密码杂凑算法（GB/T 32905），支持完整性校验和HMAC
- • SM4：分组密码算法（GB/T 32907），支持CBC/GCM/CTR/CFB/OFB/XTS等多种工作模式
协议层面：
- • TLCP（GB/T 38636-2020）：国密传输层密码协议，基于SM2双证书体系（签名证书+加密证书）
- • DTLCP（GM/T 0128-2023）：数据报传输层国密协议，UDP承载的TLCP
同时支持国际算法（AES、RSA、ECDSA、Ed25519、X25519）和后量子算法（ML-KEM、ML-DSA，需编译时启用），一套代码即可覆盖国密+国际+抗量子三套密码体系。
丰富算法之外，密评对密码模块的安全性同样有硬性要求（参考GB/T 39786），openHiTLS提供了多层次安全保障：
- • KAT测试（Known Answer Test）：确保密码算法实现的数学正确性
- • 形式化验证：对核心算法进行数学证明级别的正确性验证
- • 侧信道防护：对时序/功耗/电磁泄漏等侧信道攻击实现有效防护
- • FUZZ测试：通过模糊测试发现边界条件与内存安全问题
- • ISO 19790认证：与国际认证机构（DEKRA、SGS、BSI等）共建认证生态
目前openHiTLS已通过ISO 19790密码模块认证，在密评场景中可以作为合规的密码模块引入。
三、编译与集成：openhitls-0.3 分支实测流程
版本说明：以下流程基于实测验证可用的
openhitls-0.3分支（HEAD:ab0d11e1）。本构建环境为 Kali Linux x86\_64，GCC 15.3.0 / CMake 4.3.4 / Python 3.13.14。
3.1 环境准备
# Ubuntu/Debian/Kali
sudo apt update && sudo apt install -y cmake gcc make python3 git tcpdump
# 确认版本（本手册实测版本如下，非强制最低要求）
gcc --version # 实测: gcc 15.3.0
cmake --version # 实测: cmake 4.3.4
python3 --version # 实测: Python 3.13.14
3.2 获取源码
# 1. 克隆仓库
git clone -b openhitls-0.3 https://gitcode.com/openHiTLS/openhitls
cd openhitls
# 2. 确认版本（关键：HEAD 必须是 ab0d11e1，含 -noverify 修复）
git log --oneline -3
# ab0d11e1 fix:The command line parameter \"noverify\" has been added to app_server.c
# 0b41641b fix: harden file permissions for sensitive data and add input validation
# 33d9b653 Fix the issue where the failure branch of ReferencesInit does not reinitialize references
# 3. 核对分支
git branch -vv
# * openhitls-0.3 ab0d11e1 [origin/openhitls-0.3] ...
3.3 使用 configure.py 生成 CMake 工程
configure.py 自动完成 Secure\_C 安全库编译（39个C文件→libboundscheck.a），无需手动编译。
cd /home/kali/M/openhitls
python3 configure.py \\
--system linux --bits 64 --asm_type x8664 \\
--build_dir build --output_dir build \\
--enable all --executes \\
--add_options=\"-DHITLS_TLS_PROTO_TLCP11 -DHITLS_TLS_SUITE_ECDHE_SM4_CBC_SM3 -DHITLS_TLS_SUITE_ECC_SM4_CBC_SM3 -DHITLS_TLS_SUITE_ECDHE_SM4_GCM_SM3 -DHITLS_TLS_SUITE_ECC_SM4_GCM_SM3 -DHITLS_CRYPTO_PROVIDER_DEFAULT_SM -DHITLS_TLS_SUITE_AUTH_SM2\"
密钥参数说明:
- •
--enable all --executes: 启用所有非国密模块并编译hitls命令行工具- •
--build_dir build --output_dir build: 编译输出到build/目录- •
--add_options: 额外传递7个国密编译宏（国密模块不在--enable all范围内，必须显式启用）
configure.py 内部执行流程:
1. 检查 Secure_C 依赖 → 未找到 → 自动编译 39 个 securec C 文件 → libboundscheck.a
2. 生成 feature_config.json（各模块 C/ASM 源文件清单）
3. 生成 compile_config.json（-D 宏定义和链接参数）
4. 生成 CMake 辅助模块文件
3.4 CMake 配置 + 编译
cd build
cmake -DCMAKE_BUILD_TYPE=Debug ..
make -j$(nproc)
编译耗时约 2-3 分钟（8核）。SM3/SM4 使用 x86-64 汇编优化（
.s文件）。
3.5 产物验证
$ file hitls
hitls: ELF 64-bit LSB pie executable, x86-64, dynamically linked,
with debug_info, not stripped
$ ldd hitls
libhitls_tls.so => .../build/libhitls_tls.so
libhitls_crypto.so => .../build/libhitls_crypto.so
libhitls_pki.so => .../build/libhitls_pki.so
libhitls_bsl.so => .../build/libhitls_bsl.so
$ ls -lh libhitls_*.so hitls
-rw-r--r-- ... libhitls_bsl.so 934K
-rw-r--r-- ... libhitls_crypto.so 6.3M ← 含 SM2/SM3/SM4 汇编优化
-rw-r--r-- ... libhitls_pki.so 1.0M
-rw-r--r-- ... libhitls_tls.so 5.7M
-rwxr-xr-x ... hitls 906K
3.6 环境变量
# 每个运行 hitls 的终端必须先执行
export LD_LIBRARY_PATH=/home/kali/M/openhitls/build:$LD_LIBRARY_PATH
# 验证
hitls help
3.7 编译宏说明
| # | 编译宏 | 作用 | 必须? |
|---|---|---|---|
| 1 | HITLS_TLS_PROTO_TLCP11 |
启用 TLCP v1.1 协议栈（含 DTLCP over UDP） | 是 |
| 2 | HITLS_TLS_SUITE_ECDHE_SM4_CBC_SM3 |
注册 ECDHE\_SM4\_CBC\_SM3 密码套件 | 是 |
| 3 | HITLS_TLS_SUITE_ECC_SM4_CBC_SM3 |
注册 ECC\_SM4\_CBC\_SM3 密码套件 | 是 |
| 4 | HITLS_CRYPTO_PROVIDER_DEFAULT_SM |
将 SM2/SM3/SM4 加载到默认 Provider（必要条件） | 是 |
| 5 | HITLS_TLS_SUITE_AUTH_SM2 |
启用 SM2 证书身份认证 | 是 |
| 6 | HITLS_TLS_SUITE_ECDHE_SM4_GCM_SM3 |
注册 ECDHE\_SM4\_GCM\_SM3（备用） | 否 |
| 7 | HITLS_TLS_SUITE_ECC_SM4_GCM_SM3 |
注册 ECC\_SM4\_GCM\_SM3（备用） | 否 |
关键: 宏 #1~#5 是 TLCP/DTLCP 工作的充分必要条件。
--enable all仅启用非国密模块，国密必须通过这5个核心宏显式启用。
四、实操：使用 hitls CLI 完成 TLCP/DTLCP 通信
以下命令基于 openhitls-0.3 分支 (ab0d11e1) 编译产物，使用源码内置的 SM2 测试证书。
注意：①本文所有操作均使用最新编译的
hitls命令行工具。②必须指定-cipher参数明确选择密码套件，否则可能使用错误默认值导致握手失败。
4.1 测试证书说明
路径: /home/kali/M/openhitls/testcode/testdata/tls/certificate/der/sm2_with_userid/
实际文件清单（ls -lh 实测）:
| 文件 | 大小 | 格式 | 用途 |
|---|---|---|---|
ca.crt |
843B | PEM | CA根证书 |
inter.crt |
794B | PEM | 中间CA证书（证书链第二级） |
sign.crt |
2.2KB | x509文本转储 + PEM | TLCP签名证书 |
sign.key |
316B | EC PARAMETERS + PRIVATE KEY (PEM) | TLCP签名私钥 |
sign.der |
534B | 纯二进制DER | 签名证书（供cert callback使用） |
enc.crt |
2.2KB | x509文本转储 + PEM | TLCP加密证书 |
enc.key |
316B | EC PARAMETERS + PRIVATE KEY (PEM) | TLCP加密私钥 |
enc.der |
532B | 纯二进制DER | 加密证书（供cert callback使用） |
enc.key.der |
122B | 纯二进制DER | 加密私钥（供cert callback使用） |
sign.key.der |
122B | 纯二进制DER | 签名私钥（供cert callback使用） |
格式说明:
.crt文件不是纯 DER 格式。其内部结构为 \"OpenSSL x509 -text 人类可读输出 + PEM证书块\"。hitls内置PEM解析器（hitls_bsl/pem.c）自动跳过前缀文本并解析PEM块。命令行无需指定-certform/-keyform。
TLCP 双证书体系（GM/T 0024）:
| 证书 | Subject标识 | 用途 |
|---|---|---|
sign.crt |
OU=testsign |
签名证书 — ServerKeyExchange SM2签名 |
enc.crt |
OU=testenc |
加密证书 — 密钥交换 SM2加密/解密 |
4.2 统一环境变量
export LD_LIBRARY_PATH=/home/kali/M/openhitls/build:$LD_LIBRARY_PATH
export C=/home/kali/M/openhitls/testcode/testdata/tls/certificate/der/sm2_with_userid
HITLS=/home/kali/M/openhitls/build/hitls
每个新终端必须先执行前两行export。服务端和客户端需在不同终端运行。
4.3 TLCP 双向身份鉴别（ECDHE\_SM4\_CBC\_SM3）
预期：握手成功。双方均提供双证书，ECDHE密钥交换正常。
服务端（终端1，先启动）:
$HITLS s_server \\
-tlcp -accept 127.0.0.1:4433 \\
-cipher TLS_ECDHE_SM4_CBC_SM3 \\
-CAfile $C/ca.crt -chainCAfile $C/inter.crt \\
-tlcp_sign_cert $C/sign.crt -tlcp_sign_key $C/sign.key \\
-tlcp_enc_cert $C/enc.crt -tlcp_enc_key $C/enc.key \\
-provider default -state
预期输出:
ACCepting connections at 127.0.0.1:4433
Negotiated cipher suite: TLS_ECDHE_SM4_CBC_SM3
TLS handshake completed successfully
Handshake state: connected
客户端（终端2）:
echo \"Hello World\" | $HITLS s_client \\
-tlcp -host 127.0.0.1 -port 4433 \\
-cipher TLS_ECDHE_SM4_CBC_SM3 \\
-CAfile $C/ca.crt -chainCAfile $C/inter.crt \\
-tlcp_sign_cert $C/sign.crt -tlcp_sign_key $C/sign.key \\
-tlcp_enc_cert $C/enc.crt -tlcp_enc_key $C/enc.key \\
-provider default -state
预期输出:
Negotiated cipher suite: TLS_ECDHE_SM4_CBC_SM3
TLS handshake completed successfully
Response: Hello World!
4.4 TLCP 单向身份鉴别（ECC\_SM4\_CBC\_SM3 + -noverify）
重要说明: ECDHE 单向不可行（协议级限制，不是Bug）。ECDHE密钥交换强制客户端提供加密证书参与密钥派生（见源码
send_server_key_exchange.cL305-308），即使使用-noverify也不例外。解决办法: 使用 ECC\_SM4\_CBC\_SM3 密码套件 +
-noverify参数。
服务端（终端1，-noverify + ECC密码套件）:
$HITLS s_server \\
-tlcp -accept 127.0.0.1:4433 \\
-cipher TLS_ECC_SM4_CBC_SM3 \\
-CAfile $C/ca.crt -chainCAfile $C/inter.crt \\
-tlcp_sign_cert $C/sign.crt -tlcp_sign_key $C/sign.key \\
-tlcp_enc_cert $C/enc.crt -tlcp_enc_key $C/enc.key \\
-provider default -state -noverify
预期输出:
-noverify mode: client certificate verification disabled
Negotiated cipher suite: TLS_ECC_SM4_CBC_SM3
TLS handshake completed successfully
客户端（终端2，不提供自身证书，仅CA根证书验证服务端）:
echo \"test\" | $HITLS s_client \\
-tlcp -host 127.0.0.1 -port 4433 \\
-cipher TLS_ECC_SM4_CBC_SM3 \\
-CAfile $C/ca.crt -chainCAfile $C/inter.crt \\
-provider default -state
预期输出:
Negotiated cipher suite: TLS_ECC_SM4_CBC_SM3
TLS handshake completed successfully
Response: test
如果错误地使用 ECDHE 密码套件做单向鉴别，预期结果如下（握手失败）:
client: TLS handshake failed: 0x20c0029 ← 客户端无加密证书，编码失败 server: TLS handshake failed: 0x2040017 ← 服务端未收到对方证书错误码详解见 §五[1]。
4.5 DTLCP 双向身份鉴别（ECDHE\_SM4\_CBC\_SM3，UDP承载）
服务端（终端1，端口4444，避免与TCP冲突）:
$HITLS s_server \\
-dtlcp -accept 127.0.0.1:4444 \\
-cipher TLS_ECDHE_SM4_CBC_SM3 \\
-CAfile $C/ca.crt -chainCAfile $C/inter.crt \\
-tlcp_sign_cert $C/sign.crt -tlcp_sign_key $C/sign.key \\
-tlcp_enc_cert $C/enc.crt -tlcp_enc_key $C/enc.key \\
-provider default -state
客户端（终端2）:
echo \"Hello DTLCP\" | $HITLS s_client \\
-dtlcp -host 127.0.0.1 -port 4444 \\
-cipher TLS_ECDHE_SM4_CBC_SM3 \\
-CAfile $C/ca.crt -chainCAfile $C/inter.crt \\
-tlcp_sign_cert $C/sign.crt -tlcp_sign_key $C/sign.key \\
-tlcp_enc_cert $C/enc.crt -tlcp_enc_key $C/enc.key \\
-provider default -state
预期：握手成功。DTLCP over UDP，无TCP三次握手，握手消息含序号和分片偏移量。
4.6 DTLCP 单向身份鉴别（ECC\_SM4\_CBC\_SM3 + -noverify）
服务端（终端1，ECC + -noverify）:
$HITLS s_server \\
-dtlcp -accept 127.0.0.1:4444 \\
-cipher TLS_ECC_SM4_CBC_SM3 \\
-CAfile $C/ca.crt -chainCAfile $C/inter.crt \\
-tlcp_sign_cert $C/sign.crt -tlcp_sign_key $C/sign.key \\
-tlcp_enc_cert $C/enc.crt -tlcp_enc_key $C/enc.key \\
-provider default -state -noverify
客户端（终端2，无自身证书）:
echo \"test\" | $HITLS s_client \\
-dtlcp -host 127.0.0.1 -port 4444 \\
-cipher TLS_ECC_SM4_CBC_SM3 \\
-CAfile $C/ca.crt -chainCAfile $C/inter.crt \\
-provider default -state
预期：握手成功（与TLCP ECC单向相同原理）。
4.7 抓包分析
# 终端3：tcpdump 抓包（在客户端启动前开始）
mkdir -p captures
# TLCP（TCP，端口4433）
sudo tcpdump -i lo -w captures/tlcp_ecdhe_two_way.pcap port 4433
# DTLCP（UDP，端口4444）
sudo tcpdump -i lo -w captures/dtlcp_ecdhe_two_way.pcap port 4444
# 测试完成后 Ctrl+C 终止抓包
用 Wireshark 打开 pcap 文件，关键分析点:
| 分析项 | TLCP/DTLCP 关键字段 | 说明 |
|---|---|---|
| 协议标识 | ClientHello 中版本 TLS 1.1 + TLCP 扩展 |
TLCP使用0x0002扩展类型 |
| 密码套件 | ServerHello 中 Cipher Suite 字段 | 确认 ECDHE\_SM4\_CBC\_SM3 或 ECC\_SM4\_CBC\_SM3 |
| 双证书 | Certificate 消息 | 单向鉴别时无客户端Certificate消息 |
| ECDHE握手 | ServerKeyExchange内SM2签名值 (r,s分量) | ECDHE专有 |
| 单向标记 | 是否存在 CertificateRequest 消息 | ECC+无验证 无CR，ECDHE 始终有CR |
| 加密切换 | Change Cipher Spec + Encrypted Finished | 2组 CCS+Finished |
4.8 常用参数速查（openhitls-0.3 分支 ab0d11e1 实测可用）
| 参数 | 说明 |
|---|---|
-tlcp / -dtlcp |
协议类型：TLCP (TCP) / DTLCP (UDP) |
-cipher <val> |
密码套件标准名称（大小写敏感） |
-tlcp_sign_cert <file> / -tlcp_sign_key <file> |
SM2 签名证书与私钥 |
-tlcp_enc_cert <file> / -tlcp_enc_key <file> |
SM2 加密证书与私钥 |
-CAfile <file> / -chainCAfile <file> |
CA 根证书 / 中间CA证书链 |
-accept host:port |
服务端监听地址和端口 |
-host <host> / -port <uint> |
客户端连接地址和端口（分开指定） |
-noverify |
单向鉴别核心参数 : 不验证对端证书 |
-provider default |
指定密码Provider（必须指定） |
-state |
输出握手状态信息 |
-accept_once |
服务端完成一次连接后退出 |
密码套件常用值:
-cipher 参数值 |
密钥交换 | 单向支持 |
|---|---|---|
TLS_ECDHE_SM4_CBC_SM3 |
ECDHE + SM4-CBC + SM3 | 不支持 |
TLS_ECC_SM4_CBC_SM3 |
ECC + SM4-CBC + SM3 | 支持 |
TLS_ECDHE_SM4_GCM_SM3 |
ECDHE + SM4-GCM + SM3 | 不支持 |
TLS_ECC_SM4_GCM_SM3 |
ECC + SM4-GCM + SM3 | 支持 |
五、常见错误码
| 错误码 | 十进制 | 宏名称 | 含义 | 典型原因 |
|---|---|---|---|---|
0x27 |
39 | (外层封装错误) | Failed to create config and connection | 聚合错误，查看下层更具体错误码 |
0x20c0029 |
34340873 | HITLS_CERT_ERR_ENCODE |
Failed to encode the certificate （证书编码失败） | ECDHE单向鉴别：客户端无加密证书，EncodeEncCert() 收到NULL |
0x2040017 |
33816599 | HITLS_MSG_HANDLE_NO_PEER_CERTIFIACATE |
Not receive the peer certificate （未收到对端证书） | 对端未发送Certificate消息（或发送了空Certificate） |
0x20a000c |
— | — | 不支持的密码套件 | SM算法未集成到默认Provider（检查编译宏 HITLS_CRYPTO_PROVIDER_DEFAULT_SM） |
0x20c001f |
— | — | 证书链验证失败 | -CAfile /-chainCAfile 路径错误或证书格式不匹配 |
错误码位结构:
0x2 0c 0029= 错误级别(2=ERROR) + 模块ID(0c=HITLS\_CERT) + 模块内错误号(29)
0x20c0029 深入分析（密评中常见）
调用链（从客户端收到 ServerKeyExchange 到返回错误）:
parse_server_key_exchange.c:495 SAL_CERT_ClntGmEncodeEncCert() ← 尝试编码客户端加密证书
↓
cert.c:736 EncodeEncCert(ctx, peerCert->encCert, useLen)
↓ peerCert->encCert == NULL （客户端未提供加密证书）
cert.c:679 if (cert == NULL) return NULL;
↓
parse_server_key_exchange.c:497 → HITLS_CERT_ERR_ENCODE (0x20c0029)
六、面向未来的敏捷架构与开源生态
当前能力只是起点，openHiTLS更大的价值在于面向算法演进的前瞻设计。随着后量子密码标准化推进，基于椭圆曲线的SM2面临量子计算威胁（Shor算法可在多项式时间内破解ECC），SM4则需应对Grover算法带来的等效密钥长度减半问题。openHiTLS通过以下机制应对：
- • Provider插件机制：算法以插件形式挂载，切换算法无需改动应用层代码
- • PQCP密码创新仓：承载国产后量子算法的工程化落地
- • 配置驱动：通过配置文件指定算法，避免硬编码
这套设计使得密码标准演进时，应用层仅需少量配置调整即可完成算法迁移，大幅降低了密评整改的长期成本。
生态层面，openHiTLS由社区技术委员会治理，10+产学研组织共建，已形成\"高校创新算法设计 + 社区工程化实现 + 企业规模化应用\"的协作链条。社区定期举办开源实习活动，面向高校学生提供密码学实践机会，为密评领域持续输送人才。
七、结语
对于密评从业者而言，openHiTLS的价值不仅在于它是一个\"免费的密码库\"，更在于它提供了一套可审查、可裁剪、可演进的密码基础设施。从国密算法到安全协议，从编译集成到抗量子迁移，它为密评建设提供了从当下合规到未来演进的全链路支撑。在合规要求趋严、技术迭代加速的当下，拥抱开源密码套件或许是比采购黑盒产品更可持续的选择。
参考资源
- • 官网：https://openhitls.net
- • 源码仓库：https://gitcode.com/openHiTLS/openhitls
- • 文档中心：https://docs.openhitls.net
- • API 参考：https://apidoc.openhitls.net
版权声明
本站仅做备份收录，仅供研究与教学参考之用。
读者将信息用于其他用途的，全部法律及连带责任由读者自行承担，本站不承担任何责任。
评论