0

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

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

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

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

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

4

1 回答 1

1

我没有看到与 GDPR 的联系，但可以说这只是上下文。

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

请参阅：https ://msdn.microsoft.com/en-us/library/ms995355.aspx#windataprotection-dpapi_topic02

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

于 2017-11-30T20:39:11.307 回答