[lsb-discuss] Reflections on Trusting Trust

[Theodore Ts'o]

There's been some discussions on the weekly LSB call about how far we
should go in terms using a very careful system of protecting the OpenPGP
keys that we use for signing the packages that we release.  Some have
gone as far as to say that we should use a hardware solution, much like
Red Hat has done for signing their packages.  For more information about
what they did, it's instructive to read Mark Cox's description of what
he implemented, here:

   http://www.awe.com/mark/blog/200701300906.html

What did he do, specifically?  He created a hardware signing solution
where "authorized package signers" could submit a kerberos authenticated
request to server which then talked to a FIPS 140-2 certified hardware
module which held the private key componets of Red Hat's package signing
key.   Why did he do this?   To quote from Mark's blog posting:

	So the authorised signers not only had the ability to sign with
	the key, but they also have the ability to read the key
	material. In theory this means that a malicious internal signer
	could copy the key, take it away with them, and sign whatever
	and whenever they wanted. Or, more likely, a clever intruder who
	gained access to our internal network could perhaps capture the
	key and passphrase, compromising the key. The risks mean we've
	had to be really careful who has signing privileges with the
	legacy key and how the key signing is handled.

So there are really two fundamental threats:

(a) the malicious insider retaining a copy of the key

(b) an attacker who manages to compromise the machine containing the
key, installing a keyboard sniffer and then grabing the key.

In addition, one thing to keep in mind is that Red Hat (and any other
distribution) has to sign hundreds of packages per distribution, and so
they need a solution which can scale to handle signing a *very* large
number of packages every day, by multiple people managing the release
process.

First of all, I'll note that a malicious insider can do plenty of damage
without having any access to the key.  Anyone who can get root on one of
our build engines can build a trapdoor into the C compiler's crt0 file,
at which point every single binary that we build could be a trojan
horse.  And, of course, there is alwys the techique which Ken Thompson
demonstrted in his classic paper, "Reflections on Trusting Trust". 

So the real concern is the attacker who manages to compromise a machine
that contains the keying material, and who manages to somehow gain
access to the passphrase.  And to counter that threat, there's something
we can do that wouldn't be practical for a Red Hat or any other
distribution, but which should be good enough for us given very small
number of packages that we need to sign for releases, beta releases,
updates, etc.  What's my proposed solution?

For our most secure keys (the release key and annual key) the private
component is only kept on a bootable USB stick; the OS on this USB stick
will have no network daemons, and any new keys or packages to be signed
are stored on a second USB stick.  Once created, the bootable USB stick
never gets inserted into a running system; the procedure to be followed
is to reset the system, insert the bootable USB stick with the private
key components, and then boot into the OS stored on the bootable USB
stick.

So even if an attacker manages to compromise the laptop where the
packages are signed, the OS USB stick should be safe since the attacker
won't have access to it.  Yes, it's not as convenient as the solution
devised by Mark Cox, but it's much simpler to implement, and we would
probably need to boot into the USB environment no more than once every 2
or 3 months.

							- Ted