Trust Issues: Bypassing EVE OS Measured Boot via PCR Amnesia

Imagine a high-security vault that requires a retina scan, a fingerprint, and a voice print to open. It’s impenetrable. Now imagine the security guard decides to stop checking the voice print because he's tired, but he doesn't tell anyone. That is effectively what happened inside EVE OS.

EVE OS relies on a hardware root of trust—the Trusted Platform Module (TPM)—to implement 'Measured Boot'. The idea is simple: as the device boots, it calculates cryptographic hashes of every component (BIOS, bootloader, kernel, config) and stores them in Platform Configuration Registers (PCRs).

The device's 'vault' key (which decrypts your data) is 'sealed' against these PCRs. The TPM is essentially told: 'Only release this key if PCR 0 through PCR 13 look exactly like they did when we set this up.' If a hacker modifies the kernel, the hash changes, the PCR values mismatch, and the TPM tells the hacker to get lost. The vault stays locked.

But in CVE-2023-43634, we found out that EVE OS was strictly checking the front door while leaving the garage side-door wide open. They were measuring a critical component, but they weren't actually checking the measurement.

The root cause of this vulnerability is a classic case of 'I thought you handled that.' In the world of TPMs, different PCR indices are reserved for different things. Historically, EVE OS measured its configuration partition into PCR 13. This partition holds the keys to the kingdom—API endpoints, authorized SSH keys, and system settings.

At some point, a developer decided to clean house. In commit 56e5897, the measurement of the configuration partition was moved from PCR 13 to PCR 14. This makes sense organizationally. It keeps things tidy.

However, there are two steps to this dance: 1) Measure the data into the register, and 2) Tell the TPM to validate that register before unsealing the keys. They did step 1 perfectly. They completely forgot step 2.

The DiskKeySealingPCRs list—the policy that dictates what the TPM checks—was never updated to include PCR 14. So, every time the device booted, it dutifully measured the config into PCR 14, and then the TPM dutifully ignored it, checking only 0 through 13. You could rewrite the entire configuration partition, changing the value of PCR 14 entirely, and the TPM would still happily hand over the encryption keys.

Let's look at the code, because in Go, the mistake is almost painfully obvious once you know where to look. This is located in pkg/pillar/evetpm/tpm.go.

Here is the vulnerable code configuration:

// Vulnerable Code
// DiskKeySealingPCRs represents PCRs that we use for sealing
DiskKeySealingPCRs = tpm2.PCRSelection{
    Hash: tpm2.AlgSHA1, 
    PCRs: []int{0, 1, 2, 3, 4, 6, 7, 8, 9, 13}
}

Do you see 14 in that list? Neither do I. Also, notice the use of AlgSHA1. In 2023. That's a separate sin, but it adds flavor to the failure.

Here is the fix provided in the patch:

// Patched Code
// DiskKeySealingPCRs represents PCRs that we use for sealing
DiskKeySealingPCRs = tpm2.PCRSelection{
    Hash: tpm2.AlgSHA256, // Upgraded to SHA256 (Nice)
    PCRs: []int{0, 1, 2, 3, 4, 6, 7, 8, 9, 13, 14} // PCR 14 added
}

The fix was literally two characters (adding 14) and a much-needed algorithm upgrade. Without that 14, the cryptographic chain of trust was broken at the configuration layer.

How does a researcher (or an attacker) actually weaponize this? EVE OS is designed for edge computing—boxes sitting in factories, wind turbines, or retail stores. Physical access is often trivial.

The Attack Chain:

1. Access: The attacker physically accesses the device (Evil Maid scenario) or boots from a live USB.
2. Mount: They mount the storage medium. The config partition is usually read-only or integrity-protected, but since we are offline, we can modify the bits on the disk directly.
3. Inject: The attacker modifies the authorized_keys file in the configuration partition to include their own public SSH key. Or, they change the controller URL to point to a malicious command-and-control server.
4. Boot: The attacker reboots the device.

During boot, the bootloader hashes the modified config. The hash is different. PCR 14 changes to a new, 'tainted' value.

The TPM looks at the policy. "Does PCR 0 match? Yes. PCR 1? Yes... PCR 13? Yes." It stops there. It never looks at the tainted PCR 14. The vault key unlocks, the system boots, and the attacker logs in via SSH with root privileges using the key they injected.

The severity here is classified as High (CVSS 8.8) for a reason. EVE OS creates a promise of security: "If the device is tampered with, it won't boot (or at least won't decrypt secrets)."

This vulnerability completely negates that promise for the configuration layer. This isn't just about reading data; it's about persistence. An attacker can backdoor a device, and the device itself—specifically the TPM which is supposed to prevent this—will vouch for the system's integrity.

Since this affects the sealing of the vault, an attacker gets access to:

• Credentials: WiFi passwords, API keys, and service secrets stored in the vault.
• Workloads: They can inspect or modify the Docker containers/VMs running on the edge node.
• Network: The device can be used as a pivot point into the deeper OT (Operational Technology) network.

The remediation is straightforward but requires action. The patch d9383a7ee4e1c39f5c8c6d4a63cb2ebd00695e8a fixes the issue by explicitly adding PCR 14 to the sealing list.

But simply applying the update isn't enough. Because the sealing policy is baked into the way the data is encrypted on disk, existing data is sealed with the old policy (ignoring PCR 14).

To fully remediate:

1. Update: Flash the device to EVE OS version 8.6.0, 9.5.0, or newer.
2. Reseal: The vault keys must be unsealed (using the old policy) and then re-sealed using the new policy (SHA256 + PCR 14). In many edge scenarios, this might require a reprovisioning of the device to ensure a clean state.

This is a harsh reminder that cryptography is only as good as its implementation. You can have the strongest algorithms in the world, but if you forget to check the register, you're just doing fancy math for no reason.