Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Signing TLS handshakes inside a TPM

bschaatsbergen.com

Post reply on HN
Print view View original

31–40 of 49 posts

Re: Signing TLS handshakes inside a TPM

#31

Post by mjg59 »

KaiserPro wrote: post #18

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 emb…

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.

Re: Signing TLS handshakes inside a TPM

#32

Post by mjg59 »

ted_dunning wrote: post #22

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…

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.

Re: Signing TLS handshakes inside a TPM

#33

Post by bob1029 »

mjg59 wrote: post #30
bob1029 wrote: post #26

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…

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.

How often do we need to bind a specific machine to a specific key in the case of TLS?

In every case of TLS I've seen we are concerned with organizational identity, not machine identity. This effectively extends to client certificates in cases like B2B & vendor integration.

In both scenarios you would definitely want to use an HSM style solution.

Protecting the HSM from inappropriate use (proving you are allowed to sign using the keys within) is a problem orthogonal to protecting the key material. In cloud HSM applications, you often combine the cloud vendors managed identity solution and HSM policies to effectively bind a set of machines to a set of keys.

Re: Signing TLS handshakes inside a TPM

#35

Post by flippingheck »

bob1029 wrote: post #26

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…

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.

Re: Signing TLS handshakes inside a TPM

#36

Post by flippingheck »

thomashabets2 wrote: post #19

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.

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

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

Re: Signing TLS handshakes inside a TPM

#37

Post by mjg59 »

bob1029 wrote: post #33
mjg59 wrote: post #30

Earlier quoted context omitted.

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.

How often do we need to bind a specific machine to a specific key in the case of TLS? In every case of TLS I've seen we are concerned with organizational identity, not machine identity. This effectively extends to client certificates in cases like B2B & vendor integration. In both scenarios you would definitely want to use an HSM style solution. Protecting the HSM from inappropriate use (proving you are allowed to si…

In the given case - you want to bind communication to a given confidential compute instance, which means you want to be able to ensure that the communication is coming from within the confidential compute instance, which means you want to be able to prove that the private key is only accessible from within that instance. An HSM buys you nothing more there.

Re: Signing TLS handshakes inside a TPM

#38

Post by _flux »

ranger_danger wrote: post #7
altairprime wrote: post #6

Earlier quoted context omitted.

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.

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.

Wouldn't this in practice be a lot like Passkeys? But it might be more difficult to integrate this kind of approach to the stacks we use, whereas Passkeys fits in relatively easily.

I suppose client cert would protect against from a MitM attack, if the client failed to notice it, or if the MitMer has the website keys to make a perfect attack.

Re: Signing TLS handshakes inside a TPM

#39

Post by lesspassiveobse »

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...

Re: Signing TLS handshakes inside a TPM

#40

Post by bschaatsbergen »

lesspassiveobse wrote: post #39

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...

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