On 3/20/2021 2:46 PM, SalusaSecondus wrote:
On Sat, 20 Mar 2021 17:52:00 GMT, SalusaSecondus
<github.com+829871+salusasecon...@openjdk.org> wrote:
@valeriepeng Sorry for the delay. There were unknown Windows build failure
during the pre-submit tests that I have to rebase my commits on top of the
master tip. This new revision should cover all comments you left before. Thank
you!
Mike,
From what I can find, if you try to get a spec from a non-extractable key
you'll get an `InvalidKeySpecException`.
1. `C_GetAttributeValue`will throw a `PKCS11Exception`
2. The `PKCS11Exception` gets caught in
[P11KeyFactory](https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyFactory.java#L98-L99)
which rethrows it as an `InvalidKeySpecException`.
We seem to have a choice and I'm not sure the best way to approach this.
1. We trust the properties in `P11Key` and just ask it if the values are both
sensitive and extractable. [1]
2. But if we already trust P11Key, why not also trust that it properly
implements the RSAPrivateKey interfaces [2]. This is the strategy used by the
snippet I posted earlier (delegating to `implGetSoftwareFactory()`)
3. We don't trust P11Key except to use getKeyId(), this yields the current
design where we pull the attributes every time the factory needs them.
We should probably reduce calls to `C_GetAttributeValue` as they may be very
slow. At the least they cross the JNI boundary and at worst they interact with
a slow piece of hardware (possibly over a network). The current design will
have two calls in a worst case, but is likely to have only one call the vast
majority of the time.
[1]
https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L92
[2]
https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11Key.java#L375-L406
-------------
PR: https://git.openjdk.java.net/jdk/pull/2949
Actually, the important lines are 63-66 and 365-373:
* If the components are not accessible, we use a generic class that
* only implements PrivateKey (or SecretKey). Whether the components of a
* key are extractable is automatically determined when the key object is
* created.
attributes = getAttributes(session, keyID, attributes, new
CK_ATTRIBUTE[] {
new CK_ATTRIBUTE(CKA_TOKEN),
new CK_ATTRIBUTE(CKA_SENSITIVE),
new CK_ATTRIBUTE(CKA_EXTRACTABLE),
});
if (attributes[1].getBoolean() || (attributes[2].getBoolean()
== false)) {
return new P11PrivateKey
(session, keyID, algorithm, keyLength, attributes);
}
If the key is non-extractable, then the only attributes will be these
three and the underlying type will be P11Key.P11PrivateKey rather than
one of the RSA variants.
Simple check at the top.
Mike
