4 ms·

Check out `man sc_auth`. There's also an exportable variant where the private key is encrypted using the secure enclave as opposed to generated on the secure en

Check out `man sc_auth`. There's also an exportable variant where the private key is encrypted using the secure enclave as opposed to generated on the secure enclave: % sc_auth create-ctk-identity -l ssh-exportable -k p-256 -t bio % sc_auth list-ctk-identities p-256 A581E5404ED157C4C73FFDBDFC1339E0D873FCAE bio ssh-exportable ssh-exportable 23.11.26, 19:50 YES % sc_auth export-ctk-identity -h A581E5404ED157C4C73FFDBDFC1339E0D873FCAE -f ssh-exportable.pem Enter a password which will be used to protect the exported items: Verify password: You can then re-import it on another device % sc_auth import-ctk-identities -f ssh-exportable.pem.p12 -t bio Enter PKCS12 file password: I'll add this to the guide

sroussey 11mo ago
“ This is might be considered secure but is convenient for key backup.” Might want to clean up that sentence.
rjdj377dhabsn 11mo ago
How is this method any different from encrypting the private key without any secure enclave? Isn't it just using a password derived key?
- arianvanp 11mo ago
  The key is stored encrypted with a unique symmetric key that only your secure enclave knows until the point that you export it. It then re-encrypts it with the password. Until you export it it's just as strong as an enclave-generated one. Obviously don't keep the exported password encrypted key around and don't use a weak password for export.
  - gruez 11mo ago
    >The key is stored encrypted with a unique symmetric key that only your secure enclave knows until the point that you export it. It then re-encrypts it with the password. But what's the security benefit of this compared to having a keyfile? So far as I can tell from the commands you provided, there's no real difference, aside from a hacker having to modify their stealer script slightly.
    - arianvanp 11mo ago
      Why is it more secure: a key file on disk is decrypted into memory every time you enter your passphrase. It means the key is around in plain text in the memory of ssh or ssh-agent. Which means it's extractable by an attacker. An exportable key does all the signing inside the secure enclave and never exposes the decrypted key to OS memory. The exported key you can keep in a safe for disaster recovery. You shouldn't keep it on your computer of course.
      - traceroute66 11mo ago
        > The exported key you can keep in a safe for disaster recovery. No. Your "disaster recovery" should be either a second device with a Secure Enclave, or a Yubikey. Making it exportable from the Secure Enclave defeats the whole purpose.
      - gruez 11mo ago
        >It means the key is around in plain text in the memory of ssh or ssh-agent. Which means it's extractable by an attacker. An exportable key does all the signing inside the secure enclave and never exposes the decrypted key to OS memory. But malware can just tell the secure enclave to export the key? Yes, they'll have to write new code to do that, but it's not particularly hard (it's 1 line code from your example above), and it's security through obscurity.
        monocularvision 11mo ago
        The malware would have to prompt for biometric authentication before exporting.
        Nextgrid 11mo ago
        So it just has to wait until you’re about to do a legitimate operation requiring authentication, intercept that to export the key, and cancel the real one with a bogus error (and you’ll just try again without any second thoughts). MacOS has also no concept of secure desktop/etc where the OS can use some privileged UI to explicitly tell you what you are signing and prompt for PIN/biometrics. It’s in fact a well-known problem where legitimate dialogs for system/Apple ID password have no distinguishing features from fake ones.
  - deleted 11mo ago
    [deleted]
lxgr 11mo ago
Is there a way to import an existing (compatible) key and still mark it as non-exportable? That seems more useful for the SSH key scenario: Generate a key in memory and back it up to offline storage once, and otherwise only use it in a way totally non-exportable by any malware. This sentence > The exportable private key is encrypted with Elliptic Curve Encryption Standard Variable IVX963 algorithm which is backed by a Secure Enclave key. makes it sound like exportable keys might inherently not be Secure Enclave resident in Apple's implementation, which would be unfortunate, as anything else can still be accessed by malware with kernel-level privileges. (GPG, and I believe also PIV, allow importing externally-generated keys without necessarily marking them exportable; they'll just, correctly, lack any attestation statement about having been generated in secure hardware.)
- cyberax 11mo ago
  No. There is no way to import an existing key into the Secure Enclave. Only Apple is allowed to do that. The best you can do is use the SE to decrypt the key and then use the clear text key for encryption/decryption. This also means that passkeys on macOS/iOS are (at some point) exposed as clear text.
  - big-and-small 11mo ago
    > The best you can do is use the SE to decrypt the key and then use the clear text key for encryption/decryption. AFAIK this is what "secretive" was doing all the time.
    - lxgr 11mo ago
      I'm pretty sure it creates SE resident keys, which can't be unwrapped by either userspace or the macOS kernel.
      - big-and-small 11mo ago
        Then I'm wrong.
    - 11mo ago
