Comment by Nextgrid
5 months ago
In this case you can maintain an offline SSH CA and trust that on the remote machines, and then sign yourself leaf certificates against a non-exportable HSM-backed key. In case of loss you just make a new key and sign a new certificate.
Of course this just moves the key management problem somewhere else: now you need to protect the CA key, but that might be easier since you would only need access to it in a disaster recovery scenario if you replaced the laptop or otherwise lost access to your HSM-backed key.
As usual, it all depends on your threat model.
But how do you revoke any compromised certificate if you don't control the remote machines?
Keeping the certificate’s key as non-exportable in the HSM means you do not need to revoke it as it cannot be compromised (not permanently at least), once you’ve regained access to the HSM you can assume the bad guys are out.
Of course the CA key itself is another story, which is why this merely moves the problem elsewhere (however since you only need access to the CA during initial provisioning of a new certificate key, you can better control access to it).
> Keeping the certificate’s key as non-exportable in the HSM means you do not need to revoke it as it cannot be compromised (not permanently at least), once you’ve regained access to the HSM you can assume the bad guys are out.
How so? I can still lose my Yubikey, and even if the attacker can't export the private key corresponding to a CA-signed SSH certificate, they can still use it, no? How would I "regain access" in this scenario?
1 reply →