【问题标题】:DPAPI Key Storage and RestorationDPAPI 密钥存储和恢复
【发布时间】:2017-11-29 17:18:18
【问题描述】:

鉴于即将出台的 GDPR 法规,我工作的公司正在考虑升级其加密算法并加密比以前更多的数据。作为被指定处理此问题的人,我已经用 AES-256 替换了我们旧的 CAST-128 加密(我说加密,但它更像是散列,没有盐,并且每次都产生相同的密文),并编写了工具来迁移数据。但是,加密密钥仍然在应用程序中进行硬编码,并且可以在几分钟内使用反汇编程序提取。

我们的产品是一个桌面应用程序,我们的大多数客户都在内部安装了它。他们中的大多数人还托管自己的数据库。由于他们在本地拥有整个产品,因此保护密钥似乎是一项相当艰巨的任务。

经过一番研究,我决定采用以下方法。在安装过程中,将为每位客户生成一个随机的 256 位密钥,并用于使用 AES 加密对其数据进行加密。然后,密钥本身将在用户模式下使用 DPAPI 加密,其中唯一可以访问数据的用户将是一个新创建的具有有限权限的锁定域服务帐户,该帐户无法实际登录机器。加密的密钥将存储在注册表的 ACL ed 部分中。然后,加密模块将模拟该用户来执行其功能。

问题在于,由于密钥会在安装时随机生成,并且会立即加密,因此即使我们也不会拥有它。如果客户碰巧删除了这个帐户,重新安装了服务器操作系统,或者以其他方式设法丢失了密钥,则数据将无法恢复。所以在所有的阐述之后,真正的问题来了:

我正在考虑让客户备份存储密钥的注册表,并假设即使在重新安装或删除用户之后,只要在同一台机器上使用相同的密码创建相同的用户帐户,它就会创建相同的 DPAPI 机密并能够解密密钥。但是,我不知道是否是这种情况,因为我不确定这些秘密是如何产生的。谁能确认这是否真的如此?如果您能想到更好的方法,我也愿意接受有关完全不同的密钥存储方法的建议。

【问题讨论】:

    标签: encryption dpapi key-storage


    【解决方案1】:

    我没有看到与 GDPR 的联系,但假设这只是上下文。

    它需要的不仅仅是用户帐户、密码和机器。使用 DPAPI 加密数据时添加了更多熵。

    见:https://msdn.microsoft.com/en-us/library/ms995355.aspx#windataprotection-dpapi_topic02

    使用登录密码的一个小缺点是所有应用程序 在同一用户下运行可以访问任何受保护的数据,他们 知道关于。当然,因为应用程序必须存储自己的 受保护的数据,访问数据可能有些困难 对于其他应用程序,但肯定不是不可能的。抵消 这一点,DPAPI 允许应用程序在 保护数据。然后需要这个额外的秘密来解除保护 数据。从技术上讲,这个“秘密”应该被称为次要的 熵。它是次要的,因为虽然它不会加强关键 用于加密数据,确实增加了一个难度 应用程序,在同一用户下运行,以危害另一个 应用程序的加密密钥。应用程序应注意如何 他们使用和存储这个熵。如果它只是保存到一个文件 不受保护,然后攻击者可以访问熵并使用它来 取消保护应用程序的数据。此外,该应用程序可以 传入一个数据结构,DPAPI 将使用该数据结构来提示 用户。这种“提示结构”允许用户指定一个额外的 此特定数据的密码。我们进一步讨论这个结构 在使用 DPAPI 部分。

    【讨论】:

      猜你喜欢
      • 2013-02-09
      • 1970-01-01
      • 2021-07-26
      • 1970-01-01
      • 1970-01-01
      • 2011-01-03
      • 2010-12-29
      • 2019-08-13
      • 2013-10-30
      相关资源
      最近更新 更多