记一次国密落地的经历

前言

在一般意义上的后台服务中，身份认证可以保证数据源没有问题，完整性校验可以保证数据没有经过窃听者的篡改，但我们还要防止窃听者知道数据的内容，这就还需要加解密来帮助我们守住最后一道围墙

而在私有云交付的环境中，我们无法用现有的公司平台加解密服务，并且按照国家、金融行业等要求，需要用国密算法实现的加解密方案

国密存在哪些问题

使用不便

最大问题是使用不便。这是由于国密不在IETF国际标准中，不同于ECDSA、ECDH、RSA等国际算法，系统中往往包含相关标准加解密方式，业务数据包通过HTTPS传输时完全不用考虑如何交换公钥，如何加解密数据。

因此现阶段使用国密必须在业务层手动进行数据加解密，相当于对数据进行一步额外的操作。

无最佳实践

确定业务层进行加解密后，应该使用哪一种国密实现、该如何进行加解密是另一个难点，且暂不存在一个最优解。国密的实现方案很多，包括TencentSM、GmSSL和KMS服务器，这也需要进一步的调研和测试来决定最终方案。

国密落地过程

国密落地分为调研、制定、实现与测试四个阶段。

调研阶段主要目的有两个：

• 找到性能高效、使用便捷并且有足够保障（维护活跃度、大厂背书、有变现渠道保证不会暴死等）的国密算法实现
• 调研公司内国密改造案例

国密算法选择

我们通过benchmarks测试评估多种国密库算法性能，最终结果如下：

可以看到TencentSM的benchmarks测试结果较为突出，也是作为我们的最终选择

国密实现方案选择

对于国密的实现，我们收集到的可行方案如下：

1. XX实验室建议方案：引入额外KMS系统，独立部署管理证书、私钥，分发公钥。
   • 优点：保密性好，完整的加解密方案（包括证书、信任链等待）
   • 缺点：需要在业务侧缓存大量SM4密钥，对性能有影响
2. XXX网关团队数据加密方案：一次链接一个SM4密钥，发送SM4加密的数据同时发送SM2公钥加密后的SM4密钥。
   • 优点：过程简单
   • 缺点：服务端每次数据处理都需要双解密（解密密钥后解密数据），对性能有影响
3. 无侵入数据加密方案：使用双SSL证书（RSA/SM2）的HTTPS前置机作为网络入口，完全无侵入性地替换。
   • 优点：完全无缝地替换国际加密协议，业务侧无感知
   • 缺点：SDK侧同样需要双证书支持，但目前普遍缺乏实现；需要添加额外组件HTTPS前置机

在制定方案之前，我们总结了对解密方案的需求：

1. 简单无依赖
2. 性能好
3. 成熟
4. 支持服务器热更新SM2公钥
5. 支持上报失败后数据加密落地重传

可以接受的缺点：

1. 对业务侵入

于是在制定方案时我们充分考量了HTTPS加解密方式，设计了类似的加密上报方式

基于对称密钥加密公钥的非对称加密方案，时序图如下：

值得注意的是：

1. 为了确保解密后数据无误，同时上报原始数据MD5用以比对
2. 为了确保服务器更新SM2公钥后上报仍然可以进行，我们设计了主从密钥方式，被换下的密钥并不删除，而是作为从钥继续用以解密，并且通知终端更新公钥
3. 为了确保上报失败后可以重试，我们将加密数据以及meta信息落盘

该方案经过云鼎实验室同事确认可靠性，我们最终采取了该方案

重难点解决

高并发下的解密实现

由于解密过程需要用到线程相关的变量，若每次解密都去生成对应的上下文将非常耗时。同时由于在QAPM的国密方案下公钥是定期更新的，所以这里为了保证解密流程的性能，在初始化时使用SM2InitCtxWithPubKey为每一个Worker创建了一个上下文。

/**
 * @brief 使用SM2获取公私钥或加解密之前，必须调用SM2InitCtx或者SM2InitCtxWithPubKey函数.如果使用固定公钥加密，可调用SM2InitCtxWithPubKey，将获得较大性能提升
 * @param ctx  函数出参 - 上下文
 * @param pubkey  函数入参 - 公钥
 */
func SM2InitCtxWithPubKey(ctx *SM2_ctx_t, pubkey []byte) {
 if ctx == nil || pubkey == nil {
  panic("invalid parameter")
 }
 if len(pubkey) < 130 {
  panic("memory len is too small")
 }
 C.SM2InitCtxWithPubKey(&ctx.Context, (*C.char)(unsafe.Pointer(&pubkey[0])))
}

再通过自行实现的协程池管理并发解密任务，兼顾解密服务的稳定性和吞吐量。

type Worker struct {
 name    string
 ctx     *sm.SM2_ctx_t // ThreadLocal ctx
 handler WorkerHandler
}

避免国密接口对原有架构的侵入性

由于实现的国密方案是在项目原有的接入层微服务代码中拓展实现，为保证原有架构的完整性，避免国密接口侵入导致的额外开发量以及额外的维护成本，我们对接入层的架构进行了微调，最终通过重写fasthttp的部分方法（如BodyGunzip, MultipartFormBoundary, MultipartForm, Body等），细化对request的处理步骤，完全解耦了解密和接口具体逻辑

耗时监控

最终上线符合国密标准的接入层系统后，构建耗时监控如下：

可以看到耗时在可控范围内，且除文件上报外耗时无明显变化

总结

安全无小事，这是我第一次参与大型的加解密服务的设计与实现工作中，希望后续还会有机会丰富我浅薄的网络安全知识🤔🤔🤔