On 9/19/2018 12:51 PM, Michael StJohns wrote:
On 9/19/2018 11:45 AM, Adam Petcher wrote:
My goal is for the new provider to be at least as interoperable as
PKCS11 providers with non-exportable keys. Do all the PKCS11
providers that you have used allow importing private keys over JCA,
or over some other API? Do you have to put the HSM in some sort of
"import mode" in order for this import to be allowed? Is there any
difference in the way that you can use keys that were loaded over
this API vs keys that were generated on the device (or loaded securely)?
Again - you seriously want to hang your hat on this?:
1) Yes. Over the JCA. (Umm.. PKCS11 provider is a JCA/JCE provider
so of course this works).
2) No. In fact, the store operation of the PKCS11 keystore
implementation does this just fine.
3) Depends. If you generate or load the HSM PKCS11 keys according to
the JCA PKCS11 guidance (e.g. with the right set of attributes) using
a direct PKCS11 driver, then it's seamless. Otherwise, the Sun PKCS11
keystore implementation mostly ignores them as it can't map them
properly. I'd need to check the other two providers I'm aware of,
but I think they implement the same scheme as the Sun provider.
There's also a scheme for twiddling the attributes as part of the
provider configuration, but that's a bit more painful.
See
https://docs.oracle.com/javase/7/docs/technotes/guides/security/p11guide.html
and Appendix B.
Thanks for the information. I'm having trouble believing that there is
no situation in which a PKCS11 provider/token/HSM would reject a key
that it is asked to import. But this is mostly a detour in the
discussion. If the API of the new ECC implementation is, in some ways,
more restrictive than PKCS11 with non-extractable keys, then that is
acceptable to me.
