On 9/19/2018 11:45 AM, Adam Petcher wrote:
On 9/18/2018 4:24 PM, Michael StJohns wrote:
Adam -
Basically, the JCE is all about plugging in not about the
implementations. If this is truly an EC library, I should be able to
get the benefit of your library with very minimal changes - e.g.
specifying your provider in the various getInstance() calls. As it
stands, I doubt this will end up in anyone's "must use" category
because it will break existing code.
Is this standard of being "truly an EC library" met by PKCS11
providers that don't export keys?
This is what you want to hang your hat on? If you want to implement
your code inside an HSM and follow the PKCS11 rules, feel free.
Software libraries are not hardware libraries and the mapping between
them is pretty good, but not perfect.
And to be clear, it's not the provider that doesn't export the keys -
its the underlying HSM and not for all keys. It's perfectly OK to
generate an exportable key on an HSM, but the usual default is the roach
motel model. The provider humors this reality by following the various
interface contracts and only providing a PrivateKey object for
non-exportable private keys, regardless of type.
You want folks to convince you that interoperability is a significant
problem when what we (or at least I) want is for you to convince us
that these interop breaks are warranted due to how wonderful your
approach is and that they're absolutely necessary due the secret
sauce of wonderfulness. You're not there yet.
I don't agree with this logic.
Color me surprised.
Different providers have different levels of interoperability,
No - different providers mostly provide different suites of crypto, but
build to a well-defined interface or set of interfaces. E.g. I really
don't give a damn about what you do inside your own country, but you
need to have the same type of passport as everyone else once you leave
those boundaries.
and this interoperability is a feature that requires effort to develop
and maintain. I don't want to commit myself or this community to this
effort unless I/we think it is worthwhile. Some of the proposals to
increase interoperability for this effort (e.g. subclassing
BigInteger) would require a significant amount of additional effort,
and I think this requires justification.
Implementing to a defined interface is somewhat different than
"maintaining interoperability" - at least if you do it right. AFAICT,
you're balking at providing the getS() method of the ECPrivateKey
interface because you're afraid that conversion to/from BigInteger will
leak something. Guess what... any time you border cross you leak
something. Even
moving key material from software to hardware will cause you to leak
something.
Of course, if you know of a way to have more interoperability without
reducing assurance or significantly increasing effort, I would love to
hear about it. For assurance, an important property is that the
implementation should not branch on secrets after the developer has
put it in branchless mode (by selecting the branchless provider or by
using some other interface to switch modes).
*bleah* This is not a useful discussion - you've drawn a line in the
sand without actually understanding the cost/benefit of that line. And
I gave you several approaches - simplest is to clone BigInteger and
de-branch it for the methods you need. Actually, simplest is to use the
existing BigInteger, because if the provider user is exporting the key
material, they're probably going to be putting it into a whole different
provider with "weaker" branchless protections.
As for PKCS11 - there are exportable and non-exportable private keys
(e.g. PKCS11 with an accelerator vs an HSM for example). The
exportable ones show up as ECPrivateKeys, the non-exportable ones as
PrivateKeys (and I think with an underlying type of PKCS11Key...).
So it follows the model for exportable keys. And every PKCS11
provider I've used at least has a way of IMPORTING ECPrivateKeys.
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.
