Encryption Key Storage

I posted this in the Microsoft Crypto group, but didn't get a response.
This group may be better suited anyway....

I know this has been discussed before, but I have not been able to find
a good solution or explanation of how an encryption key should be
stored. Here is my scenario:

1.) This is a web app.
2.) The web servers are in the DMZ.
3.) The SQL Servers are secured.
4.) Sensitive information is stored encrypted in the db
5.) Sensitive information needs to be decrypted as well and used/shown
via web servers.
6.) There is an encryption/decryption dll on the web servers.

I know storing the encryption key on disk, in the registry, or in the
code is frowned upon because this basically allows a hacker that has
made it onto the server be able to use the key and any encrypted data
he can find at a later date.

So, what can be done? The encryption key could be stored on the
secured db server and the encryption dll could just get it via a file
share, but wouldn't the hacker be able to look at "the wire" and see
what the key is?

We are trying to become PCI/CISP compliant, our first audit was last
week and the auditor did NOT like the fact that our encryption key was
compiled into the code.

Any ideas for making the key more secure in a situation where human
intervention is bad?

Thanks,
Micky

Re: Encryption Key Storage

>>>>> "MickyM" == MickyM writes:

MickyM> I know storing the encryption key on disk, in the
MickyM> registry, or in the code is frowned upon because this
MickyM> basically allows a hacker that has made it onto the server
MickyM> be able to use the key and any encrypted data he can find
MickyM> at a later date.

MickyM> Any ideas for making the key more secure in a situation
MickyM> where human intervention is bad?

Aye, there's the rub. The best way I know to secure this is (1) to
prompt for the key interactively at server (or web service) startup,
(2) to obfuscate the location of the key in memory, and (3) to ensure
that the memory locations containing the key are never swapped out to
disk.

Consider the following (ordered in terms of increasing paranoia and
attack sophistication):

I assume you are using a modern version of Windows and IIS. Let's say
you store the decryption key in a file on the server, with permissions
such that only the web service account (e.g. IUSR_* or IWAM_*) can
read it. If an attacker can get a program to run in the security
context of the web service (e.g. by injecting code through the use of
a buffer or heap overflow, or by uploading a script that will be
executed by the web service), the attacker can access that file.

Since the decryption key must be stored somewhere in memory, a savvy
attacker could try to walk through the web service's address space and
read the decryption key straight out of process's memory. If I recall
correctly, there are a variety of techniques available to hide this
location from an attacker. Ultimately, the attacker will find the
key, so all this does is buy you time to detect and interrupt a
successful web server compromise.

If the memory location(s) containing the decryption key are swapped
out to disk, the attacker could merely examine the contents of
pagefile.sys in order to retrieve the key. Windows can be configured
to clear the contents of this file when it shuts down. This should be
enabled on specially hardened servers (like the web server you
describe). Be aware that it will make rebooting the server take a
much longer time than normal.

An attacker with physical access to the server can bypass the page
file clearing process by interrupting the normal operating system
shutdown process, e.g. by pulling a mirrored drive, by powering down
the server, etc.

An attacker with administrative access (e.g. by exploiting a privilege
escalation flaw, or perhaps a trusted insider) will have a much easier
time with all of these attacks. Unless activity on your web servers
is being monitored very closely, attacks on your decryption keys that
leverage elevated privileges may be much harder to detect because
access is simpler and faster (i.e. the attack can execute faster than
you as a defender can react).

There are probably other interesting failure modes that could be
exploited by an attacker.

Best wishes,
Matthew

--
jsoffron: I'm generally pretty high on national defense...
Mr. Bad Example: Careful...it's a gateway policy. Before you know it,
you'll be mainlining the hard stuff like trade agreements.
jsoffron: Too late...I've been freebasing Nafta all day... Sweet,
sweet NAFTA.
- As seen on Slashdot

Re: Encryption Key Storage

MickyM wrote:
> Any ideas for making the key more secure in a situation where human
> intervention is bad?

The box where the private keys are, has to be scure. I see no other way.

Yours,
VB.
--
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
Harald Schmidt zum "Weltjugendtag"

Re: Encryption Key Storage

MickyM wrote:


> I know this has been discussed before, but I have not been able to find
> a good solution or explanation of how an encryption key should be
> stored.

Use a HSM (Hardware Security Module).
These things are built for that.
Some models can do SSL-acceleration as well.

Examples:
IBM 4758
Utimaco CryptoServer 2000
nCipher nShield
Rainbow CryptoSwift
etc.