Stopping Evil Maid Attacks with UEFI Firmware Logs

Firmware integrity measurement logs safeguard UEFI systems against Evil Maid attacks by creating an unforgeable, step-by-step cryptographic record of the boot process through a mechanism known as Measured Boot. By recording hashes of every firmware component, driver, and bootloader into a Trusted Platform Module (TPM) before execution, the system can detect unauthorized physical modifications. If an attacker tampers with the UEFI firmware or boot chain while possessing physical access, the recorded measurements alter, preventing the release of full-disk encryption keys and blocking access to sensitive data.

The Evil Maid Threat to UEFI Systems

An Evil Maid attack occurs when an adversary gains brief, unsupervised physical access to a target machine. In UEFI environments, attackers typically attempt to:

  • Flash modified, malicious firmware directly onto the SPI flash memory chip.
  • Replace or inject unauthorized UEFI Option ROMs or drivers.
  • Downgrade boot components to vulnerable, older versions (known as downgrade or replay attacks) to bypass standard Secure Boot checks.
  • Alter the bootloader to inject a keylogger capable of capturing full-disk encryption (FDE) passphrases.

While UEFI Secure Boot blocks unsigned code, it can be bypassed if an attacker exploits a known vulnerability in an officially signed, older binary (such as the BootHole vulnerability) or modifies system NVRAM variables. This makes integrity verification essential.

How Measured Boot Generates Integrity Logs

To counter these sophisticated physical interventions, modern systems rely on Trusted Computing Group (TCG) standards to execute a "Measured Boot" sequence:

  1. Root of Trust for Measurement (RTM): The process begins at an immutable hardware layer—the Core Root of Trust for Measurement (CRTM)—located within the CPU or protected SPI controller. This code cannot be altered without replacing the underlying hardware.
  2. Measurement via Cryptographic Hashing: Before any executable code or configuration file runs, the current stage computes a cryptographic hash (typically SHA-256) of the subsequent stage. This includes firmware code, configuration settings, Option ROMs, and the operating system bootloader.
  3. Extending the TPM Registers: The calculated hashes are sent to the TPM's Platform Configuration Registers (PCRs). Rather than overwriting existing values, the TPM uses an "extend" operation: New PCR Value = Hash(Old PCR Value || Current Stage Measurement) Because this operation is mathematically irreversible, an attacker cannot forge the final register state without executing the exact, untampered sequence of original code.
  4. Generating the TCG Event Log: In parallel, the UEFI firmware writes a human- and system-readable audit trail known as the TCG Event Log. This log lists every item measured, its specific measurement, and the target PCR index.

Neutralizing the Attack: Sealed Storage and Attestation

Firmware integrity measurements actively disrupt Evil Maid attacks through two core mechanisms:

1. Sealing Full-Disk Encryption Keys

Operating system encryption tools (such as Windows BitLocker or Linux LUKS via systemd-cryptenroll) bind the master decryption key to specific PCR states.

  • Under normal conditions, the PCR values match the trusted baseline, and the TPM unseals the key automatically at boot.
  • If an Evil Maid alters the firmware, modifies a UEFI driver, or swaps the bootloader, the cryptographic extend operations produce a different value in the relevant PCRs (commonly PCR 0 for firmware code and PCR 2/4 for boot applications).
  • Because the target PCR values do not match, the TPM refuses to release the encryption key. The system refuses to boot automatically, halting the attack and demanding a high-entropy recovery key that the physical attacker does not possess.

2. Local and Remote Attestation

Beyond local key sealing, the TCG Event Log enables attestation:

  • Integrity Validation: When analyzed, the OS or a remote server replays the event log, computing the expected PCR values from the recorded events. If the calculated result fails to match the actual, hardware-backed PCR value held inside the TPM, the system flags tampering.
  • Remote Attestation: In enterprise settings, the TPM uses an Attestation Identity Key (AIK) to cryptographically sign the PCR values and event log, sending them to an external verification server before granting network access. An infected device is immediately quarantined.

Through this chain of cryptographic trust, firmware integrity measurement logs shift the security boundary from simply attempting to prevent execution to ensuring that any physical tampering leaves an undeniable, machine-verifiable signature that neutralizes the attacker's objective.