Overview of the Trusted Platform Module (TPM) in EVE-OS

Introduction

A Trusted Platform Module (TPM) is a specialized microchip, typically located on an edge device's motherboard, which provides hardware-based security. Think of it as a secure vault within your edge device that protects sensitive cryptographic information. The primary purpose of a TPM is to safeguard your system by securely generating, storing, and managing cryptographic keys.

This article describes how and for what purpose a Trusted Platform Module (TPM) is used in EVE-OS. Some technical details are left out for the sake of brevity, but the description accurately reflects the process and the purpose. 

Platform Boot Integrity

Boot integrity plays a key role in providing trust, enabling us to verify that the system was bootstrapped with untampered software. EVE-OS uses TPM to provide hardware supported Boot integrity, in the form of the Measured Boot (not to be confused with Secure Boot).

Measured boot, is a boot sequence starting at a root of trust for measurement or RTM (i.e. BIOS IBB or Intel® Boot Guard if available) initiating a series of measurements consisting of all the security relevant components (BIOS itself, Firmwares, Option ROMs, boot-loader, root filesystem, etc) into the TPM’s Platform Configurable Registers (PCRs).  A PCR is a memory register inside the TPM that can store the output of a hash algorithm.

A measurement is created by computing a hash (digest) of the next content that affects the boot process, it can be code (for example, firmware) or configuration data (for example, kernel boot parameters). A measurement is the result of execution of the Extend function, the extend operation ensures that the value of each measurement relies on the previous value. This way we can form a chain so changes in one stage of the boot process will propagate into the next ones, resulting in a different set of PCR values at the end.

There are two important details to note:

• TPM offers multiple PCRs (usually 24) and PCR indexes used to store the measurement are not resettable or directly writable at run-time, only a power-cycle and subsequent execution of the RTM can reset the PCR value to the initial value (usually zero), combined with the extend-only operation, a malicious actor cannot forge a good-known-state into PCRs at an arbitrary stage in the boot sequence.

• The measured boot performs no evaluation or verification of any of the component's identities, but paves the way to use other functionalities of the TPM to protect system secrets in case of malicious boot attack.

At the end of the measured boot process, EVE-OS is provided with a set of PCR values and an Event log containing all the data that was measured (for example kernel boot parameters). EVE-OS also sends the TPM Event log back to the cloud controller, but the process behind it is outside the scope of this document. See the following table for an example of TPM Event log:

Events:
- EventNum: 1
  PCRIndex: 0
  EventType: EV_S_CRTM_VERSION
  DigestCount: 2
  Digests:
  - AlgorithmId: sha256
    Digest: "4a20365460e54003a6358f7ae08fcf7d6a0a6b391a19c8c2aea3906aa675b85f"
  - AlgorithmId: sha1
    Digest: "4c8e06fd2f8f4f6f816ba2fd1fac0eac81c43f59"
  EventSize: 46
  Event: "4800300039002000760031002e003500320020002800300037002f0031003…"
- EventNum: 2
  PCRIndex: 0
  EventType: EV_EFI_PLATFORM_FIRMWARE_BLOB
  DigestCount: 2
  Digests:
  - AlgorithmId: sha256
    Digest: "31cb93a3185450e185414ca36e90e5d3608d8c9767f29e2c0bdbae37a3e1bafa"
  - AlgorithmId: sha1
    Digest: "b85a5a053f5b43a4dee61eccf388e27285c5b74d"
  EventSize: 16
  Event:
    BlobBase: 0xfff00000
    BlobLength: 0x100000
[...]
- EventNum: 208
  PCRIndex: 8
  EventType: EV_IPL
  DigestCount: 2
  Digests:
  - AlgorithmId: sha1
    Digest: "42dc8f8aeabd7f52224f301df7e802a6ef258f9d"
  - AlgorithmId: sha256
    Digest: "f08af96dbc5f16ab99945b84496236a1c19189466604b32ebba49ebcd9a315ae"
  EventSize: 359
  Event:
    String: |-
      "grub_cmd linux /boot/kernel console=tty0 root=PARTUUID=ad6871ee-31f9-4cf3-9e09-6f7a25c30052 dom0_mem=800M,max:800M dom0_max_vcpus=1 dom0_vcpus_pin EVE-OS_mem=650M,max:650M EVE-OS_max_vcpus=1 ctrd_mem=400M,max:400M ctrd_max_vcpus=1 change=500 pci=realloc=off rootdelay=3 rfkill.default_state=0 video=efifb:off console=tty0 pcie_acs_override=downstream,multifunction\0"