ggm 11mo ago
Can you explain which keys in the secure enclave make this work because it has at least two keysets: a public-private keypair locked to the root key Apple instantiated in hardware as fused links in the chip and so in theory this could include private keys common to all the devices in this chipset generation, and the locally generated unique keys which are tied to this specific device. Using the first pair or products of the first pair, means in principle your private key is protected by the goodwill of Apple only: if you allow it to exist at rest in a form only this shroud protects, then Apple can read the private key unless the symmetric algorithm used to "unlock this private key with your password" is a good one, and you chose a password wisely. I haven't used the function so I can't comment how they constrain what you put in as a personal lock on these blobs. I am not a cryptographer.

sroussey 11mo ago

“ This is might be considered secure but is convenient for key backup.” Might want to clean up that sentence.

rjdj377dhabsn 11mo ago

How is this method any different from encrypting the private key without any secure enclave? Isn't it just using a password derived key?

arianvanp 11mo ago
The key is stored encrypted with a unique symmetric key that only your secure enclave knows until the point that you export it. It then re-encrypts it with the password. Until you export it it's just as strong as an enclave-generated one. Obviously don't keep the exported password encrypted key around and don't use a weak password for export.
- gruez 11mo ago
  >The key is stored encrypted with a unique symmetric key that only your secure enclave knows until the point that you export it. It then re-encrypts it with the password. But what's the security benefit of this compared to having a keyfile? So far as I can tell from the commands you provided, there's no real difference, aside from a hacker having to modify their stealer script slightly.
  - arianvanp 11mo ago
    Why is it more secure: a key file on disk is decrypted into memory every time you enter your passphrase. It means the key is around in plain text in the memory of ssh or ssh-agent. Which means it's extractable by an attacker. An exportable key does all the signing inside the secure enclave and never exposes the decrypted key to OS memory. The exported key you can keep in a safe for disaster recovery. You shouldn't keep it on your computer of course.
    - traceroute66 11mo ago
      > The exported key you can keep in a safe for disaster recovery. No. Your "disaster recovery" should be either a second device with a Secure Enclave, or a Yubikey. Making it exportable from the Secure Enclave defeats the whole purpose.
    - gruez 11mo ago
      >It means the key is around in plain text in the memory of ssh or ssh-agent. Which means it's extractable by an attacker. An exportable key does all the signing inside the secure enclave and never exposes the decrypted key to OS memory. But malware can just tell the secure enclave to export the key? Yes, they'll have to write new code to do that, but it's not particularly hard (it's 1 line code from your example above), and it's security through obscurity.
      - monocularvision 11mo ago
        The malware would have to prompt for biometric authentication before exporting.
        Nextgrid 11mo ago
        So it just has to wait until you’re about to do a legitimate operation requiring authentication, intercept that to export the key, and cancel the real one with a bogus error (and you’ll just try again without any second thoughts). MacOS has also no concept of secure desktop/etc where the OS can use some privileged UI to explicitly tell you what you are signing and prompt for PIN/biometrics. It’s in fact a well-known problem where legitimate dialogs for system/Apple ID password have no distinguishing features from fake ones.
- deleted 11mo ago
  [deleted]

lxgr 11mo ago

Is there a way to import an existing (compatible) key and still mark it as non-exportable? That seems more useful for the SSH key scenario: Generate a key in memory and back it up to offline storage once, and otherwise only use it in a way totally non-exportable by any malware. This sentence > The exportable private key is encrypted with Elliptic Curve Encryption Standard Variable IVX963 algorithm which is backed by a Secure Enclave key. makes it sound like exportable keys might inherently not be Secure Enclave resident in Apple's implementation, which would be unfortunate, as anything else can still be accessed by malware with kernel-level privileges. (GPG, and I believe also PIV, allow importing externally-generated keys without necessarily marking them exportable; they'll just, correctly, lack any attestation statement about having been generated in secure hardware.)

cyberax 11mo ago
No. There is no way to import an existing key into the Secure Enclave. Only Apple is allowed to do that. The best you can do is use the SE to decrypt the key and then use the clear text key for encryption/decryption. This also means that passkeys on macOS/iOS are (at some point) exposed as clear text.
- big-and-small 11mo ago
  > The best you can do is use the SE to decrypt the key and then use the clear text key for encryption/decryption. AFAIK this is what "secretive" was doing all the time.
  - lxgr 11mo ago
    I'm pretty sure it creates SE resident keys, which can't be unwrapped by either userspace or the macOS kernel.
    - big-and-small 11mo ago
      Then I'm wrong.
  - 11mo ago

ggm 11mo ago

Can you explain which keys in the secure enclave make this work because it has at least two keysets: a public-private keypair locked to the root key Apple instantiated in hardware as fused links in the chip and so in theory this could include private keys common to all the devices in this chipset generation, and the locally generated unique keys which are tied to this specific device. Using the first pair or products of the first pair, means in principle your private key is protected by the goodwill of Apple only: if you allow it to exist at rest in a form only this shroud protects, then Apple can read the private key unless the symmetric algorithm used to "unlock this private key with your password" is a good one, and you chose a password wisely. I haven't used the function so I can't comment how they constrain what you put in as a personal lock on these blobs. I am not a cryptographer.