In my last blog post I described how to set up SSH with TPM-protected keys. This time I’ll try to explain how it works.

SRK

The SRK is a public key pair that is the main secret inside the TPM chip. It is always generated by the chip, and the private key cannot be read or migrated.

In order to use the SRK key with any operation, the SRK password must be supplied. The SRK password is just an access password. It’s not related to the key itself. The SRK password is usually set to the Well Known Secret (20 null characters), or sometimes the empty string, or something silly like “12345678”.

There is not much point in having a good SRK password, since you probably have to store it on disk somewhere anyway, to allow TPM operations by daemons.

If you want a password then you probably want to set that per key, not chip-wide like the SRK password is.

Key generation

The stpm-keygen binary asks the TPM to generate a key, and the TPM hands back the public portion of the key, and a “blob” that has no meaning to anyone except the TPM. The blob is encrypted with the SRK, and the SRK never leaves the chip.

Key migration

At key generation time you can specify if you want the key to be migratable. If you do, then that allows the TPM operation “take this blob, decrypt the key and re-encrypt it with this other key, and give it back to me”. It is meant for migrating a set of keys from one TPM to another, but there’s no way to prove to the TPM that the new SRK is really from another TPM chip, so you could provide ANY new key and it’ll hand you your migratable key. Key migration operations are locked behind the “owner password” of the TPM.

If you generated a key as non-migratable, then you can’t change that attribute and later migrate it. (and vice versa)

Key migration is, in my opinion, a ridiculous concept, and should not be enabled when it can be avoided.

SSH auth operation

During an SSH handshake, the SSH client presents the public half of the keys it has access to. When the server sees a key that it would accept, it asks the SSH client to prove that it has the private key.

The SSH client proves to the server that it has the private key by signing some data (that’s the SSH2 protocol. IIRC the SSH1 protocol instead encrypted or decrypted some data).

For TPM keys, the SSH client calls my module telling it to sign this data, and my module in turn hands the key blob and this data to the TPM chip for signing, and is returned the signature. The TPM chip then forgets everything about the key. The TPM chip is not a key store.