Trusted Boot, Untrusted Config: Breaking EVE OS Encryption (CVE-2023-43633)

Edge computing is the Wild West of IT. You have expensive, sensitive boxes sitting in factories, wind turbines, and utility closets, often miles away from a security guard. To protect these devices, we rely on Measured Boot and Full Disk Encryption (FDE) backed by a Trusted Platform Module (TPM). The promise is simple: if anyone touches the hardware or tampers with the bootloader, the cryptographic measurements (PCRs) change, the TPM refuses to release the decryption key, and the device turns into a useless brick. Safe, right?

Enter CVE-2023-43633. LF-Edge EVE OS, a popular operating system for edge virtualization, had a gaping hole in this logic. While it meticulously measured the kernel and the initrd to ensure the OS code hadn't been tampered with, it completely ignored a specific configuration partition.

This is the equivalent of a bank vault that checks your retina and fingerprints (the OS code) but ignores the fact that you're holding a handwritten note saying "I am the manager, let me in" (the config file). By placing a simple JSON file on the disk, an attacker can tell the OS to drop its shields, and the TPM—oblivious to the change—happily hands over the keys to the kingdom.

To understand this failure, you have to understand TPM Sealing. You don't just "measure" software into Platform Configuration Registers (PCRs); you have to seal your secrets against those specific registers. If you measure the bootloader into PCR 4 but don't tell the TPM "Only release the key if PCR 4 matches X," then the measurement is just a number in a log, not a security control.

EVE OS has a mechanism to override global settings using a file located at /config/GlobalConfig/global.json. This feature is intended for legitimate provisioning and debugging. However, in vulnerable versions, this file resided on a partition that was either mutable or effectively ignored by the TPM's sealing policy.

Here is the logic failure:

1. Boot Process Starts: The BIOS, Bootloader, and Kernel are measured. PCRs 0-9 are extended.
2. The Check: The TPM checks its sealing policy. It sees that PCRs 0-9 match the expected "Golden State."
3. The Unseal: The TPM releases the disk encryption key. The encrypted vault is mounted.
4. The Betrayal: The OS mounts the /config partition, reads the malicious global.json, and executes instructions to enable SSH and disable authentication.

The system was "secure" up until the millisecond after it decrypted the data, at which point it voluntarily surrendered to the attacker defined in the unmeasured config file.

The fix reveals exactly how simple the oversight was. In the world of Go and TPMs, everything comes down to a struct definition. The vulnerability existed because the list of PCRs used to seal the DiskKey was missing the index for the configuration measurement (PCR 13 or 14, depending on the version).

In pkg/pillar/evetpm/tpm.go, the developer defines which PCRs matter. Here is what the patch looked like for the initial fix (commit aa3501d6c57206ced222c33aea15a9169d629141):

// Before: PCR 13 (config) is ignored
DiskKeySealingPCRs = tpm2.PCRSelection{Hash: tpm2.AlgSHA1, PCRs: []int{0, 1, 2, 3, 4, 6, 7, 8, 9}}
 
// After: PCR 13 is enforced
DiskKeySealingPCRs = tpm2.PCRSelection{Hash: tpm2.AlgSHA1, PCRs: []int{0, 1, 2, 3, 4, 6, 7, 8, 9, 13}}

But wait, it gets better. This was fixed in version 8.6.0. Then, in the 9.x branch, the developers moved the measurement to PCR 14 during a refactor... and forgot to update the sealing policy again. This regression meant that versions 9.0.0 through 9.4.x were vulnerable all over again. It's a classic case of "security by spreadsheet"—if the dev forgets to add the number to the list, the cryptography is worthless.

Exploiting this requires physical access, but for edge devices, that's part of the threat model. Here is how an attacker turns a locked box into an open book:

1. Preparation: The attacker unscrews the chassis and removes the storage medium (SSD/SD Card) or boots a live Linux USB stick.
2. Injection: They mount the unencrypted configuration partition and create the file /config/GlobalConfig/global.json. The content is a shopping list of bad ideas:

{
  "debug.enable.ssh": true,
  "debug.enable.usb": true,
  "app.allow.vnc": true,
  "authorized_keys": "ssh-rsa AAAAB3... [ATTACKER_KEY]"
}

3. The Boot: The attacker puts the storage back and powers on the device.

4. The Bypass:

   • The GRUB bootloader runs (Measured: OK).
   • The Kernel loads (Measured: OK).
   • TPM Unseals Vault (Because the config partition wasn't in the policy).
   • Userland starts, sees debug.enable.ssh: true, and starts the SSH daemon with the attacker's key.

5. Profit: The attacker SSHs into the device. Since the vault was successfully unsealed by the TPM, they have full read/write access to all encrypted secrets, certificates, and application data.

A common rebuttal in security is, "If they have physical access, it's game over anyway." This is wrong. The entire point of TPM-backed Full Disk Encryption (FDE) is to secure data-at-rest even against physical theft. If a thief steals an ATM or a secure edge gateway, they should ideally end up with a pile of encrypted garbage.

CVE-2023-43633 breaks that contract. It allows the device to boot into a fully functional state under the control of the attacker. This allows for:

• Data Exfiltration: Extracting proprietary algorithms, customer data, or VPN keys.
• Lateral Movement: Using the trusted edge node as a pivot point to attack the upstream cloud infrastructure.
• Persistence: Installing deeper backdoors (like kernel modules) that might persist even after the config file is removed, assuming the boot partition isn't properly verified on subsequent boots.

The remediation involves two critical steps that had to be applied to the codebase:

1. Measure the Filesystem: A new GRUB module (measurefs) was introduced (commit 5fef4d92e75838cc78010edaed5247dfbdae1889). This calculates a SHA-256 hash of the /config partition and extends it into the TPM PCR.
2. Enforce the Measurement: As shown in the code section, the PCR list in evetpm/tpm.go was updated to include the new measurement.

For administrators running EVE OS, the only real fix is to upgrade to version 9.5.0 (or 8.6.0 if you are still on the older branch). If you cannot upgrade, physical security controls (tamper-evident tape, epoxy, locked cabinets) are your only defense against this specific attack vector.