[Cryptech Tech] cryptlib HAL for EIM

[Peter Gutmann]

Rob Austein <sra at hactrn.net> writes:

I'm going to answer this in two parts.  The simple stuff comes first.

>- I noticed that generatePKComponents() only supports RSA and the DLP
>  algorithms.  Given the overall structure of the code, I suspect that
>  adding ECDSA would be no big deal.  If this is correct, having ECDSA
>  key generation support would be useful, because we expect that to be
>  our second public key algorithm.

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.

>- Also in device/hardware.c, it would (probably) be useful to have a
>  call-out to device/hw_dummy.c for the PIN handling code (right now
>  it seems to assume that direct hardware doesn't use PINs).  I'm fine
>  with having to enable a compile time option to get this if that
>  approach simplifies anything for you.

Yeah, so far all the crypto devices have been crypto IP cores integrated into 
ASICs so there's no concept of PINs or access control. I can add some glue 
code to pass a PIN call down to hw_dummy.c.

>- What's the status of the "user" support in the new version of
>  Cryptlib?  I confess to having gotten a little confused between the
>  CRYPT_DEVINFO_AUTHENT_* device attributes, the various CRYPT_USER
>  arguments, and the 3.4.2 manual's statement that most of this was a
>  placeholder for some future release.

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.

>- Last, I've been unsure about how I should handle random numbers.  As
>  you no doubt already know, we have this TRNG core with hardware
>  entropy sources and all that, and the folks who have been focusing
>  on it seem pretty happy with their results.  Cryptlib, of course,
>  has its own CSPRNG.  It has not been clear to me whether our
>  hardware TRNG should just be an input to the Cryptlib CSPRNG or
>  should replace it entirely in our case.
 
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.
 
>  What I've done so far is just write something that uses the Cryptech
>  TRNG as the sole entropy source for the Cryptlib CSPRNG (ie, I
>  implemented fastPoll() and slowPoll() in terms of the Cryptech TRNG,
>  and tweaked the build to use that instead of random/unix.c).

Yeah, that would work.  Given that you can never have too many sources, if 
there's anything else present to draw entropy from (even low-useful stuff like 
a system clock), that'd be useful to retain.  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.

>I haven't spent as much time working on the HAL code as I would have liked 
>because I somehow got tasked with writing a PKCS #11 implementation...

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?

>So my first attempt, which you can see at:
>
>  https://wiki.cryptech.is/browser/user/sra/pkcs11/pkcs11.c
>
>is not really workable 

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.  It adds an awful lot of complexity in the name of 
generality, if all you want is basic encrypt/decrypt/sign/verify then it's... 
OK, but once you add all the object management it gets really complex.  And 
the annoying thing about it is that since most apps only use it at the 
"get/set a key" level, all of that complexity sits there unused...

>I think this means I'm going to have to do at least some of this stuff via 
>Cryptlib's internal APIs (or give up and write everything from scratch or use 
>something like OpenSSL, neither of which I want to do, for various reasons), 
>so at least some of the PKCS #11 code will end up sitting alongside the HAL 
>code rather than on top of Cryptlib, so that PKCS #11 can get at the raw key 
>components, call the signing operations directly, etcetera.

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.  Going in at the HAL layer may be easier, that's really what a 
HAL is there for.  OTOH as I've mentioned doing a PKCS #11 implementation is 
(a) a fairly major undertaking and (b) not a lot of fun.

>In the long term I can see us perhaps taking your advice and going with PKCS
>#15 for the token store (at the high level, PKCS #15 looks to me to be an 
>ASN.1-based filesystem);

Pretty much, and it was specifically designed as a marshalling format for PKCS 
#11 so the two fit together pretty well.

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.

Peter.