Making it harder to compromise Heads even if attacker can flash externally

[UndeadDevel]

I've been playing with this idea in my head and I'm curious what you think:

One of the characteristics of Heads' typical deployment environment is very constrained available space for the firmware. I wonder if that could be made use of:

What if, in connection with #216 (encrypted boot partition), the encrypted boot would store an additional secret that would be needed for unlocking the main LUKS container? I'm thinking here along the lines of:

• the system has only one internal drive (SSD)
• the only other accessible persistent storage is the BIOS flash space (leaving aside TPM nvRAM here)
• the SSD has only two partitions - boot and main; main is the main LUKS device and there is no accessible free space on the SSD
• boot is encrypted via a large keyfile and either a passphrase or another keyfile that comes from the user (e.g. external usb or dongle)
• the large keyfile is the entire content of the BIOS flash dd-ed in RAM

If I'm not misunderstanding something then it seems to me this would make it very difficult for the attacker to install some malicious firmware without breaking the ability of the system to decrypt the boot partition, because there simply won't be enough space in the BIOS flash to store the image of the non-compromised BIOS + the compromised BIOS (which needs to look and feel like normal Heads).

The only two ways (2 and 3 are closely related) I see right now how this could be defeated is if

1. the attacker manages to create a fake Heads that looks like Heads and fools the TPM and does HOTP properly while also being small enough that it can keep the (possibly compressed) image of the original Heads in flash space.
2. the attacker corrupts the main partition to store the image of the original Heads there
3. the attacker replaces the SSD with another one that has more storage space and stores the image in the extra storage space, while the boot and main partitions are replicated (cloned) there

If 1) is possible then maybe this idea is not so good after all, though this would mean that Heads is easy to compress; one possible countermeasure, which would also serve to make this solution compatible with a much wider range of motherboards (the amount of flash ROM available varies a lot) would be to "fill up" the remaining space of the flash ROM with random data generated before flashing.

If only 2+3 are possible then at least the user could know that something is up, because he would likely notice that his LUKS device has been corrupted or the SSD being different (so better than nothing, even though attacker could have imaged the container and now has the passphrase, but at least the user knows; there are also more ways now to more easily notice something is up, before entering the TPM DUK passphrase or DRK passphrase).
To further improve the situation and mitigate 2+3, it might be possible to make use of OPAL native SSD encryption:
Basically the "main" partition (LUKS device) would remain the same, but now be "double-encrypted"; IIUC this doesn't have a performance penalty on OPAL drives, because they don't care if you activate OPAL or not; the difference is only whether there is a key set up or not.
The boot partition would be encrypted only once, namely via OPAL just like the rest of the data (also note that the latest cryptsetup supports OPAL now). Assuming that OPAL can be set up, e.g. via cryptsetup, such that it takes the key file (BIOS image) + passphrase / second external key file, then this would actually prevent the attacker from being able to switch out the SSD or corrupt any data on it, because, IIUC, OPAL won't allow reads or writes unless it is unlocked.

Of course OPAL is proprietary in implementation and code and so cannot be ultimately trusted, but I think for most threat models this would actually add quite a bit of extra security and the main user data (main partition LUKS device) is still LUKS software encrypted in addition to the OPAL hardware encryption. Also, with the OPAL part implemented, the secret in the boot partition would not be necessary anymore, it seems.

Now, since I'm not an expert on any of these topics, I'm sure I've missed some glaring holes in my scheme...what do you think?

[tlaurion]

I will revisit but here first thoughts on what I had in mind on my side. Again trying my best to address goals (FDE including boot which should be a seperate discussion on which I have some ideas since we now have Authenticated Recovery shell and could definitely add a TPM "boot time DUK" which only heads would seal/unseal, eg vaultboot did it with additional labeling of boot partition in their codebase) and here, which is kinda RFC for additional layers of security added for externally spi flash access.

I will just start by separating those two ideas because I'm already running out of time today, but there are multiple ways to accomplish this.

Let me again remind that :

