代码审计里的国密算法落地：六个检查点

Java 生态多用 BouncyCastle，版本不一致会导致签名值的编码格式不同

正着读代码容易漏，因为入口太多；反着找危险点，数据流只有那么几条。

先说结论

先列危险点，再回溯入口，最后确认校验与权限。

• 检查点一：所有外部入口是否都过统一校验
• 检查点二：危险函数是否集中封装
• 检查点三：校验是否只做一次、是否白名单
• 检查点四：权限判断是否在服务端
• 检查点五：错误信息是否泄露内部细节
• 检查点六：是否有兜底日志

检查点一：入口

SM3 输出 256 位，内部结构与 SHA-256 不同，两者不能互相替代，混用会直接验签失败。

把入口列全：HTTP 参数、请求头、上传、消息队列、定时任务的外部输入。漏一个就白审。

检查点二：危险点

SM4 是 128 位分组与 128 位密钥，CBC 模式下 IV 必须随机且不可复用，复用等于泄露明文关系。

检查点三：校验逻辑

国密改造常卡在双向证书，服务端与客户端要同时支持 SM2 套件，缺一端就协商不起来。

看到「先替换再校验」「只在一个接口校验」这两种写法，基本可以直接标红。

这个问题的几个审计细节

实际代码里最容易漏的几处：

• Java 生态多用 BouncyCastle，版本不一致会导致签名值的编码格式不同

检查点四到六

越权是审计里性价比最高的方向：少一行判断，就是一个中高危。错误信息要统一，日志要记入口摘要。

再补充几点

这几条不改变结论，但会改变你评估风险时的顺序。

• SM2 签名前要先算 ZA，把用户标识与公钥一起摘要，漏掉这一步必然验签失败
• 密评关注的是完整链路，只换算法而不改密钥管理通常过不了
• 签名不带 ZA，和第三方联调怎么都验不过
• 以为换了 SM4 就满足合规，密钥仍硬编码在代码里
• SM2 密文编码不统一，C1C3C2 与 C1C2C3 互相解不开

审计的产出不是「找到几个洞」，是「知道这类洞在哪个模式里反复出现」。