[...]
- EventNum: 216
  PCRIndex: 5
  EventType: EV_EFI_ACTION
  DigestCount: 2
  Digests:
  - AlgorithmId: sha1
    Digest: "475545ddc978d7bfd036facc7e2e987f48189f0d"
  - AlgorithmId: sha256
    Digest: "b54f7542cbd872a81a9d9dea839b2b8d747c7ebd5ea6615c40f42f44a6dbeba0"
  EventSize: 40
  Event: |-
    Exit Boot Services Returned with Success
pcrs:
  sha1:
    0  : 0x762424354f0061ed6bd3724cb812b67d42ad1d72
    1  : 0x12a9b8f31bc5678705d5252e2456218236b5b7d2
    2  : 0x18dfbaac298fcd509ee1c614fd227e4d9ca482cd
    3  : 0xb2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
    4  : 0xbac2e9209b8fe5248e62e2f62108adc49681062d
    5  : 0x70f6e62805c975cbb76cc2ba6a5a9985168ffc00
    6  : 0xb2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
    7  : 0x3bed737e691a3a06d2f5d61042e31ab0b4e3fde4
    8  : 0xbc13aa0a4c9cdf892fa8c45acc7e611980f928ec
    9  : 0x44109ebb0a7622bdcace4f32df0eb1e39a9e34c8
    13 : 0xc3b4732ada9f39981ef1303b48d17bc755507f73
  sha256:
    0  : 0x279d0bf5d9435c8b719f42031fc7d1d706b0e7ec974e58f52a1d915c687aac1d
    1  : 0xcc8850302d0bc54e7f2127cd243028b8e5389e3109adb43a74f3acf05b1e892e
    2  : 0x0f6d6de2a9e28f193d0930f219510e80a0322768ce0ea7044f60f381f40e14c4
    3  : 0x3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
    4  : 0x025e44fbbf14d64fb60c6e8ff74710a17ae778ae8559ae4634bd4d29f6818892
    5  : 0xdf2af523c5169c1f1a17c933b6896c1c7283f9e3240cfc403b4de9f9bc68d7e3
    6  : 0x3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
    7  : 0xa927857cdc7cbf4fdf9f6d5f506373d33abadcf1206caf0140330ff924d7f280
    8  : 0x8f3d86443522b1737bedcd15accc1f49971e63187189253a0042c84255ef3284
    9  : 0x1a1961c687866a98a99188e4e74aba2c9cad9729a91a209396e6ed2f5cf1c418
    13 : 0xcb18c5c53a23f83b3330220f947d5ff0914de89162616ecda4d013bcbf6db096

Secret Sealing

Measured boot processes can be utilized to protect system secrets. In EVE-OS’s case, the secret is the symmetric key of the encrypted partition (vault). Vault is used to store and protect user data at rest by encryption.

An important functionality offered by TPM is the ability to seal a secret by binding it to the static value of a set of PCRs. This means we can store a secret into the TPM by asking the TPM to record the current value of the selected PCRs and reveal the secret in the future only if the future PCR values match the one stored with the secret. As we mentioned, PCR values are not forgeable, and since the PCR values are directly linked to the measured boot, we can protect the secret and reveal it only if the system is booted securely to a known-good-state.

The following sequence shows Events in EVE-OS to generate and protect the vault key once the edge node is onboarded:

1. Generate a random key for the vault.
2. If PCR banks with SHA-256 hash are not available, store the Key in the TPM non-volatile memory with no PCR bindings, go to step 4.
3. If PCR banks with SHA-256 hash are available, store the Key in the TPM, binding it to the current value of the PCR indexes: 0, 1, 2, 3, 4, 6, 7, 8, 9, 13, 14.
4. Encrypt the vault key using a TPM unique key and send it as a backup to the cloud controller (see Attestation section for more details).
5. Send a quote to the remote controller containing the current PCR values (see Attestation section for more details).

It is expected that the device will be provisioned in a secure environment, so the value of PCR indexes from step 3 are considered a good-known-state which is not malicious or tampered with for any reason. Besides that it is worth noting that it is not possible for the cloud controller to recover the key from the encrypted backup key from step 4, since the symmetric encryption key used to encrypt the backup key (lets called Key Encryption Key or KEK) is unique per TPM and never leaves the TPM. KEK is a AES key that encrypt/decrypt a given secret, the key is derived from a seed which is protected inside the TPM. In other words, to decrypt a secret successfully, one will need to be on the same device.

TPM attack scenarios

If the device is not equipped with a TPM, the protection of the user data at rest is minimal and anyone with physical access to the device can mount the disk to read the content. 

If the TPM exists but the SHA-256 PCR banks are not available for use, there is still some security since the vault key will be stored out of the disk and in the TPM non-volatile memory albeit without any binding policy. So just stealing the disk or inserting it in another device is not equal to getting access to the vault information, because the vault key is stored in the original TPM. But anyone who manages to boot the system with a malicious software that gives them access to the system, can just read the key from the TPM. 

