Hacker News new | ask | show | jobs
by awesomeMilou 1052 days ago
> that can be exploited remotely, they can keylog -> steal your PIN -> replay it later to dump the key. Or just dump the key in memory if they have a PE (privilege escalation) as well.

That can't happen if a TPM is used correctly. If the TPM is coupled with an OPAL enabled SSD for example, the actualy key used for data encryption is never loaded into main memory. Sure, disk content can be read by a malicious OS, but you do not gain access to any encryption keys. Additionally, you prevent MITM attacks by using challenge response authentication which some TPM's support, so again, your key is never revealed.

> It cannot protect against an attacker who installs something on your unattended computer

This is a strawhat since you won't ever be able to protect from user space malware. Apart from that, TPM's can enforce mandatory access control if supported (I know the T2 on Macs does exactly that). So no, you cannot easily install a root kit and expect it to work.

> It cannot protect against a compromise in the boot chain (e.g. a UEFI driver is exploited, and it lies to TPM about the subsequent stage of code that is loaded while running a malware implant)

At this point we are in the realm of an attacker stealing your device, desoldering a chip and rewriting the firmware on that chip. Were talking about _considerable_ ressources spent, just to trick you into thinking your device hasn't been compromised.

I know that on non-Apple devices vendors will likely use some insecure off the shelf solution, but if done correctly these things are as close to unbreakable as possible.

> Basically the most common ways people get compromised

The TPM spec was written by NIST and it's purpose is not to protect the common user, but to offer advanced security features for business clients and governments. And there, a device that get's stolen is a common occurence.

The reason you see it integrated in consumer devices for cost reduction. It getting abused for DRM purposes is entirely the media industries fault.

1 comments

You can edit UEFI drivers from the operating system's bootloader, and you can even flash the UEFI itself from the OS in most computers. While secure boot. Failing that, you can shim a preloader between the bootloader and the UEFI and load arbitrary drivers despite secure boot, like is done here : https://github.com/ValdikSS/Super-UEFIinSecureBoot-Disk

Any sufficiently motivated attacker can make a UEFI rootkit happen, and it's in the wild right now. TPM really do offer no protection to users, either against userspace malware, or rootkits. It's purely about DRM.

No, this isn't true nor correct.

Secure Boot and TPM do offer tangible security benefits and is security features you can take ownership of.

Secure Boot allows your own key hierarchy, and TPM allows you to take ownership.

The linked boot disk isn't really proof that Secure Boot is useless. If you don't set a MOKManager password (as you should), and you change the security state of the machine while present at the keyboard. Yes you can boot things.

This is intended to make sure people can actually decide to trust things. And having insecure defaults makes this less useful. Not very surprising.

EDIT: The bootdisk won't work with a recent shim nor a recent grub. The old shim it was using should be revoked if you have any remotely updated machine as well.

TPMs could also prevent attacks like this on your machine.

Incidentally I've invested quite a bit of time in making user-friendly Secure Boot tooling as well. https://github.com/Foxboron/sbctl