📚 课程目录第2章密码学基础

密码学基础：对称加密、非对称加密、哈希函数、消息认证码、数字签名与密钥交换协议

硬件安全模块（HSM）的核心职责是保护密钥全生命周期，并为上层应用提供密码运算服务。要理解HSM的设计原理、安全边界和攻击面，必须先扎实掌握现代密码学的基础构件。本章将系统梳理六大核心密码学原语：对称加密（AES/DES）、非对称加密（RSA/ECC）、哈希函数（SHA-2/3）、消息认证码（HMAC）、数字签名以及密钥交换协议。我们将从数学原理、工程实现、HSM中的典型应用场景以及常见误区四个维度展开，帮助你在后续章节中理解HSM如何通过硬件隔离和密钥管理来增强这些算法的安全性。

上图展示了本章六大密码学构件在HSM中的协同关系。对称加密提供高效的数据保护，非对称加密解决密钥分发问题，哈希函数确保完整性，HMAC同时提供完整性与真实性，数字签名实现不可否认性，而密钥交换协议则安全地协商会话密钥。HSM作为信任根，将这些算法封装为硬件级安全服务，确保密钥材料在物理隔离的环境中生成、存储和使用。

2.1 对称加密：AES与DES

核心原理

对称加密使用同一个密钥进行加密和解密操作，其安全性完全依赖于密钥的保密性。DES（Data Encryption Standard）诞生于1977年，使用56位有效密钥和64位分组，由于密钥空间过小，在1999年已被证明可以在24小时内被暴力破解。AES（Advanced Encryption Standard）于2001年由NIST正式发布，取代DES成为现代对称加密的标准。AES支持128/192/256位密钥长度，分组大小为128位，其设计基于Substitution-Permutation Network（SPN）结构，通过多轮（10/12/14轮）的字节代换、行移位、列混合和轮密钥加操作实现高度混淆与扩散。

在HSM中，AES引擎通常以硬件加速器形式实现，支持ECB、CBC、CTR、GCM、CCM等多种工作模式。其中GCM（Galois/Counter Mode）同时提供加密和完整性校验，是TLS 1.3和IPsec中广泛使用的认证加密模式。DES在HSM中仅用于兼容遗留系统，例如金融领域的IBM 3624 PIN生成算法仍依赖DES/3DES。

判断方法或操作流程

在HSM中调用对称加密API时，需要明确以下参数：

算法标识：AES-128-CBC、AES-256-GCM、3DES-EDE等
密钥标识：HSM中的密钥句柄（Key Handle），而非明文密钥
工作模式：ECB（不推荐）、CBC、CTR、GCM等
填充方式：PKCS#7、NoPadding（CTR/GCM模式不需要）
初始化向量（IV）：CBC模式要求随机且不可预测的IV

// 以PKCS#11接口为例，使用CKM_AES_GCM加密
CK_MECHANISM mech = {CKM_AES_GCM, &gcm_params, sizeof(gcm_params)};
CK_SESSION_HANDLE session;
CK_OBJECT_HANDLE hKey;
// 初始化会话、查找密钥句柄...
CK_BYTE ciphertext[1024];
CK_ULONG ciphertext_len = sizeof(ciphertext);
C_EncryptInit(session, &mech, hKey);
C_Encrypt(session, plaintext, plaintext_len, ciphertext, &ciphertext_len);

案例拆解：金融支付终端PIN加密

在ATM/POS终端场景中，持卡人输入的PIN必须从终端安全传输至银行主机。传统方案使用3DES或AES对PIN Block进行加密。假设某支付系统要求PIN长度为4-12位，PIN Block格式遵循ISO 9564-1 Format 0。HSM内部操作流程如下：

终端生成随机密钥（KEK，Key Encryption Key）并加密PIN Block
终端使用银行公钥加密KEK，形成数字信封
HSM接收密文后，先用HSM内部存储的私钥解密出KEK
HSM使用KEK解密PIN Block，验证PIN格式后重新加密为银行主机密钥格式

