Hacker News Reader

Comment by teddyh | Hacker News Reader

If your attacker is both sophisticated and able to access your hardware directly, the game is over; nothing we can do can currently avoid this.

What we can do is address the scenarios in which an attacker is either unsophisticated or remote. Normal network security takes care of the latter case, and for unsophisticated attackers, a good FDE (Full Disk Encryption) system covers it nicely. For laptops you can either live with typing in a password at every boot, or get a USB key of some kind. For servers with FDE you might want to use something to enable remote and unattended reboots, like (shameless plug) Mandos¹.

1. https://www.recompile.se/mandos

View on HN

> If your attacker is both sophisticated and able to access your hardware directly, the game is over; nothing we can do can currently avoid this.

I think with blanket statements like this it's important to define sophisticated.

For example, what kind of resources are required to break the disk encryption of a computer protected with tpm 2.0 + secureboot + luks w/tresor* ?

I'm of course not talking about social engineering or fooling the user into typing their password on a fake system, since this is preventable.

* https://www.cs1.tf.fau.de/research/system-security-group/tre...

> For example, what kind of resources are required to break the disk encryption of a computer protected with tpm 2.0 + secureboot + luks w/tresor* ?

Intel ME and the equivalent AMD PSP.

> I'm of course not talking about social engineering or fooling the user into typing their password on a fake system, since this is preventable.

As other pointed out when the atacker has physical access it is game over. Also network access is insecure due to management engines.

Again, Blanket statements. What ME flaws?

There are dozens of known CSME vulns -- there's a list on cvedetails [0] which itself seems to be missing some (e.g. 2019-0090/2019-0091). Plenty of these could be used by a sophisticated attacker with physical access, and some can even be executed remotely.

Here's an Intel Whitepaper detailing one such vulnerability of moderate severity (CVE-2019-0090, CVSS 4.4) [1]. From the 'Potential Consequences' table:

> Unauthorized BIOS compromises OS loader and OS integrity... All use cases / user secrets protected by Intel TPM are compromised.

Other bits and pieces of firmware including AMT have been similarly plagued with vulns [2], such as CVE-2017-5689, with a CVSS score of 10!

These are often difficult to patch, and even more difficult to convince manufacturers to spend the effort testing and distributing updates for their products. My own laptop is still running a version of CSME vulnerable to many of these attacks.

[0] https://www.cvedetails.com/vulnerability-list/vendor_id-238/...

[1] https://www.intel.com/content/dam/www/public/us/en/security-...

[2] https://www.cvedetails.com/vulnerability-list/vendor_id-238/...

GP already made space for this analysis by admitting a sophisticated/unsophisticated axis, thus the contrary stance of your comment is unnecessary.

You don't really make an argument on where your example should fall on that axis, which is what I would have preferred to see.

I think it's a fair doubt.

In this case, I don't know if sophistication could mean an evil maid attack with a breadboard and $15 worth of electronic components (which was required to break the tpm 1), or something better than what the FBI has since they struggled to unlock a terrorist's phone. I can worry about the former, and relax about the later.

I'm not an expert and when someone throws that statement with authority I'd like to know if I'm vulnerable to geek or to the CIA

It's certainly possible to MITM a TPM, this is why MS built all the keys into the CPU on the Xbox One[1].

[1] https://www.platformsecuritysummit.com/2019/speaker/chen/

AFAIK that wouldn't be the case with TPM 2.0

> For example, what kind of resources are required to break the disk encryption of a computer protected with tpm 2.0 + secureboot + luks w/tresor* ?

There are two main vector of attacks to get access to the data. The simpler version are those that attempt to get they key by recording it when the user type it in, like hooking into the keyboard. No real need to try make it a fake system since no keyboard that I know of has security built in to prevent MITM attacks. If we are asking what spy agencies do, I would also suspect that the camera on a laptop could be replaced with a look-alike with a transmitter.

The other main attack vector is to target the hardware while it is running and without waiting for the owner to type in the password. Get access to the main bus would be the primary target if the ram is not vulnerable (usb vulnerabilities, debug pins on the mother board, and so on). Vulnerabilities of the software is also an alternative, and if time is not a problem one could in theory wait until a vulnerability is found. I would assume that all internal connections are to a degree vulnerable to malicious designed hardware in mass consumer laptops, sever and desktops, but the main question is how to do it hot without crashing the machine.

> break the disk encryption of a computer protected with tpm 2.0 + secureboot + luks w/tresor*

On Windows (even modern versions IIRC) you can sniff the traffic (or maybe forge requests? I think it was simply sniffing though) to the TPM and get the keys to decrypt the HD, if there is no additional protection (like a PIN or password). Don't know if this is also applicable to Linux stacks. Kind of weird the interface has not been designed and/or programmed to resist to such attack, although of course password-less full disk decryption is often going to be less secure than with one, at least Macs are not subject to the same attack, I think?

