[osy]

> This sounds like the rant of a typical Linux fanboy

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

[yakkityyak]

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

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.

[lxgr]

> Just a friendly reminder that attacks on the author's credentials have no baring on the weight of the arguments.

> 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"?

[H8crilA]

I lol'ed pretty hard when I read the appendix. What an amateur job. All this time I was sure someone thought of the possibility of attaching a logic analyzer, or an $80 FPGA, to one of the pins.

[Nextgrid]

> whose entire personality is making Hackintosh and VM apps for iOS

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.