RFR: 8325254: CKA_TOKEN private and secret keys are not necessarily sensitive
Martin Balao
mbalao at openjdk.org
Tue Feb 6 18:24:54 UTC 2024
On Tue, 6 Feb 2024 17:09:26 GMT, Mark Powers <mpowers at openjdk.org> wrote:
>> Hi,
>>
>> May I have a review for this fix to [JDK-8325254](https://bugs.openjdk.org/browse/JDK-8325254)?
>>
>> With this change, CKA_TOKEN = true is used as an indicator of a sensitive private key (opaque) only if the token is NSS. The behavior previous to [JDK-8271566](https://bugs.openjdk.org/browse/JDK-8271566) is restored for non-NSS tokens.
>>
>> No regressions observed in jdk/sun/security/pkcs11.
>
> Your change looks good to me. It makes sense. What testing has been done?
Hi @mcpowers ,
Thanks for having a look at this proposal. I ran a regression over jdk/sun/security/pkcs11 which exercises the code with the NSS Software Token, and all 111 tests passed. In addition, I asked the people who originally reported this bug to me to do some tests to confirm that JDK-8271566 introduced an observable change in behavior for the KeyStore::getKey public API. These tests included a CKA_TOKEN = TRUE, CKA_SENSITIVE = FALSE, CKA_EXTRACTABLE = TRUE case where we could see how 8271566 made their hardware token to return an opaque key instead of one with all the information. I am personally confident about this change, which does nothing more than returning to pre-8271566 behavior for non-NSS tokens and keeping the new behavior for NSS. If someone has more hardware tokens to test, I'd appreciate any additional feedback.
Martin.-
-------------
PR Comment: https://git.openjdk.org/jdk/pull/17712#issuecomment-1930516127
More information about the security-dev
mailing list