[Cryptech Tech] cryptlib HAL for EIM

[Rob Austein]

At Thu, 30 Apr 2015 16:13:41 +1200, Peter Gutmann wrote:
>
> ECDSA is a bit specialised since the domain parameters are fixed, you don't 
> need to generate them, so there isn't actually anything to generate.  
> Presumably the crypto hardware will do the private-point generation, since 
> that's just a string of random bits.

Ah, OK.  Yes, one would hope we can just use the TRNG if all we need
is some random bits.

> The framework has been there for over a decade, but it's never been completed 
> due to absence of any user demand.  And I don't mean "lack of demand" here, I 
> mean complete absence of it :-).  So unless there's a lot of interest in this, 
> don't plan on it being present and just use the PKCS #11-style authentication
> mechanisms.

OK, just making sure I wasn't missing something I should be doing.  Don't
change anything here on my account.

> It should be fed into the cryptlib CSPRNG.  cryptlib doesn't make any 
> assumptions about entropy sources, so it's written in an extremely paranoid 
> manner to self-check everything as it runs (it checks for things like stuck-at 
> faults, entropy quality, repeated outputs, and so on).  You can use an 
> external PRNG directly, but you're losing a lot of self-checking by bypassing 
> the CSPRNG.

Works for me.

> In terms of feeding in the TRNG data, a better way would be to register the
> device's object handle as an entropy source in slowPoll() and have cryptlib
> import data from there whenever slowPoll() is called, which avoids the need
> to have custom code in slowPoll().  I can add code to do that, there's
> already an outline there for PKCS #11 devices but it should really go into
> hw_dummy.c as well as a template.

A template for that would be great.

> So just to be clear, that's a PKCS #11 layer built on top of cryptlib
> rather than a PKCS #11 layer that cryptlib can call down to?

Yep.  Nuts, right?  Original idea was just to adapt SoftHSMv2 to run over
Cryptlib as it already does over Botan and OpenSSL, but some of the folks here
liked the general idea but really wanted our own code rather than SoftHSMv2,
not really sure why.  Eventually became clear that this approach was a poor fit
for the Cryptlib API, hence the rest of this conversation.

> Doing PKCS #11 is a huge undertaking, and would probably best be
> done as native code, i.e. an alternative API to the HAL rather than
> trying to build it on top of cryptlib.

That's pretty much the conclusion I came to recently.  I'm not sorry I tried
doing it over Cryptlib first, we didn't have any asymmetric FPGA cores when I
started this and I needed something for testing, but in the long run PKCS #11
needs to talk to the HAL directly, yes.

Am a little unclear how I'd go about reusing things like Cryptlib's RSA key
component generation while talking directly to the HAL.  No doubt I will find
a way, but if there's a preferred approach, holler.

> Another option is to take someone else's PKCS #11 code and use that
> to talk to the HAL, if you need something like that let me know and
> I can ask about availability.

Am of two minds on this: on the one hand we've sunk a fair amount of effort
into the current one, most of which should be reusable alongside the HAL; on
the other hand, the first step when one realizes that one has dug oneself into
a hole is to stop digging....

The other packages I've looked at so far were SoftHSMv2, which has already been
discussed and nixed, and the MuscleCard package (http://pkcs11.sourceforge.net)
which is really just a skeleton containing stuff that falls directly out of the
specification (guess the muscle is elsewhere).

For now I'll press on with what I have, since I understand its internals and
it's well enough along that at least a toy DNSSEC signer can produce what look
like valid RSA DNSSEC signatures with it.

> Going in at the HAL layer may be easier, that's really what a HAL is
> there for.

Yeah, I asked Paul to look at reorganizing the HAL code with an approach like
this in mind as soon as it became clear that the PKCS11-over-Cryptlib path I
was on might not work out.

> OTOH as I've mentioned doing a PKCS #11 implementation is (a) a
> fairly major undertaking and (b) not a lot of fun.

Noticed that, both.

> For PKCS #11, I'd really leave it as a version 2 thing, I realise that there's 
> a need for it but that's going to be such a big, and ongoing, job that it's 
> probably better to get something going with what's available and add the extra 
> features later.

Wish I could.

Thanks!

--Rob