[lsb-discuss] Reflections on Trusting Trust

[Nelson B Bolyard]

Theodore Tso wrote, On 2008-10-23 12:22:

> Date: Thu, 23 Oct 2008 15:22:15 -0400
> From: Theodore Tso <tytso at mit.edu>
> To: Nelson B Bolyard <nelson at bolyard.me>
> Cc: lsb-discuss at lists.linux-foundation.org
> Bcc: tytso at mit.edu
> Subject: Re: [lsb-discuss] Reflections on Trusting Trust
> Message-ID: <20081023192214.GB7842 at mit.edu>

Is anyone else but me getting Bcc headers in the emails from Ted?

> On Thu, Oct 23, 2008 at 10:40:39AM -0700, Nelson B Bolyard wrote:

>> Enabling multiple people to sign things with a single private key is
>> the same issue for all HSMs, I believe.  I don't believe it's any more
>> difficult with any one device.
> 
> As I said, a number of the web pages said that the devices were
> designed so the key *had* to be generated on the device, and there was
> no provision to extract the key from the device once it was generated
> --- since that would ruin the whole point of the non-repudiation
> feature of the deice.  

Well, (a) eTokens simply impose no such requirements.  I know this
from direct personal experience.  But I don't doubt that you've seen
web pages that say otherwise.

(b) even in the case of HSMs that have keys generated on board that
cannot be extracted in any way (and PKCS#11 supports that, too),
the problem of how to enable any one of N people to generate signatures
using that one key in that one HSM is the same problem for all such HSMs.
That was the point I was trying to make above (but did poorly).


> Some of the other web pages claimed that it was
> impossible to upload keys to said device; 

I believe you that pages say that.  It just isn't true.

> Part of the problem as near I can tell is most people get it working for
> themselves, but don't spend much time making the solution general, or
> focus on usability.  So there was a lot of, here's this hackish patch and
> then things worked for me that you'll find on the web, and not so much 
> HOWTO's that basically say, "Just install Fedora 9, or Debian Sarge, and
> it all works out of the box."

A LOT of applications try to reinvent the crypto wheel for themselves.
Lots of applications implement their own crypto, and so are not readily
adapted to use crypto engines from other providers.  In many cases, they
create their own crypto architectures that are not readily altered to
fit other more well known and widely used architectures.

Hopefully, standardizing on NSS will help that, a lot.  Any application
that uses NSS pretty much adapts to any device with a PKCS#11 interface
out there.  (That's a bit of an overgeneralization, because there are
applications that use crypto algorithms that are pretty far out of the
mainstream, and NSS doesn't support those far-out algorithms, but its pretty
true for apps that want to use the mainstream ciphers.)

> Instead, I saw things like, install GPG, then replace its smartcard
> daemon with this other smartcard daemon, and apply this patch, etc.

Today, many applications roll their own crypto, up to (and including)
rolling their own code to handle smart cards.  This has been due to the
absence of a standardized OS API and/or service to handle that.

Once Linux has a standardized crypto API which supports HSMs, then even
on a system with a good HSM with a good robust PKCS#11 module, it may
still be true that your favorite application still will NOT work with it
because the app has no way to use any crypto but its own, and patches
will be needed to that app to fix that.

But once Linux systems all have a common system crypto API that does readily
facilitate HSMs (e.g., NSS), I hope that apps will migrate to it.

> Maybe I'm wrong and all of this stuff is working out of the box --- no
> patches, no replacing daemons, no config file changes --- for all of
> the major distributions.  But it if that's true, someone should be
> trumpeting this fact, and encouraging everyone to use these devices to
> store the OpenSSH and GPG keys.  

I suspect that OpenSSH and GPG may need to switch to use an OS API for
that before that will happen.  But I think that's (part of) what we (LSB)
are trying to accomplish.