The command is available on Sequoia too!
Native Secure Enclave backed SSH keys on macOS
151–160 of 204 posts
Re: Native Secure Enclave backed SSH keys on macOS
#152Earlier 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…
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…
Another option is to generate a key and put it on an offline storage, and have a second key only in the SE. This means you'll need to upload two public keys to places to have a backup instead of one, but I think would otherwise achieve the same thing.
The nice thing with this is you can keep your backup public key easily accessible. I try to keep a primary and backup Yubikey on everything important, but you have to physically get the backup Yubikey in order to add it to a site.
Re: Native Secure Enclave backed SSH keys on macOS
#153If 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…
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.
Re: Native Secure Enclave backed SSH keys on macOS
#154If 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…
This is the fundamental paradox of hardware secured keys. Basic ones generate the private key inside and never let it be exported. This allows you to be very sure it won't ever leak but also doesn't let you back it up. Higher end Hardware Security Modules allow the private key to be exported but only when encrypted with the valid public key of a destination HSM.
Re: Native Secure Enclave backed SSH keys on macOS
#155Earlier quoted context omitted.
It's much safer to export a key one time and import it into a new machine, or store it in a secure backup, than to keep it just hanging out on disk for eternity, and potentially get scooped up by whatever malware happens to run on your machine.
Any malware capable of exfiltrating a file from your home folder is also capable of calling the export command and tricking you into providing biometrics.
Not necessarily; "read file" is very different from "execute command." The biometrics part is a substantial lift as well.
Re: Native Secure Enclave backed SSH keys on macOS
#156Earlier quoted context omitted.
Yeah but if you get a new device, you have to go add its pubkey to every server you ever use. I wish there were an easier way, otherwise it's understandable that people copy privkeys.
There is an easier way, it's called TLS certificates, it's just that SSH decided not to use it for some reason. Other systems of this nature have figured out long ago that you should be able to have one personal certificate (stored securely in an airgapped environment), from which you'd generate leaf certificates for your devices every year.
or FreeIPA?
Re: Native Secure Enclave backed SSH keys on macOS
#157If 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…
posting late in the discussion, but you shouldn't back up our private keys. The ideal setup is with ssh-ca's anyways.
Re: Native Secure Enclave backed SSH keys on macOS
#158If 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…
Right, you can back up the key.
There’s three general approaches to SSH: having per-device client keys, having per-server keys and having the same key everywhere.
A Secure Enclave, Yubikey or other hardware keys work well with the first approach. Ideally, you won’t loose all keys at once.
Re: Native Secure Enclave backed SSH keys on macOS
#159Ok I wished for this kind of feature for years. I started using a yubikey with an ssh key via gpg ssh-agent in 2018 or 2019. When resident ssh keys came around I switched over to FIDO2 based keys on my yubikey. The main issue with both was the fact that the default ssh setup wasn’t working anymore. One needs extra configs and more commands to get to the public key etc. Yubikey’s are great but block an USB port. And then there is the age old question for me: One SSH key per User for all services? One key per machine for all services? Or one key per service?
This year I started to play around with the 1Password ssh-agent feature (bit warden has it as well as far as I know)
If you're ok with allowing all your keys being listed in the agent this works pretty easy out of the box.
I never liked the fact that the default recommended way to use ssh is to use an agent that just has multiple keys which can be tested one after another and in most cases stay unlocked there after first use for the rest of the session.
I configured around to make sure that I explicitly use one key for one specific service. But that is sadly extra configuration etc etc.
Re: Native Secure Enclave backed SSH keys on macOS
#160Earlier quoted context omitted.
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…
It’s important to remember that over time systems develop complexities that can be hard to recover from scratch because by definition air gapped data aren’t ones you are regularly exercising. Here’s an example of this in action from Google’s history https://google.github.io/building-secure-and-reliable-system...
>It took an additional hour for the team to realize that the green light on the smart card reader did not, in fact, indicate that the card had been inserted correctly. When the engineers flipped the card over, the service restarted and the outage ended.
This is some good read!