On Fri, Mar 6, 2020 at 3:55 PM Wols Lists <antli...@youngman.org.uk> wrote: > > On 06/03/20 19:39, Rich Freeman wrote: > > > > They don't detail the effort required. If the firmware is patched it > > sounds like it still requires tinkering with hardware. > > By then it's TOO LATE. The firmware is signed for security, AND LOADED > AT BOOT. But if the boot process is compromised, the attacker simply > doesn't load the patched firmware.
The patched firmware executes before any software you boot, assuming your device was patched before the hacker got his hands on it. Obviously if you lost your laptop last week and the hacker has it in their closet, then they're going to be able to attack the unpatched firmware with a software hack. >From the descriptions I'm seeing it sounds like the attack against the hardware itself requires physical access to some of the busses. A proper TPM should resist this sort of attack, and that is why this is a vulnerability. However, you can't just stick a USB drive into a computer to hack it if the firmware is patched. > > > > Yes, but keep in mind the signing keys have nothing to do with disk > > encryption. It is for remote attestation. Hence my Netflix comment. > > > Signing keys have EVERYTHING to do with whether you can trust the CPU. > If you can't trust the CPU, then it can simply read the disk encryption > credentials without any reference to whether it SHOULD read them. So, I think you're conflating a few different things here. First, trust is a choice you make. Whether you trust the CPU or not makes no difference in whether somebody else can defeat the embedded TPM. Second, the signing keys we're talking about are keys embedded in the CPU used by the CPU to sign stuff. These keys aren't used for encrypting anything, and they aren't used for decrypting anything. They're also not used to verify firmware/etc. It would make no sense to put the firmware signing key in the CPU - that key would be locked up at the firmware vendor's HQ with the corresponding public key embedded in the CPUs. Don't get me wrong - encryption keys stored in the CPU are compromised by this vulnerability. However, this has nothing to do with the signing keys. I suspect that modifying the firmware might also be possible due to this vulnerability, by replacing the public key in the CPU with a new one that you generated. Again, that has nothing to do with the signing keys on the CPU. The signing keys should just be associated with remote attestation. > And it only takes ONE person to crack that master key ONCE, and > EVERYBODY is up shit creek. No - there isn't any master key stored inside an Intel CPU that can be used to compromise the encryption on other hosts. We're talking about the signing keys used for remote attestation. Again, Netflix and Intel and similar companies are going to be ticked if that master key is leaked, but it won't have any impact on disk encryption. Of course, disk encryption is still compromised by the vulnerability. It just has nothing to do with the master signing keys (which are also model-specific and not completely universal), and hacking any individual device, if patched, will probably still require a hardware-level attack against that specific device. > At the end of the day, it's a "tree of trust". And once the root key is > compromised, you can NOT trust ANY key that was secured by said root > key. Yup. Fortunately the disk encryption keys are unique to each device, and stored in the compromised TPM hardware. They aren't really secured by a root key in any meaningful way. -- Rich
