[Cryptech Tech] cryptlib HAL for EIM

[Rob Austein]

At Thu, 30 Apr 2015 10:12:04 +1200, Peter Gutmann wrote:
> 
> Is there anything you need done from my end for this?  I hope to (finally) get
> 3.4.3 out within the next few weeks, so if there's any changes you need let me
> know.

Hi, Peter,

Paul may have comments of his own, but I think he's mostly been
focused on plumbing issues, not on Cryptlib per se: he's been working
on the very lowest level of the C code and the upper layers of the
Verilog code, which, between them, are responsible for presenting an
API for the crypto cores up in C where the Cryptlib HAL can use it.

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.

- 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.

- 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.

- 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.
  
  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).

  If replacing the CSPRNG entirely seems like a sane thing to do in a
  case like ours, having a clean way to do so would be nice.

That's all I can think of at the moment for straightforward stuff.
I don't think any of this is a showstopper for us, except maybe ECDSA
component generation if that turns out to be a hard problem

You can see what we've done with the HAL code so far at:

  https://wiki.cryptech.is/browser/sw/cryptlib

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...

...which is what the rest of this message is about.  You might want to
grab a glass of some calming beverage before reading the rest of this.

Let me say off the top that none of the following should be taken as a
criticism of Cryptlib.  Having worked extensively with OpenSSL, I
*like* Cryptlib's disciplined approach and firm intention of making it
easy to do reasonable things and difficult to do stupid things.  My
current problem is just figuring out how to reuse Cryptlib code while
writing PKCS #11 non-stupidly (well, that's a bit of an oxymoron, it's
PKCS #11, oh nevermind...).

So my first attempt, which you can see at:

  https://wiki.cryptech.is/browser/user/sra/pkcs11/pkcs11.c

is not really workable even after one stops laughing at all the
SQLite3 code.  It uses Cryptlib's public API in much the same way that
SoftHSMv2 uses OpenSSL's API, the difference being that, since
Cryptlib won't let me do stupid things, I had to cheat (by using
cryptDecrypt()) to support signing for CKM_RSA_PKCS via Cryptlib's
public API, and don't think I'll be able to support signing for
CKM_ECDSA at all this way.

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.  I don't really understand the internal
APIs well enough to know what to ask for here beyond key generation
(covered above).  Advice welcome.  No clue whether this implies any
kind of code changes.

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); in the short term I expect
I'll stay with SQLite3 so that I can focus on hooking PKCS #11 up to
the crypto cores.  This probably means that the private key material,
at least in the short term, will be stored in the SQL database, in
encrypted form (RFC 5649 is next on my to-do list), representation TBD
and subject to change (ignoring efficiency issues, I could probably
just encrypt the relevant CRYPT_PKCINFO_* structure as a first cut).

To repeat: none of the PKCS #11 mess described here is your fault, or
Cryptlib's.  Given my druthers, I'd just use Cryptlib over the FPGA
and PKCS #11 could take a long walk off a short pier...but the market
won't accept that answer, so I'm trying to figure out how to get the
job done while borrowing as much of the tricky code as possible from a
source I think I can trust to have gotten it right.

Thanks,

--Rob