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

问题描述

如果我使用AES（System.Security.Cryptography）简单地加密和解密在SQL Server BLOB或备注字段，然后我在哪里存储在服务器上的关键和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,...)

和什么与AES的保护重点和IV的价值观？

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

背景问题是更多：如果他们黑客服务器，并得到了质数据库......那么很可能他们可以得到那些加密的东西还计划（这是在同一台服务器上，不能帮助它） ...如果他们都非常好，那么他们会发现这里的重点和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.

请指教？你如何处理所有AES键和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.

这一切都是建立在一个单一的服务器环境（应用程序加质数据库），所以我不能够发送/检索的关键在于第二个服务器。此外，在该特殊的情况下，我不能够通过一个机器级或用户级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，利用因任何windows的帐号您（或您的应用程序）的密码的API下安全地存储数据的运行。只有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的一个特别好的特性是，如果管理员（通过计算机管理）重置一个用户的密码，<一个href="http://stackoverflow.com/questions/4755851/protecteddata-unprotect-dpapi-stops-working-after-password-change">access以用户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“键”和“IV”的值的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！