密钥管理架构设计概述

Key Management Service：密钥管理服务，为公司加解密、接口签名等服务提供统一的密钥管理能力，包括密钥生成、存储、下发、更新、销毁等。

一、概念

1、密钥属性：

（1）密钥状态

NEW：相应的密钥版本已准备就绪，可以使用。
    USING：相应的密钥版本已无法使用，但密钥材料仍可以使用，并且可重新设置成已启用状态。
    STOP：手动停用的密钥。
    LIMIT：限制的密钥，不可在做加密操作，但可以用来解密历史数据。
    DEL：删除的密钥，不能再进行任何加密或者解密操作。

（2）密钥版本：从1.0逐渐增加。

（3）有效期：单个密钥有效期60分钟。密钥失效前10分钟生成新密钥。

2、密钥用途：KMS为以下场景提供相应的密钥用途：数据加密、数字签名、各种场景的key管理。

3、密钥更新：密钥更新，不会对历史数据重新加密，只是在更新的时间点之后，自动使用新密钥做加密

自定更新，设置更新周期和更新时间
    手动更新，随时更新，并且不影响自动更新

4、密钥分级：密钥分级保证密钥本身的安全性。

简单的分级方案：
    第一层：工作密钥，DEK，用来加密实际的敏感数据。
    第二层：密钥加密密钥，又叫做终端主密钥，KEK，用来加密工作密钥，在各个终端中存在。
    第三层：非对称密钥，数字证书的一部分，用来识别身份，并加密传输KEK。

二、思路

1、严格校验用户端和服务端的身份，避免冒用。身份校验应以可信的第三方CA为标准。

2、密钥管理设计时要充分考虑密钥备份、容灾恢复等问题。

3、在各个关键节点要设计降级方案，如向KMS申请密钥超时，SDK需要支持本地生成临时密钥。

4、密钥更新过程中一定要保证多节点的密钥一致性。

5、能在SDK中封装好的功能尽量在SDK封装好，避免与业务线代码侵入过多。

6、尽量避免转加密现象。

三、组成架构

简单的密钥管理体系由四大部分组成：

KMS：密钥管理系统，用来统一管理各类密钥的生命周期，维护密钥各类属性。在密钥更新的过程中，实际是由KMS来判断是否需要更新、向各客户端下发更新指令，并实际生成密钥的。

TMS：TOKEN管理系统，用来管理各个系统和密钥直接的对应权限关系。

CA：统一认证中心，用来生成并下发数字证书，管理数字证书生命周期。

SDK：按照统一标准封装加解密、签名等方法，并在后台与KMS定期通信，维护密钥更新流程。

四、密钥管理方案

初始化阶段：

1、各个Service首先在KMS中接入获得身份令牌token

2、各个Service生成自己的RSA公私钥

3、各个Service拿自己的RSA公钥去CA申请证书

密钥准备阶段：

1、Service用自己的证书去KMS申请需要的密钥

2、密钥保存在Service本地，定期去KMS重新获取（当有效期设置为0时，即不在Service本地保存，一次一密）

业务调用阶段：

1、Service用获取到的签名密钥做签名，加密密钥做加密，调用其他服务。

2、其他业务线校验签名，返回数据。

五、密钥管理的一些经验：

1、什么时候做数字签名？

每次接口调用都做数字签名。

2、数据加密的算法？

建议采用对称加密AES256位密钥，待加密的数据类型不同，选择不同模式，一般情况下CBC模式适合大多数场景，XTS模式适合本地存储场景。

3、如何判断一条数据是否被加密？

在系统迁移的过程中，必然出现明文和加密两种逻辑同事出现的情况，此时就需要程序判断数据是明文还是密文，建议在SDK中提供方法判断。

4、存储加密数据库索引如何处理？

基于安全的设计，相同的明文可能密文不同，因此需要建立一条不可逆并且与明文一一对应的值做索引。

5、存储加密历史数据如何处理？

第一次加密之前的历史数据，需要提前先由刷库 工具 统一将明文刷成密文，刷库时，需要先新建一列密文列，将明文列加密后刷到密文列中，之后程序写入或者更新操作时，需要对明文列、密文列双写，读取操作时只读取密文列，等程序稳定运行一段时间后，再将明文列删除。

第一次加密之后，随着密钥定期更新，不同时期的数据使用不同密钥加密。

6、密钥如何存储？

在KMS服务端，工作密钥需要加密存储于数据库中，加密存储的密钥可采用分段式密钥，通过RAID方式将不同密钥段存储于不同介质中。

7、证书如何生成下发？

证书生成下发通常有两种方式，第一种是SDK生成RSA公私钥，将RSA公钥发给CA申请证书，CA用自己的私钥签发证书后返回给SDK。第二种是直接CA生成RSA公私钥，并签发证书，并下发给SDK。这两种方式可根据实际业务需求选择。

证书是对客户端做身份识别的最重要标识，因此在第一次下发证书时，建议采用可信的第三方系统独立下发，如SRE发布系统。如果有有效且安全的手段保证客户端的合法性，可通过SDK与KMS的交互来下发证书。

8、证书如何验证，保证客户端的合法性？

证书验证需要两个步骤：

（1）验证证书的合法性，通过CA的公钥解密证书，校验签名即可验证证书的合法性、未被篡改。

（2）验证客户端持有证书对应的私钥，KMS向SDK发起challenge，向SDK发送一个随机数，SDK使用私钥加密后，返回给KMS，KMS使用证书中的公钥解密，验证SDK确实持有合法的私钥，证明SDK的合法身份。未了保证安全性，KMS发送的随机数可以做一次哈希。

9、密钥协商方式？

密钥协商可采用集中协商或者分散协商两种方式。

（1）集中协商：各个SDK分别向KMS请求密钥，KMS生成后返回给各个SDK。

（2）分散协商：假设有两个客户端A和B，A和B使用DH密钥协商算法，来协商密钥。