Hacker News

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.

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.

TPM is just a spec, it isn't necessarily a black box.

ARM TrustZone, for example, can run this OSS TPM: https://github.com/OP-TEE/optee_ftpm

I expect there are equivalents for Intel/AMD.

A dedicated HSM will give you stronger trust that the private key material can't be extracted, but there's no real way to bind an HSM to a specific client and that's a very easy thing to do in the vTPM case.

I helped design the attestation framework for https://docs.cloud.google.com/transfer-appliance/docs/4.0/re... - the goal was to ensure that the device you're about to copy a bunch of sensitive information onto is actually the device you were shipped and is running the expected software. This is definitely used in the real world.

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

Yeah, a typical TPM chip has much lower throughput than OP.

Not suitable for servers, since it's such an easy DoS vector.

> is this any conceptually different from using PKCS11 provider for TPM in OpenSSL?

PKCS11 doesn't allow you to attest that the key is resident in the PKCS11 provider, which as you say, the author alludes to, but doesn't cover.

> with real TPM, the key could be locked to a specific configuration register value, which makes less sense for VMs.

A vTPM is as real as a physical TPM chip.

The question is which TPM endorsement certificate CAs you are willing to trust.

For some that might the manufacturer of TPM chips, for others it might be their VM provider. (For some, none: for some both!)

Trusting their VM provider isn't so crazy if the VM provider is able to influence the guest code anyway.

This feels like a somewhat odd design choice - you have a TEE, most TEEs (outside TPMs) are fast so there's little overhead in pushing your signing through there, why bother with short-lived credentials instead of just attesting to private key material ownership and having that be what the SPIFFE cert is issued to? Bearer token SVIDs are an awful thing that we should be getting as far away from as possible.

Thanks for sharing Ted!

Joke's on them, I don't have the key either.

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.

Attested TLS has had some rough patches lately which can be attributed to making big changes to a complex protocol.

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.

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

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.

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

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

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.

[dead]