此过程中，PIN明文仅在HSM安全边界内出现，任何软件层都无法直接读取。若使用AES-256-GCM，还能同时检测密文是否被篡改，防止中间人攻击。

常见误区与总结

风险提示：ECB模式不应使用。ECB模式下相同的明文分组产生相同的密文分组，会泄露数据模式。例如加密一张位图，ECB模式会保留图像轮廓。HSM中应默认使用CBC+随机IV或GCM模式。

另一个常见误区是混淆密钥长度与安全强度。AES-128在量子计算下提供64位安全性，AES-256提供128位安全性。对于长期保护的数据（如密钥证书），建议使用AES-256。DES/3DES在2023年NIST已正式弃用，新系统不应再部署。

2.2 非对称加密：RSA与ECC

核心原理

非对称加密使用一对数学关联的密钥：公钥用于加密或验签，私钥用于解密或签名。RSA基于大整数分解难题，其安全性依赖于两个大素数乘积的分解困难性。RSA密钥长度通常为2048/3072/4096位，2048位在2023年后已不被NIST推荐用于新系统。ECC（Elliptic Curve Cryptography）基于椭圆曲线离散对数难题，在相同安全强度下密钥长度远小于RSA。例如，256位ECC提供与3072位RSA相当的安全性，计算效率更高，尤其适合资源受限的嵌入式HSM。

ECC的核心参数包括曲线方程、基点G、阶n和余因子h。NIST P-256（secp256r1）、Curve25519（X25519）是当前主流选择。Curve25519由Daniel Bernstein设计，避免了NIST曲线中潜在的背door争议，且实现更简单、常数时间执行更易保证。

判断方法或操作流程

在HSM中选择非对称算法时，需考虑以下因素：

需求维度	RSA	ECC
密钥长度	2048/3072/4096位	256/384/521位
运算速度（签名）	较慢（模幂运算）	较快（标量乘法）
运算速度（验签）	较快（小指数）	较慢
密钥生成	需要素数检测，较慢	快速
硬件资源占用	大（需要大数运算单元）	小（适合嵌入式）
兼容性	最广泛	现代协议优先

HSM中RSA私钥操作（解密、签名）必须发生在硬件内部，私钥永不以明文形式导出。ECC私钥同样受硬件保护。PKCS#11机制中，CKM_RSA_PKCS、CKM_RSA_PKCS_OAEP用于加密/解密，CKM_ECDSA、CKM_ECDSA_SHA256用于签名。

案例拆解：TLS握手中的ECDHE_RSA

在TLS 1.2/1.3握手过程中，服务器使用RSA私钥对ECDHE参数进行签名，客户端使用服务器公钥验签，从而确保密钥交换参数的真实性。具体流程：

服务器生成临时ECDH密钥对（ephemeral），私钥仅存在于内存
服务器使用长期RSA私钥对ECDH公钥和随机数进行签名
客户端使用服务器证书中的RSA公钥验签，确认参数未被篡改
双方通过ECDH算法协商出共享密钥，再通过HKDF导出会话密钥

此方案结合了RSA的成熟生态和ECDH的前向保密性。HSM在此过程中承担RSA签名运算，确保服务器私钥不暴露给应用进程。若使用TLS 1.3，RSA签名方案需使用RSA-PSS，而非传统的PKCS#1 v1.5。

常见误区与总结

经验提醒：不要直接使用RSA加密大数据。RSA加密有长度限制（2048位密钥最多加密245字节），且计算开销大。正确做法是使用混合加密：用RSA/ECC加密对称密钥，用AES加密实际数据。

另一个误区是忽略ECC曲线选择。某些旧曲线（如secp256k1）虽然被比特币使用，但并非所有HSM都优化支持。对于合规场景，应选择NIST P-256或Curve25519。此外，ECC实现必须防止侧信道攻击，HSM硬件应保证标量乘法在常数时间内完成。

2.3 哈希函数：SHA-2与SHA-3

核心原理

