4 ms·

From the FAQ: > Q: How do I import my current SSH keys, or export my Secretive Keys? > A: The secure enclave doesn't allow import or export of private keys. F

by pqdbr 6y ago

From the FAQ: > Q: How do I import my current SSH keys, or export my Secretive Keys? > A: The secure enclave doesn't allow import or export of private keys. For any new computer, you should just create a new set of keys. If you're using a smart card, you might be able to export your private key from the vendor's software. I don't get it. If so, how am I supposed to back up my keys in case of a hardware failure or hardware theft?

Metus 6y ago
You aren't. It is the same with Yubikeys, if you use them. You are supposed to generate a certificate per user and device they are using for authentication, which is not a big deal at least for remote login on servers, as you can set an arbitrary number of valid SSH keys.
- corty 6y ago
  You are supposed, yes, but it is not necessary with Yubikeys. You can still import private keys into your Yubikey. At work we are using this for group access to some appliances that annoyingly limit the number of SSH authorized keys you can teach them.
  - namibj 6y ago
    Also, there are arguments against generating RSA keys with closed-source software (don't tell me that's all pure hardware in a smartcard). For one, generating keys that are vulnerable to something exotic is very much a viable threat, and yubikeys in particular had an issue where some accidentally created very weak keys. Sure, you need to make sure the key doesn't leak on it's way, but that's not really the issue.
    - Xylakant 6y ago
      > and yubikeys in particular had an issue where some accidentally created very weak keys. So did Debian between 2006 and 2008 https://certlogik.com/debian-weak-key-check/ https://certlogik.com/debian-weak-key-check/
      - corty 6y ago
        Yes, but software is easier to fix and the problem is easier and more probable to find.
        namibj 6y ago
        More importantly: you can check the key generator to not include a Dual_EC_DRBG.
      - namibj 6y ago
        In OpenSSL. Not in GnuPG. I'm not claiming the latter necessarily has better code, but the former's bad code quality is known.
drewbug 6y ago
Keep a separate spare set of keys
GekkePrutser 6y ago
Like the others have said: You just use multiple. You can just add multiple keys to the authorized_keys file. This is actually the perfect scenario because an attacker can never get hold of the private key. That means that the key is unique: If it's in your hands, it means an attacker doesn't have it. Most smart cards work this way, they generate the private key inside and it can never leave the hardware, you can only prove you have it by using it to sign or encrypt something. This is very different from SSH keyfiles on disk which can be stolen in many ways, and as such can be compromised without you ever knowing about it. It's really cool that we can now use this functionality for SSH too. I currently use Yubikeys in OpenPGP mode for this but I might switch to this once I get a T2-enabled Mac.
- jooize 6y ago
  Is there a convenient way to manage and maintain those keys? Keeping the public key of each device and easily select which ones to place on servers.
  - acdha 6y ago
    In the case of SSH keys, when you export the key fingerprint you can edit the comment. I like the convention of email address & hostname to disambiguate the entries in a centrally-managed authorized keys list – when you get a new device, update the list and push the new version out.
  - GekkePrutser 6y ago
    Very good question. I've been thinking about a central way to manage keys. There doesn't really seem to be one, and it would be a big point of attack because an attacker might abuse it to add their own key. Right now what I do is I just log into my servers and copy the list :P I don't have that many anyway. The openssh people are also advocating certificates now, which means you'll have to set up a PKI, which will take care of revocation and such.
- pqdbr 6y ago
  By "you just use multiple", you mean I would have to generate extra private keys, add them to authorized_keys, and store them somewhere other than my mac, right? Because just by using multiple keys I would still be locked out if all of them were stored in this 'Secretive' app.

by pqdbr 6y ago

Metus 6y ago

You aren't. It is the same with Yubikeys, if you use them. You are supposed to generate a certificate per user and device they are using for authentication, which is not a big deal at least for remote login on servers, as you can set an arbitrary number of valid SSH keys.

corty 6y ago
You are supposed, yes, but it is not necessary with Yubikeys. You can still import private keys into your Yubikey. At work we are using this for group access to some appliances that annoyingly limit the number of SSH authorized keys you can teach them.
- namibj 6y ago
  Also, there are arguments against generating RSA keys with closed-source software (don't tell me that's all pure hardware in a smartcard). For one, generating keys that are vulnerable to something exotic is very much a viable threat, and yubikeys in particular had an issue where some accidentally created very weak keys. Sure, you need to make sure the key doesn't leak on it's way, but that's not really the issue.
  - Xylakant 6y ago
    > and yubikeys in particular had an issue where some accidentally created very weak keys. So did Debian between 2006 and 2008 https://certlogik.com/debian-weak-key-check/ https://certlogik.com/debian-weak-key-check/
    - corty 6y ago
      Yes, but software is easier to fix and the problem is easier and more probable to find.
      - namibj 6y ago
        More importantly: you can check the key generator to not include a Dual_EC_DRBG.
    - namibj 6y ago
      In OpenSSL. Not in GnuPG. I'm not claiming the latter necessarily has better code, but the former's bad code quality is known.

drewbug 6y ago

Keep a separate spare set of keys

GekkePrutser 6y ago

Like the others have said: You just use multiple. You can just add multiple keys to the authorized_keys file. This is actually the perfect scenario because an attacker can never get hold of the private key. That means that the key is unique: If it's in your hands, it means an attacker doesn't have it. Most smart cards work this way, they generate the private key inside and it can never leave the hardware, you can only prove you have it by using it to sign or encrypt something. This is very different from SSH keyfiles on disk which can be stolen in many ways, and as such can be compromised without you ever knowing about it. It's really cool that we can now use this functionality for SSH too. I currently use Yubikeys in OpenPGP mode for this but I might switch to this once I get a T2-enabled Mac.

jooize 6y ago
Is there a convenient way to manage and maintain those keys? Keeping the public key of each device and easily select which ones to place on servers.
- acdha 6y ago
  In the case of SSH keys, when you export the key fingerprint you can edit the comment. I like the convention of email address & hostname to disambiguate the entries in a centrally-managed authorized keys list – when you get a new device, update the list and push the new version out.
- GekkePrutser 6y ago
  Very good question. I've been thinking about a central way to manage keys. There doesn't really seem to be one, and it would be a big point of attack because an attacker might abuse it to add their own key. Right now what I do is I just log into my servers and copy the list :P I don't have that many anyway. The openssh people are also advocating certificates now, which means you'll have to set up a PKI, which will take care of revocation and such.
pqdbr 6y ago
By "you just use multiple", you mean I would have to generate extra private keys, add them to authorized_keys, and store them somewhere other than my mac, right? Because just by using multiple keys I would still be locked out if all of them were stored in this 'Secretive' app.