密钥的安全管理通常采用层次化的保护方式，一般情况下分为三层加密（根密钥、密钥加密密钥、工作密钥）和两层加密（根密钥、工作密钥）。
三层加密密钥通常适用于以下情况：
- 根密钥的加、解密运算复杂
- 更换根密钥时，大量工作密钥的解、加密运算会造成巨大的运算开销
- 工作密钥需要频繁变更
- 工作密钥频繁变更，解、加密运算会造成巨大的运算开销
- 工作密钥数量巨大且相互独立
- 所有工作密钥都用根密钥加密，一旦根密钥被攻破则所有工作密钥均被攻破。
加密算法
| 算法 | 说明 | 防御 | 举例 |
|---|---|---|---|
| 对称加密 | A与B之间的通讯数据都用同一套密钥来进行加解密 | 机密性防御 | DES，AES， 3DES |
| 非对称加密 | 公钥加密过的东西只能通过私钥解密 | 合法性防御 | RSA, Diffie-Hellman |
| hash | 对目标信息生成特定长度的hash值，但不能还原目标信息 | 完整性防御 | MD2， MD4，MD5， SHA |
1 、密钥分层管理结构
密钥的安全管理通常采用层次化的保护方式。密钥的分层管理机制通常把密钥分为三层，即：根密钥、密钥加密密钥和工作密钥，下层的密钥为上层密钥提供加密保护。采用分层的密钥结构有助于使密钥的管理满足本规范的要求
- 工作密钥：工作密钥对本地保存的敏感数据和需要在不安全信道上传输的数据提供机密性、完整性保护，还可提供认证和签名等密码学服务。工作密钥直接被上层应用程序所使用，包括存储加密使用的密钥、预共享密钥、MAC密钥、签名私钥等。
- 密钥加密密钥：对工作密钥提供机密性保护的密钥，其自身受到根密钥的保护。对于较为简单、安全等级要求不高的密码应用系统，密钥加密密钥的职能可以直接由根密钥兼任。
- 根密钥：位于密钥管理分层结构的最底端，用于对上层密钥（如密钥加密密钥）的机密性进行保护。
规则：密钥分层管理至少选择两层结构进行管理说明: 密钥的分层管理机制最少把密钥分为两层，即：根密钥和工作密钥，根密钥为工作密钥提供加密保护。根密钥、工作密钥的生成必须满足本规范中4.1节对密钥生成的相关要求。密钥分层管理结构的选择与其应用场景有密切的关系。选择三层结构还是两层结构取决于产品所涉及的加密应用场景的复杂度。应用场景复杂的情况推荐使用三层管理结构。适合三层密管理结构的场景有：
- 根密钥更新过程产生大量的加解密运算开销
在应用系统中，如果使用根密钥直接保护工作密钥，根密钥的更新会导致所有受其加密保护的工作密钥需要全部使用更新前的根密钥解密，再重新使用更新后的根密钥加密。当工作密钥数量比较庞大时，对工作密钥的解密和加密操作将耗费大量的资源并影响系统的性能。为解决上述问题，推荐使用三层密钥管理结构，在根密钥和工作密钥之间增加一层密钥加密密钥（KEK），密钥加密密钥对工作密钥进行加密保护，根密钥则对KEK进行加密保护。当根密钥更新时，只需要解密和重新加密KEK即可，由于KEK的数量远远小于工作密钥数量，对KEK的解密和加密操作不会消耗大量资源，对系统的性能影响很小。当KEK更新时，将需要被更新的KEK和被其保护的工作密钥都保存成历史密钥信息。应用系统需要解密被历史密钥信息加密的数据时，直接使用历史密钥解密即可。 - 系统要求频繁的进行工作密钥更新
在应用系统中，如果工作密钥的更新频率很高，典型的应用场景是工作密钥作为通信密钥（可能要求每次会话都被要求使用不同的密钥）。该场景下的工作密钥更新过程通常在线进行，需要使用工作密钥的下层密钥加密保护工作密钥的传输过程。如果使用根密钥直接保护工作密钥，根密钥加密的密文会频繁的在不安全的信道上传输，并易于被攻击者截获。攻击者可以通过分析大量密文破解根密钥。虽然通过更新根密钥的方法可以有效避免上述对根密钥的攻击，但根密钥更新周期一般较长，且一般使用手动方式更新，无论采用白盒密码还是基于密钥组件的根密钥保护方案，根密钥的更新操作都较为繁琐，难以广泛的适应该应用场景的要求。为解决上述问题，推荐使用三层密钥管理结构，在根密钥和工作密钥之间增加一层密钥加密密钥（KEK），工作密钥的更新过程使用KEK保护，由于KEK的更新频率远远小于工作密钥的更新频率，KEK的更新可以使用根密钥保护。由于KEK更新周期相对较长，即使攻击者可以截获使用根密钥加密的KEK密文，获取的密文数量也非常有限，所以攻击者很难通过分析密文破解出根密钥。 - 应用系统结构复杂
如果应用系统中包含两个或者两个以上的子系统，各子系统之间的业务相互独立，每个子系统都为用户提供不同的服务。在这样的场景下，各子系统使用的密钥应该各不相同。如果不同的应用系统之间使用的工作密钥都被根密钥保护，根密钥的泄露（根密钥的泄露风险可参考“系统要求频繁的进行密钥更新”场景）将导致各子系统由密码机制保障的安全性完全失效。为解决上述问题，推荐使用三层密钥管理结构，在根密钥和工作密钥之间增加一层密钥加密密钥（KEK），为每个子系统分配各自的KEK，这样即使某一个子系统的KEK泄露，密码安全机制失效的威胁仅也限于该子系统内，不会影响其他子系统的安全性，而且由于KEK更新较为方便，当发生KEK泄露的事故后，可以通过立即更新KEK的方法将信息泄露的损失最小化。
2、密钥生命周期
一个密钥在其生命周期中会经历多种不同的状态。密钥在其生命周期的各个阶段，都应满足一些基本的安全要求，以保障自身的安全性。
| 密钥生命周期 | 由于不良设计可能导致的安全问题 |
|---|---|
| 生成 | 生成算法随机性差，导致密钥可被预测，或攻击者可以自己生成密钥。 |
| 分发 | 密钥明文分发，导致密钥存在被攻击者截获的风险。 |
| 更新 | 密钥从不更新，导致攻击者更容易获取密钥，从而能够轻易获取敏感数据的明文。 |
| 存储 | 密钥明文存储在数据库中，导致攻击者容易读取出密钥，从而能够轻易获取敏感数据的明文。 |
| 备份 | 如果重要密钥从不备份，一旦密钥丢失，将导致原有加密的数据不能解密，大大降低了系统可靠性。 |
| 销毁 | 密钥仅被普通删除，导致攻击者有可能恢复出密钥。 |
3 、密钥生命周期的安全管理[url=] 密钥的生成
密钥通常被划分成对称密钥和非对称密钥。常用的密钥生成方式包括：基于安全的随机数发生器、基于密钥导出函数、基于标准的密钥协商机制、基于安全的密钥生成工具等。利用随机数发生器、密钥导出函数、密钥协商等方式来生成密钥，均应遵循一些规则，以使产生的密钥足够安全。
1 iPSI、OpenSSL数字信封加解密接口
| 接口 | iPSI | OpenSSL |
|---|---|---|
| 加密 | CRYPT_sealInit() | EVP_SealInit() |
| CRYPT_sealUpdate() | EVP_SealUpdate() | |
| CRYPT_sealFinal() | EVP_SealFinal() | |
| 解密 | CRYPT_openInit() | EVP_OpenInit() |
| CRYPT_openUpdate() | EVP_OpenUpdate() | |
| CRYPT_openFinal() | EVP_OpenFinal() |
4、密钥须支持可更新，并明确更新周期，在一次性可编程的芯片中保存的密钥除外
工作密钥及密钥加密密钥在使用过程中，都应保证其可以更新。对于根密钥暂不要求必须支持可更新。密钥可更新才能保证密钥使用的安全，原因如下：
- 密钥使用时间越长，攻击者花费精力去破解它的诱惑也越大，这使得密钥被破解的风险也越大；
- 密钥加密的数据量越多，攻击者能够获取到密文的数据机会也越大，而对被同一个密钥加密的多个密文进行密码学分析相对比较容易，导致密钥越容易被破解；
- 如果密钥已经泄露，那么密钥被使用的时间越久，损失越大。
密钥生命周期的结构因素较多，包括：密文被攻击者进行密码分析的可能性、密钥泄露产生的连锁危害的严重程度、密钥本身的保护机制（如：访问控制）的强度、被密钥保护的敏感数据的重要程度、密钥因为某些管理原因造成泄露的可能性等。应用系统设计人员可以参考以上因素确定适当的密钥更新周期。
密钥的更新一般包括如下两种方式：
1、系统定期自动更新密钥。执行密钥更新时，系统根据密钥生成的规则，重新生成新密钥，同时使用旧密钥解密已加密的数据，并使用新生成的密钥重新加密，同时销毁旧密钥；对于加密数据量很大的场景，可以考虑保留旧密钥，用于解密旧密钥加密的数据，同时使用更新后的密钥加密新数据。此方式适用于系统可自主生成密钥的场景。
2、管理员手动更新密钥。管理员根据实际需要，触发密钥更新指令，系统接收到更新指令后，根据密钥生成规则，重新生成密钥；或者管理员利用安全的密钥生成工具，重新生成新密钥。生成新密钥后，系统利用旧密钥解密已加密的数据，并使用新密钥重新加密数据，同时销毁旧密钥；对于加密数据量很大的场景，可以考虑保留旧密钥，用于对旧数据的解密，同时使用更新后的密钥加密新数据。
