Live data from Hacker News

Native Secure Enclave backed SSH keys on macOS

gist.github.com

41–50 of 204 posts

Re: Native Secure Enclave backed SSH keys on macOS

#41
post #13

If I understand correctly, this means you can't back up the private key, correct? It's in the Secure Enclave, so if you lose your laptop, you also lose the key? Since it looks like export only really exports the public key not the private one? Probably not the worst thing, you most likely have another way to get into the remote machine, or an admin who can reset you, but still feels like a hole. Or am I missing somet…

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 A581E5404ED157C4C73FFDBDF…

“ This is might be considered secure but is convenient for key backup.”

Might want to clean up that sentence.

Re: Native Secure Enclave backed SSH keys on macOS

#42
post #13

If I understand correctly, this means you can't back up the private key, correct? It's in the Secure Enclave, so if you lose your laptop, you also lose the key? Since it looks like export only really exports the public key not the private one? Probably not the worst thing, you most likely have another way to get into the remote machine, or an admin who can reset you, but still feels like a hole. Or am I missing somet…

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 A581E5404ED157C4C73FFDBDF…

How is this method any different from encrypting the private key without any secure enclave?

Isn't it just using a password derived key?

Re: Native Secure Enclave backed SSH keys on macOS

#43

Earlier quoted context omitted.

Which makes yubikey impossible to use with geographically distributed backups. You need the backup available at all times for when you want to register with any new service. This is why you should use a device which allows exporting the seed, like e.g. multi purpose hardware crypto wallets.

Are you talking about SSH or a different setting? With SSH, you can always share the primary and backup pub keys, even if you don't have the backup key handy.

No I got distracted by the word yubikey. Arguably not the same subject. :)

Re: Native Secure Enclave backed SSH keys on macOS

#45

Earlier quoted context omitted.

Are you talking about SSH or a different setting? With SSH, you can always share the primary and backup pub keys, even if you don't have the backup key handy.

No I got distracted by the word yubikey. Arguably not the same subject. :)

Nonetheless I'm glad to hear about it. I don't yet use YubiKeys for FIDO, because I was concerned a bit about this enrollment process, and hadn't bothered to figure out what others do.

Re: Native Secure Enclave backed SSH keys on macOS

#46
post #34
post #31

Earlier quoted context omitted.

You're not really supposed to 'export' keys. Any time you move a key you risk exposing it. The idea of PKI is that only public keys move, the private key stays in one place, ideally never seen.

I've been in the security space for 25 years, and understand the theory of PKI. But I've also been in the ops space for 30 years, and understand that if you don't balance security theory with operational practice, critical business functions can fail. Ideally yes, the private key is never seen. In reality, it needs to be backed up in a secure place so it can be restored in the event of a failure.

You can use more than one key you know.

Keep the private key you actively use in the secure enclave. The system you actively use is most at risk.

Keep a secondary offline private key as backup. You can generate and store it in a secure location, and never move it around. Airgapped even if you want. You could even use a yubikey or other hardware for the secondary key giving you two hard to export keys.

Distribute pub keys for both of them.

Best of both worlds?

Re: Native Secure Enclave backed SSH keys on macOS

#47

Earlier quoted context omitted.

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 A581E5404ED157C4C73FFDBDF…

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

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.

Re: Native Secure Enclave backed SSH keys on macOS

#48

Does anybody know if there is something similar for gpg keys? E.g. for commit signing? That is, natively with the Secure Enclave, not exportable.

You can (mis)use ssh keys for git signing, but GPG on gpg-card and S/MIME on PIV card are the two standards and their respective hardware implementations (for signing keys in general.)

Re: Native Secure Enclave backed SSH keys on macOS

#49
post #2

It's a total pain in the ass to try to have password encrypted gpg or ssh keys in mac. Nothing better that another way to make it even more painful and complicated, so that people will just store plain text keys to not be annoyed.

> It's a total pain in the ass to try to have password encrypted gpg or ssh keys in mac. Who uses password encrypted keys anyway ? No exfiltration protection, and a sitting duck for unlimited automated password guessing attempts. Pre-Tahoe people used Yubikeys or Secretive. But now this native tool is a better option than Secretive, even if Yubikeys still have their uses for the power-users.

With an ssh agent and time-bounded key expiration one can have very strong password on the key that is convenient to use.

Also password managers like 1password or Bitwarden support ssh-agent protocol so one can have a master password that protects both stored passwords and keys.

Re: Native Secure Enclave backed SSH keys on macOS

#50

Earlier quoted context omitted.

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

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.

>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.

Post reply on HN