Encryption DPAPI密钥存储和恢复

鉴于即将出台的GDPR法规，我所在的公司正在考虑升级其加密算法，并对比以前多得多的数据进行加密。作为负责这项工作的人，我已经取代了旧的CAST-128加密，我说的是加密，但它更像是散列，没有盐，每次都使用AES-256生成相同的密文，并编写了迁移数据的工具。然而，加密密钥在应用程序中仍然是硬编码的，并且可以在几分钟内用反汇编程序提取

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

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

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

---

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

我看不到与GDPR的联系，但假设这只是上下文

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

见：

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