Yes, if the user chooses to ignore the feature within Heads that alerts them to tampering (TOTP code) then attack #1 would work, but it would be better for the attacker to just set a new secret as then it wouldn’t hide the 6-digit code but instead just display some other code and a user who isn’t checking the code at each boot (as they should) wouldn’t detect it.
Attack #2 is also possible, but it would need to be custom-tailored for each user as each user’s BIOS will be slightly different (as it will contain their custom GPG keyring and settings) so the attacker would need to pull down their particular BIOS and couldn’t just use a standard Heads ROM. We have tested this type of attack and it does work! Our plan is to mitigate it for remote attackers by setting the ROM to read-only mode inside Heads at boot time. We also have some plans to mitigate it in the future for local attackers but we aren’t ready to announce anything along those lines yet.
Currently we have added patches to Heads such that you can flash the ROM within Heads itself, but we haven’t yet added the feature that sets the read-only bit when it boots into the OS itself. Once it’s enabled though, the attacker would need to be physically present to be able to reboot into Heads to reflash the ROM.
It’s important to remember that our goal with this is to detect tampering but while still allowing the user to completely control their device. That’s why by default we have Heads alert the user to tampering but we explicitly don’t prevent them from booting into a tampered system. We offer a particular “unsafe boot” option within Heads that allows exactly this (but sets the console background to be red to warn the user that this is risky) so they can boot into a tampered-with system to inspect it or otherwise fix it. Because innocent tasks like kernel updates have the potential to trigger this, we need to be careful about anything that would lock a user out.