问题描述

如果我使用 AES (System.Security.Cryptography) 来简单地加密和解密 SQL 服务器中的 blob 或 memo 字段，那么我应该将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,...)

那么如何保护那些 AES密钥"和IV"值?

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

背景问题更多:如果他们"破解服务器并获取数据库......那么他们可能也可以访问执行加密内容的程序(它在同一台服务器上，无能为力)......如果他们"非常好，那么他们会注意到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)中设置的，因此我无法将密钥发送/检索到第二台服务器.此外，在这种特殊"情况下，我无法通过机器级或用户级 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.

优点:

• 密钥永远不会在磁盘上.
• 即使服务器已root，获取密钥也不是一件容易的事.

缺点:

• 无法自动重启.
• 您可能必须与任何处理支持的人分享密码.
• 您需要记住，存储在内存中的数据可能在某些情况下会透明地写入磁盘.

• 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" 值的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！