3、验证点总体规划：分层验证策略

说实话，刚入行那会儿我也想过：加密功能，算法跑对了不就完了？后来在几个项目里吃过亏——算法对，密钥丢了；密钥没丢，协议握手被中间人劫了；协议通了，集成调用却把明文输出了。嗯，从那时起我就明白：验证点不能平铺，得分层。

分层验证说白了就是**把加密系统的不同关注点拆开，每层只测本层的事**。这样问题定位快，覆盖率也容易量化。我自己习惯把部署后的加密验证分成四层，每层再拆验证点。下面这张图算是我的「祖传框架」：

3.1 密码算法层验证

这是地基。算法实现是否正确？加解密结果和标准向量对得上吗？我个人习惯在部署前先用 OpenSSL 或者自己写的小脚本跑一遍 KAT（Known Answer Test）。部署后也要留个保底：用生产环境的密钥对一组固定数据做加解密，验证结果和预期一致。

验证点	检查内容	工具/方法示例
对称算法（AES / SM4）	ECB/CBC/GCM 等模式是否按规范填充	openssl enc -aes-256-cbc -K ... -iv ...
非对称算法（RSA / ECC）	签名验签、密钥对生成、填充格式（PKCS1 v1.5 / OAEP）	openssl pkeyutl -sign / -verify
哈希/摘要（SHA-256 / SM3）	输出长度、碰撞验证（单位时间内随机输入不重复）	自定义脚本 + 抽样对比

3.2 密钥管理层验证

算法对了，但密钥在蜜罐里被泄漏了？那就全白费。密钥生命周期分为：生成 → 存储 → 使用 → 轮换 → 销毁。每一环都要验证。

1. 生成验证：密钥是否来自安全随机源？RNG 是否通过 SP800-22 测试？我习惯在部署后触发一次“强制重新生成”，然后用 HEX dump 看熵源。
2. 存储验证：密钥文件权限是否 600？HSM 中的密钥是否无法通过控制台导出？我见过有人在 /var/lib/keystore 里给了 755 权限，一查就凉半截。
3. 轮换验证：触发轮换后旧密钥是否立即失效？新密钥是否能在不重启服务的情况下生效？
4. 销毁验证：删除后硬盘上是否有残留？我上周刚帮同事查了一个问题：SQLite 里存了明文密钥，delete 后 WAL 文件还在。

3.3 协议安全层验证

密钥和算法都稳了，但协议实现有没有漏洞？TLS 版本是否允许 1.0？SSH 主机密钥是否被缓存篡改？我建议从三个维度入手：

• 版本与套件：检查服务端是否仅允许 TLS 1.2+，禁止 3DES、RC4。用 nmap --script ssl-enum-ciphers 扫一下。
• 握手异常：故意发畸形 ClientHello，看服务端是否崩溃或泄漏内存。我记得有一次在金融项目里试了半长的 SNI 字段，结果服务端日志打印了栈地址。
• 重放攻击：抓包后重发相同加密报文，看是否被拒绝。不少系统在 nonce 验证上漏了防重放窗口。

# 快速验证 TLS 最低版本
echo "Q" | openssl s_client -tls1_1 -connect target:443
# 如果连接成功，说明旧版本没禁用，风险很大

3.4 系统集成层验证

这一层验证的是“接口对”，而不是“实现对不对”。API 是否在加密边界上做了校验？异步回调中的密文是否又被解密了一次？我自己的经验是画一张加密数据流图，然后把所有跨模块调用的点标出来，逐个攻防。

集成场景	典型验证点	个人经验
REST API 加解密	请求体密文是否被中间件二度解密	有一次我发现 gateway 解了一次，业务层又解了一次，导致乱码。
数据库加密层	写入时加密，读取时解密，同时验证字段级粒度	多表关联时注意加密字段无法直接 JOIN，否则性能爆炸。
日志脱敏	是否有明文密钥或密文被记入切面日志	我同事的 logback 配置里漏了 filter，连着三周敏感信息都在 ELK 里裸奔。