Signing TLS handshakes inside a TPM

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

I suppose the value of this depends on your threat model.

The TPM will give you stronger assurance that a machine owns a key, but it's likely that a dedicated HSM would be much harder to extract the key material from.

TPM being inside the machine is a double edged sword. On one hand it makes attestation feasible, but on the other you now have the security black box inside the same physical domain as the machine that uses it. Risk of side channel extraction goes up dramatically when these systems coexist. It's a lot harder to instrument an HSM across the network.

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.

I might be missing something: is this any conceptually different from using PKCS11 provider for TPM in OpenSSL?

Also, with real TPM, the key could be locked to a specific configuration register value, which makes less sense for VMs. “Quote” is mentioned and I guess author means that, but did not elaborate further.

Looks like speeds have picked up since I last looked at this, when a signature in TPM took 0.7s and no concurrent capacity.

https://blog.habets.se/2012/02/Benchmarking-TPM-backed-SSL.h...

https://blog.habets.se/2012/02/TPM-backed-SSL.html

Well, it's been over 14 years so I should hope so.

The link between attestation and the key is nicely made with TAS. TAS gives you a cert and Spiffe then requires a cert like that to give a SVID that you use as a certificate for mTLS.

This means that the root of trust threads through software (TAS) that verified that your attestation evidence matches the live policy. This works with no changes to Spiffe.

This doesn't really meet your requirements to keep the key out of memory since the resulting SVID lasts for several minutes in memory, but it does meet most people's needs.

https://github.com/TEE-Attestation/tas

Isn't this a well-discussed issue already, and not specific to TPM?

We faced a similar issue (we use OpenSSL). OpenSSL does have OPENSSL_secure_malloc() which prevents sensitive memory from being dumped. However, the problem is that not all paths use the secure allocator. For example, this issue: https://github.com/openssl/openssl/issues/27603

Not sure if this has changed in OpenSSL 4.x, but it is certainly something desirable.

I wonder, at what point will it be cheaper to kidnap and ransom those remote attestation engineers' families for key material than to work around those schemes with technical measures. Keeping in mind that people set up bot farms with physical phones just for attestation keys, it seems like tightening it all too much will just shift the balance towards the $5 wrench approach...

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

Oh great, a new fresh hell against users, keeping them from being able to see the world or understand computing. Fantastic.

The War Against General Purpose Computing ticks on.

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.

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.