The reason there is no explicit threat model defined in the TPM specs is because it defines a general-purpose hardware security module. It is up to integrator to define the threat model (TPM's security properties also depend on the rest of the system) and the application.
Even if a TPM is not perfect and depends on other pieces of the puzzle to also be secure, it at least opens the possibility of making it secure in the future once those vulnerabilities are discovered & fixed. Furthermore, even in this vulnerable state, it still increases the effort required for a successful attack.
Support for TPM-backed full disk encryption means you can now have FDE on by default for everyone with no usability impact at all. Even if it's not secure and a dedicated attack will still break it, it means a casual attacker can't just pull a drive or reboot the machine and run chntpw or steal sensitive data from discarded drives that haven't been properly wiped.
I like TPMs. I like the fact that a rogue datacenter employee or intruder can't just pull one of my servers' drives out and get sensitive data. I like not having to worry about having sensitive keys on the filesystem somewhere because every secret is in memory and is ultimately derived from the TPM doing remote attestation at boot and handing ephemeral keys. I like not having to worry about unattended reboots or entering LUKS passphrases remotely.
There's no reason to believe this will require a TPM or depend on the presence of one. As far as I know, Widewine and similar DRM schemes successfully achieved this without any hardware assistance. Yes, bypasses exist and all the major piracy groups have them, but the objective of preventing the masses from having access to a working bypass is clearly achieved and doesn't require hardware.
But in such a scenario, an attacker can also use such an attack to bypass any remote attestation/DRM/etc!
I guess you could argue that such attacks are too much work for consumers, and that low fences control big dumb animals…but I think, fundamentally, the same argument applies to consumer security functions like FDE!
Tl;dr: I think it’s hard to argue that TPMs are both useless for practical user security and a threat to free computing. It’s gotta be one or the other!
Will this stop a dedicated attacker? Probably not, although a fTPM with an up to date OS would require the attacker to find an exploit for this machine's early boot firmware (UEFI, etc) or burn a Windows zero-day, both of which are very costly.
It does however prevent your casual thief from watching a YT video "how to reset windows password using linux live cd" and then getting access to your sensitive data (browser's saved passwords, etc), so it's a major improvement.
Yes, there are a lot of vulnerabilities in the Secure Boot process on most devices, because the surface area is huge, but the attacker still needs _some sort_ of vulnerability to gain a foothold.
I agree with the frustration in the gist - Secure Boot and TPM-sealed disk encryption aren't nearly as good as they could be, because the surface area is gigantic and sure to get exploited. But this is a classic Security Nerd vs Reality scenario: while it is absolutely _possible_ to pwn Secure Boot + TPM-sealed encryption in almost any scenario, using it still makes it _much harder_ for an attacker to do so, and most will give up.
I'm not sure if this is what Windows actually does, though, or if the TPM just hands over the disk encryption key after Windows passes system attestation and then verifies the screen unlock PIN/password in software – that would be significantly less secure.
The only thing I do not get is why this is not done by a simple SIM card like in any mobile phone. Then one could choose a TPM. Even more: I do not get why I cannot encrypt my android phone with my SIM card.
Hi, it's me the Linux fanboy whose entire personality is making Hackintosh and VM apps for iOS. Just a friendly reminder that attacks on the author's credentials have no baring on the weight of the arguments.
> The reason there is no explicit threat model defined in the TPM specs is because it defines a general-purpose hardware security module
It sounds like you have zero experience in security :)
> it defines a general-purpose hardware security module
No it doesn't. I think you're hinting at HSM which is another beast I may write another fanboy FUD piece about at some point. But no, HSMs are not the same as TPMs. And TPMs are not HSMs. For one thing, and HSM defines something called a trust boundary where keys should never leave. TPMs will happily hand you the keys when you meet a certain condition. HSMs support key migration and provides a secure way to transfer keys from one HSM to another without leaving the trust boundary. I can go on and on...
> TPM's security properties also depend on the rest of the system
The argument isn't TPM versus no security. The argument is TPM versus the existing security you have on Windows. (Passwords, FDE, etc). Of course all this depends on the system. TPM doesn't add anything (* with the exception already listed in the article).
> it at least opens the possibility of making it secure in the future once those vulnerabilities are discovered & fixed
Nope. Architecturally flawed. But I'd just be repeating the argument from the article.
> means a casual attacker can't just pull a drive or reboot the machine and run chntpw or steal sensitive data from discarded drives that haven't been properly wiped
They can with a $80 FPGA. Read the appendix.
> I like the fact that a rogue datacenter employee or intruder can't just pull one of my servers' drives out and get sensitive data.
They can with a $80 FPGA. (Unless your datacenter uses Intel TXT and tboot and other prerequisites that were talked about in the article)
> I like not having to worry about having sensitive keys on the filesystem somewhere
If you use BitLocker, they are always in kernel memory
> derived from the TPM doing remote attestation at boot
That's not what "remote attestation" means :)
> I like not having to worry about unattended reboots or entering LUKS passphrases remotely
If you like that, just disable your password and you'll get the same result
You can create non-exportable keys on TPM's, and there are mechanisms to securely transfer keys between devices.
Granted, doing so is kind of a mess, but nonetheless possible.
> It sounds like you have zero experience in security :)
Seems like you're countering an ad hominem with an ad hominem here...?
I don't know the TPM specifications in detail myself, but I do know that TPMs are in fact quite general-purpose HSMs, of which assisting in attestation/measurements for the purpose of trusted computing is only one (although certainly the most controversial) subfeature.
If I can store my SSH keys on my TPM and just don't use trusted computing at all... How is that "zero practical security"?
Congrats and thanks as I'm fairly sure I must've used your work at some point.
> Just a friendly reminder that attacks on the author's credentials have no baring on the weight of the arguments.
I didn't check nor care about the author nor their credentials because my comment was purely on the piece itself and what it sounded like to me and not an ad-hominem to the author. It did after all contain the usual scary terms such as "Microsoft", UEFI, Secure Boot as well as dismisses an entire concept just because of some flaws that can be rectified incrementally.
> It sounds like you have zero experience in security :)
I never claimed to be a security expert, but maybe my layman's approach allows me to overlook the pedantry and avoid dismissing something entirely just because it doesn't perfectly conform to some ideals? (I think the TPM's threat model will be up to the integrator to determine, as it depends on other things such as discrete vs firmware TPM, UEFI/Option ROMs and their security flaws, etc).
> No it doesn't.
I used "HSM" to mean "dedicated hardware device that does security-related things", rather than a 1-to-1 equivalent of a commercial HSM. But to the best of my knowledge a TPM can also act as a (low-throughput) actual HSM if you so desire, allowing operations with a secret key without ever disclosing it?
> The argument is TPM versus the existing security you have on Windows. (Passwords, FDE, etc)
My argument is that the TPM enables frictionless FDE for the masses without any change in user experience and without even relying on a password (which would often be weak and thus useless in practice).
Tell me how this is the same level of security as no FDE or FDE with weak password. Even if it can be broken using various methods (some of which you've described), surely you see that it still significantly increases the barrier to entry and cost of a successful attack?
> They can with a $80 FPGA. (Unless your datacenter uses Intel TXT and tboot and other prerequisites that were talked about in the article)
Those machines use fTPM which isn't vulnerable to this attack, but regardless, $80 is still more expensive than the $1 a Linux live-CD/USB costs, not to mention the requirement for lengthy physical access and ability to solder/connect wires onto the mainboard.
I'm not arguing that TPM is unbreakable or will resist sophisticated, prepared, targeted attackers. But it raises the bar by at least $80 (and in practice by a lot more on modern machines with fTPM), with zero additional effort from the user (thus it can even be used where conventional passworded FDE is impractical, such as unattended servers). It's literally free security, and yet you chose to shit on it just because it's not perfect (even though the flaws would get patched up over time, as with any product).
I think it would be good if this level of security could become the baseline (even if it's not perfect) and would rather not have FUD getting in the way. You are of course welcome to use something stronger depending on your requirements, but this becoming the baseline is still an improvement over no FDE at all (still seems to be the norm on PCs).
> If you use BitLocker, they are always in kernel memory
Yes I understand, it would still means you'd need to either be root already or have a privilege escalation exploit to extract them.
I'm not necessarily talking about FDE keys here though (for FDE keys, if you can execute code just read the filesystem directly, no need to even care about the FDE).
TPM allows a machine to prove (with reasonable levels of security, requiring at least $80 to break) to another one that it's in a given state, and be able to obtain ephemeral credentials based on that claim, this avoiding needing to persist those anywhere.
> That's not what "remote attestation" means :)
See above.
> If you like that, just disable your password and you'll get the same result
Well no, because then any guy with a Linux live CD can get the data (or someone at the recycler if the drives are swapped and discarded without being sanitized), where as now they'd at least need to shell out 80 bucks plus a soldering iron and lengthy & suspicious-looking physical access to the machine.
It seems like it's a sunken cost fallacy that big tech spent a lot of money on and they are trying to get it back by convincing average Joe that a TPM is good for your PC.
I thought the piece was ok, but it doesnt add anything new. its another piece pointing at the puzzle a lot of people including you already know exists. its not aimed at you for that matter. (so fair comments, but perhaps a bit harsh?)
If somebody that wants your data steals your PC he will be likely to find a way to access your personal data. It's a protection against a casual thief that is probably not interested in your data and can't probably even figure out how to bypass the Windows password screen.
But if this doesn't make harm, why not have it? Because having disk encryption enabled by default to a user that doesn't know that is enabled by default is not necessary a good thing. Let's face it: users don't do backups. I know even companies that have all their data on a single server with no backups.
Now if the motherboard breaks and you don't have backup... you can't just take the disk out of that computer, connect to another PC and recover the data. You have lost your data!
But wait, you say Microsoft tought about that, indeed if you signed in with a Microsoft account you can recover your Bitlocker encryption key from the Microsoft portal... wait what? Exactly. No security at all! Microsoft knows your encryption keys and it stores it on their servers... again: false sense of security is worse than no security at all!
Finally, even if this system was 100% secure: do you trust the hardware? The same hardware produced by the same manufacturer of the products where nearly once in a year a big security flaw is discovered? The same hardware where we know that the NSA, and probably other government agencies, placed backdoors?
Whatever, typing a password when booting up the computer (that is once in a day) is such a big deal?
Can't you alternatively also export a copy of the actual disk encryption key and write that on a piece of paper? The last time I used Windows, that was possible, at least (but I think I didn't use the TPM back then).
On macOS, you can do either, for example, and it uses a similar construction (although using Apple's proprietary secure element and hardware encryption engine rather than a TPM and secure boot).
This is complete disinformation. Microsoft gives you the OPT-IN OPTION to save your Bitlocker encryption key to your account.
It's clearly labeled and you need to click on it to activate it:
https://allthings.how/content/images/wordpress/2021/11/allth...
The datacenter use case sounds useful—should have led with that.
My problem with the piece is that it reads like the usual knee-jerk pro-Linux FUD that typically originates around scare words like "Microsoft", "secure boot" and "UEFI".
That's not zero. In my mind that's the main thing a TPM is really useful for. It's a secure enclave for a private key used for U2F/WebAuthn style attestation. I agree that the threat model not being explicitly discussed is a huge miss. But to that point, a TPM is still useful because it prevents someone who has hacked into my computer from commanding the TPM's authentication factor.
The other useful application is to prevent block device data extraction without knowing the passkey. And the author's argument there hinges on the notion that Microsoft won't patch OS security vulnerabilities that enable key extraction from memory. Which, OK, third-party drivers suck, but Microsoft's effort to patch is also not zero, and the most common (OS+browser/sandbox) threat model requires a chain of vulnerabilities that are hard to come by.
> The other useful application is to prevent block device data extraction without knowing the passkey.
Nope, read the appendix. Since 2006, BitLocker without PIN is vulnerable to physical extraction with $80 worth of equipment. And to enable enhanced PIN for BitLocker you have to jump to a lot of hoops that most people don't even know about.
So some industry stakeholders are doing bad things with an inherently neutral technology. Does that mean we need to get rid of the entire thing, thereby also killing the OSS use cases?
Yes, trusted computing can be used in user-hostile ways, but the solution here seems to be to not use OSes and applications using it in that way, rather than throwing out the technology as a whole.
Unfortunately, it's not much good for that either.
A yubikey has a button to confirm the user's presence - so even if a remote attacker has completely compromised the machine, because they can't press the button, they can't get anything out of the key.
The TPM has no button, so it has to rely on the OS to keep your pin safe from keyloggers. If your OS is that trustworthy, you might as well just store your secrets in the OS keyring.
The TPM is also about 50x more complicated than a yubikey, to support things like multi-user systems. This means there's a much bigger attack surface.
How?
Actually, on second thought, it's secure boot that protects against this attack, which doesn't require or use a TPM? So maybe I'm wrong
Even then, the argument that a TPM is worthless because it can't guarantee that software is free of vulnerabilities just belies an un-seriousness of the post. Like okay, that argument applies to every threat model ever.
A boot chain can be secure with or without a TPM. The TPM just says "I'll record what your boot chain told me and spit it back out with a signature that is verifiable by public key cryptography, so that you can tell it's what your boot chain told me. How much you trust your boot chain is up to you."
(Most other threat models go "ok we trust some part of this is secure, and that means we can guarantee x, y, z; if that part is not secure then we cannot do this.)
> Each of dozens (up to hundreds) of UEFI drivers written by various OEMs with varying levels of competence and care are loaded
Doesn't the BIOS signature encompass those drivers? Put another way, isn't the BIOS vendor attesting those drivers are non-malicious with their signature?
I think the TPM will turn out to be a net negative for consumers since it's going to get used to get used for attestations users can't control (ie: against the will of the user), but there are some benefits. Having a BitLocker key unlocked via a PIN where the TPM can protect against brute force attacks is useful for me. That alone covers most of my threat model which is having my data extracted from a lost or stolen PC.
D-RTM requires TPM.
That means it either requires a second protocol for authentication, or that you will lose your accounts with all kinds of services all the time.
There are plenty of valid use-cases where you'd want the machine to authenticate itself to services (VPN to enterprise network?) before anyone logs in (or ever logs in, as in the case of servers who operate unattended).
This one is huge: always-on VPNs mean enterprise security mandates don’t delay patching or other remote management tasks just because someone is on vacation or sick, and that stuff can happen at 3am on Sunday rather than when they start work. No more “please leave your computer on overnight” messages.
So for example, if I login to Gitlab on my phone, I can use my fingerprint (lockscreen auth). It's more convenient than using the TOTP app.
Similarly, I could register a TPM from my desktop that could be the same as using the fingerprint auth? It would only work from that desktop, but it's the same logic as my phone, and in a sense, that's a nice benefit.
Sometimes I think the average person would be better of with a highly secured email account and magic links for everything else. Even for me, I have YubiKeys, TPMs, etc. configured for everything, but if I forget to lock my laptop and someone walks off with it, they have access to my email which is basically my entire digital life due to account recovery via email.
Technically speaking, the exact same restrictions apply to a Yubikey.
That’s what makes it secure.
EDIT: To clarify, Widevine doesn't actually use the TPM, but Widevine L2 uses a TEE for key exchange and decryption, which are all things that modern TPMs support. The use a crypto coprocessor for key exchange and decryption is widely used.
Time to go back to kernel mode everything I guess. Just run everything as root, get rid of sudo.
> There are a plethora of attacks on TPM in the past but we need to be clear that a system that is widely attacked does not necessarily mean it is fundamentally insecure but only that there are many implementation issues. Most of these implementation issues do not touch upon the points raised in this article (it doesn't matter if the gate to your garden is strong or weak if there is no fence around the garden). Nevertheless, many of the attacks demonstrate the lack of care and consideration in the TPM ecosystem.
The issue is that TPM is being heavily pushed while it provides no security value. When you have Secure Boot (no additional hardware required), you get everything that Microsoft promises. The entire idea of TPM is that it gives you an extra level of security and I argue that it doesn't.
TPMs can do other useful things besides performing attestation measurements for trusted computing, including acting as a secure element to safeguard and rate-limit keys used for SSH, disk encryption and much more.
Good luck trying to remote (RDP) into a Windows box with a passwordless account or to access a fileshare.
While passwordless Microsoft accounts are very convenient it is only according to MS Marketing department that windows can be a true passwordless system. In reality it is not. There any several components in Windows that does not work with a passwordless account. The RDP and network issues has been know for many years and is a PITA for home networking.
I do have a travel laptop and recently installed LUKS to it. I like having my long password, but being able to tie unlocking to the hardware sounds like a good idea too. Is there a way to have both? A long password and require the local TPM?
Despite the shortcomings, I think they are very useful devices from the perspective of running data centers. I consider it useless against evil maid attacks though.
Nowadays with Microsoft making it a requirement (as well as fTPM which means the TPM no longer requires dedicated hardware) we might see more use-cases.
I'd have to check if bottom cover tampering on my Lenovo actually requires me to put in the BitLocker keys again.
No dang, I don't care about the spirit of the site when absolute ludicrous mindrot garbage is up voted here constantly. You'll note on the Wayland thread that, despite being the 30th Wayland thread, the only substantive reply agreed with me. It's a joke.
Don't worry, I'm changing my password to a random guid, you'll be free of me in 45 seconds.
TPM is the specification and standard for a predictable way this is implemented, and most modern CPUs do this as you say, with option ROM validation, UEFI firmware integrity checking, etc.
> Note that at any point in this process, if the attacker is able to control code execution, there is no way for TPM to know that the measurement it was just handed wasn't a lie. Now let's assume you are an attacker trying to get the BitLocker keys, what can you do? [0]
[0] https://gist.github.com/osy/45e612345376a65c56d0678834535166...
