[izacus]

> Of course, that doesn't mean you're protected against attackers who have physical access to the machine; they can simply install a keylogger.

How would that attack work if someone stole my Ryzen powered laptop with full disk encryption, TPM2.0 and secure boot with firmware password enabled?

[blueflow]

I'd buy you an replacement laptop of the same model and then install a rendering of your boot process and password prompt on it. Doing a switcheroo and waiting in my bunker until the fake sends me the password you entered.

The screen/keyboard is not authenticated to the user, and TPM is not capable of fixing that.

It doesn't require some state actor to do that. Just money.

[Foxboron]

`tpm2-totp` defeats the entire "replace the laptop" threat scenario.

https://github.com/tpm2-software/tpm2-totp

[blueflow]

The "replaced laptop" scenario is a full MITM on the hardware. TOTP generally does not protect against MITM. The required TOTP code is, in this scenario, generated by the device in the attackers hand. So the fake could also display it.

[Foxboron]

You need to decide between the attack here. Are you subverting hardware or are you replacing a laptop?

The TOTP token here is sealed inside TPM.

[blueflow]

And what do you need to do to unseal it? And why cant the fake laptop relay that to the real laptop?

[Foxboron]

It's never unsealed. `tpm2-totp` does an encrypted session to the TPM and runs `TPM2_HMAC` on the TPM shielded key, you can also include PCRs to add further authentication to this entire exchange.

What do you mean with "relay"?

(All of this is trivially solved with glitter nail polish anyway.)

[dist-epoch]

A solution would be to have two passwords, and display a secret security image between them.

User is required to not enter the second password if the wrong security image is displayed.

You can still attack it with a fancy radio transmitter which transmits the security image from the stolen laptop when it's displayed after you've entered the first password to the second laptop.

[p_l]

Attestation closes this vulnerability, for example through tools like Ultrablue [1] which provides a self-hosted method of verifying that the TCB has not been modified through external tool (in this case, your phone running Ultrablue)

[1] https://github.com/ANSSI-FR/ultrablue

[blueflow]

The TCB has not been modified - that's the point of that attack. Its just physically elsewhere. A high 24 dBi high gain antennae to close that gap costs 70 EUR and you would attest the device in the attackers hands, not the one in front of you.

[hedora]

I think some of those hardware attestation thingies use clocks and tight latency jitter bounds to make replay attacks harder. If it takes more than "2 x time light takes to move 10 ft + deterministic delay from the other side", or less than the deterministic delay, then they refuse to unlock.

Some cars even get this right these days. Most don't.

[fargle]

i like the way you think

[wooosh]

Probably not the most practical attack, but it is very possible to MITM the connection between the keyboard itself and the motherboard.

[izacus]

And then return me my laptop and steal it again?

[xzjis]

You have to consider what kind of risk you are protecting yourself against.

It's highly unlikely that you would be the target of such a highly sophisticated attack, but a hacker could get into a place where you left your computer without surveillance (such as your home or a hotel) for about 15 minutes, and install it inside your computer.

If you think you could be the target of such an attack, you could maybe enable an alert in the settings of your UEFI if your computer has been opened (I know that my ThinkPad has that option), or the better option is to always keep your laptop with you.

[izacus]

I'm mostly asking because the original poster was painting a process that can be sniffed off the bus (that is - buy a stolen laptop off ebay, try to boot it, sniff the key off the bus) with a process that requires active targeting and multiple breakins to work as equivalent.

It seems like these security discussions always devolve into rather funny moving of goalposts without actually considering how much work each exploit requires.

[michaelt]

The goalposts haven't moved in my mind, but I suppose I didn't make them clear in my first post.

Basically the TPM provides a set of features that are really useful for corporate Windows deployments. No more forgotten passwords, because the self-unlocking disk encryption sends the user straight to the Windows login screen, and helpdesk can reset forgotten Windows passwords remotely.

And for casual home Windows users, it lets them log in with a 4-digit PIN or with biometrics, so it's got usability benefits for them too. If every OS now needs Microsoft's signature of approval, or a really fiddly setup process? Well they were running Windows anyway, so no problem.

