-
Enhancement
-
Resolution: Fixed
-
P3
-
8
-
b75
-
x86
-
windows_xp
-
Verified
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
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
- relates to
-
JDK-5061398 RFE: BigInteger is immutable
-
- Closed
-
-
JDK-8158689 java.security.KeyPair should implement Destroyable
-
- Closed
-
-
JDK-8228419 Default implementation of Destroyable.destroy should not throw exception
-
- Closed
-