如何安全地处理AES“Key”和“IV”值 [英] How to securely handle AES “Key” and “IV” values

问题描述

如果我使用AES（System.Security.Cryptography）简单地加密和解密SQL服务器中的blob或备注字段，那么在哪里可以将Key和IV值存储在服务器上？ （文件，Regkey，Dbase，...）

If I use AES (System.Security.Cryptography) to simply encrypt and decrypt blob or memo fields in a SQL server, then where do I store the "Key" and "IV" values on the server? (File, Regkey, Dbase,...)

还有那些AESKey和IV值的保护？

And what with the protection of those AES "Key" and "IV" values?

背景问题更多的是：如果他们破解服务器并获取dbase ...那么可能他们可以得到加密的东西的程序（它在同一个服务器上，可以如果他们非常好，那么他们会注意到Key和IV值被存储在哪里...（。NET 4.5 ILSPY），并且所有内容都可以被解密。

The background question is more : If "they" hack the server and get the dbase... then probably they can get to the program that do the encryption stuff also (It's on the same server, can't help it)... and if "they" are very good, then they will notice where the "Key" and "IV" values are stored...(.NET 4.5 ILSPY) and everything can be decrypted again.

请咨询？您如何处理AESKey和IV值？

Please advice? How do you all handle AES "Key" and "IV" value’s?

Ps：这不是关于pwd字段...所以，这不是关于哈希...它的纯数据加密。

Ps: This is not about pwd fields... so, it's not about hashing... its pure data cryptography.

推荐答案

IV已被其他答案彻底涵盖，所以我将专注于存储

The IV has been thoroughly covered by the other answers, so I'll focus just on storing the key.

首先...

除了它可以不能在软件级别的单个服务器上完成。

I can't except it could not be done on a single server at software level.

软件中完成的任何操作都可以在软件中撤销。您可以加密，隐藏和锁定尽可能多的保险箱，但您的应用程序仍然需要能够访问密钥。如果您的应用程序可以访问，那么与您的应用程序具有相同级别访问权限的用户也可以访问。

Anything done in software can be undone in software. You can encrypt, hide, and lock it in as many safes as you want, but your application still needs to be able to get access to the key. If your application has access, then someone with the same level of access as your application is able to get to it as well.

开发人员一直在处理此问题很长时间没有银弹。

Developers have been dealing with this problem for a very long time and there is no silver bullet.

这一切都是在单一的服务器环境（应用程序加dbase）中设置的，所以我' m无法将密钥发送/检索到第二个服务器。另外，在这种特殊情况下，我无法使用机器级别或用户级别的RSA密钥容器加密密钥。

This all is setup in a single server environment (application plus dbase), so I’m not able to send/retrieve the key to a second server. Also, in this "special" case I’m not able to encrypt the key by a machine-level or user-level RSA key container.

I can think of two possible solutions.

选项1：

将密钥存储在磁盘上，并在操作系统级别配置文件访问，以便只有您的应用程序运行的帐户才能读取该密钥所在的文件。该文件可能是一个平面文件或受保护的加密容器通过您的应用程序知道的密码（由您决定，但加密的容器更好）。

Store the key on disk and, at the OS level, configure file access so that only the account your application is running under can read the file the key is contained in. The file could be a flat file, or an encrypted container that's protected by a password which your application knows (up to you to decide, but an encrypted container is better).

优点：

• 无需人为干预即可重新启动。

缺点：

• 您必须执行操作系统安全性，没有任何错误的余地。


• 具有管理员权限的攻击者可以获得密钥。

另一个类似的选项是使用 DPAPI ，而不是用于存储密钥的文件（只要您能够为您提供特殊情况即可） ）。这是一个内置于Windows的API，它利用您（或您的应用程序）运行的任何Windows帐户的密码来安全地存储数据。只有存储数据的Windows帐户能够检索它。

Another similar option to this would be to use DPAPI instead of files for storing the key (as long as you're able to do this given your "special case"). This is an API built in to windows that utilizes the password for whatever windows account you (or your application) is running under to securely store data. Only the windows account that stored the data is able to retrieve it.

DPAPI的一个特别好的功能是，如果管理员重置用户密码（通过计算机管理），对该用户的访问DPAPI数据丢失。攻击者需要首先妥协用于存储数据的实际帐户，而无需重置密码。

One particularly nice feature of DPAPI is that, if an administrator resets a users password (via computer management), access to that users DPAPI data is lost. An attacker would need to compromise the actual account that was used to store the data in the first place without resetting the password.

选项2：

要求在应用程序启动时由人员输入密码，并从该密码中导出加密密钥。一旦你有钥匙，丢弃密码并保留内存中的密钥。

Require that a pass phrase be entered by a person at application start up and derive an encryption key from that pass phrase. Once you have the key, discard the pass phrase and retain the key in memory only.

优点：

• 密钥从不在磁盘上。


• 即使服务器已经扎根，获取密钥也不是一件简单的任务。

缺点：

• 无法自动重新启动。


• 您可能需要与处理支持的任何人分享密码。


• 您需要记住，存储在内存中的数据可能在某些情况下透明地写入磁盘。

• Automated reboots are not possible.
• You'll likely have to share the pass phrase with anyone handling support.
• You need to keep in mind that data stored in memory may transparently be written to disk in certain situations.

或者您可以在这两个系统之间进行妥协，其中，密码最初是用于导出保存在内存中的加密密钥，并且每当应用程序正常重新启动时，密钥临时写入磁盘或加密容器。当重新启动完成后，应用程序加载密钥，然后将其从临时存储中删除（如有必要，请务必覆盖存储密钥的磁盘位置，以使其无法恢复）。

Or you could do a compromise between these two systems where, a pass phrase is initially used to derive the encryption key which is held in memory, and the key is temporarily written to disk or encrypted container whenever the application is gracefully restarted. When the restart is complete the application loads the key and then deletes it from temporary storage (and if necessary, be sure to overwrite the disk location where the key was stored so that it can't be recovered).

这篇关于如何安全地处理AES“Key”和“IV”值的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！