Storing encryption keys in a separate key vault

[GoogleCodeExporter]

In the current ESAPI implementation, a central encryption key is generated by 
the JavaEncryptor command line tool and stored in plain in the esapi.properties 
file:

# To calculate these values, you can run:
#       java -classpath esapi.jar org.owasp.esapi.reference.crypto.JavaEncryptor
#
#Encryptor.MasterKey=

This leaves users with the problem that they cannot separate key management 
from managing the ESAPI configuration. So there might be too many people with 
access to this key.

A solution would be to store the key in the key store built into the JVM,
see:

http://download.oracle.com/javase/6/docs/api/java/security/KeyStore.html

This way, users could manage the keys with tools that they are already familiar 
with, users could implement their own key store implementation
or that of third party products they use.

The remaining problem is how to store and retrieve the key store password in a 
secure way (currently, everyone with access to the ESAPI.properties file has 
also unrestricted access to the key).

There are various options to do this. Here is an incomplete list:

1. Having users enter the password during start up.
+ Pretty secure as the password is never stored anywhere
- Unattended start up is not possible
- Hard to implement in a really secure way

2. Saving the password in the ESAPI.properties file
+ Easy to implement and use
- Everyone with access to the file has also access to the password

2. Saving the password in the source code
+ Easy to implement and use
+ The password is in a different file than the ESAPI.properties file
  so file permissions can be different for both.
- Everyone with access to the source code or class file
  can gain access to the password.

3. Saving the password in a separate file using a stashing algorithm
A stashing algorithm hides a password in a file with random data.
So the mechanism is pretty similar to steganography. An attacker has to know 
the algorithm to determine the password.
+ Easy to implement and use
+ The password is in a different file than the ESAPI.properties file
  so file permissions can be different for both.
- Obscuring the password makes it harder for an attacker to find the
  password. Depending of the experience of the hacker,
  it might not be too challenging thought.

Another, more radical change would be to delegate encryption and key management 
to a different application which could also reside on
a different server/appliance.
In this scenario, only the keys for the communication between the web server 
and this application would be stored on the web server.

+ Key management and encryption of stored data is separated from
  web servers so only the keys for communication need to be revoked
  if a web server gets compromised.
+ In depth separation of duties: Only people authorized
  to access the crypto application would have access to the keys.
- Initial installation and configuration is more work than
  using the other options. Adding new web servers to use the application
  is very easy though.
- Crypto application can leak keys due to implementation failures
  (see Bruce Schneier et al.: Practical cryptography). This
  could be mitigated by tokenization in some cases.
  With tokenization, you only get a token instead of
  the encrypted document. When you send this token back to
  the crypto application, you get the decrypted document.

Original issue reported on code.google.com by sebastia...@expectit.at on 8 Nov 2010 at 8:36

[GoogleCodeExporter]

Original comment by chrisisbeef on 20 Nov 2010 at 9:05

• Changed state: Acknowledged
• Added labels: Component-Encryptor, Component-SecurityConfiguration, Milestone-Release2.1, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

IMHO, this is more likely to be an enhancement for release 2.2 (or perhaps 3.0) 
unless we can find a suitable FOSS key management system to use. There are not 
very many that I've found. This is discussed in more detail in section 4.2 of 
the "Design Goals in OWASP ESAPI Cryptography" document included with the ESAPI 
documentation.

Original comment by kevin.w.wall@gmail.com on 31 Dec 2010 at 12:08