Conceptual feedback on new ECC JEP

[Michael StJohns]

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.