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.


Reply via email to