• to be able to craft a tampered rom that would unseal TOTP secret, what can be accessed through recovery shell and final OS's cbmem -L TCPA/TPM event log traces. As a reminder, those exposed measurements of measured binary sections (FMAP + raw content of coreboot stages from bootblock up to payload) are directly exposed from the TPM event log, creating what the TPM extends from TPM clean init state (0) of PCR2, en tending previous measurement with measured content up to the final content of PCR-0 which can be read from pcrread of pcr2.
• An attacker knowing what is the current commit of built rom would be able to get the coreboot stages raw hashes and additional user content added to cbfs (persistance of user content across internal flashing)
• An attacker would need to be able to backup the rom and then flash back a crafted rom faking measurements of all the stages and include user persistent configs. Or hardcoded measurements in both coreboot and heads code.
  • To accomplish that, attacker needs to have access to recovery shell and backup firmware. Craft a firmware that reports same raw content measurements. And flash it back externally or internally.
    • Heads offer authentication prior of recovery shell access. When enabled, we currently block evil maids from accessing recovery shell to take needed backup needed to craft firmware image. Bootguard debate and RoT in cpu is out of the question as of now. DRTM is not yet implemented. And WP protection enforced by SPI with newer flashrom requires a non-existent gadget to implement hardware switch to set WP pin to GND, which again, physical access to SPI would defeat protection.

Tldr: as of today, if an attacker knows what is the commit ID, it's not enough to create a rom that could fake measurements. The attacker needs rom backup, which needs physical access to SPI chips, or Recovery shell access, which is successfully prevented with Gpg detached signed Authentication and accepting to create Key Material backup at OEM factory reset/re-ownership, which enables the feature.

I will review your ideas in detail next time I have an idea. But my idea here would be to create proper helpers to be able to inspect raw content (there is WiP PR on that) and adding tools to externally inspect a backup rom.

Other measures will be ko with spi access, where limited space on SPI flash is only true for older devices and non-maximized board versions nowadays. I'm not sure of having that as a premise for security is a good strategy. But will think about the rest of un reviewed ideas here.

@UndeadDevel thanks for creating this discussion!

[UndeadDevel]

Thanks for your reply! Yeah I guess I should have done more research on how much flash ROM is available across systems; I just sort of assumed that it would be fairly homogeneous, but if the variation from motherboard to motherboard is significant then indeed the main part of my idea is moot; from a preliminary search it seems that the flash ROM is always a multiple of 64 KiB, with 1 MiB+ being common; in case of the NV41, according to dmidecode, it's a whopping 32 MB. Oh well...

I guess the only way to salvage the idea would be to suggest a Heads feature, such as Heads generating lots of random additional data, which will be used as a filler to make the total Heads + filler be the size of the available flash ROM. However, for cryptsetup at least, it allows only one key file up to 8 MiB, so one would need to use some encryption program that would support larger key files.

[tlaurion]

The discussion here might get complex and will need to make things way clearer, since not all platforms are equivalent, and not strategies can be applied.

We have to make a clear distinction between what hardware backed root of trust mechanisms are available to which platform chipsets. What we can do today, what can be done in the future for old platforms as well, and what can be done for newer platforms. From the outcome of those discussions, documentation will need to be updated.

SRTM

Ivy Sandy Haswell (<Gen 6 CPU)

• Bootblock write protection if bootblock stops to evolve. I revisited recently and it doesn't seem to have changed for the last 2 years, but need to confirm hash. If that's the case, a discussion should be engaged with coreboot, and we could have a guide to help people short WP pin to GND (actively enforcing SPI protection from an internal flash). This is not easily revertible. And would permit bootblock to be trusted to measure itself and next phases. Tldr : soldering and epoxy needed, or gadget with switch needs to be manufactured. As strong as irreversible soldering + epoxy. Of course if bricking occurs, an epoxied SPI is literally a brick and depending how good that was applied, it light be impossible to remove the epoxy that fused with the motherboard. Such board should never run personal builds nor be used to test things and only run production ready rom images where bricking is thought improbable.

Gen 6+ CPU

• measured boot can have RoT in CPU through ACM+sInit and IBB definition PCR-0 measured region by CPU include bootblock. Basically, CPU launches ACM after having verified ACM integrity through fused CPU key and then have ACM measure bootblock to PCR-0 prior of launching it, which then does current measured boot process. The difference here is that PCR-0 cannot have its measurement done by any other thing then ACM and therefore have a RoT for measurement in ACM.

DRTM:

• ACM+sInit blobs need to be added to coreboot. Trenchboot needs to be investigated and Heads modified accordingly. Ivy bridge+ should be able to be supported but lack of expertise here to comment

I will edit this post a lot.