哈希函数将任意长度消息压缩为固定长度摘要，具有单向性、抗碰撞性和雪崩效应。SHA-2家族包括SHA-224/256/384/512，基于Merkle-Damgård结构，使用压缩函数处理消息分组。SHA-3基于Keccak海绵结构，由Guido Bertoni等人设计，2015年成为FIPS 202标准。SHA-3与SHA-2在数学结构上完全不同，即使SHA-2被攻破，SHA-3仍可提供安全保障。

在HSM中，哈希引擎通常支持SHA-1（仅兼容）、SHA-256、SHA-384、SHA-512以及SHA3-256/384/512。SHA-1已被证明存在碰撞攻击（SHAttered），不应再用于安全场景。SHA-256是当前最广泛使用的哈希算法，用于证书签名、代码签名、区块链等。

判断方法或操作流程

选择哈希函数时，需根据安全强度和性能要求：

SHA-256：输出256位，适合大多数场景，TLS证书签名、固件完整性校验
SHA-384：输出384位，用于更高安全等级，兼容64位平台性能较好
SHA-512：输出512位，适合需要更长摘要的场景
SHA3-256：抗量子计算能力更强，适合未来合规需求

HSM中哈希运算通常与签名/验签结合。例如，使用CKM_SHA256_RSA_PKCS机制，HSM内部先计算消息哈希，再对哈希值进行RSA签名，避免应用层将完整消息送入HSM。

案例拆解：固件签名与安全启动

在嵌入式设备安全启动流程中，Boot ROM使用HSM中预置的公钥验证固件签名。具体步骤：

固件编译完成后，构建服务器使用HSM中的私钥对固件镜像的SHA-256哈希值进行签名
设备启动时，Boot ROM计算固件镜像的SHA-256哈希
Boot ROM使用HSM中的公钥验证签名，确认哈希值匹配
验证通过后，固件才被允许执行

此方案确保固件未被篡改且来源可信。HSM在此过程中保护签名私钥，即使攻击者获得设备root权限，也无法提取私钥伪造固件。SHA-256的碰撞抗性保证了攻击者无法构造具有相同哈希的恶意固件。

常见误区与总结

风险提示：不要使用哈希函数替代MAC。哈希函数本身不包含密钥，无法提供消息认证。攻击者可以同时修改消息和哈希值。必须使用HMAC或数字签名来确保完整性和真实性。

另一个误区是忽略长度扩展攻击。SHA-2（Merkle-Damgård结构）存在长度扩展攻击风险，因此当需要密钥参与时，应使用HMAC结构而非简单的H(key || message)。SHA-3天然免疫长度扩展攻击，但HMAC-SHA3仍然是推荐做法。

2.4 消息认证码：HMAC

核心原理

HMAC（Hash-based Message Authentication Code）使用哈希函数和共享密钥生成消息认证码，同时提供完整性和真实性保证。HMAC的构造为：HMAC(K, m) = H((K' ⊕ opad) || H((K' ⊕ ipad) || m))，其中K'是密钥K经过填充后的值，ipad和opad是固定的填充字节。这种双重哈希结构有效防止了长度扩展攻击。

在HSM中，HMAC常用于API请求认证、会话令牌生成、密钥派生（HKDF）等场景。HMAC-SHA256是TLS 1.3中HKDF的核心组件，也是JWT（JSON Web ）的默认签名算法之一。

判断方法或操作流程

使用HMAC时需注意：

密钥长度：不应小于哈希输出长度，推荐与哈希输出等长（如HMAC-SHA256使用32字节密钥）
密钥管理：HMAC密钥应存储在HSM中，通过句柄引用
比较方式：验证MAC时使用常数时间比较，防止时序攻击

// 使用PKCS#11计算HMAC-SHA256
CK_MECHANISM mech = {CKM_SHA256_HMAC, NULL, 0};
CK_BYTE mac[32];
CK_ULONG mac_len = sizeof(mac);
C_SignInit(session, &mech, hKey);
C_Sign(session, message, msg_len, mac, &mac_len);

案例拆解：API请求签名

