Signing TLS handshakes inside a TPM

KaiserPro a minute ago | parent | next [-]

For a company I work for I needed to ship a machine through unknown channels and have some confidence that it wasn't fiddled with.

my threat model was reasonably technical engineer swapping drives for some reason, or someone claiming that the machine is "different". (no nation state shit)

after the machine was imaged, it would connect to our central config server, get its hostname and exchange keys which would be embedded in the TPM.

once the machine is shipped and booted, it'll check in and sign a challenge. any kind of action on the central API could have a challenge. Each machine is attested at least once an hour.

I'm not sure how "secure" it all is, but it seems to work.

▲

duk3luk3 4 hours ago | parent | prev | next [-]

Sounds interesting; too bad all we get is text made up by an LLM rather than any of the author's insights.

	▲	abound 4 hours ago \| parent \| next [-]
		Yeah I was interested for the first few paragraphs, then all of a sudden I get hit with two "genuinely"s and a > That’s the third property, and it’s the one that decides this. and I gave up at that point.
	▲	bschaatsbergen an hour ago \| parent \| prev [-]
		Author here. All of it is mine, the library (https://github.com/bschaatsbergen/go-tpm-tls) and the benchmarks (https://github.com/bschaatsbergen/go-tpm-tls-bench) and the working notes. English isn't my first language, so I edit a lot, and I can see how that comes out flat. I've been over it once more; hopefully it reads better now. Thanks for saying so rather than just closing the tab.

▲

psanford an hour ago | parent | prev | next [-]

I wish the author provided some latency numbers for this. One issue with tpms is that they are slow relative to performing the same operation on a modern CPU.

	▲	donavanm 38 minutes ago \| parent \| next [-]
		Thats the “what it costs” section? Im a bit impressed if they are down to ~3ms per handshake. When I last looked at TPM signing (many years ago) it was more like single digit transactions per second. That said, even 3ms TPM signatures are going to be for special cases or novelty. Plain old CPU tls will do about 1ms cpu time per request which will scale by cpu core count. One or two orders of magnitude more throughput per host.
	▲	bschaatsbergen 38 minutes ago \| parent \| prev [-]
		Author here. There's a benchmark table further down the post, the numbers come from this repo if you want to run them yourself: https://github.com/bschaatsbergen/go-tpm-tls-bench

▲

ram_rattle 3 hours ago | parent | prev | next [-]

Nothing new here, attested TLS was being discussed in IETF for quiet sometime right?

https://datatracker.ietf.org/doc/draft-fossati-tls-attestati... https://www.youtube.com/watch?v=MF9AwkMJOlw

▲

bschaatsbergen an hour ago | parent | next [-]

That's right, I'm learning in public here. That draft is a different direction though, they change the handshake: new TLS extensions carry the evidence, and the far end appraises the platform during the connection.

What I'm doing changes nothing on the wire, the verifying side has no idea a TPM is involved. In RATS (https://www.rfc-editor.org/rfc/rfc9334.html) we prove a machine is sound by measuring it and appraising the evidence. But after attestation the usual thing is to hand the machine a short-lived identity saying it is attested, and when that machine then authenticates over mTLS to something like an HSM, the thing that gives that machine its identity is a private key in a file. That bothered me. What I want is to tie the key in the TPM to the evidence of the confidential VM at issuance time, and let that be the identity the machine carries afterwards. Working notes while implementing RFC 9334.

	▲	ram_rattle 42 minutes ago \| parent [-]
		Never mind, I had no idea who you where, looked you up, please take a bow, apologies if the comment came out rude, more power to your work and agree learning in public and publishing more will what will make this idea better. Hat Tip!

▲

madduci an hour ago | parent | prev [-]

Exactly, you could do this also with the Microsoft Cryptographic Provider long time ago, which is the basic Provider called by the go-tpm library, when running under Windows

▲

ranger_danger 3 hours ago | parent | prev [-]

Let's hope this doesn't get picked up by the (corporate) masses... the last thing I want is my browser offering personal TLS certificates to every server I visit as some kind of identity verification or fingerprint/tracking.

It's bad enough that ssh does this by default with all your keys.

▲

zx8080 an hour ago | parent | next [-]

This is most probably where it's going in less than a year. The recent campaign "Safer with Google" in Chrome hints to this.

▲

altairprime 2 hours ago | parent | prev [-]

Client TLS is rather unusable on the Internet by a typical random end user visiting a random public site, so that should at least keep the specific scenario you describe at bay.

▲

ranger_danger 2 hours ago | parent [-]

Currently yes, but there's not much stopping Chrome etc. from adding a new feature that has a way of presenting a client certificate to a website in a backwards-compatible manner.

Of course the website itself would need to support that, but it's all possible in time.

	▲	altairprime an hour ago \| parent [-]
		Chrome would be more likely to implement a persistent and identifiable (to Google alone) tracking cookie replacement and ship it worldwide, which iirc they did — and then cancelled, of course. They seem to be focusing instead on improved tracking of Android users from the kernel up, rather than browsers from the headers down; GrapheneOS is, presumably, viewed as a serious threat to their advertising revenue. https://privacysandbox.google.com/blog/update-on-plans-for-p...