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

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

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.

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.

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

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.)

Yes and you can relay that authentication, too.

The same way the fake laptop can relay your password to me, i could also relay the generated TOTP code from the stolen laptop to the fake in front of you. As tried to convey, the fake laptop is basically a full MITM on your screen/keyboard.

Making a machine visuals non-reproducible helps that, but only if the attacker cannot easily switch the exterior parts (chassis, keyboard) between the two machines.

> The same way the fake laptop can relay your password to me, i could also relay the generated TOTP code from the stolen laptop to the fake in front of you. Also any authentication to generate that TOTP in the first place. As tried to convey, the fake laptop is basically a full MITM on your screen/keyboard.

This is a hollywood level threat scenario.

It involves the attacker having intimate familiarity with the operating system, and having to break inn twice to even get this attack done.

If you do put inn the effort then I deserve to be hacked and can pick up sheep farming in the country side.

Why twice? You can keep the fake laptop.

The OS does not matter? Grab the video output via HDMI/DisplayPort and insert the keypresses via USB. Thats likely gonna work. Basically what modern KVM switches do. And setup the fake laptop as VNC client. Same tech that companies can use to remotely manage servers.

> The OS does not matter?

Of course it does. You are replaying the logos and screens.

> Grab the video output via HDMI/DisplayPort and insert the keypresses via USB. Thats likely gonna work. Basically what modern KVM switches do. And setup the fake laptop as VNC client. Same tech that companies can use to remotely manage servers.

You believe you can boot up an entire VNC client to display something that would take most machines under a second to display?

> You are replaying the logos and screens

Which the real machine happily gives me via HDMI/DisplayPort.

> You believe you can boot up an entire VNC client to display something that would take most machines under a second to display?

Do i need to? That the user presses the power button does not mean the machine will freshly boot. It could also be an unsuspend/wakeup or some regular ACPI event if the machine is only appearing to be off.

> Do i need to? That the user presses the power button does not mean the machine will freshly boot. It could also be an unsuspend/wakeup or some regular ACPI event if the machine is only appearing to be off.

This is a completely imaginary scenario. I'd be amazed to see it pulled off.

EDIT: I hear Amazon is still getting pitches for Hacker 2. You might have a shot.

Windows Fastboot (active per default) is suspend disguised as shutdown:

https://www.windowscentral.com/how-disable-windows-10-fast-s...

I'd like to add that the VNC relay machine only has to fool the end user once. So, the attacker wins as long as they think "the bios is a bit janky this morning, and this is more kernel panicky than usual", and type their pin/password anyway.

Of course, it's much easier to just pop the original laptop open and interpose on the keyboard. Even easier: use acoustics to snoop the keystrokes. The snooper could even be 5g/wifi/gps, assuming it's easy to steal some power from the mainboard. I guess fingerprint + camera ID make that attack harder. Still, the hypothetical device could stream HDMI at a few FPS if it was easy to splice into the display panel cable. (I haven't cracked a laptop recently, but those used to be socketed + unencrypted.)

Miniaturization is weird. The latter attack is probably easier to pull off these days than the former. If you wanted to swap my laptop, you'd need to replicate the dents and stickers. Good luck doing that!

OP is trying to say that this TPM TOTP approach doesn’t help verify a machine is legitimate if there is a possibility that the machine you’re using has been swapped with a malicious one.

This doesn't really mesh well with what the TPM-TOTP idea is trying to solve: trust in the machine you’re using.

Hyperbolic or fairly extreme-sounding scenarios are common when discussing this kind of thing, partly because it makes discussion about a fairly boring topic a little bit more interesting. Don’t get distracted by that.

That being said, using a TPM-based TOTP is pretty extreme sounding in and of itself.

> Hyperbolic or fairly extreme-sounding scenarios are common when discussing this kind of thing, partly because it makes discussion about a fairly boring topic a little bit more interesting. Don’t get distracted by that.

It's not. They are very much intended to derail serious discussions around threat models.

> That being said, using a TPM-based TOTP is pretty extreme sounding in and of itself.

It's not. It's trivial to implement.

There are like three operating systems in common use. An attacker being familiar with the one you use certainly isn't a "Hollywood level threat scenarios".

Buying the same model laptop and swapping it with your targets is an elementary level targeted attack

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

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.

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.

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.

i like the way you think