FWIW, TPM 2.0 can encrypt the TPM traffic, so the attack by physically sniffing the TPM (https://dolosgroup.io/blog/2021/7/9/from-stolen-laptop-to-in...) is no longer possible.

It can but from the article, with a not so old Windows stack it seems that this encryption is not used:

> At the time of this writing BitLocker does not utilize any encrypted communication features of the TPM 2.0 standard, which means any data coming out of the TPM is coming out in plaintext, including the decryption key for Windows. If we can grab that key, we should be able to decrypt the drive, get access to the VPN client config, and maybe get access to the internal network.

> For example, what kind of resources are required to break the disk encryption of a computer protected with tpm 2.0 + secureboot + luks w/tresor* ?

a: 1 copy of all the computer hardware present in the target system.

b: 1 secure radio link of sufficient bandwidth.

c: 1 apartment or van near the target system.

d: Sufficient equipment to interface with the target system (now in said apartment/van[c]) well enough to replicate its login UI (via radio link[b]) on the fake copy of it[a] you left in its place when you stole it.

There are millions of lines of code in a bios supported by billions of transistors. A wireless component can fit inside any innocuous chip at any part.

Software wise, the bios can contain many flaws that can be exposed via peripherals, remotely, etc. The certificates are kept secure by unknowns parties protected by algorithms that few can prove the validity of.

A physical attack access is rarer (* from sophisticated attackers). Sophisticated/dominant attackers leverage low end attackers to do the actual physical attack. Identification and knowledge of such an attacker greatly diminishes that attacker's capability and credibility. Low end attackers are also resources.

Remote attacks do exist. One of the common attack frameworks is a type of radar attack that exploit bugs in the hardware design. They work like RFID where some component has an exploit that can be activated remotely by radar. Defending against such attacks is quite difficult. Other attacks include errors in manufacturing. Not all chips come out of the oven equal, and a sophisticated attacker need not risk physical detection when they are capable of deducing the how to exploit those errors.

> nothing we can do can currently avoid this.

Unless you scope "sophisticated" as "can compromise hardware we currently believe is secure", we can get to the point where the only mechanism is a hardware keylogger (which is something made far more complicated by, eg, using a Bluetooth keyboard). This has a few problems:

1) It's relatively easy to detect - you're adding a new physical object 2) You're only seeing a small amount of what you want to see - you have no ability to inspect the data on the disk, and if the user is using MFA then getting their passwords doesn't get you much 3) Exfiltrating the data isn't easy. Either you need further physical access to extract the object, or you need it to broadcast data occasionally and that's another thing that's going to make it easier to be detected

If you're able to move from "A physically present adversary can compromise the system in a way that gives them complete access" to "A physically present adversary can log your keystrokes", that's a win.

The issue isn't compromise of the remote system, but trust of that remote system. TPM 2.0 gives us the ability to make measurements before establishing trust.

Well, you can probably annoy at least some attackers by using tamper-proof seals on your PC case and act accordingly if they are broken, because that would likely prevent them from conducting the first physical attack. But that won't help in the long run.

Outstanding locks on a reinforced door and a combination of visible and hidden cameras in the hallway are probably more effective.

All tamper-evident devices can be defeated by a sophisticated attacker with physical access.

https://www.slideshare.net/MichaudEric/how-to-steal-a-nuclea...

This is incorrect

Perhaps you'd like to cite a source.

Wait, did I miss something or how does a sophisticated attacker break encryption with ~100+ bit password entropy?

if they have access to your device, they don't have to. They'll just snoop on whatever you use to enter your key.

I believe OP is referring to the fact that a sophisticated attack has access to the hardware and you continue using it afterwards. They could, for example, change the unencrypted /boot partition to log the password you use to decrypt your partition. Or, if you sign the boot partition, they could install a hardware key logger, or do any other kind of hardware modification that defeats the security. Preventing this kind of attack is incredible difficult. They are many means to prevent those kind of attacks but, for the most part, it just making it harder for the attacker so that the attacker needs to become even more sophisticated.

Full disk encryption only helps if you are worried that your hardware gets stolen

Just wanted to add that this is generally referred to as the "Evil Maid" scenario in case someone wants to Google it.

It can be mitigated somewhat with secure boot, tpm technologies etc but due to the breadth of possible attacks it's really hard to do against a serious attacker.

Even the sound of the keyboard is often enough to give your password away.

Or encrypt the boot partition. Libreboot supports this.

(Though to be fair, Libreboot only runs on a very limited number of old devices).

No amount of software complexity defeats a hardware keylogger, though... or like, a no-touch version of that, such as a spycam in the room that records the sight and sound of you typing your password.

Security token defeats all that.

And glitter nail polish :)

How does one go about breaking FDE tho? If it's secured by a password that's only in your mind.

Keylogging? Depending on the bar for sophistication, I'm told this could be done by a microphone at the other end of town, or by measuring the power consumption of your building from the grid... but there's probably something at the middle point between these paranoid risks and something simple anyone could place in your computer case / keyboard.

> If your attacker is both sophisticated and able to access your hardware directly, the game is over; nothing we can do can currently avoid this.

This, particularly if your hardware has Thunderbolt capabilities. It's been proven that Thunderbolt can be exploited to give an attacker direct memory access[0], and there's really no recourse for it in the spec. Physical access is going to be game-over for a very long time, unfortunately.

[0] https://thunderspy.io/#affected-apple-systems

> there's really no recourse for it in the spec

There's not only a recourse for it, modern firmware implements it. You just use the IOMMU to restrict Thunderbolt devices to being able to access their own buffers.

Reply on news.ycombinator.com