If the device is equipped with TPM and SHA-256 PCR banks are available, the maximum offered security is ensured. In this scenario, Even if the attacker manages to boot up a malicious software, they will not be able to read the vault key from the TPM, since as a result of booting tampered software measured boot will report a different set of PCR values and the PCR policy which as described before binds unsealing of the key to a set of known PCR values, will fail, and TPM refuses to reveal the secret.

In the above scenario, even if the disk is stolen and placed into another device, the attack will be unsuccessful. Firstly the local unseal operation will fail due to PCR mismatch, and secondly even if the cloud controller hands the new device the backup vault key (because for example the attestation is not in enforcement mode, see next section), still decrypting the vault is not possible, because as mentioned before, the KEK used to encrypt the backuped vault key is unique per TPM and the new device will fail to decrypt the backup vault key received from the cloud controller.

Remote Attestation

Remote attestation is a cryptographically secure and verifiable process that a Prover (here EVE-OS) shows a Remote Verifier or Challenger (here cloud controller) that the system is in a certain state. For the case of EVE-OS, the required state is that the system was booted to a known-good-state.

Using remote attestation, a verifier can enforce policies on the prover, for example it can add EVE-OS into a specific private network or reveal a secret, only after successfully evaluating the system state. The prerequisite to this verification is to have a snapshot of the known-good-state in the cloud controller. This snapshot comes in the form of the PCR values, from the time the system gets onboarded (step 5 in Table 3 : Onboarding Sequence), and as mentioned before, these values are expected to come from an untampered device that was provisioned and onboarded in a secure environment.

The process of reporting the PCR values to the verifier, is called Quote Operation. Quoting is a cryptographically secure operation that happens inside the TPM. During a quote operation, TPM signs the current value of the PCRs plus a nonce that is received from the cloud controller (to ensure the freshness of signed data against replay attacks) and sends it to the cloud controller. The key used in this signing operation is called Attestation Identity Key (AIK). AIK has certain security attributes, for example it is non-migratable key (cannot leave the TPM in any shape or form, even encrypted), used only for signing operations and only the public key can be made available outside of the TPM.

The cloud provider already having the public key of the AIK, and a snapshot of the good-know-state of the PCRs, now can verify that the system holds the required property by first making sure the signature is valid, data is fresh (checking signed nonce) and finally comparing the PCR values with a saved snapshot.

Use of remote attestation in EVE-OS

In the step 4 of Onboarding Sequence we mentioned that EVE-OS will save an encrypted backup of the vault key in the cloud. This backup key is mainly used for keeping the system functional after an update. 

Since an update will come with changes that affect the binding PCRs (any of indexes 0, to 9 plus 13 and 14) , the TPM will refuse to reveal the secret after the system boots up, hence the vault remains locked. To solve this problem, we can predict the new PCR values by updating the device in a secure environment and recording the new PCR values. These new PCR values can be used to update the PCR snapshot in the cloud controller . 

Now the device that is failing to unlock the vault will ask the cloud controller for the backup key by sending a quote request with its current PCR values. After successful evaluation of the quote, the cloud controller compares the device’s current PCR values with the expected “update” PCR values; if they match, it means these new PCR values (though different) are legitimate and result of a system update and not a malicious boot up. After the successful comparison, the cloud controller will send back the device's encrypted backup key.  Upon receiving the key, the device will decrypt it and seal it again with its current PCR values, so it can operate independently of the cloud controller in the future power cycles.  The following table explains the sequence in more details:

Remote attestation attack scenarios

Assuming the SHA-256 banks are available for use, If the remote attestation is in enforcement mode, a malicious device can not unlock the vault neither locally nor by resorting to the cloud controller for the backup key.

If the remote attestation is not in enforcement mode, a device with a tampered version of the EVE-OS which is failing to unlock the vault locally, can just ask the cloud controller for the backup key.

What Do I Need to Do?

There are a few things you can do to utilize these TPM-based security features in EVE-OS:

• Make sure that your edge device has a TPM with SHA-256 support. This provides the strongest security.
• You don't need to do anything to enable Measured Boot. It's an automatic process when a TPM is present.
• You can configure an attestation policy in your project. When set to enforce, the ZEDEDA Cloud will not send any secrets (like a backup vault key after an update) to a device that fails attestation.

Here’s how these features work together to protect you from common attacks:

Next Steps

This is a series of articles, you will likely follow them in this order:

• Overview of the Trusted Platform Module in EVE-OS - You are here!
• Factors Affecting PCR TPM Register
• Remote Attestation Overview
• Manage PCR Templates
• Configure an attestation policy in your project.
• Use EVE-OS Local UI to analyze attestation issues.