TPM Operations
Generating Random Numbers
The TPM2_CC_GetRandom
command generates random bytes (max 48 per call).
Generating Keys
Each hierarchy can have a primary key, which acts as a parent for all the child keys. The children are wrapped (encrypted by the parent).
Enrollment Primary Key is certified by the manufacturer of the TPM. It means that the key has an accompanying certificate signed by the trusted CA. This certificate is stored in the TPM’s NVDATA. It can be read and verified any time. The NV indices for the certs are reserved.
If EK is trusted, all keys under it can be trusted as well (chain of trust).
The Primary Key may be recreated multiple times, it will always be the same, as long as the provided parameters (such as key type) are the same. The EK has predefined templates, which can be used anytime we need that key. One is for RSA, the other for ECC.
Keys may be stored persistently, but TPM has limited space for it.
Attributes
Other than algorithm information, it is also required to provide attributes of the new key (object). Example:
Some of the parameters:
- Decrypt (
TPMA_OBJECT_DECRYPT
) - Specifies an encryption key. - Sign (
TPMA_OBJECT_SIGN_ENCRYPT
) - Specifies a signing key. - Restricted (
TPMA_OBJECT_RESTRICTED
) - Restricts the key to signing/encrypting only internal TPM data.
Non primary keys are created with the TPM2_CC_Create
command. The command
requires a handle to the parent key.
Using Keys
Keys generated by TPM might be used to sign, verify, encrypt, decrypt data.
Ownership
Endorsement Hierarchy keys are protected by the EK (which is certified and can be trusted). The Owner Hierarchy cannot be trusted in the same way, it’s not certified by the TPM manufacturer. It’s the owner’a responsibility to provision and certify the primary key of the owner hierarchy. The primary key of the owner hierarchy is the Storage Root Key (SRK) (like in TPM 1.2?). It’s a restricted encryption key.
Having a trusted, restricted signing key is useful for remote system attestation. It’s, therefore, recommended to create and certify a restricted signing key during provisioning time. This trusted signing key is also called Attestation Identity Key (AIK).
Taking Ownership
- Read and validate the EK certificate. Proceed only if you trust the vendor.
- Clear the owner hierarchy with
TPM2_CC_Clear
. - Create a primary, restricted asymmetric encryption key on the owner hierarchy
(
TPM2_CC_CreatePrimary
). Call this the SRK. - Certify the SRK with your enterprise CA: create a CSR with SRK public part,
and ask your internal, trusted CA to sign it. Store the certificate in NV
data (
TPM2_CC_NV_DefineSpace
,TPM2_CC_NV_Write
). Alternatively, you can store the SRK public key in a remote database. Use this database to verify the SRK’s authenticity in the future. - Make the SRK persistent by evicting it to NVDATA (
TPM2_CC_EvitControl
). - Create a restricted asymmetric signing key under the SRK (
TPM2_CC_Create
,TPM2_CC_Load
). Call this the AIK. - Certify the AIK with your enterprise CA: create a CSR with AIK public part,
and ask your internal, trusted CA to sign it. Store the certificate in NV
data (
TPM2_CC_NV_DefineSpace
,TPM2_CC_NV_Write
). Alternatively, you can store the AIK public key in a remote database. Use this database to verify the AIK’s authenticity in the future. It’s possible to use the SRK certificate as root of trust for the AIK, however, having an AIK certificate can simplify some workflows. - Make the AIK persistent by evicting it to NVDATA (
TPM2_CC_EvitControl
).
These keys should be set as fixed (non-duplicable): use TPMA_OBJECT_FIXEDTPM
and TPMA_OBJECT_FIXEDPARENT
in the objectAttributes
field in their
templates. At this point we have two trusted keys we can use: one for storage
(protecting other TPM keys) (SRK?) and one for signing TPM statements (AIK).
Measured Boot
It’s a standardized technology supported by modern firmware. Before executing an element in the boot sequence, it’s measured to make sure that it is the expected executable. If the result is unexpected, it’s not executed.
Each element is measured by its predecessor in the sequence. Each measurement is stored in a different PCR.
Measuring the Firmware
We assume that the first element (firmware) is trusted. It measures itself into PCR0. Vendors publish the expected measurements of their firmware.
Another approach is to use CRTM. There’s an immutable code component called Core Root of Trust for Measurement (CRTM). It is the first piece of code that executes on the main processor during the boot process. It measures the firmware blob before passing execution to it.
Event Log
There is a log that gives some details about measurements sent to TPM. It’s maintained by the firmware, bootloader and the OS. Users can read the log to see what was measured.
Log example:
Thanks to Measured Boot a Remote Attestation may be done. It checks the integrity of a system.
Authorization
TPM may be used only with the right authorization. Authorization policies are used. Many authorization schemes are supported (e.g. a password scheme). Autorization value may be set for the entire hierarchy or on individual keys.
An example of authorizing before calling a command:
When more than three attempts of authorization fail, TPM enters locked-out mode. It protects against a dictionary attack. It will not accept any command for the target object in that state.
Session Authorization
Session is an internal TPM object that encodes an authorization value. A session has a digest of PCRs. When creating a data/key in TPM, we can specify what is the expected PCR digest. If the session’s digest matches the one expected by the data/key it is accessible.