[dave1010uk]

If you were building a system with legacy firmware (so, for examole you couldn't rotate keys in case of a breach), how would you mitigate against situations like this? Can anyone give a brief overview of how to architect a more secure system?

[rdl]

When you build a public key into firmware which isn't easily updated, you need to put a lot of effort into securing the corresponding private key. The correct way to do this is to have a separate credential for your actual admin users who then use that to authenticate to an HSM or similar system which controls the actual widely-deployed keys. Humans should never be able to access the important private keys directly, and there should be a logging process which shows those keys have never been exported (and have technical and policy controls against being exported) without proper multi-party control (so, you back them up in k of n shares, and distribute those shares across corporate officers in multiple sites in the event you need to replace the HSM).

Shorter lived keys and more frequent updates, provided you also have a secure way of authenticating the updates (hard) is often preferred.

[cnvogel]

The "canonical" way of solving this is of course with a certificate hierarchy. You can configure your target system to allow authentication whenever your certificate is signed by the "golden" key, and by creating the certificates with expiration dates it's easy to restrict the time that a certificate (which maybe got stolen or was made public inadvertendly) can be used for login.

Adding auxiliary data (comparable to X509 certificate usage restrictions only for code-signing or signing for emails) would allow you to have a (central hardened) machine hand out certificates to your "semi trusted" administrators that only allow login from a specific IP-address, to a specific target-system, up to a certain date or even time. Putting this functionality in a script (to acquire the certificate and login to a system) such a wrapper could most likely be used as a drop-in replacement for the normal ssh-client.

If your restriction is to use only the default openssh already deployed to the target machines, one quick solution to hide the critical private key from the developer/admin/service machines would be to place it on a (hopefully somewhat hardened) machine running the ssh-agent, and access the agent by creative use of tunelling. In essence then the hardened machine would act as a kind of "smartcard" for all your admins.

[bdonlan]

You can put the private key on a few HSMs, and have the HSM enforce a security policy (eg - access must be authorized by a quorum of operators). Never allow the private key to leave the HSM, ever again, except when initializing a new HSM (in which case, it had better be encrypted by the new HSM's unique key before leaving the old one).

Then you go fix your legacy firmware.