4

Within the measured boot process, consider a scenario where I aim to create a measurement for a specific piece of code, perhaps, for illustrative purposes, a potentially malicious operating system. so i know that the PCR is read and extend only.

My understanding is that the firmware manually reads and hashes the boot loader sector, initiating the measurement (correct me if im wrong on this one). Subsequently, when the bootloader proceeds to measure the OS, does it engage in a similar process of manually hashing the entire OS, or does the OS autonomously measure itself? If it is the latter, what safeguards exist to prevent a malicious OS from providing a hash of a legitimate OS, creating therefore an authentic PCR? Conversely, if the former is the case, doesn't hashing the entire OS seem somewhat resource-intensive?

PS: I'm asking about this because if I want to make remote attestation of another device, how can i make sure that the PCR values are authentic and all the components in the boot chain are correct and not malicious and providing correct hashes.

1 Answer 1

2

You didn't really specify the type of device in question so my answer will focus on x86_64 devices running Linux. For phone, my reference is GrapheneOS with their Auditor App.

It all comes down to the integrity of the Root of Trust, which is the first piece of code doing the first measurements, to ensure the integrity and immutability of the whole boot chain (trust chain).

One may achieve it by enabling Intel Boot Guard or AMD Platform Secure Boot which fuses the public key of the OEM into the hardware. This integrity is unalterable unless the private key is leaked.

My understanding is that the firmware manually reads and hashes the boot loader sector, initiating the measurement (correct me if im wrong on this one)

The measurement began before the UEFI firmware.

what safeguards exist to prevent a malicious OS from providing a hash of a legitimate OS

The measurement of the stage to be executed is calculated and stored in a TPM. Since measured boot doesn’t stop the platform from booting, the host OS can’t be relied upon to report the hashes.

With verified boot, the Secure Boot mechanism would have prevented someone to replace the OS without you noticing. Contrary to measured boot, the boot process is stopped immediately after a wrong measurement.

The TPM also relies on these measurements to provide specific features like secure storage or remote attestation. With the sealing operation, you could bind the encryption key of a LUKS device (with systemd-cryptenroll) to the PCRs values. It ensures that the disk is decrypted only if the platform has booted with the expected hardware and software, and if no attacker tampered with the boot process.

You could add a PIN code (systemd feature) to prevent the TPM to happily unseal the LUKS key to a physical attacker in case you only have measured boot.

does it engage in a similar process of manually hashing the entire OS, or does the OS autonomously measure itself?

The secure boot doesn't measure initramfs and there is not pre-OS component that measure the whole OS.

The best solution to this is to boot the OS directly from the UEFI with a UEKI.

Additionally, IMA-measurement could be used to attest to the system's runtime integrity both remotely and/or locally.

how can i make sure that the PCR values are authentic and all the components in the boot chain are correct and not malicious and providing correct hashes.

You just have to use the sealing feature of the TPM.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .