3 ms·

hmm, where do you store the CA private key? We're just going around in circles

• deleted 4y ago
  [deleted]
• ikiris 4y ago
  in a safe at the bottom of the ocean? who cares, put an intermediate signer in a cloud somewhere that requires 2FA with multiple valid tokens, and everything is now much more secure and not tied to your specific key.
  • chasil 4y ago
    I think it's more nuanced. SMP and hyperthreading are risky for security. Closed firmware is also concerning. Older systems without these architectural features are more difficult to abuse. I would find one of these if I needed a secure SSH CA for myself, and use OpenBSD. I probably couldn't get away with that in a larger organization.
• friendzis 4y ago
  > hmm, where do you store the CA private key? On another device. > We're just going around in circles Depends on attack vector. Both solutions store private key in HSM and hence protect against "attacker gains access to local memory/storage". However, ssh certs allow key to be "regenerated". HSM'd keys are subject to "device got lost/destroyed" attack, HSM'd certs are subject to "CA got compromised". Pick your poison.
• mbreese 4y ago
  The point isn’t how to secure the CA’s private key. The point is that this is a separate system that is probably easier to secure. Physically, it’s probably in a data center. If you want to, you could have the CA key loaded into memory at boot time with a removable USB drive. That key should be easier to protect than a private key on an end user computer, Secure Enclave or not.