数据加密键和密钥加密键
我希望有人可以帮助我了解DEK和KEK在外行期间的工作方式。
这是我到目前为止的理解
第1部分 上传的数据存储在块中。每个块都用DEK加密。 DEK存储在块状数据附近。
第2部分数据块用kek包裹
第3部分 kek存储在kms中。
Google课程材料的这句话确实使我绊倒了。
随后将包含的数据加密密钥与此数据一起存储
我的大脑对这些问题感到疯狂：
- 这个包装的数据加密密钥是什么？那不是第2部分中的kek吗？
- 如果那是第2部分中的kek，那不应该在公里吗？
- 如果是，KMS会存储数据吗？
- 如果没有，则有多少数据数据？ 2迪克斯？
- 我们（用户/客户）保留哪些键？
- 我们将数据存储在哪个键？
I hope someone can help me to understand how DEK and KEK works in layman term.
This is my understanding so far
Part 1
Uploaded data is stored in chunks. Each chunk is encrypted with DEK. DEK is stored near the chunked data.
Part 2 DEK of the data chunk is wrapped with KEK
Part 3 KEK is stored in KMS.
This sentence from a Google's course material really tripped me.
The wrapped data encryption keys are then stored with this data
My brain goes crazy with these questions:
- What is this wrapped data encryption keys? Isn't that the KEK in part 2?
- If that's the KEK in part 2, shouldn't that be in KMS?
- If yes, does KMS store data?
- If no, how many DEKs a chunk of data has? 2 DEKs?
- What keys do we(users/customers)keep?
- We store the data with which keys?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
包裹的DEK是用KEK加密磁盘的结果。之所以称其为密钥加密密钥，是因为它加密（数据加密）键。
否。顾名思义，钥匙管理系统仅存储密钥，特别是Keks。
一。数据仅加密一次，因此只有一个密钥。
只有kek。当使用KMS时，即使您知道该键，即KMS的用户。
用包裹的碎片。
这是一个具体示例：
数据（即明文）：
黄色潜艇kek（又名主键）：
my-Secret-Masterdek（每片数据随机生成）：
ttlly-random-dekciphertext：base64（aes（data，dek））=
tj4slfty0smdvge55qcuyq ==包装dek：base64（aes（dek，kek））=
loemql1jusonz8ulorc/vq ==第二个操作是由kms完成的，如果有一个（必须是，因为它是唯一的一个）拥有Kek，它永远不会透露它）。
您一起存储的内容：
tj4slfty0smdvge55qcuyq ==和loemql1jusonz8ulorc/vq ==。并重建给定
tj4slfty0smdvge55qcuyq ==+loemql1jusonz8ulorc/vq ==：dek：aes'（base64'（
loeemql1jusonz8ulorc/vq = q q q q q q q q q q Q = Q Q Q Q Q Q Q Q Q Q q Q = Q Q Q Q Q Q Q Q q Q = QQ = q q q Q = Q = Q = Q = =）很多），kek）// =ttlly-random-dek合制：aes'（base64'（tj4slfty0smdvge55qcuyq ==），dek），第一个操作是在第一个操作的情况下完成的。有一个（同样，必须是，因为涉及kek）。
在上面的示例中，我方便地选择了16个数据和16个字节键，因此我可以掩盖密码模式和IVS/Nonces。当然，在实际应用中，每个加密的IV也必须保留。
请注意，KMS永远不会看到您的数据，只需要加密和解密很少的数量即可。这就是为什么我们做所有这一切的原因；只有您，数据的所有者才以明确的方式看到它（显然是KMS是一个诚实的政党）。
The wrapped DEK is the result of encrypting the DEK with the KEK. The key encryption key is called that because it encrypts (data encryption) keys.
No. As the name suggests, a key management system only stores keys, and specifically KEKs.
One. Data is encrypted only once, so there is only one key.
Only the KEK. When using a KMS, not even that key is known to you, the user of the KMS.
With the wrapped DEK.
Here is a concrete example:
Data (i.e. plaintext):
yellow submarineKEK (aka. master key):
my-secret-masterDEK (randomly generated for each piece of data):
ttlly-random-dekCiphertext: Base64(AES(Data, DEK)) =
TJ4SLFTy0sMdvGe55QCuYQ==Wrapped DEK: Base64(AES(DEK, KEK)) =
lOEmql1JuSONZ8uLorc/vQ==The second operation is done by the KMS, if there is one (it has to be, because it's the only one in possession of the KEK, and it will never disclose it).
What you store together:
TJ4SLFTy0sMdvGe55QCuYQ==andlOEmql1JuSONZ8uLorc/vQ==.And to reconstruct the plaintext given
TJ4SLFTy0sMdvGe55QCuYQ==+lOEmql1JuSONZ8uLorc/vQ==:DEK: AES'(Base64'(
lOEmql1JuSONZ8uLorc/vQ==), KEK) // =ttlly-random-dekPlaintext: AES'(Base64'(TJ4SLFTy0sMdvGe55QCuYQ==), DEK)The first operation is done by the KMS if there is one (again, it has to be, because the KEK is involved).
In the example above I conveniently chose 16 bytes of data and 16-byte keys, so I could gloss over block cipher modes and IVs/nonces. In practical applications the IVs for each encryption have to be retained as well, of course.
Note that the KMS never sees your data, and it only has to encrypt and decrypt tiny amounts. That is why we do all of this; only you, the owner of the data ever sees it in plaintext (assuming the KMS is an honest party, obviously).