二、密码学基础：对称加密、非对称加密、哈希函数、数字签名等核心概念与原理
密码学是CRA合规（商用密码应用安全性评估）的底层技术基石。无论是评估信息系统的密码应用方案，还是审查密钥管理流程，都必须首先透彻理解各类密码算法的数学原理、安全属性与适用场景。本章将围绕对称加密、非对称加密、哈希函数和数字签名四大核心模块展开，结合CRA合规中的实际判定逻辑，帮助学员建立从算法原理到合规评估的完整认知链路。
2.1 对称加密：高效的数据机密性保障
2.1.1 核心原理与工作模式
对称加密算法使用同一个密钥完成加密和解密操作，其安全性完全依赖于密钥的保密性。在CRA合规评估中，对称加密主要用于业务数据、敏感文件的传输加密和存储加密。国密算法SM4是当前国内商用密码体系中的主流对称算法，其分组长度为128比特，密钥长度同样为128比特，采用32轮非线性迭代结构。国际算法中AES（高级加密标准）和DES（数据加密标准）也常见于存量系统。
对称加密的工作模式直接影响安全强度，CRA合规审查中需要特别关注模式选择：
- ECB模式：相同明文产生相同密文，存在模式泄露风险，CRA合规中通常不建议用于超过一个分组的数据加密。
- CBC模式：引入初始向量（IV）实现前后分组关联，需确保IV的随机性和不可预测性。
- GCM/CCM模式：认证加密模式，同时提供机密性和完整性保护，是当前合规评估中的推荐模式。
| 算法 | 分组长度 | 密钥长度 | CRA合规状态 | 典型应用 |
|---|---|---|---|---|
| SM4 | 128 bit | 128 bit | 合规（国密） | 金融数据加密、VPN |
| AES-256 | 128 bit | 256 bit | 合规（国际） | 云存储加密、数据库加密 |
| DES | 64 bit | 56 bit | 不合规（强度不足） | 存量老旧系统 |
2.1.2 密钥管理与CRA判定要点
对称加密的密钥管理是CRA合规评估中的高频扣分项。密钥生成必须使用符合GB/T 37092要求的随机数发生器；密钥传输必须采用非对称加密或密钥协商机制进行保护；密钥存储不得以明文形式存在于数据库或配置文件中。实际评估中常见问题包括：硬编码密钥、密钥长期不更换、同一密钥用于多个业务系统等。
2.1.3 实战场景：金融交易数据加密
某银行核心交易系统需要加密存储客户交易流水。初始方案采用DES-ECB模式，密钥硬编码在Java代码中。CRA预评估发现：ECB模式导致相同交易金额和时间的记录产生相同密文，存在统计分析攻击风险；硬编码密钥在源码泄露场景下会导致全量数据泄露。整改方案为：升级为SM4-GCM模式，密钥由密钥管理系统（KMS）统一生成并加密存储，每次加密使用随机IV，密钥每季度轮换一次。整改后密文随机性显著提升，密钥泄露风险得到有效控制。
2.2 非对称加密：密钥分发与身份认证的基石
2.2.1 数学原理与安全属性
非对称加密基于数学难题（如大整数分解、椭圆曲线离散对数问题），使用公钥和私钥密钥对。公钥可公开分发，私钥必须严格保密。国密SM2算法基于椭圆曲线密码体制（ECC），在同等安全强度下密钥长度远短于RSA，计算效率更高。CRA合规中，SM2用于密钥交换、数字签名和加密，是构建PKI体系的推荐算法。
非对称加密的核心价值在于解决对称加密的密钥分发难题：发送方使用接收方的公钥加密数据，只有接收方的私钥能够解密。这一特性使得非对称加密成为密钥协商、数字信封和身份认证的基础。
2.2.2 密钥对生成与生命周期管理
非对称密钥对的生成必须在合规的密码设备（如密码机、智能密码钥匙）中完成，私钥不得导出到非安全环境。CRA合规要求密钥对具备完整的生命周期管理流程：生成、存储、使用、备份、归档、销毁。私钥的备份必须采用加密保护，且备份副本数量受控。
2.2.3 案例拆解：数字信封在电子政务中的应用
某省级政务平台需要向多个委办局安全分发敏感数据文件。采用数字信封方案：发送方随机生成SM4会话密钥，使用SM4加密业务数据；再使用接收方的SM2公钥加密会话密钥。接收方使用自己的SM2私钥解密得到会话密钥，再用会话密钥解密业务数据。该方案兼顾了对称加密的高性能和非对称加密的密钥分发安全性。CRA评估中，该方案在密钥传输机密性、算法合规性方面均满足要求，但需注意会话密钥的随机性必须由合规随机源产生。
2.3 哈希函数：数据完整性的守护者
2.3.1 核心特性与算法选择
哈希函数将任意长度的输入映射为固定长度的输出（摘要），具备单向性、抗碰撞性和雪崩效应。国密SM3算法输出256比特摘要，安全强度等同于SHA-256。在CRA合规中，哈希函数用于完整性校验、口令存储、数字签名预处理等场景。
哈希函数的三个关键安全属性：
- 抗原像攻击：给定摘要值，无法反推出原始输入。
- 抗第二原像攻击：给定输入和摘要，无法找到另一个输入产生相同摘要。
- 抗碰撞性：无法找到两个不同输入产生相同摘要。
2.3.2 口令存储的合规实践
在CRA合规评估中，用户口令存储是常见检查点。明文存储或仅使用MD5/SHA-1等弱哈希算法均不符合要求。合规做法是使用SM3哈希结合随机盐值（Salt）进行多次迭代运算。例如：hash = SM3(SM3(password + salt) + salt)，迭代次数建议不低于1000次。
2.3.3 场景说明：软件完整性校验
某企业级应用在启动时校验自身JAR包的SM3摘要值，防止被篡改。发布流程中，构建系统计算JAR包的SM3摘要并签名，应用启动时重新计算摘要并与签名中的摘要比对。若摘要不一致，则拒绝启动。该机制有效防止了恶意代码注入，是CRA合规中“应用自身完整性保护”的典型实现。
2.4 数字签名：身份认证与不可否认性的实现
2.4.1 签名与验签的完整流程
数字签名结合了哈希函数和非对称加密：签名方使用私钥对消息摘要进行签名运算，验证方使用签名方的公钥验证签名。国密SM2数字签名算法是CRA合规中的推荐算法，其签名过程包含随机数参与，同一消息每次签名结果不同，增强了安全性。
标准签名流程：
- 发送方计算消息的SM3摘要值。
- 发送方使用自己的SM2私钥对摘要值进行签名运算，生成签名值。
- 发送方将消息原文和签名值一并发送给接收方。
- 接收方使用发送方的SM2公钥对签名值进行验签运算，同时计算消息的SM3摘要值。
- 验签通过则确认消息完整且来源可信。
2.4.2 数字证书与PKI体系
数字签名的公钥可信度依赖于PKI体系。CA机构为签名方签发数字证书，证书将公钥与实体身份绑定。CRA合规要求证书的签发、存储、验证和吊销流程符合GB/T 20518和GM/T 0014等标准。在评估中，需要检查证书链的完整性、证书有效期管理以及CRL/OCSP的配置情况。
| 检查项 | 合规要求 | 常见不合规表现 |
|---|---|---|
| 证书有效性 | 证书在有效期内，证书链完整 | 使用自签名证书且未纳入信任库 |
| 私钥保护 | 私钥存储在硬件密码模块中 | 私钥导出到应用服务器文件系统 |
| 签名算法 | 使用SM2或RSA-PSS等安全算法 | 使用MD5withRSA等弱签名算法 |
| 证书吊销 | 配置CRL或OCSP服务 | 未配置吊销检查，证书失效后仍被信任 |
2.4.3 案例拆解：电子合同签署系统
某电子合同平台需要满足CRA合规要求。初始方案使用RSA-1024签名，私钥存储在数据库表中。评估发现：RSA-1024已不满足安全强度要求；私钥明文存储存在严重泄露风险。整改方案：升级为SM2签名算法，私钥托管在服务器密码机中，应用通过国密API调用签名服务；同时部署企业级CA，为每个企业用户签发SM2证书。整改后，签名性能下降约15%（SM2签名速度低于RSA-1024），但安全强度显著提升，且私钥不再暴露在应用层。该平台顺利通过CRA评估，并获得“密钥管理规范”单项好评。
2.5 四大密码原语的协同与CRA合规综合判定
2.5.1 密码套件的组合逻辑
实际密码方案中，四大原语通常协同工作。以HTTPS通信为例：握手阶段使用非对称加密（SM2）完成身份认证和密钥协商；会话阶段使用对称加密（SM4-GCM）加密业务数据；哈希函数（SM3）用于完整性校验和密钥派生。CRA合规评估需要从整体方案角度审查密码套件的组合是否合理，是否存在弱算法降级风险。
2.5.2 合规评估中的常见误区
- 误区一：认为只要使用了国密算法就必然合规。实际上，算法使用方式（如模式选择、密钥长度、随机数质量）同样影响合规判定。
- 误区二：混淆哈希与加密的用途。哈希用于完整性，加密用于机密性，两者不可替代。
- 误区三：忽视密钥管理。即使算法强度足够，若密钥管理混乱（如长期不轮换、明文存储），整体安全性仍不达标。
- 误区四：忽略随机数质量。SM2签名和密钥生成均依赖高质量随机数，使用伪随机数发生器将导致严重安全漏洞。
2.5.3 综合判定流程
在CRA实际评估中，对密码技术应用的判定遵循以下路径：首先识别系统使用的密码算法和协议，对照GB/T 39786-2021附录A检查算法合规性；其次检查密钥管理流程是否符合GM/T 0054-2018要求；然后验证密码产品是否持有商用密码产品认证证书；最后通过渗透测试和代码审计确认实现层面无弱点和后门。整个判定过程需要综合运用本章所学的四大密码原语知识，任何环节的薄弱都可能导致整体不合规。