> ## Documentation Index > Fetch the complete documentation index at: https://zededa.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. > ## Agent Instructions > Use the documentation index to find relevant pages, then read the linked Markdown before answering and cite the source URL. > Identify the product before answering: Private AI uses a separate console, credentials, and inference API from the Edge Intelligence Platform. Do not apply instructions from one product to the other. > Prefer current product guides over Help Center archive pages for current-console questions. Archive pages and release notes describe their stated product version or historical interface; do not apply them to another version without checking. > Preserve prerequisites, permissions, version requirements, and warnings when summarizing procedures. Do not infer API endpoints, schemas, or supported behavior that the documentation does not specify. # Trusted Platform Module (TPM) Overview > How EVE-OS uses the Trusted Platform Module (TPM) to protect vault encryption keys, establish measured boot integrity, and enable remote attestation. ## Introduction The Trusted Platform Module (TPM) is a specialized security microchip, typically embedded in an edge device's motherboard, that provides hardware-based cryptographic services. EVE-OS (Edge Virtualization Engine) uses the TPM to protect the vault encryption key, establish measured boot integrity, and support remote attestation. These three mechanisms work together to protect node data even when an attacker has physical access to the device. ## How It Works ### Supported TPM hardware EVE-OS requires a TPM 2.0 implementation that provides a SHA-256 PCR bank. Both discrete TPM chips and firmware TPMs (such as Intel PTT or AMD fTPM) qualify, regardless of vendor. TPM 1.2 devices are not supported. For the strongest protection, choose hardware whose firmware is not affected by CVE-2018-6622, which allows PCR values to be reset after an S3 sleep state. ### Measured boot Measured boot is a boot sequence starting from a root of trust for measurement (RTM, typically the BIOS or Intel Boot Guard if available) that cryptographically measures each component of the boot process before it executes. These measurements are stored in the TPM's Platform Configuration Registers (PCRs). A PCR is a memory register inside the TPM that stores the output of a hash algorithm. Measurements are created by computing a hash of each component that affects the boot process, then extending the current PCR value with the new hash: ```text theme={"dark"} New_PCR_Value[i] = SHA-256(Old_PCR_Value[i] || Input_Digest) ``` Two properties of PCRs make them resistant to tampering: * PCRs are not resettable or directly writable at runtime. Only a power cycle and re-execution of the RTM can reset them. * The extend-only operation means a malicious actor cannot inject a known-good state into PCRs at an arbitrary point in the boot sequence. ![Measured boot chain showing how each software layer measures the next, from firmware through bootloader, kernel, and EVE-OS, with measurements stored in TPM PCRs](https://mintcdn.com/zededa/nH470gZ2VKSQBZu8/new-ui/infrastructure-services/images/tpm-measured-boot.png?fit=max\&auto=format\&n=nH470gZ2VKSQBZu8\&q=85\&s=1c3ee5fc756a0c84cb8fc4e8b7f454ef) At the end of the measured boot process, EVE-OS has a set of PCR values and an event log containing all measured data (including kernel boot parameters). These values represent the software state of the device at boot time. EVE-OS also sends the TPM event log to Edge Infrastructure Services for attestation purposes. The following is a sample of a parsed TPM event log showing selected events and the final PCR values: ```text theme={"dark"} Events: - EventNum: 1 PCRIndex: 0 EventType: EV_S_CRTM_VERSION DigestCount: 2 Digests: - AlgorithmId: sha256 Digest: "4a20365460e54003a6358f7ae08fcf7d6a0a6b391a19c8c2aea3906aa675b85f" - AlgorithmId: sha1 Digest: "4c8e06fd2f8f4f6f816ba2fd1fac0eac81c43f59" EventSize: 46 - 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" 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 ``` EventNum 208 shows a GRUB kernel command line event. The full kernel boot parameters, including memory allocations and EVE-OS-specific flags, are captured as part of the PCR 8 measurement. The final `pcrs` block shows the resulting hash values for each algorithm across the PCR indexes measured on this particular device. Depending on the firmware and platform, additional indexes in the 0–15 range can also carry measurements. ### Vault key protection (secret sealing) EVE-OS encrypts user data at rest using a vault key. The TPM protects this key through PCR binding. The TPM seals the key against the current PCR values so that it can only be unsealed if the device boots to the same known-good state. The vault key generation and sealing sequence when a node is onboarded: 1. Generate a random key for the vault. 2. If a SHA-256 PCR bank is available, seal the key in the TPM bound to the PCR indexes in the sealing policy. The default policy covers PCR indexes 0, 1, 2, 3, 4, 6, 7, 8, 9, 10, 11, 12, 13, and 14. PCR 5 is excluded because it measures the GPT partition table, which EVE-OS modifies on every A/B base image update. PCR 15 is excluded because it is reserved for OS or user-defined measurements. You can change the selection per node with the [Flexible PCR Policy](https://zededa.mintlify.site/new-ui/infrastructure-services/eve-os/flexible-pcr-policy.md). 3. If a SHA-256 PCR bank is not available, store the key in TPM non-volatile memory with no PCR binding. 4. Encrypt the vault key using a TPM-unique key (Key Encryption Key, or KEK) and send it as a backup to Edge Infrastructure Services. 5. Send a quote to Edge Infrastructure Services containing the current PCR values (see the following Remote attestation section). The KEK is unique per TPM and never leaves the device, meaning the encrypted backup key cannot be decrypted on any other hardware. Before sealing, EVE-OS confirms that PCR 0 and PCR 4 hold real measurements rather than their all-zero reset values. If either is all zeros, the firmware did not perform a SHA-256 measured boot, and any code running after the firmware hands off could forge the PCR state. In that case EVE-OS refuses to seal the key to PCRs and falls back to the unprotected storage path. If the sealed key cannot be unsealed at boot because the saved sealing policy no longer matches, EVE-OS first tries to recover on its own. It tests the default policy, then systematically tries subsets of PCRs 0–15 against the sealed key's policy digest. If a match is found, EVE-OS records the recovered policy and continues without contacting Edge Infrastructure Services. Only if local recovery fails does the device fall back to remote attestation. ### Remote attestation Remote attestation is a cryptographically secure process that allows Edge Infrastructure Services to verify that a node booted to a known-good state. EVE-OS performs a Quote operation: the TPM signs the current PCR values (always PCRs 0–15 in the SHA-256 bank) plus a nonce provided by Edge Infrastructure Services. Edge Infrastructure Services verifies the signature using the device's attestation key public certificate, checks that the signed nonce is fresh, and compares the PCR values against the PCR template it holds for that device. Remote attestation is used primarily after EVE-OS updates. Since an update changes the PCR values, the vault key cannot be unsealed locally after the update. The device requests the backup vault key from Edge Infrastructure Services by sending a new quote. If the attestation succeeds and the new PCR values match the expected post-update template, Edge Infrastructure Services returns the encrypted backup key. The device decrypts the key using its TPM and reseals it to the new PCR values. **Attestation policy and security implications:** When the attestation policy is set to **enforce** mode, a device that fails the PCR check receives no backup key from Edge Infrastructure Services. This means a device running tampered or unauthorized software cannot unlock its vault, even if it can reach Edge Infrastructure Services. When the attestation policy is not in enforce mode, a device with modified PCR values can still request and receive the backup key, which weakens the security guarantee. If the vault remains inaccessible beyond the configured cutoff (the `timer.vault.ready.cutoff` property, 300 seconds by default), EVE-OS reboots the node or places it in maintenance mode so that the condition is visible and recoverable. ## Key Benefits * **Physical theft protection:** If an attacker steals the storage device and moves it to another machine, the vault remains encrypted. The TPM-sealed key is bound to the original device's PCRs and cannot be unsealed on different hardware. * **Tampered boot detection:** If an attacker boots the device with malicious software, the measured boot process produces different PCR values. The TPM refuses to unseal the vault key, keeping user data inaccessible. * **Cloud-enforced attestation:** When the attestation policy is set to enforce mode in Edge Infrastructure Services, a device that fails the PCR check will not receive the backup vault key, preventing access even if an attacker manages to boot a tampered system. * **Automatic key recovery after updates:** EVE-OS updates change PCR values, but the remote attestation mechanism handles key recovery transparently without manual intervention. ## Security Levels | TPM Configuration | Security Level | | - | - | | No TPM | Minimal. Anyone with physical access can mount the disk and read vault contents. | | TPM present, no SHA-256 PCR bank | Partial. Vault key is stored in TPM non-volatile memory without PCR binding. Disk theft is blocked, but a successful malicious boot can read the key. | | TPM with SHA-256 PCR bank, firmware does not perform measured boot (PCR 0 or PCR 4 all zeros) | Partial. EVE-OS detects the missing firmware measurements and refuses to seal to PCRs, falling back to the unprotected path. Enable measured boot in the firmware to reach the maximum level. | | TPM with SHA-256 PCR bank and firmware measured boot | Maximum. Vault key is PCR-bound. Both disk theft and malicious boot are blocked. | ## What to Configure * **Measured boot** is automatic when a TPM is present. No configuration is required. * Ensure your edge device has a TPM with SHA-256 support for maximum security. * Configure an attestation policy in your project. When set to **enforce**, Edge Infrastructure Services will not send the backup vault key to a device that fails attestation. See [Configure Project Policies](https://zededa.mintlify.site/new-ui/infrastructure-services/projects/configure-project-policies.md). ## Next Steps > [card] [Host Platform Configuration (PCR 1) Interpretation Guide](https://zededa.mintlify.site/new-ui/infrastructure-services/eve-os/pcr1-interpretation-guide.md) > > A full list of events measured into PCR 1. > [card] [TPM PCR Index Security Implications](https://zededa.mintlify.site/new-ui/infrastructure-services/eve-os/tpm-pcr-security.md) > > A full reference for all PCR indexes used by EVE-OS. > [card] [Remote Attestation Overview](https://zededa.mintlify.site/new-ui/infrastructure-services/eve-os/remote-attestation.md) > > How EVE-OS validates node integrity using the TPM.