Comment by jedberg
5 months ago
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
I'll add this to the guide
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.)
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.
4 replies →
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.
1 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.
23 replies →
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.
“ 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?
19 replies →
I think you are mixing up concerns. You need a backup key. That doesn't mean you need to backup your key.
Anything (everything?) using SSH authentication supports multiple authentication keys. Have a yubikey in a locked deposit box or something.
6 replies →
No but that’s the point. If there’s a copy of the private key out there, then it can be copied. The whole point is that the jedberg-laptop-1 key only ever exists as jedberg-laptop-1. When that laptop gets lost/stolen/destroyed/aged out, there's 100% certainty that it can't be recreated. The other side of that equation is that you need a tree of keys and a whole IT department to manage them so you don't get locked out of your servers. This particular bit of software is about ssh keys and exists within a larger conversation about PKI which you know more about than I, but operationally, you have this, and then you have a root login private key file locked with Shamir secret sharing (ssss on debian) that you distribute to a very select few number of key bearers. And then don't all get on the same plane together, ever.
This was a thing with Google Authenticator. People kept asking how to back up or transfer keys, official answer was you can't and WAI. Eventually they conceded and added a backup option, but it was still confusing. I think this ruined the entire reputation of TOTP.
> 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)
In what scenario would you prefer to backup an SSH key in favor of generating new SSH keys?
6 replies →
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.
1 reply →
Correct. Set up multiple keys as backups. Thats also a positive, as nothing can leak the key.
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.
Yeah, that is why you should not [always (depends on your use case)] 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.
> 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.
2 replies →
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.
1 reply →
Does OpenSSH's `sshd` even support GPG key revocation? (Assuming you're talking about using the GnuPG card application of Yubikeys, since the newer "native" FIDO security key implementation of OpenSSH does not support importing existing keys to my knowledge.)
1 reply →
I faintly remember some service that would only let me add one YubiKey, taking the 2 in 2FA very literal.
Do you have a good guide/video/write up on this?
I’ve been putting off remaking my GPG and SSH keys using a Yubikey.
3 replies →
You are talking about GPG keys. The featured article only refers to SSH keys. Know the difference.
1 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.
This is true for passkeys/webauthn/u2f, which is why it’s trash and a completely flawed and not fit for purpose standard (of course the primary purpose is vendor lock-in, not reliable and disaster-proof authentication).
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.
6 replies →
Not true. If you use YubiKeys to store your GPG key, it's not a problem. You can have multiple YubiKeys with the same private key, or you can encrypt to multiple recipients.
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.
2 replies →
> You need the backup available at all times for when you want to register with any new service.
Not for SSH (at least using the OpenSSH sk implementation).
> 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 ?
Yes, that's the point, indeed. One key per device, impossible to extract, so you need to break into the device to use the key.
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.
You use multiple keys, if you need a key usable across different systems then buy a yubikey.
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.
> 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?
In a business environment, that's what you want. The key is then burned, and you ask your coworkers (who still have access) to remove the old key and store your new one on the servers.
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.
posting late in the discussion, but you shouldn't back up our private keys. The ideal setup is with ssh-ca's anyways.
You shouldn’t be backing these keys up anyway imo
I had being using krypton, with the private key being on my iPhone, and am now using secretive. Never had much of an issue with not having access to my private key. We made rolling out public keys to the servers very easy by using the gitlab key file. So when I get a new Macbook I'd just need to create a new key and upload it to gitlab. We have multiple devops that can run the playbook to roll it out to the servers. And if they have a new Macbook I roll it out for them. And we don't have that many Macbook upgrades anyway.
[dead]