RSA signatures with TPM2.0 and OpenSSL

Foreword

Welcome stranger and thanks for stopping by. This is my first blog post (ever) and presently I am not even sure whether I want to maintain a blog… so who knows? It could also be the last. 🙂

What I am going to show applies to any Trusted Platform Module (TPM) implementing TPM2.0 specs. However, I wrote this article after spending two days trying to use the Minnowboard MAX firmware TPM (fTPM) for something useful in real life… I hope I can save you some time and a lot of troubles [1].

The problem

As it turns out tpm2-tools (the only TPM2.0 userland tools available on Linux that I am aware of)  uses an output format for cryptographic operations like signatures, public keys export, hashing, etc which is not compatible with OpenSSL.

This is very annoying as you can’t use directly a TPM for useful stuff if the other party is not able to load those TPM data structure (e.g. using a tpm2-tools).

After spending quite a bit of time on the TPM2.0 specs (a reading that I would recommend to anyone with a lot of time and masochistic personality) I came up with some procedures to convert RSA public keys and signatures.

In this article I am going to generate a RSA key that we can use to identify a particular device using a TPM that implements TPM2.0 specification. The easiest way to achieve that is using an AIK.

But, let’s start from the beginning…

Generating an Endorsement Key (EK)

Before generating a new AIK, we need to generate an EK. As I am using a newly initialised TPM, I have no password configured, so I can just issue the following command:

~# tpm2_getpubek -H 0x81010000 -g 0x01 -f ek.pub

That will generate a new RSA (hex code 0x01) key, store it in the NVRAM of the TPM with handle 0x8101000 and export the public portion in a file named ek.pub.

Unfortunately we can’t use this key directly for what we need to do, so let’s:

Generate an Attestation Identity Key (AIK)

Similarly to what we have done to generate the EK, we can generate a AIK:

~# tpm2_getpubak -E 0x81010000 -k 0x81010010 -f ak.pub -n ak.name

RSA is the default algorithm. The AIK is defined in the endorsement hierarchy so it needs to be generated using a EK (0x81010000 in this case). This new key is stored in the device NVRAM with handle 0x81010010. The public bit is exported in ak.pub.

ak.name contains the cryptographically secure name of the key. We are not going to need it for now.

ak.pub is a TPMT_PUBLIC structure which, among other things, contains the RSA modulus. As we generated a 2048 bits key (default), the modulus is exactly 256 bytes.

It is important to note that ak.pub doesn’t contain the RSA exponent (actually that field is present but it is set to 0). For RSA, TPM2.0 assumes that the exponent is always 2^16+1, or 65537 (for a good reason).

All that being said, we can convert the key to a DER and/or PEM format.

The DER key is then defined as <header> <modulus> <mid-header> <exponent>; we can use the following commands to compute all these elements:

1. Extract the modulus (removing TPMT_PUBLIC header and padding)

~# dd if=ak.pub of=modulus.bin bs=1 skip=102 count=256

2. Define the fixed header used by OpenSSL to identify a RSA key

~# echo 'MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA' | openssl base64 -a -d > header.bin

3. Mid-header is always 0x02 0x03 i.e. the exponent is a 3 bytes (0x03) integer (0x02)

~# echo -en '\x02\x03' > mid-header.bin

4. Exponent is always 65537 (2^16+1) as we have already seen

~# echo -ne '\x01\x00\x01' > exponent.bin

5. Compose the DER key

~# cat header.bin modulus.bin mid-header.bin exponent.bin > key.der

6. If needed you can easily convert the DER encoded key to PEM

~# openssl pkey -inform der -outform pem -pubin -in key.der -out key.pem

If you want to see how the modulus and the exponent look like, just run:

~# openssl rsa -in key.pem -pubin -noout -text
Modulus (2048 bit):

00:c7:2d:bd:f1:88:30:01:64:6a:0c:ae:61:52:23:
[stuff...]
87:a9

Exponent:
65537 (0x10001)

Ok. It seems legit, doesn’t it?

Signing a document

In TPM1.2 an AIK cannot be used to sign objects that are external to the TPM. TPM2.0 extends this concept: to sign an object with a primary key, we have to prove the TPM that object has been generated by the TPM itself. In order to do so, TPM2.0 uses tickets.

The following command computes the sha256 hash of a txt file and generate a TPM2.0 ticket (0x00B tells tpm2_hash to use SHA256.):

~# tpm2_hash -H e -g 0x00B -I message.txt -o hash.bin -t ticket.bin

Let’s sign the hash using ticket.bin as the authorisation token and the AIK with persistent handle 0x81010010:

~# tpm2_sign -k 0x81010010 -g 0x000B -m message.txt -s sign.bin -t ticket.bin

sign.bin contains the signature, wrapped in a TPMU_SIGNATURE structure.

In order to get something we can use with OpenSSL, let’s extract the relevant bits (i.e. the raw signature):

~# dd if=sign.bin of=sign.raw bs=1 skip=6 count=256

Verifying a TPM2.0 RSA signature

This is easy because we have already got a RSA public key that can be used by OpenSSL and a raw signature:

~# openssl dgst -verify key.pem -keyform pem -sha256 -signature sign.raw message.txt

If you get:

Verified OK

congratulations, it worked!

Conclusion

This is just an example of what we can do with a TPM. In one of the next articles (if any :P) I will explain how to decrypt a message encrypted with the a pubic key generated by the TPM.

---

 

[1] To create a custom version of the UEFI firmware for the MBM and enable the fTPM I suggest you to read this excellent article: Minnowboard Max: Enable the firmware (TXE) TPM 2.0

 

Advertisements