某金融系统要求所有API请求必须携带HMAC签名，防止请求被篡改。流程如下：

客户端使用HSM中的HMAC密钥对请求参数（时间戳、随机数、消息体）计算签名
服务端HSM使用相同密钥重新计算HMAC
若两个HMAC值一致，则请求合法；否则拒绝

此方案中，HMAC密钥仅存在于HSM内部，即使数据库泄露，攻击者也无法伪造合法请求。时间戳和随机数（Nonce）防止重放攻击。HSM的高吞吐量HMAC计算能力可支撑每秒数万次请求验证。

常见误区与总结

经验提醒：HMAC密钥应定期轮换。在HSM中可设置密钥有效期，到期后自动失效。轮换策略应结合业务风险，例如每90天轮换一次API签名密钥。

常见误区包括：使用相同密钥进行加密和MAC（应使用不同密钥）；将HMAC密钥硬编码在代码中（应存储在HSM）；使用不安全的比较函数（如memcmp）验证MAC（应使用常数时间比较）。

2.5 数字签名与密钥交换协议

核心原理

数字签名结合哈希函数和非对称加密，提供完整性、真实性和不可否认性。签名过程：发送方使用私钥对消息哈希值进行签名运算；验证方使用公钥验证签名。RSA-PSS和ECDSA是两种主流签名方案。ECDSA基于椭圆曲线，签名长度短（64字节），适合带宽受限场景。

密钥交换协议允许双方在不安全的信道上协商共享密钥。Diffie-Hellman（DH）是最早的公钥交换协议，但传统DH不提供认证，容易受到中间人攻击。ECDH（Elliptic Curve Diffie-Hellman）使用ECC实现更高效的密钥交换。现代协议（如TLS 1.3）使用ECDHE（Ephemeral ECDH），每次会话生成临时密钥对，实现前向保密。

判断方法或操作流程

在HSM中实现密钥交换时，需遵循以下流程：

双方各自生成临时密钥对（在HSM内部生成，私钥不导出）
交换公钥（可通过证书认证公钥真实性）
各自使用对方公钥和自己的私钥计算共享密钥
通过HKDF等KDF（密钥派生函数）从共享密钥派生会话密钥

此流程中，HSM确保临时私钥仅存在于安全边界内，即使通信被窃听，攻击者也无法计算共享密钥。前向保密性保证即使长期私钥泄露，历史会话密钥也无法被解密。

案例拆解：TLS 1.3握手中的密钥协商

TLS 1.3简化了握手流程，仅需一次往返（1-RTT）即可完成密钥协商。具体步骤：

客户端发送ClientHello，包含支持的密码套件和客户端密钥共享（ECDHE公钥）
服务器回复ServerHello，选择密码套件并发送服务器密钥共享
双方各自计算共享密钥，通过HKDF-Expand派生应用密钥
后续所有通信使用AES-256-GCM加密

在此过程中，HSM承担ECDHE密钥生成、共享密钥计算和签名验证。若使用PSK（预共享密钥）模式，HSM还需安全存储PSK。TLS 1.3移除了RSA密钥交换，仅保留ECDHE和PSK，确保所有会话都具有前向保密性。

常见误区与总结

风险提示：不要使用未认证的DH协议。传统DH不验证对方身份，攻击者可实施中间人攻击。必须结合数字签名或证书认证公钥。TLS 1.3通过证书签名或PSK认证解决了此问题。

另一个误区是忽略密钥派生函数。直接从ECDH共享密钥使用原始字节作为AES密钥是不安全的，应通过HKDF等KDF进行扩展和增强。HSM通常提供HKDF机制，确保派生过程符合NIST SP 800-108标准。

总结本章，对称加密提供高效数据保护，非对称加密解决密钥分发，哈希函数确保完整性，HMAC提供认证，数字签名实现不可否认，密钥交换协议协商会话密钥。HSM将这些原语封装为硬件安全服务，密钥生命周期完全受控。理解这些基础构件及其在HSM中的实现方式，是后续学习密钥管理、安全协议和HSM应用开发的前提。