3 ms·

NB: If you use this, make sure to backup the key somehow. About a year ago I tested this with a few servers and lost all of the keys when my Mac had a kernel pa

NB: If you use this, make sure to backup the key somehow. About a year ago I tested this with a few servers and lost all of the keys when my Mac had a kernel panic that wiped the state of the Secure Enclave! Updates can do this too!

riobard 4y ago
Correct me if wrong, but I thought that you cannot extract the private key from the Secure Enclave at all?
- pocketarc 4y ago
  Yes, you can’t extract it, the Secure Enclave can just create a key and has it to sign stuff. You can never actually grab it or access it for backing up, so it shouldn’t be your only way of accessing a server, there should be another authorised key that you do have access to.
- friendzis 4y ago
  This is true for any [citation needed] hardware security module. The interface allows to store/generate secrets and request cryptographic operations (encryption, signing, etc). Aside from physically tampering with the chip to access bits in raw silicon there is no way for the secret itself to leave the chip. Software security modules behave the same way, with the exception that one does have software access to the backing encrypted storage.
  - Too 4y ago
    Yubikeys can be backed up, using what they call export under wrap. It requires you initially created the key with exportable flag. The idea is you do this on first use to create an encrypted backup and then instantly remove the exportable flag from the key you carry around day to day. As others already noted, having more than one key is a good idea anyway. If you are really serious, use ssh certificates so you don’t have to update every server with new keys. Just sign them with the root CA.
- fulafel 4y ago
  It's designed to make it hard, but it does crypto operations using the key so it's in there and possible to extract similarly as other tamper resistant chips have been successfully physically attacked.
- olliej 4y ago
  It depends on the setup. You can generally only ask an hsm to perform a few specific operations “encrypt this data”, “sign this data”, etc and you’re restricted to the exact formats that it supports. Because they are generally not very configurable (their design goal is to be secure and so the less complexity the better) it’s fairly common for them to just not directly support any specific cryptographic protocol. Given that, what you can choose to do instead is have the hsm generate a key for you, and then you use that key to wrap your specific secret - say an ssh key - then you decrypt it when you need it which requires user authentication through the hsm - use the raw key and then clear it from memory. But if the only record of the external key is wrapped by the hsm, if the hsm loses that decryption key then you’ve lost access to the ssh (or whatever) key as well.
ikiris 4y ago
No, this is what ssh certs are for. You can use any key you want as long as you get a CA that everything trusts to sign it.
- booi 4y ago
  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.
adastra22 4y ago
The whole point is that you literally can’t backup the key.
runeks 4y ago
The trick is to have multiple SSH keys -- spread out over several physical devices -- all of which are in your server's authorized_keys.
drdaeman 4y ago
There is no export or import functionality with Secure Enclave. Unlike with Yubikeys or similar HSMs, you can't even migrate your pre-existing private key(s) into SE.

riobard 4y ago

Correct me if wrong, but I thought that you cannot extract the private key from the Secure Enclave at all?

pocketarc 4y ago
Yes, you can’t extract it, the Secure Enclave can just create a key and has it to sign stuff. You can never actually grab it or access it for backing up, so it shouldn’t be your only way of accessing a server, there should be another authorised key that you do have access to.
friendzis 4y ago
This is true for any [citation needed] hardware security module. The interface allows to store/generate secrets and request cryptographic operations (encryption, signing, etc). Aside from physically tampering with the chip to access bits in raw silicon there is no way for the secret itself to leave the chip. Software security modules behave the same way, with the exception that one does have software access to the backing encrypted storage.
- Too 4y ago
  Yubikeys can be backed up, using what they call export under wrap. It requires you initially created the key with exportable flag. The idea is you do this on first use to create an encrypted backup and then instantly remove the exportable flag from the key you carry around day to day. As others already noted, having more than one key is a good idea anyway. If you are really serious, use ssh certificates so you don’t have to update every server with new keys. Just sign them with the root CA.
fulafel 4y ago
It's designed to make it hard, but it does crypto operations using the key so it's in there and possible to extract similarly as other tamper resistant chips have been successfully physically attacked.
olliej 4y ago
It depends on the setup. You can generally only ask an hsm to perform a few specific operations “encrypt this data”, “sign this data”, etc and you’re restricted to the exact formats that it supports. Because they are generally not very configurable (their design goal is to be secure and so the less complexity the better) it’s fairly common for them to just not directly support any specific cryptographic protocol. Given that, what you can choose to do instead is have the hsm generate a key for you, and then you use that key to wrap your specific secret - say an ssh key - then you decrypt it when you need it which requires user authentication through the hsm - use the raw key and then clear it from memory. But if the only record of the external key is wrapped by the hsm, if the hsm loses that decryption key then you’ve lost access to the ssh (or whatever) key as well.

ikiris 4y ago

No, this is what ssh certs are for. You can use any key you want as long as you get a CA that everything trusts to sign it.

booi 4y ago
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.

adastra22 4y ago

The whole point is that you literally can’t backup the key.

runeks 4y ago

The trick is to have multiple SSH keys -- spread out over several physical devices -- all of which are in your server's authorized_keys.

drdaeman 4y ago

There is no export or import functionality with Secure Enclave. Unlike with Yubikeys or similar HSMs, you can't even migrate your pre-existing private key(s) into SE.