These usability/support benefits rely on self-unlocking disk encryption, which is vulnerable to sniffing if someone gets a stolen laptop on ebay.

For the kind of technically sophisticated, security enthusiast users who comment on blog posts about TPMs? We're more than happy to key in a strong unique password at every boot, and if we forget the password and lose access to everything on that disk that's just the system working as it's supposed to.

For us, the benefits of TPMs and measured boot for personal use are a lot more obscure. You'll sometimes hear people claim it protects against 'evil maid attacks' where an attacker repeatedly gets physical access to your laptop. The truth is it provides no such protection.

[Foxboron]

> For us, the benefits of TPMs and measured boot for personal use are a lot more obscure. You'll sometimes hear people claim it protects against 'evil maid attacks' where an attacker repeatedly gets physical access to your laptop. The truth is it provides no such protection.

TPMs give you fine and adequate protections in many scenarios, even physical ones.

They also provide you with better protection for private key material.

I'll even give you an example:

https://github.com/Foxboron.keys

The last key is a TPM key from my `ssh-tpm-agent` project: https://github.com/Foxboron/ssh-tpm-agent

Here is the private key: https://paste.xinu.at/9fc2YJQuUCbg1Sa/

I don't remember if the key has a PIN (it was for a presentation/demonstration), but if it has it's like 4 digits long.

[AnthonyMouse]

> Basically the TPM provides a set of features that are really useful for corporate Windows deployments. No more forgotten passwords, because the self-unlocking disk encryption sends the user straight to the Windows login screen, and helpdesk can reset forgotten Windows passwords remotely.

Unclear why this requires a TPM. Boot the system from a static unencrypted partition containing no sensitive data, display the login screen, when the user authenticates the system uses their credentials to get the FDE decryption key from the directory server. Bonus: Now the FDE keys are stored in the directory server and if the system board fails in the laptop you can remove the drive and recover the data.

An attacker with physical access could modify the unencrypted partition to compromise the user's password the next time the user logs in, but they could do the same thing with a hardware keylogger.

> And for casual home Windows users, it lets them log in with a 4-digit PIN or with biometrics, so it's got usability benefits for them too.

This could be implemented the same way using Microsoft's servers, given that they seem to insist you create a Microsoft account these days anyway.

It's not clear that unsophisticated users actually benefit from default-FDE though. They're more likely to lose their data to it than have it protect them from theft, and losing your family photos is generally more of a harm than some third party getting access to your family photos.

[michaelt]

A high grade hardware implant doesn't just capture your password, it'll also replay your password along with a curl | sudo bash at 4am

[rwmj]

Bluetooth keyloggers are a thing. The attacker would need to be nearby.

[xattt]

Not if there’s some sort of cell bridging device nearby as well.

[HeatrayEnjoyer]

Relays can be prevented with a round-trip timeout. Limit to 8ft/c, should be plenty for a keyboard. You can't outpace light.

[izacus]

I'd have to use bluetooth keyboard then, right?

[Foxboron]

Glitter nailpolish on your machine seams/screws and tamper detection. Keyboard sniffing is not as trivial as people make it out to be.

[fellerts]

I doubt your physical keyboard's connection to the motherboard is encrypted (I'd guess USB, I2C or maybe even PS/2 internally). I would also not be surprised if you can get small in-line sniffers that an attacker, with physical access for half an hour, could hide in your laptop.

All bets are off if your attacker is determined and has physical access.

[atoav]

There have been papers about extracting key presses from acceleration sensors of a phone, or from the sounds of key clicking by statistical inference what feels like a decade ago. You probably don't even need to touch the laptop to do that.

[izacus]

I mean, I wouldn't be there to type in my password because the laptop was stolen.

[user_7832]

There might be hardware "solutions" to that problem.

[contingencies]

I believe https://xkcd.com/538/ is the comic you're looking for.

[user_7832]

Lol that’s also true, though I was alluding to hardware sitting next to/after the keyboard. But whatever is easier I guess.