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.
It seems like these security discussions always devolve into rather funny moving of goalposts without actually considering how much work each exploit requires.
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.
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.
I agree that's adequate, in the sense that keeping the an SSH key as a password-protected file on disk is adequate, and having it be a password-protected secret in the TPM is no less secure than that.
But the whole point of binding a key to hardware is to be secure even if a remote attacker has gotten root on your machine. An attacker with root can simply replace the software that reads your PIN with a modified version that also saves it somewhere. Then they can use the key whenever your computer is online, even if they can't copy the key off. And although that's a bit limiting, once they've SSHed to a host as me once they can add their own key to authorized_keys in many cases.
That's why Yubikeys and U2F keys and suchlike have a physical button.
TPMs would be a lot more useful if the spec had mandated a physical button for user presence.
It protects against extraction, not usage on the machine itself. Of course they can use the secret on the compromised machine.
> And although that's a bit limiting, once they've SSHed to a host as me once they can add their own key to authorized_keys in many cases.
Assuming they can edit the file.
> That's why Yubikeys and U2F keys and suchlike have a physical button.
The TPM spec has a policy setup to account for some fingerprint reader that can be used to authenticate. I haven't been able to figure out how/what/whys of the implementation here but this is very much a thing.
Yes, this is why I was careful to say that the benefits are obscure, rather than saying they're entirely nonexistent.
I'll admit that's a benefit, but it seems very small benefit considering the far-reaching changes it's needed like kernel lockdown mode, the microsoft-signed shim, distro-signed initrd, the difficulties it creates with DKMS, and so on.
Whereas people who need to bind their SSH key to hardware can get a higher degree of security with a far smaller attack surface by simply spending an hour's wages on a Yubikey.
None of this is needed to take advantage of TPMs.
> Whereas people who need to bind their SSH key to hardware can get a higher degree of security with a far smaller attack surface by simply spending an hour's wages on a Yubikey.
Yubikeys are expensive devices, and TPMs are ubiquitous. Better tooling solves this problem.
You're not binding the secret to PCR values? I thought TPM fans loved those things?
I don't blame you - they look like a design-by-committee house of cards to me, with far too many parties involved and far too much attack surface. Just like the rest of the TPM spec.
Binding things to PCR values doesn't imply you need Secure Boot, signed initrd, lockdown mode, shim and signed kernel modules. All of these things are individual security measures that can be combined depending on your threat model.
> I don't blame you - they look like a design-by-committee house of cards to me, with far too many parties involved and far too much attack surface. Just like the rest of the TPM spec.
The v2.0 version of TPM doesn't really make PCR policies easier to use, so I've had troubles getting them properly integrated into the tools I write as you need to deal with a key to sign updated policies. `systemd-pcrlock` might solve parts of this but it's all a bit.. ugly to deal with really.
The entire TPM specc is not great. But I find TPMs too useful to ignore.
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.
FWIW, Bitlocker already can store recovery keys in AD. It has been a feature for a long time.
Keeping the key stored on the machine, TPM or no, is also less secure than keeping it somewhere else. If someone steals your laptop, you deny all access to the key on the server and they can't get it even if they could guess the pin (or the user wrote that on the bottom of the computer), and there is no way to use an offline method to extract the key from the TPM because it isn't there.
Computers have these neat things called "local filesystems". They're a real hoot. Maybe you can get one on your computer.
This seems like it isn't worth the cost in authoritarianism?
For that matter you could still implement even that with just a secure enclave that will only release the key given the correct PIN (and then rate limits attempts etc.), but then does actually release the key in that case and doesn't do any kind of remote attestation or signing.
So...a TPM?
> This seems like it isn't worth the cost in authoritarianism?
You know what's really authoritarian? Having your computer practically only decryptable by some remote directory server, potentially not even under your control.
All bets are off if your attacker is determined and has physical access.
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.
The TOTP token here is sealed inside TPM.
What do you mean with "relay"?
(All of this is trivially solved with glitter nail polish anyway.)
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.
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.
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.
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?
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.
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.
https://www.windowscentral.com/how-disable-windows-10-fast-s...
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!
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.
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.
Buying the same model laptop and swapping it with your targets is an elementary level targeted attack
Some cars even get this right these days. Most don't.
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.
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?