DEK、KEK工作原理及密钥存储规则相关技术咨询

先把三个核心概念的关系讲透，你之前的认知偏差本质是混淆了DEK的两种存在形态，用日常场景类比就很好懂：

• DEK（数据加密密钥）：相当于你锁私人文件柜的钥匙，直接用来锁/开你的文件（业务数据）
• KEK（密钥加密密钥）：相当于你家保险柜的钥匙，只用来锁刚才那把文件柜钥匙，从来不会直接碰你的文件
• KMS（密钥管理服务）：相当于你家专门放保险柜的独立密码柜，只有它能接触到KEK，外人碰不到

标准加密存储流程 #

你之前记的流程错了一个最关键的点：明文DEK永远不会被持久化存储，正确的存储步骤是：

1. 上传的数据分块后，系统为对应粒度的数据块（单块/整个文件/整个存储桶，依安全要求定）生成一个随机的明文DEK
2. 用明文DEK在内存中直接把数据块加密成密文
3. 把明文DEK发给KMS，KMS用自己存储的KEK加密明文DEK，得到wrapped DEK（封装后的DEK，也就是DEK的密文形态），把wrapped DEK返回给存储系统
4. 存储系统立刻把内存里的明文DEK彻底删除，只把加密好的数据块、和对应的wrapped DEK存在一起

读取数据的流程反过来：

1. 拿到数据块和旁边存的wrapped DEK
2. 把wrapped DEK发给KMS，KMS用KEK解密出明文DEK返回
3. 用明文DEK在内存里解密数据，用完立刻删明文DEK

具体问题解答 #

（1）什么是wrapped data encryption keys？它是否就是KEK？ #

wrapped DEK是被KEK加密后的DEK密文，和KEK完全是两种东西。
接着之前的类比：wrapped DEK就是锁在保险柜里的文件柜钥匙，你没有保险柜钥匙（KEK）的话，就算拿到这个锁起来的钥匙，也开不了文件柜。

（2）wrapped DEK为什么可以和数据一同存储，不需要存在KMS？ #

因为wrapped DEK本身就是加密状态，没有KEK根本解不开，就算攻击者拖走了所有存储的数据，拿到了wrapped DEK，没有KMS里的KEK，既拿不到明文DEK，也解不开业务数据，没有任何安全风险。
反而把wrapped DEK存在数据旁边效率更高：不需要在KMS里维护海量DEK和数据块的映射关系，读写数据时只需要在解封装DEK的环节调用一次KMS就行。
你之前的认知误区就在这：你以为存在数据旁边的是明文DEK，实际上存的是密文形态的wrapped DEK。

（3）KMS是否会存储业务相关数据？ #

绝对不会。KMS的职责边界非常清晰：

• 持久化存储的只有KEK，以及KEK的权限、创建时间这类元数据
• 只处理两类请求：用KEK加密DEK生成wrapped DEK、用KEK解密wrapped DEK得到明文DEK
  业务数据不管是明文还是密文，都不会被传到KMS，更不会被KMS存储。

（4）单个数据块会对应多少个DEK？是否单个数据块存在2个DEK？ #

单个数据块只会对应1个DEK，不存在两个DEK的说法。
你觉得有两个，是把同一个DEK的两种形态当成了两个不同密钥：一个是能直接加解密数据的明文形态，一个是被KEK加密后只能持久化存储的密文形态（也就是wrapped DEK），两者的密钥内容完全一致，只是能不能直接用的区别。
实际落地时为了性能，通常不会给每个数据块单独生成DEK，一般是一个文件或者一个存储桶共用一个DEK，安全粒度可以按需调整。

（5）作为用户/客户方，我们需要自行持有哪些密钥？ #

分部署模式：

• 用公有云托管KMS的常规场景：你不需要手动持有KEK，只要管好KMS的调用权限就行（比如配置哪些账号/服务能调用KMS的解密接口）；如果安全要求高，可以选择BYOK（自持密钥）模式，自己生成根KEK导入KMS，云厂商也拿不到你的KEK
• 自建加密存储体系的场景：你必须自己持有根KEK，要保证KEK和业务数据、wrapped DEK存在完全隔离的存储域，绝对不能混存
  不管哪种场景，你都不需要长期持有DEK，DEK都是加密时随机生成、用完即删的临时密钥。

（6）执行数据存储操作时，我们实际使用的是哪类密钥？ #

两个环节用的密钥不一样：

• 加密业务数据这个环节，用的是随机生成的明文DEK，这个操作在业务服务器或者存储节点的内存里完成，KEK不会接触到业务数据
• 加密DEK生成wrapped DEK的环节，用的是存在KMS内部的KEK，这个操作在KMS内部完成，明文DEK不会被KMS持久化存储

内容的提问来源于stack exchange，提问作者FlyingPenguin