Storing encryption keys in a separate key vault

[meg23]

From sebastia...@expectit.at on November 08, 2010 03:36:40

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.
2. Pretty secure as the password is never stored anywhere
3. Unattended start up is not possible
4. Hard to implement in a really secure way
5. Saving the password in the ESAPI.properties file
6. Easy to implement and use
7. Everyone with access to the file has also access to the password
8. Saving the password in the source code
9. Easy to implement and use
10. The password is in a different file than the ESAPI.properties file so file permissions can be different for both.
11. Everyone with access to the source code or class file can gain access to the password.
12. 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.
13. Easy to implement and use
14. The password is in a different file than the ESAPI.properties file so file permissions can be different for both.
15. 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: http://code.google.com/p/owasp-esapi-java/issues/detail?id=179

[meg23]

From chrisisbeef on November 20, 2010 13:05:09

Status: Acknowledged
Owner: kevin.w.wall
Labels: -Type-Defect Type-Enhancement Milestone-Release2.1 Component-Encryptor Component-SecurityConfiguration

[meg23]

From kevin.w.wall@gmail.com on December 31, 2010 04:08:21

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.

[kwwall]

For a while now, ESAPI's Encryptor has offered encrypt() and decrypt() methods that take a SecretKey. And SecretKey's can be managed separately in a KeyStore or stored in an HSM, etc. So, while ESAPI does not directly support this, it no longer requires a single master key which it managers either. Thus in some ways, the whole point of this issue now seems moot. While it may be a "nice to have" I think this is really a low priority and I am therefore just considering closing it as a "will not fix" (or whatever the equivalent is for an enhancement request).

If anyone has any objections about closing this, please speak up now.

[jackycct]

Agreed - SecretKey should be managed separately. I think we only need to provide guidance for developer to manage it securely using KeyStore, HSM or CyberArk

[kwwall]

Changed to milestone 2.3 since 2.2.0.0 release already released without addressing this.

[kwwall]

Changing this from milestone 2.3 to 3.0. I'd like to use Hashicorp Vault for this, but I do not want to pull in more direct and transitive dependencies into ESAPI when very few ESAPI clients (probably less than 1%) use the ESAPI Encryptor.