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

[Vincent Ryan]

FYI javax.security.auth is in the base/compact1 module.

On 22/01/2013 00:54, Weijun Wang wrote:
> 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.
>>