JDK-6263419 : No way to clean the memory for a java.security.Key
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: java.security
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2005-04-29
  • Updated: 2019-07-24
  • Resolved: 2013-01-22
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8 b75Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
A DESCRIPTION OF THE REQUEST :
Many implementations of java.security.Key contain sensitive data. After using an Object with sensitive data the application might wish to not only free the Object, but also to wipe-out its memory so that the sensitive data is no longer present in memory.

The java.security.Key interface should have a dispose() method that erases the sensitive information from memory.



JUSTIFICATION :
Without this feature, once you've created a Key, you can never be sure of erasing its memory. The getEncoded() method returns a copy so zeroing that isn't useful.

This is especially important for applications running on time-sharing systems or in kiosks where the odds of another user accessing your process's memory become much greater.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
A dispose() method to zero out the key's data.

CUSTOMER SUBMITTED WORKAROUND :
I guess we could rewrite all of the JDK's impls for Key to include a dispose method (although this is nasty).

Workaround at  http://forum.java.sun.com/thread.jspa?threadID=608196
************************************************************************
byte[] keyMaterial = new byte[32];
Random rand = new SecureRandom();
rand.nextBytes (keyMaterial); // generating a random key
Key secretKey = new SecretKeySpec (keyMaterial, "AES"); // creating a key from the key material

Try to erase the underlying key material (Arrays.fill (keyMaterial, (byte)0), but it does not affect the Key.
*****************************************************************************
it says that it doesn't always work. Furhermore, the workaround is also clearly out of spec (ie: the Key impl could copy the key material at creation or later on in the Key's lifespan or could even keep multiple copies of the key material around (I know, nasty but allowed by spec)).

###@###.### 2005-05-02 12:38:42 GMT

Comments
Addess this requirement by enhancing java.security.PrivateKey and javax.crypto.SecretKey classes to extend the javax.security.auth.Destroyable interface.
17-01-2013

SUGGESTED FIX ###@###.### 2005-05-02 12:38:42 GMT
02-05-2005

EVALUATION There are generally two kinds of "software" key objects: 1. sensitive internal info represented as java.math.BigInteger 2. sensitive internal info represented as byte arrays BigIntegers are immutable (as currently defined). There is no way to clear that memory. We would have to add a 'destroy' method to BigInteger to make that happen (see 5061398). We could clear byte arrays. In fact, javax.security.auth.kerberos.KerberosKey already provides a 'destroy' method to do just this. javax.crypto.spec.SecretKeySpec does not, but theoretically could. In either case, clearing out a BigInteger or byte[] reference doesn't guarantee that the sensitive information is gone from memory. The operating system's virtual memory may have been swapped to disk, for example, leaving a copy on the local hard drive. In addition, the Java runtime VM may itself have multiple internal copies of the information. Although such copies are likely to be overwritten at some point in time, users can not be assured that it will ever happen (nor when it would happen if it does). Therefore there is no straightforward solution to this problem. Simple 'destroy' methods are a possible first step, but don't solve the problem. To truly guarantee that sensitive key material remains fully protected, users should rely on secure tokens like PKCS#11 devices (smartcards, for example). In that case, the key material never leaves the token. ###@###.### 2005-04-29 21:07:07 GMT
29-04-2005