Generating and storing #SSH keys inside the #TPM (Trusted Platform Module)
-
@pemensik from [1] I learned to `usermod -G tss $USER'
@jpmens Interesting. Is there a limit of keys number, which I can store into my TPM 2.0 chip? I think I would like a local root service a bit more, talking by unix domain socket to local users. But nobody wrote anything similar and I won't have time to do that soon myself. Found about half year ago, practical using of TPM on Linux is very sparsely documented for mere mortals.
-
@jpmens Interesting. Is there a limit of keys number, which I can store into my TPM 2.0 chip? I think I would like a local root service a bit more, talking by unix domain socket to local users. But nobody wrote anything similar and I won't have time to do that soon myself. Found about half year ago, practical using of TPM on Linux is very sparsely documented for mere mortals.
-
Generating and storing #SSH keys inside the #TPM (Trusted Platform Module)
Store ssh keys inside the TPM: ssh-tpm-agent
After writing age-plugin-tpm a friend of mine at the hackerspace was super excited to finally have easy file encryption with TPM sealed keys, all without having to rely on gnupg. “This is great!” he said. “I wish I could have my SSH keys sealed in a TPM just as easily”. We should have left it at that. I shouldn’t have replied with a random assortment of facts like “I know google/go-tpm now”, or “but Go has a ssh-agent protocol implementation” followed-up with “Filippo has already implemented yubikey-agent, it can’t be that hard”. So I wound up writing a new ssh agent.
Morten Linderud (linderud.dev)
It works, at least on a Thinkpad X1 and Debian 12. I'm not sure I'd actually prefer that to something more portable such as a Yubikey.
I'm interested in hearing your feedback, and whether you actually use the TPM (and what for).
@jpmens
I'm using it both in my home lab as a PoC and (so far, only experimentally) in my day job. We've gotten to the point now where exfiltration of keys is table stakes if an attacker gets into your environment, so I'm a big fan of hardware-bound keys. A yubikey is technically better, imo, but the UX when you've got less-security-focused-users is just better if the key is built into the machine they're provided with. -
@jpmens
I'm using it both in my home lab as a PoC and (so far, only experimentally) in my day job. We've gotten to the point now where exfiltration of keys is table stakes if an attacker gets into your environment, so I'm a big fan of hardware-bound keys. A yubikey is technically better, imo, but the UX when you've got less-security-focused-users is just better if the key is built into the machine they're provided with.@iMeddles interesting. Does that mean you pre-generate keys for laptop/desktop users, and if I may ask, passphrase-less?
-
@jpmens I wish systemd-credentials was somehow merged with this usage style. So I can have as many keys for as many users on local system, but encrypted by some key stored in the TPM.
That information is great, but on very obscure domain. I think it should deserve some text file in actual packages providing such functionality.
-
@iMeddles interesting. Does that mean you pre-generate keys for laptop/desktop users, and if I may ask, passphrase-less?
@jpmens
At present, yes, while it's experimental, but the eventual design I want to get to once the tooling is a *little* more mature would get rid of pre-generation and render passphrases moot.(Warning: wall of text incoming in next reply with design details :p)
-
@jpmens
At present, yes, while it's experimental, but the eventual design I want to get to once the tooling is a *little* more mature would get rid of pre-generation and render passphrases moot.(Warning: wall of text incoming in next reply with design details :p)
@jpmens
The design I *want* to get to in order to roll this out as non-experimental combines the tpm-bound ssh keys with short-lived (<24hr) SSH certificates, alongside device attestation (to prove a given ssh key is on a tpm, no matter who or when it was generated).The background flow I'm working on, for which we *almost* have all the tooling, is: every day a script notices the user doesn't have a valid ssh certificate, and so generates a new CSR for the key, alongside an attestation statement. The SSH CA validates the attestation statement is correct for the laptop that that user was issued (and API calls out to the Device Management System to check that the device is compliant with all our policies) before issuing the certificate. Access to the CA is gated behind an SSO login, which enforces a daily check that the user is still valid and hasn't been suspended.
Thus the UX for the end user is minimally changed (one SSO login gets enforced per day, but otherwise they ssh and git in the manner they're used to, without them needing to change any behaviour - in fact as they never have to worry about copying their SSH publeys around, it's likely easier for the end user overall); whilst for us in Sysadmin we get loads of upsides:
1. No longer having to care about managing and clearing out authorized_keys files as they don't exist thanks to the certs
2. Guarantees that a given ssh login was initiated from a device that has our security policies applied to it
3. the knowledge that if we have to suspend a user for any reason, all their SSH access will be gone either as soon as the device management system locks their computer out (if their computer is online) or as soon as the ssh certificate expires if not
4. We can leverage the TPMs ability to measure boot to stop a user even starting the process of getting access if the operating system or the system boot settings have been tampered with.It's definitely a system with a bunch of complexity, but when you're in an Organisation context it has a lot of nice upsides as a trade off for that.
-
@jpmens
The design I *want* to get to in order to roll this out as non-experimental combines the tpm-bound ssh keys with short-lived (<24hr) SSH certificates, alongside device attestation (to prove a given ssh key is on a tpm, no matter who or when it was generated).The background flow I'm working on, for which we *almost* have all the tooling, is: every day a script notices the user doesn't have a valid ssh certificate, and so generates a new CSR for the key, alongside an attestation statement. The SSH CA validates the attestation statement is correct for the laptop that that user was issued (and API calls out to the Device Management System to check that the device is compliant with all our policies) before issuing the certificate. Access to the CA is gated behind an SSO login, which enforces a daily check that the user is still valid and hasn't been suspended.
Thus the UX for the end user is minimally changed (one SSO login gets enforced per day, but otherwise they ssh and git in the manner they're used to, without them needing to change any behaviour - in fact as they never have to worry about copying their SSH publeys around, it's likely easier for the end user overall); whilst for us in Sysadmin we get loads of upsides:
1. No longer having to care about managing and clearing out authorized_keys files as they don't exist thanks to the certs
2. Guarantees that a given ssh login was initiated from a device that has our security policies applied to it
3. the knowledge that if we have to suspend a user for any reason, all their SSH access will be gone either as soon as the device management system locks their computer out (if their computer is online) or as soon as the ssh certificate expires if not
4. We can leverage the TPMs ability to measure boot to stop a user even starting the process of getting access if the operating system or the system boot settings have been tampered with.It's definitely a system with a bunch of complexity, but when you're in an Organisation context it has a lot of nice upsides as a trade off for that.
@iMeddles it’s late here, and I’m tired, but I will try and process/understand tomorrow. Thank you for your insights!
-
@iMeddles it’s late here, and I’m tired, but I will try and process/understand tomorrow. Thank you for your insights!
@jpmens
No problem, I'm very happy to answer any questions about this - I'm still trying to make sure I've got all the pieces straight in my head, and answering questions is the best way to find the gaps in my own knowledge! -
`ssh host whoami` takes just over 1 second longer when using a TPM-backed SSH key than when using the same key algorithm in a file on the file system.
@jpmens I’m not surprised by that.
I suspect that the security trade off warrants it, especially for headless servers to have the private part of the key in hardware that it can’t be extracted from.
Maybe not ideal for interactive use.
But could be better if TPM key didn’t have a passphrase requirement and a local file did require a passphrase.
Assuming corporate security scans all keys and flags any without a passphrase on them.
-
R relay@relay.infosec.exchange shared this topic
