Tpm

TPM enabled security in Emulab

Secure Remote Node Communication via TMCC

Theory

Background - Trusted Platform Modules (TPMs) can create RSA keypairs that are suitable for secure communications by today's standards. During this creation process,the private key never leaves the TPM in an unencrypted form. Furthermore, the created key can be 'wrapped' (encrypted) by the storage root key (aka SRK). The SRK is generated every time somebody takes ownership of a TPM.

Because of these properties and the fact that we have no persistent storage, the following should hopefully work:

Boss starts configuring a node for a new experiment.

At some point when the client is ready to receive sensitive information from boss, the client asks boss to send her the following items:

Client's X509 cert (for her public key, of course) signed by our CA (certificate authority)

Client's corresponding private key blob (remember it is encrypted with a key in the TPM and can supposedly only be useful after it is loaded into that specific TPM using the proper TPM password)

The client checks for consistency between the cert and the keypair after successfully unwrapping it.

The client then uses it's received CA signed cert, the corresponding key blob that is now loaded and functional in the TPM, and a local copy of the trusted CA's cert (embedded in the Frisbee image, for now) to setup a strictly authenticated TLS tunnel.

This is an OpenSSL engine that will make our lives much easier; it saves us the hassle of writing the code to load, unwrap, and convert a TPM keyfile into an OpenSSL usable key. Also, more importantly, it lets us integrate TPM use directly with OpenSSL.

tpm-tools will be useful to take ownership of the tpm, but it doesn't have to be done with tpm-tools; you can even take ownership of the TPM in a different OS and it will still work.

Setup

XXX: how to enable in the BIOS

Use 'TPM=1' in your defs file.

Put your SRK password into testbed/etc/gpxesrkpass or [gPXE source root]/src/gpxesrkpass before you build gPXE if you wish to compile it in. Otherwise you can use a gPXE script to configure it at runtime using the "srkpass" command.

For GNU/Linux, you will need support for TPM devices; many distros do not have a module compiled or have a driver compiled in the kernel. You will likely need to do this yourself. The TrouSerS daemon will immediately exit if it doesn't detect a TPM device.

Before proceeding, you need to have the TrouSerS daemon running and openssl-tpm-engine installed.

Now we need to import our signed cert and keyblob into the SQL database on boss - they go into tbdb/node_hostkeys. At the moment, this is all done manually. I found it easier to do it like this (obviously you will need to replace $PCID with the proper value): (sorry for the long line but there shouldn't be newlines in the tpmblob)

This should be everything that is necessary. Now, when a node boots up in an experiment, it will run rc/rc.tpmsetup and get the cert and keyblob; they will be called tpm.cert and tpm.key.

You can now use the -T flag with tmcc on this node. In the future, you only need the TrouSerS daemon to be running.

Trusted OS Loading in Emulab

Theory

TPM enabled nodes are capable of "measuring" or SHA1 hashing the boot sector before passing control to it (the BIOS measuring code is immutable). The hashes are stored in registers in the TPM called PCRs. Other secure boot-loaders then continue this chain of hashing (the TPM hashes the requested content in an accumulative fashion) in order to guarantee that we can verify what we have loaded. It is possible to seal data or keys to certain PCR values; the key cannot be used or the data unsealed unless the PCRs match. The PCRs are also impossible to change except through extension - when arbitrary data is hashed and then combined with the previous hash in a (supposedly) cryptographically secure fashion.

Current Design

(This section is wrong - Cody will fix it).
Because data cannot be sealed on behalf of other nodes and sealing keys are TPM specific (obviously), setup will require that we generate a magic blob (whether that be a key or sealed data) on every node that we wish to be able to boot securely. In order to avoid the maintenance nightmare that would ensue if we were to measure the boot all the way to the frisbee loader (the PCRs would differ if one bit anywhere in the boot chain was ever flipped thus requiring us to generate a new magic blob for _every_ trusted boot path for every individual node), we have decided to use the TPM to measure only the first bootloader which will give us access to the magic PCR-sealed blob. Our boot software will SHA1 all the next pieces of the bootchain (before passing control to the pending piece) and send the hashes to boss using the magic PCR-sealed blob (this will probably be a signing key), asking if we should boot the next piece. This way if an attacker were to compromise the very first stage, it would be noticed when we tried to use our magic PCR-sealed blob as we wouldn't be able to. If any subsequent stage were to be compromised, boss would see that the signed SHA1 hash of it was very wrong and tell the node to not boot the rubbish.

Design Decisions

Because we want to eventually send off the correct, accumulative hash to boss which will make use of the magic PCR-sealed blob, and because GNU/Linux is the only convenient OS with TPM support, it makes the most sense to use Ryan's Linux MFS to load the final image via frisbee. We aren't aware of a bootable PXE card that is wise enough to measure what it receives with the TPM so we need to boot from a dongle; probably to gPXE which will then pull down a frisbee MFS. Then, the MFS will load on the selected OS.