固定链接 加解密服务设计的思考

加解密服务设计的思考

加解密服务设计的思考

为什么需要加解密系统?

很多用户的敏感数据(证书私钥,密码,用户和员工隐私数据)以明文存储到磁盘或者数据库中,在后续使用过程中面临着各种数据泄露的风险。为此很多公司对数据静态安全提出了要求:禁止将敏感数据明文存储。所以就需要使用加解密系统进行加密存储,而使用在使用到这些数据的时候自然就需要对其解密。

当部分用户意识到需要对敏感数据加密后,虽然各种算法的实现互联网上都有开源的代码或库,但对于算法种类、强度、分组模式等选择不当的话也达不到高强度的安全。所以使用由专业团队建立和维护的加解密服务是更好的选择。

一谈到加密解密,那么自然就要联想到秘钥,永远都避免不了“秘钥是如何管理的?”这个问题。秘钥的生命周期管理包括对于秘钥生成、保管、分发、更新以及销毁等环节。这些过程需要的专门的系统进行维护。

系统基本功能设计

从上面的分析可以看到加解密服务需要考虑的两个功能:秘钥管理和加解密。作为信息安全基石系统,本身安全性也要求很高。认证和权限管控以及审计功能必须考虑在其中,但不在本文讨论内容当中。

秘钥管理

秘钥管理会通常会设计成为一个链式的结构,如下图:

系统第一次启动时需要初始化生成 Master Key,作为系统中最重要的秘钥需要用来负责加密所有的用户主密钥(CMK),所以 Master Key 本身的安全性也至关重要,所以需要将 Master Key 进行加密存储。那么这里的加密秘钥如何设定才会比较安全?一般有两种办法:

  • 第一种,将加密秘钥分为多人保管,就好像于可口可乐的配方分成了三份由三个进行管理,当需要使用的时候将多个人的信息合并到一起就可以合成秘钥,从而解密获得 Master Key。刚好 Shamir’s secret sharing algorithm 就是解决这个问题的,该算法不仅可以将秘钥分成多少片,还能设定最少恢复人数。比如可以将秘钥通过该算法分为 5 份,其中任意 3 份就可以恢复出原秘钥。

  • 第二种,使用硬件设备加密 Master Key,由硬件来负责保管秘钥,同时确保秘钥不可用被导出。类似设备有加密机、Usbkey、PM 等。

解决了 Master key 的加解密问题后,服务启动后将其加载到内存,当接到用户创建秘钥的请求后,生成响应的格式的秘钥后,由 Master Key 进行加密后存储。这个秘钥一般称之为用户秘钥(CMK),一个用户根据不通的用途可以有很多个 CMK,典型的用途分为两种远程的加解密和本地加解密。本地加解密时系统会生成一个数据加密秘钥(DEK),会使用用户指定的 CMK 进行加密,然后将 DEK 的明文和密文都返回给用户,服务本身并不存储这个秘钥。

加解密

远程加解密

根据不同类型的 CMK,可以提供不同的功能,最常用的就是对称加解密功能,对于数据量较小的情况,直接调用服务 API,指定 CMK 并提供数据明文服务即可对数据进行加密。当需要获取明文时,提供密文和指定的 CMK 就能对密文进行解密获取明文。在这个过程中用户并不会获取 CMK,数据和秘钥是严格隔离的以保障安全性。

信封加解密

当需要加密的数据比较大时,可以使用信封加密方式进行加解密:

  • 加密过程

    服务使用生成数据秘钥接口,获取数据加密秘钥(DEK)和被对应的 CMK 加密的 DEK 的密文。

    服务使用 DEK 对数据进行加密,将加密后的数据和 DEK 密文一同保存起来。

  • 解密过程

    使用 KMS 解密接口对 DEK 密文进行解密,获得 DEK。

    使用 DEK 对加密数据进行解密从而得到原始的数据。

如何做的更好?

上述过程满足了秘钥的安全性和一般用的需求,由于加解密的特殊性,数据一旦加密后,再更新加密方式就比较困难,所以一些高级功能还需要在系统设计时考虑清楚,即使不需要立即实现也需要考虑好,为后续的特性进行兼容。有以下几点需要我们考虑:

  1. 秘钥 ID 和密文打包一起存储,如果用户使用多个 CMK 进行加密,管理密文和秘钥的对应关系将产生额外的工作量,所以如果将秘钥 ID 和密文打包在一起返回给用户一并存储,在解密时直接调用解密接口即可。省去了查找对应密文的工作。

  2. 秘钥更新机制,安全的使用加解密的原则之一就是定期更换密钥,而用户在已经使用原秘钥进行加密的情况下,更新秘钥变得更加的困难。所以 CMK 不是单独的一个秘钥,而是一个带有版本信息的秘钥链,更新秘钥时只需要在秘钥链上新增一个秘钥。用户调用接口方式不需要变更即可使用新的秘钥。这样密文中也需要包含秘钥版本信息,在解密时加解密服务才能找到对应的秘钥。由于秘钥链的长度如果过长可能会影响秘钥查询性能,服务也应该提供重新加密功能和秘钥删除功能。

  3. 一致性加密,由于默认的安全加密在每次加密时都会使用随机数 nonce 参与计算,就使得即使每次加密相同的内容也会产生不同的结果。这样安全性得到增强,但在很多用户使用场景中,需要使用加密的密文做查询。可以使用类似 AES-SIV 利用消息明文生成 nonce。这样就可以保证相同明文加密后产生相同的密文。

最后

滴滴云加解密服务会在不久的将来上线,文中提到的很多高级功能也会陆续到来,欢迎各位开发者使用。

本文作者:康竟淞

您的留言将激励我们越做越好