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.
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.
% 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:
% sc_auth import-ctk-identities -f ssh-exportable.pem.p12 -t bio
Enter PKCS12 file password:
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.
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.)
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.
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.
Isn't it just using a password derived key?
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.
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.
The exported key you can keep in a safe for disaster recovery. You shouldn't keep it on your computer of course.
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.
But yeh the malware only needs to trick you to hit TouchID once. Instead of on each sign operation. So if that's in your threat model don't make the key exportable.
That's not meaningfully more difficult than tricking you into revealing your key file password.
>Instead of on each sign operation.
But from your video each sign operation also requires a touchid prompt?
No, but that's meaningfully more difficult to do without an intervention from the user. Say your computer is infected, the malware won't silently do it: it will have to interact with you.
And an important part is that you apparently don't have to make the key exportable:
> So if that's in your threat model don't make the key exportable.
Which now makes it meaningfully more difficult to extract.
I would personally not export it, just like I don't export (and can't export) the key from a security key. That's a feature.
MacOS is so needy about all kinds of fingerprint/password-related things (and has no context of secure desktop) that it is trivial for malware to simulate and no way for the user to tell whether it's genuine, so it's not a real barrier at all.
But even if security was exactly the same, I'd prefer the touch to the typing.
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.
Of course, this was back in the day when computers were primarily a productivity tool and not an ad delivery vehicle, so it's unlikely this problem will ever be solved.
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.
Might want to clean up that sentence.
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.
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?
https://google.github.io/building-secure-and-reliable-system...
It’s not too bad, if the number of servers is not too high.
I have different client pub keys on my phone, multiple laptops and desktop computers and manage my authorized keys to be able to ssh into my servers from the devices, as well as from one laptop to another or from my phone to one of the laptops, etc.
Because I already have several client devices I don’t really need any backup ssh keys. The fact that each device has a different key means that if one laptop breaks or my phone is stolen, I can still ssh into everything from one of the remaining devices and remove the pub key of the broken or stolen device from authorized keys and generate new keys on new devices and then using one of the existing devices to add the pub key of the new device to the authorized keys of the servers and other devices.
For me it’s manageable to do it manually. But if you have very many servers you’d probably want to use a configuration management tool like Chef, Ansible, Puppet or Saltstack. Presumably if you have a very high number of servers you’d already be using a configuration management tool like one of those for other configs and setup anyways.
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.
If I lose one I can still sign new certs with the other.
https://github.com/arianvp/nixos-stuff/blob/master/modules/s...
SSH isn't always that. For example, ssh-copy-id by default does not copy over multiple identities.
For that reason, I'd personally prefer to import my (otherwise airgapped) key into my secure hardware exactly once and mark it as non-exportable in the SSH scenario.
Anything (everything?) using SSH authentication supports multiple authentication keys. Have a yubikey in a locked deposit box or something.
I was simply asking if that is still possible with this method, nothing more.
And not every service that uses ssh auth allows multiple keys.
The advantage of non-exportable, HSM-backed keys is that you are guaranteed that the only way to use that key is to have online access to the HSM, and you can recover from HSM access compromise without having to replace the keys.
If you make the key exportable it is no better than if it was stored on your disk to begin with.
Beyond that, you can do that just fine right now by making TWO keys. If you lose the laptop, oh well. Recover with your backup key (which is hopefully kept more securely than you describe - it can be inconvenient to access since it is only needed for recovery).
This also lets you go further in locking things down or providing you notifications, as you can distinguish server side between your usual key and the backup key.
The point of the enclave is to be noncloneable and access limited. Extracting the key for the backup would negate the benefits derived from that.
Such a setup is marginally more secure than just typing in the passwords, since it is much harder to intercept the TouchID chain from touch to decrypting the SSH key compared to your keyboard to the terminal.
All that said, here are the priorities of a few security technologies:
TouchID:
#1 environment integrity, that is to say, to protect Apple services monopolies and fees such as eliminating password sharing of services accounts, #2 convenience as an alternative to passwords reducing friction when you buy stuff, #3 security.
#1 convenience, #2 security
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)
Of course this just moves the key management problem somewhere else: now you need to protect the CA key, but that might be easier since you would only need access to it in a disaster recovery scenario if you replaced the laptop or otherwise lost access to your HSM-backed key.
As usual, it all depends on your threat model.
Of course the CA key itself is another story, which is why this merely moves the problem elsewhere (however since you only need access to the CA during initial provisioning of a new certificate key, you can better control access to it).
How so? I can still lose my Yubikey, and even if the attacker can't export the private key corresponding to a CA-signed SSH certificate, they can still use it, no? How would I "regain access" in this scenario?
Either way, you either recover the HSM and then don't need to rotate the keys, or you don't in which case you either use OpenSSH's key revocation mechanism (which I believe involves distributing some some sort of CRL to every server), use time-limited SSH certificates and wait out the expiry of the compromised key, or scrap the whole CA and start fresh.
Again this depends on your threat model. The somewhat uncommon requirement where you can't manage your own `authorized_keys` on the remote host complicates things a lot; if you could, then you'd use your existing access (sign yourself a new certificate using your SSH CA) to rotate the whole CA... or just keep two keys in there (primary and backup) and skip the whole CA dance, since it's purely a workaround for the hard requirement of only being able to put one key in authorized_keys.
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.
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!
No. You should ALWAYS generate on the Yubikey. That's the whole point.
Your backup is one (or more) other keys.
Generating keys exclusively in (non-backup-able) secure hardware is great if your scenario readily supports multiple keys per server/domain you're authenticating in.
Creating an airgapped backup and loading that into a "daily driver" Yubikey marked as non-exportable can be perfectly fine if that's not the case and you don't want to notify the world every time you're adding or retiring a new Yubikey (for reasons other than key compromise).
It is only slightly less secure if you pre-generate subkeys on an offline machine if you want identical subkeys on multiple devices (and if you want exact backups). Sometimes this is exactly what people want.
Ultimately it really depends on your use case.
BTW, please check the parent comments to which I responded.
PS. I think it would be useful for others if you elaborated on your statements (for educational purposes).
I’ve been putting off remaking my GPG and SSH keys using a Yubikey.
This is why you should use a device which allows exporting the seed, like e.g. multi purpose hardware crypto wallets.
But SSH allows you to export the public key and then you can enroll it on as many hosts as you want without needing access to the private key, so the backup key can remain in a safe, ideally forever as you should never need it.
There's also no technical obstacle preventing anyone from creating "paired" hardware authenticators that share the same internal root derivation key and can as such authenticate to all services (at least if they don't demand resident credentials) that were registered to any of the keys in the set.
The fact that these keys don't exist on the market (I believe Yubikey looked into them a while ago) more is evidence for the lack of demand, and less for the existence of a cabal, in my view.
Authenticator implementations who allow exports outside of the vendor cartel are threatened to be blacklisted: https://github.com/keepassxreboot/keepassxc/issues/10407
> My primary hardware key can be from a completely different vendor than the backup one, so I don't quite buy the conspiracy angle.
The fundamental flaw is that enrolling an authenticator requires it to be present, making a backup strategy much less resilient as it means your secondary device needs to be constantly present and thus exposed to the same local/environmental risks the primary one is (theft/fire/faulty USB port that fries everything plugged in and you only realize after nuking both your keys). It makes an offline backup scenario like with SSH (where you copy a public key and otherwise leave the authenticator out of reach in a safe place) impossible.
Making it hard/impractical to maintain a reliable backup yourself sure makes those proprietary sync-based services attractive, which also doubles as reducing security since key material is being synced and can potentially be extracted (impossible with a true HSM + PKI implementation).
> preventing anyone from creating "paired" hardware authenticators
Don't certain types of keys involve writing something to the authenticator, fundamentally preventing this (as the backup authenticator won't get this written value)?
> cabal
It doesn't have to be explicit coordinated action like intentionally wanting to prevent people from self-managing passkeys (in fact any hint of it being intentional would be a liability in a potential anti-trust situation, so that's a big no-no); it can be done by simply omitting this scenario, by accident or for "security" purposes, or deprioritizing it to hell. In fact the Credential Migration spec is still a draft and appears quite recent, despite passkeys being heavily promoted for a while: https://fidoalliance.org/specs/cx/cxp-v1.0-wd-20241003.html - you'd think that such as basic feature would be sorted before the push to switch to passkeys no?
In fact you see this exact strategy playing out: https://github.com/keepassxreboot/keepassxc/issues/11363#iss...
> For the initial delivery of Credential Exchange, we focused on the most wide use case [emphasis mine]
"Initial" delivery focuses on the most widespread use-case (how convenient it also happens to be the most corporation-friendly use-case), with everything else coming "later", meaning never. I'm sure it'll rot in some Jira backlog as a liability shield so they can promise they did plan for it and just never got around to it, but everyone understands it will never actually get implemented.
> The fundamental flaw is that enrolling an authenticator requires it to be present [...]
Yes, but that doesn't mean you can't backup the full authenticator state.
Here's a toy WebAuthN implementation that is backed by a passphrase that you remember or write on a piece of paper which works on many websites supporting passkeys and not enforcing attestation (which is the vast majority, since Apple, Google, 1Password, and Bitwarden all don't support attestation for synchronized credentials a.k.a. passkeys): https://github.com/lxgr/brainchain
> Making it hard/impractical to maintain a reliable backup yourself sure makes those proprietary sync-based services attractive
It's also completely open source and can be backed up :) (But again, it's a toy demo – don't use it for anything sensitive!)
All they have to do is publish a "best practices" statement or some RP certification program mandating attestation to be used (and some PR around how only "certified" RPs are secure) and job done. The only reason they didn't do that yet is that Apple is refusing to play ball and support attestation (but this may change).
The threat was clearly there in the original Github issue, and it's just a temporary inconvenience they can't currently follow through on it.
> Yes, but that doesn't mean you can't backup the full authenticator state.
Having the secondary authenticator present in the same vicinity as the primary one exposes it to risks. Having to dump authenticator state at regular intervals now means your backup authenticator must be reachable for writing online, so it can't be a simple "cold storage" backup like a Yubikey in a safe anymore. This also opens up security concerns since you're now dumping and syncing private keys left and right over a network and you lose the peace of mind of using an HSM-backed non-exportable private key where the HSM being unplugged guarantees nobody is currently using your keys.
Seems like a shit ton of complexity and effort to work around a problem OpenSSH elegantly solved 30 years ago.
> Here's a toy WebAuthN implementation
Thanks, I will check it out and read up on it. I'd be genuinely happy to move to WebAuthn if I could build my own hardware authenticators that allow the backup one to remain fully offline in a safe, and not have private keys flying around (if I'm doing that, it's not much of an improvement over syncing passwords - except those I can at least type or tell over the phone in an emergency when I need someone else to act on my behalf).
Edit: so it seems like I am mostly right? Only discoverable credentials count as "passkeys", and those generate per-site private keys, meaning offline, cold-storage backups are impossible. I guess I'm sticking to my password manager then since passkeys would provide no improvement in this case.
Not for SSH (at least using the OpenSSH sk implementation).
With SSH, you can always share the primary and backup pub keys, even if you don't have the backup key handy.
Huh ?
You do know you can wrap a symmetric key with multiple asymmetric keys, right ?
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.
If you want to maintain backup access, you can use an SSH CA to sign your public SSH keys, then keep the private keys on your device. If you keep the CA keys safe (i.e. physically safe on a flash drive), this means you can even add new keys after you lose all your devices.
This way, you only need to trust your one CA on your servers (so you don't need to copy 20 public keys around for every server).
Plus, if you're setting up a (separate) SSH CA, you can also sign servers' host keys, so you don't need to rely on TOFU to prevent MITM attacks, if that's something you care about.
Plugging my blog post for how to achieve this on Windows 11:
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
I started working on one few years ago: https://github.com/Foxboron/ssh-tpm-agent
We have a blog post on this, but I guess it was never made public, but the only difference between GPG and SSH is the way in which keys and signatures are wrapped and listed through the various layers -- it's all just fundamentally ECDSA with a named curve.
[0] https://github.com/KeetaNetwork/agent
[1] https://github.com/KeetaNetwork/agent/tree/main/Agent/gnupg/...
I've been using Secretive for years, and prefer it to all the physical key/card based systems I've tried to get going over the years. I know exactly when my SSH key is used for any operation, because I need to hit a button or do a fingerprint scan. I can keep ssh-agent tunnels to remote boxes so that I can sign git commits remotely without having to worry about a rogue system getting complete access to key ops without me knowing what's going on.
However the Tahoe version of secretive is buggy and frequently locks up on initial key op requests. I don't have the bandwidth to debug it and file a bug report, and honesty I'm not sure I want to relearn all that knowledge of SSH to figure it out.
I think the smart card SSH UX is worse than secretive's, IIRC my past pain, but if it is reliable, worth a shot.
I also really like secretive, but at least this part is not exclusive to it; OpenSSH's `ssh-agent` and `ssh-add` have long supported confirmation of each private key use with `ssh-askpass` (although it unfortunately can't distinguish between remote and local key uses).
I've heard people make the point before that EdDSA is not great for secure enclaves due to being suspictable to Fault Attacks which could lead to (partial) key extraction
> I've heard people make the point before that EdDSA is not great for secure enclaves due to being suspictable to Fault Attacks which could lead to (partial) key extraction
Huh, got a link? My understanding is that eddsa is better with respect to side channels in every way, that was part of the intent of it's design. I've worked with crypto hardware which supports it.
I think this can be solved by using hedged eddsa (Signal does this)
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.
Key can be generated, but 'ssh-keygen -w /usr/lib/ssh-keychain.dylib -K -N ""' cannot find the key to export.
openssh only supports sk-ecdsa-sha2-nistp256 and sk-ed25519 security keys iirc
The article even mentions that it doesn't contain any sensitive data:
> Note that the "private" key here is just a reference to the FIDO credential. It does not contain any secret key material.
It's a slightly different story for non-resident `sk`-backed keys; these actually require the private key file since the hardware authenticator itself is (or at least can be) stateless. (It's still not a security risk if it ever leaks, but it's an availability risk if it's ever lost.)
Not sure if macOS's backing implementation is stateful or stateless (or some unfortunate hybrid of both; i.e., it might just store a stateful wrapped key in some system-level keychain in a way that intransparently breaks if the OS is ever reinstalled, but also doesn't allow querying an intact system for any existing credentials).
That is, natively with the Secure Enclave, not exportable.
Won't be ditching Yubikeys just yet but I can see a number of use-cases for this already.
https://www.centerforcybersecuritypolicy.org/insights-and-re...
Because this is different !
Secretive required installation, which is both friction and security-sensitive tool written by a third party.
This is native, written by Apple, available out-of-the-box in Tahoe.
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.
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.
Edit: I'm not suggesting an ssh key with a passphrase (or password) is better than what the article suggests; I'm only saying that adding a passphrase (or password) to an ssh key at least buys time to address the situation while the attacker is trying to break the encryption on the stolen key.
I am anti-Mac in every way, but I do use passphrase protected ssh keys so if someone were to get a copy of my ssh key, they would have to be able to break the encryption to use the key. I see a lot of devs using blank passphrases on their ssh keys, smh.
> sitting duck for unlimited automated password guessing attempts.
Using a passphrase on your ssh key has nothing to do with whether the ssh service is configured to allow or deny passwords.
Given the consistent use of "password" instead of "passphrase", I think they meant an exfil'ed encrypted key is vulnerable to no-rate-limit bruteforcing, in contrast with hardware-backed keys.
I'm anti-Mac but for the year recently that I had to use one at work, no choice...I had no issues, none, using gpg or using a passphrase on my ssh keys.