Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • 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.

    by yusufmotiwala
  • 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

    by ted_dunning
  • 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.

    by KaiserPro
  • 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.

    by ranger_danger
  • 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.

    by jauntywundrkind
  • 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.

    by thomashabets2
  • 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.

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

Explore Birbla archives

Signing TLS handshakes inside a TPM · Birbla