Hacker News new | ask | show | jobs
by tashian 1143 days ago
I agree with the sentiment of the piece, but I disagree with the idea that TPMs don't add much value for end users.

TPMs were originally designed in the early days of ecommerce, when it became clear that home computers would need better security if they were going to be used for financial transactions.

Today's TPMs don't have a lot of compute power, but they have a lot of features. It's just that we don't have that much software taking the best advantage of those features yet, probably because they have only just become ubiquitous in the last couple years.

TPMs lay the groundwork for unphishable credentials, using hardware-bound asymmetric keys.

TPMs add a user-friendly option for full-disk encryption, in a way that's resistant to physical attacks.

TPMs can be used to protect symmetric credentials too, instead of storing them on disk (see systemd-creds TPM2 support).

And, TPMs do have actual privacy mechanisms. End-user TPMs do not offer up their endorsement key to any third party. Attestation workflows shield third parties from the endorsement key.

I'm excited for more widespread use of TPMs in Linux especially. Lately systemd has been making some good progress here.

3 comments

Seems like a lot of banking and other secure business is moving to mobile first or mobile only, presumably as it's likely the only secure device the user has.
I agree with your assessment: desktop-browser online banking (with US banks in particular) is a depressing experience given how they’re full of ads for credit-card offers and manual (if not broken) OFX/QFX downloads that only contain a fraction of the actual backend txn data that the banks won’t ever share with their (retail-banking) customers…

And yet, while lots of banks now use SMS 2FA, none of the banks I use (Chase, BoA, Citi, and a couple of credit-unions) offer the far more secure TOTP scheme, let alone any way for headless clients to download txn data except via the literally-25+-years-old Quicken/Intuit OFX endpoints - presumably without 2FA, but with zero documentation in their online help and their retail banking customer support people have no idea what I’m talking about when I say OFX - it’s maddening,

lots of banks’ legacy OFX endpoints are listed here: https://www.ofxhome.com/index.php/home/directory

What else is in the backend transaction data?
LOADS of data - especially for industry-verticals that have heavy integration with credit-card companies (e.g. airlines include ticketing and even seat info in the metadata they submit to banks: this dates back to how air-miles rewards cards originally worked in the late 1980s) and there was tight integration between banks and airlines - even (or so I'm told) to the point of where banks' in-house "main" databases and ssytems have dozens of very, very hardcoded fields because of that early collab work - which then ossified in-place and now everyone's too scared to remove those now unused fields for fear of breaking everything.

...which leads me to believe that Cobol does not lend itself well to unit and integration testing in isolation then.

> And, TPMs do have actual privacy mechanisms. End-user TPMs do not offer up their endorsement key to any third party. Attestation workflows shield third parties from the endorsement key.

Then how do endorsement keys work?

If I understood the OP correctly, the purpose of the endorsement key is so a third party can choose only to accept attestation from TPMs of "trusted" vendors. How does this work if the third party can't query the endorsement key?

Ah, this was a grammar error on my part. Sorry about that, let me clarify.

TPMs do offer up their endorsement key (or an endorsement key certificate) to third parties.

And, TPMs can share attestations in a way that doesn't reveal the endorsement key. They use attestation keys for this. Attestation keys can sign TPM attestations, and these keys do not identify the TPM.

This approach requires a trusted CA. The CA confirms the TPM's identity (using an endorsement certificate issued by the TPM vendor), it confirms that the attestation key and endorsement key reside on the same TPM, and it issues a certificate for an attestation key.

The attestation certificate might contain TPM vendor info, firmware version number, and proof that the attestation private key is hardware-bound. But it need not contain any permanent identifier. The TPM can now use its attestation key and certificate to sign attestations for a third party.

Yes, there are end-user uses for TPMs. But, personally, none of them are compelling enough to overcome my fundamental mistrust of how companies will use them.