Hacker News Reader

Comment by bob1029 | Hacker News Reader

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.

View on HN

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.

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.

Any time you've got hardware and want to attest that it hasn't been tampered with before allowing it to interact with something like an API endpoint.

At work we deploy industrial IoT gateways, these are very much not end-user devices. We are actually concerned about the device's identity, and more specifically about being able to attest that the device is in fact the one we thought it was and it hasn't been tampered with. By putting the key for TLS client certificate in the device's TPM, locked behind attestation that what's been booted is what we expected to boot, we can have a reasonable degree of confidence that we're communicating with the device we thought we were rather than just someone who managed to copy the private key off disk.

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.

Reply on news.ycombinator.com