21–30 of 49 posts
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.
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.
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
It really better to separate the attestation, the check against policy and then the TLS stuff. Solve one problem at a time, sign that progress and move on.
Sounds interesting; too bad all we get is text made up by an LLM rather than any of the author's insights.
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.
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.
[1] Typically ARM these days, but most system vendors aren't picking TPM vendors based on performance
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.
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 benchmarks are from GCP, where the vTPM is implemented in the hypervisor rather than on something that's plausibly an 8051[1]. Doing this on actual client hardware is going to be a bunch slower. [1] Typically ARM these days, but most system vendors aren't picking TPM vendors based on performance
Worth adding that not every outbound connection needs to go through the TPM (IMO). It's for the handful of services where the machine-identity actually matters, a secret store, or an HSM releasing key material onto an attested confidential VM, in my case.
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…
Earlier quoted context omitted.
The benchmarks are from GCP, where the vTPM is implemented in the hypervisor rather than on something that's plausibly an 8051[1]. Doing this on actual client hardware is going to be a bunch slower. [1] Typically ARM these days, but most system vendors aren't picking TPM vendors based on performance
What mjg59 says. The benchmarks are against a vTPM, that was what I had access to, and it's the environment I'm implementing the RATS side in. Worth adding that not every outbound connection needs to go through the TPM (IMO). It's for the handful of services where the machine-identity actually matters, a secret store, or an HSM releasing key material onto an attested confidential VM, in my case.
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…