Comments
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 something?
ps. It amuses me that my Mac won't let me type Secure Enclave without automatically capitalizing it.
Edit: I understand good security is having multiple keys, I was simply asking if this one can be backed up. OP answered below and is updating their webpage accordingly.
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:
You can then re-import it on another device% 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:
I'll add this to the guide% sc_auth import-ctk-identities -f ssh-exportable.pem.p12 -t bio Enter PKCS12 file password:By rjdj377dhabsn 2025-11-2319:191 reply 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.
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.
By sroussey 2025-11-2319:19 “ This is might be considered secure but is convenient for key backup.”
Might want to clean up that sentence.
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?
By morshu9001 2025-11-2319:58 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.
By philsnow 2025-11-2319:46 > if you don't balance security theory with operational practice, critical business functions can fail
i.e. people will circumvent the secure-but-onerous path. (I don't think they can be faulted for trying to get their work done either, I'm agreeing with you)
By eptcyka 2025-11-2319:45 In what scenario would you prefer to backup an SSH key in favor of generating new SSH keys?
By asteroidburger 2025-11-2319:17 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.
By justincormack 2025-11-2318:46 Correct. Set up multiple keys as backups. Thats also a positive, as nothing can leak the key.
By hylaride 2025-11-2319:17 Strictly speaking people should be using multiple keys so if a device is lost/stolen, you're not left high and dry. Ideally one per device, especially if they don't support some kind of secure enclave.
I keep one in a yubikey protected by a PIN that sits in a safety deposit box, too. This way if I have my laptop, phone, and day-to-day yubikey is a house that suddenly burns down, I'm still ok.
Inability to export the private key is no different from using an YubiKey? You can't "backup" the private key they generate either.
By johnisgood 2025-11-2318:563 reply Yeah, that is why you should not generate it on a YubiKey.
You need to have:
- an offline master private key backup (air-gapped)
- primary YubiKey (daily use)
- backup YubiKey (locked away)
- revocation certificate (separate storage) (it is your kill-switch)
Having a second YubiKey enrolled is the standard practice.
What people do wrong is:
- They generate directly on YubiKey
- They only use one device
- They do not create a revocation certificate
- They have no offline backups
You generate your GPG keys on a secured system, load the subkeys (not the master because it is not used for daily cryptography) into the YubiKeys, and then remove the secret keys from this system where you generated the keys.
By traceroute66 2025-11-2319:56 > Yeah, that is why you should not generate it on a YubiKey
No. You should ALWAYS generate on the Yubikey. That's the whole point.
Your backup is one (or more) other keys.
By eptcyka 2025-11-2319:46 You are talking about GPG keys. The featured article only refers to SSH keys. Know the difference.
I can understand revocation for GPG, but is revocation ever used for SSH? I could understand it if SSH certificates are used, but honestly I've never encountered an org using SSH's cert system.
By johnisgood 2025-11-2319:18 Well, OpenSSH has a built-in key revocation mechanism (KRL which is just SSH revocation), and there are SSH certificates (with a CA) and certificate revocation, and there is ad-hoc "revocation" by removing keys from the "authorized_keys" file.
If you use your GPG key for SSH, the servers that have your public key do not automatically know that your GPG key was revoked, and SSH authentication will proceed unless you remove the public key from the server OR the server uses an SSH CA/KRL model.
All in all, SSH supports real revocation, but it must be enforced by the server. It is different from GPG where revocation follows the key, not the server.
I have not used KRL myself, but I sort of know how it works. You can generate a new empty KRL, then add keys to revoke, and then to distribute the KRL to servers by configuring OpenSSH to use the KRL file, by adding "RevokedKeys /etc/ssh/revoked_keys.krl" to "/etc/ssh/sshd_config".
The pros of KRL is that they scale better than manual removal for multiple servers, and you can revoke entire CA ranges instead of individual keys if using SSH certificates which is recommended for large setups.
I hope I could clear some things up. Let me know if you have any questions though!
By nothrabannosir 2025-11-2319:082 reply 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.
By traceroute66 2025-11-2319:57 > Which makes yubikey impossible to use with geographically distributed backups.
Huh ?
You do know you can wrap a symmetric key with multiple asymmetric keys, right ?
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.
By nothrabannosir 2025-11-2319:201 reply No I got distracted by the word yubikey. Arguably not the same subject. :)
By epistasis 2025-11-2319:25 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.
How can I get such a key into my iPhone too, so that I can sign emails and file and such with the same private key when I'm on my phone, and my public key is valid for all such operations ? Will iCloud take care of that ? And then I want it all usable from my (multiple) email clients...
By arianvanp 2025-11-2319:59 These aren't synced over iCloud
What you're thinking of are Passkeys. Which are synced. Somebody would have to write an SecurityKeyProvider that talks to the Passkey API instead.
Actually I don't think it's completely impossible. The only thing is that passkeys are origin-bound. They belong to a specific AppBundle ID or domain name. If say Secretive would add passkey support then that specific public/private keypair can't be used by another app. Though it does sync across instances of the app across devices.
By redleader55 2025-11-2319:381 reply This exists: https://github.com/facebookincubator/sks.
It's a golang library that abstracts usage of ssh keys backed by hardware on all sorts of devices - mostly designed for laptops, but supports Linux, Windows and MacOs
By Foxboron 2025-11-2319:47 A golang library is cool, but it doesn't give you a working ssh-agent.
I started working on one few years ago: https://github.com/Foxboron/ssh-tpm-agent
