vlambda博客
学习文章列表

敏感数据的保存，或脱敏后保存，或加密后保存。脱敏后保存的安全性自不必说，但是脱敏后无法还原，业务需要的数据肯定是需要可以还原的。所以我们重点讨论数据加解密，我们都知道，加密有对称加密和非对称加密。对称加密算法在加密和解密时使用的是同一个秘钥；而非对称加密算法需要两个密钥来进行加密和解密，这两个密钥是公开密钥（public key，简称公钥）和私有密钥（private key，简称私钥）。

对称加密算法的特点是算法公开、计算量小、加密速度快、加密效率高。

非对称加密算法的特点是算法强度复杂，其安全性依赖于算法与密钥。由于其算法复杂，而使得加密解密的速度远远低于对称加密算法，因此不适用于数据量较大的情况。但非对称加密算法加密数据的安全性上又高于对称加密算法。

通过以上简单的介绍和对比，一方面方便部分不熟悉的读者，另一方面想说的是：我们要保存的是海量敏感数据，高并发之下，使用非对称算法进行加解密不合适。因此我们没得选，只能用对称加密算法。

对称加密的算法本身有前辈们设计了多种加密算法，经过大量验证，安全性上自不必操心，然而因为加密和解密都使用同一个密钥，密钥保存也就成了必须解决的一个问题，否则一切努力就都白费了。

或者更霸道的想法是，我们要对称加密的轻便快，我们还要非对称加密的安全性！

1. 程序员小A按照领导要求把敏感数据加密后落库，密钥配置在发布包的配置文件里，时间久了因为处理问题或者修改配置，小A拿到了密钥，通过后台服务小批量导出数据，解密后卖给了不法分子；

2. 运维人员小B配置好密钥后，偷偷记录下密钥，在无人时，导出数据库相关表里的数据，解密后卖给了不法分子；

3. 黑客小C攻入我们服务器，拿到了配置的密钥，一番分析导出了数据库相关表数据，并解密后卖给了不法分子。

以上场景都是因为对称加密算法公开，密钥配置后无处隐遁，一旦泄露，就有数据泄露的风险。

场景有点极端哈，还是回到我们的霸道想法，回到我们的主题：如何使对称加密“不对称”？

为了便于理解，首先我们先看下对称加解密的过程：

左图，通过密钥b对元数据a经加密算法加密可以得到数据密文串c，然后把密文保存到DB即可实现数据的加密保存；

右图，通过密钥b对数据密文c进行解密，可以得到元数据a即可实现数据的解密读取。

前文有提到我们只能对称加密，那么在安全要求面前我们只能想办法改变图1中加密密钥b容易泄露的现状。再看下图：

说明：

图2中同样是3个数据加解密的过程原理跟图1一样。

左图，随机生成两个密钥串1和2，用2对1进行加密得到密文3。

右图，拿着公钥（密钥2）和私钥（密文3），经解密算法，可以得到密钥1.

说到此处我们已经实现了使对称加密“不对称”，全文完！

什么？已经实现了？一头雾水！！！！

解释：

把图1和图2结合起来看。

其实，图2紫色的方框密钥1就是图1里面的加密密钥b。图2就是为了保护这个加密密钥b而设计的。

事情是这样的，使用方拿着配置文件里的公钥来访问我的密钥管理系统Key Management System（图2算法的实现系统，简称KMS），KMS根据用户ID，授权号，可以找到该用户的私钥，有了公钥和私钥（图2右图）就能计算出密钥1，也就是图1里的加密密钥b。

还有点晕？再看图3：

1. 加密密钥不在任何地方存储  

2. 公钥可以定期更换，可以配置到期时间，可以配置到期提醒

1. 小A只有公钥没有私钥；

2. 小B一般不知系统中配的是公钥跟加密数据其实无直接关系，退一步来说就算知道，也可以查到数据库表里一堆私钥，也可以拿到配置文件里的公钥，但不知这两者跟敏感数据密文的关系；

3. 小C呢费老大劲攻入服务器，拿到了公钥和密文数据，尝试了市面各种对称加密算法，始终得到的还是一堆乱码。