[Esapi-user] store encyrptor.masterkey encrypted

Kevin W. Wall kevin.w.wall at gmail.com
Sat Jan 30 23:07:27 EST 2010

Chris Schmidt wrote:
> If the security of your filesystem is questionable, or you want a secure
> means of retrieving the configuration, the best thing I can come up with is
> to have create a keypair, and install it to the java keymanager, then store
> your master private key in a keylocker somewhere. You could then create your
> own implementation of the SecurityConfiguration Interface that stores an
> encypted properties file on disk, then use the key loaded into your JVM's
> keymanager to decrypt the properties file and load it into memory.
> Kevin might have some better ideas, but this is the first thing that comes
> to mind.

Even if you create a key pair and use the public key to encrypt something
(the DB password, the MasterKey itself, etc.), all that does is mean that
what you are left protecting is the private key. So how are you going to
protect it? You can take the usual tact and put it into a protected key store.
(PKCS#12 key store would be preferred, but even a JKS key store would suffice.)
But if you do that, how do you protect the pass phrase used to encrypt the
private key in that's encrypted in the key store? You are essentially back
were you started.

There are essentially 2 different approaches. The simplest (cheapest)
way...write your application so that an operations person must login
and then type in the pass phrase or the DB connection password or
whatever. The downside, of course, is it requires manual intervention
to restart your application.

The second is that you could store your key in a TPM or HSM instead of
a DB and obtain it from there. Most modern business laptops have TPMs,
but most server-class machines generally don't. You would have to write
some additional code, specific to your TPM or HSM  and whatever API
the provide, to obtain your key from them.  You could also read the
key from a removable USB flash drive, but then you're back to manual
intervention--to insert the USB drive when the application starts and
then remove it after the key has been read from it--because if you
leave the USB drive in, you're back to the equivalent of leaving
solely it up to the file system to protect the key.

The last way is just to use obfuscation sufficient to give you the
warm fuzzies. For example, you might generate a key pair, encrypt
it with the public key and keep the private key encrypted in a
PKCS#12 key store with some pass phrase. Then you could obfuscate
all this code, including the the pass phrase, in your application
code. One simple approach is to make your passphrase based on something
like XOR'ing two different error messages together and then base64 or
hex encode them and use that for the key store pass phrase for the
private key. Then read the private key and use it to decrypt the
master key. If you obfuscate it all with an obfuscater such as
Dash-O Pro or similar commercial obfuscater, it probably is "good
enough", but of course that all depends on your threat model. The
obfuscation is not going to be as secure as reading the key from
a TPM or HSM.

Of course, before you go through all that trouble, realize that
your other application vulnerabilities are. The bad guys seldom
go after weaknesses in crypto, unless its some well-known weakness
like WPA, etc.

Kevin W. Wall
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents."        -- Nathaniel Borenstein, co-creator of MIME

More information about the Esapi-user mailing list