【问题标题】:Deterministic encryption using AWS KMS使用 AWS KMS 的确定性加密
【发布时间】:2020-06-08 10:39:00
【问题描述】:

我需要构建一个身份服务,该服务使用客户提供的密钥来加密敏感 ID 值以存储在 RDS 中,但还必须允许我们稍后使用明文 ID 查找记录。我们想为此使用一个简单的确定性加密算法,但看起来 KMS API 不允许您指定 IV,因此您永远无法获得相同的明文来加密两次相同的值。

我们还需要使用另一个非安全值查找数据并检索加密的安全值并对其进行解密 - 所以单向哈希很遗憾无法工作。

总之,这意味着我们将无法执行安全 ID 的查找,除非暴力遍历所有记录并解密它们并与明文值进行比较,而不是简单地使用已知的加密明文搜索值IV 并使用该加密值作为索引来查找数据库中的匹配记录。

我猜这是对 SSN 之类的东西非常普遍的要求,那么人们如何解决它?

提前致谢。

【问题讨论】:

    标签: amazon-web-services encryption aws-kms


    【解决方案1】:

    稍后使用明文 ID 查找记录

    那么您将失去相当多的安全性。也许您可以在加密数据中存储 ID 的哈希(例如 sha-256),这样可以更轻松地查找记录,但不会恢复值

    这种方法假设 ID 来自相当大的消息空间(可能有很多 ID),因此为每个可能的值创建映射是不可行的

    KMS API 不允许您指定 IV,因此您永远无法获得相同的明文来加密两次相同的值。

    是的,KMS 似乎为执行良好安全实践的密文提供了自己的 IV

    【讨论】:

    • 本质上,这是一个数据转换管道,我们在其中输入带有敏感 ID 的明文文件,我们希望对其进行标记/替换,然后使用标记化的 ID 执行许多不同的处理步骤(以便日志记录和步骤之间发送的数据集根本没有敏感 ID),然后在输出步骤中重新插入敏感 ID(如果需要)。散列与加密结合将是一种解决方案,但我什至看不到使用 KMS 密钥对数据进行通用 SHA 散列的方法。总体而言,功能似乎非常有限。
    • @MikeB 您可以创建一个普通的加密哈希(不需要 KMS)。 KMS 可用于加密存储的原始 ID,直到处理完其余数据。
    • 是的 - 谢谢 - 这正是我们最终所做的,使用 pgencrypt 扩展使其变得简单
    【解决方案2】:

    如果我正确理解您的用例,您的流程是这样的:

    1. 客户提供密钥 K,您使用此密钥加密密钥 S,该密钥与关联 ID 一起存储在 RDS 中。
    2. 给定一个非秘密密钥 K,您希望能够查找 S 并对其进行解密。

    如果客户重复使用密钥,这实际上并不难完成。

    1. 为客户创建 KMS 密钥。

    2. 使用此 KMS 密钥加密客户的 IV 和客户指定的密钥,并将它们存储在 Amazon Secrets Manager - 最好由客户以某种方式命名。像这样的 Json 结构:

      { "iv": "somerandomivvalue", “key”:“somerandomkey” }

      将允许您轻松解析出值。 ASM 还允许您无缝地执行密钥轮换——这真是太棒了。

    3. 如果您是偏执狂,您可以借此获取客户名称(或其他名称)和命名空间的加密哈希。

    4. RDS 现在将客户的数字 ID、不安全值和命名空间值(或某种派生位置的方法)存储在 ASM 中。

    5. 不用说,您需要限制对 Secrets Manager 保险库的访问。

    使用解决方案:

    1. 客户发出读取安全值的请求。
    2. 服务访问 ASM 并为客户解密密钥。
    3. 服务提取 IV 和密钥
    4. 服务使用 IV 和密钥初始化密码方案并解密客户数据。

    优势:您可以使用您完全控制的 KMS 密钥加密和解密 ASM 中的秘密值,并且您可以存储和恢复以安全方式解密客户值所需的任何状态。

    其他人可能会有更好的加密解决方案,但这应该是第一次尝试。

    【讨论】:

    • 我们考虑过做这件事,尽管你已经用命名空间的想法更彻底地充实了它。缺点是它将客户端密钥暴露给我们的客户端 lambda 代码 - 我们希望将所有加密操作安全地保持在 KMS 的范围内,但我想这根本不可能,因为没有办法为 KMS 指定 IV甚至没有任何数据散列操作,这将是我们的替代方案 - 让 KMS 为一列加密并为查找列散列。考虑到 AWS 的成熟度,我一直认为这必须以安全的方式解决。
    【解决方案3】:

    最后,我们决定继续使用 KMS 对客户提供的敏感 ID 列的密钥加密/解密,同时启用 PostgreSQL pgcrypt 扩展来为查找提供安全散列。所以除了我们的加密列之外,我们添加了一个 id_hash 列,我们对表进行如下操作:

    `INSERT INTO employee VALUES ..., id_hash = ENCODE(HMAC('SENSITIVE_ID+SECRET_SALT', 'SECRET_PASSPHRASE', 'sha256'), 'hex');

    SELECT FROM employee WHERE division_id = ??? AND id_hash = ENCODE(HMAC('SENSITIVE_ID+SECRET_SALT', 'SECRET_PASSPHRASE', 'sha256'), 'hex');`

    我们本可以在客户端完成散列,但由于算法是以后查找的关键,我们喜欢让数据库为我们执行散列的简单性。

    希望这对寻找解决方案的其他人有用。

    【讨论】:

    • 是的,这就是我回答的意图。但是 - 请注意 - 加密哈希被设计为抗冲突,但不能在数学上保证它是唯一的。如果您使用受监管和审计的数据(例如付款、健康记录),您可能需要检查并确保或处理没有重复数据
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2020-02-12
    • 2023-03-10
    • 1970-01-01
    • 2020-11-26
    • 2018-08-03
    • 2016-12-20
    • 2019-07-24
    相关资源
    最近更新 更多