DPAPI密钥存储与恢复

Question

鉴于即将出台的GDPR法规，我所在的公司正在考虑升级他们的加密算法，并对更多的数据进行加密。作为负责处理这一问题的人，我用AES-256取代了旧的CAST-128加密(我说加密，但更像是哈希，没有盐，每次都会产生相同的密文)，并编写了迁移数据的工具。但是，加密密钥在应用程序中仍然是硬编码的，并且可以在几分钟内用反汇编程序提取。

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

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

问题是，由于密钥将在安装时随机生成，并立即加密，甚至连我们都不会拥有它。如果客户碰巧删除此帐户、重新安装服务器操作系统或设法以其他方式丢失密钥，则数据将无法恢复。因此，在做了这么多的论述之后，这里出现了一个实际的问题：

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

Answer 1

我没有看到与探地雷达的联系，但让我们说，这只是背景。

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

请参阅：topic02

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