[8] Code review request for 6263419: No way to clean the memory for a java.security.Key

[Weijun Wang]

Hi Vinnie

I don't feel comfortable to use an interface from the 
javax.security.auth package which was designed around JAAS. I am also 
not sure if it will be included in the core module in jdk9.

Also, the test seems quite unnecessary. You can add one on real classes 
after you update the key impl classes.

Thanks
Max

On 01/21/2013 07:43 PM, Vincent Ryan wrote:
>
> On 21 Jan 2013, at 10:59, Florian Weimer wrote:
>
>> On 01/17/2013 06:04 PM, Vincent Ryan wrote:
>>
>>> Please review the fix for 6263419. It introduces a mechanism to destroy
>>> the sensitive data associated with private keys and secret keys. It is
>>> a component of the JEP-166 delivery.
>>>
>>> Webrev: http://cr.openjdk.java.net/~vinnie/6263419/webrev.00/
>>>
>>> Implementers of JCE security providers can override the default method
>>> implementations in the Destroyable interface to allow applications to
>>> take advantage of this new facility. We intend to update our key
>>> implementation classes soon.
>>
>> How does this change interact with the existing approaches?  Some crypto-related classes use a finalize() method to trigger overwriting the key material.
>>
>> I'm a bit worried that this old approach extends the life time of the key material considerably (because it has to be kept around until finalizers run).  Keeping a reference to a key object just to be able to overwrite it could have the same effect.
>>
>> --
>> Florian Weimer / Red Hat Product Security Team
>
>
> Hello Florian,
>
> Depending on a finalizer is a little unpredictable so this new approach is preferred.
> I don't think it will have any detrimental impact on existing approaches. Implementers can always
> choose to destroy key material in advance of any call to its destroy() method.
>