8 ms·
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
by jedberg 11mo 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.
- aaomidi 11mo agoYou shouldn’t be backing these keys up anyway imo
- justincormack 11mo agoCorrect. Set up multiple keys as backups. Thats also a positive, as nothing can leak the key.
- comprev 11mo agoInability to export the private key is no different from using an YubiKey? You can't "backup" the private key they generate either.
- deleted 11mo ago[deleted]
- johnisgood 11mo agoYeah, 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.
- epistasis 11mo agoI 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.
- johnisgood 11mo agoWell, 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!
- eptcyka 11mo agoYou are talking about GPG keys. The featured article only refers to SSH keys. Know the difference.
- johnisgood 11mo agoI know the difference, thank you for your concern.
- traceroute66 11mo ago> 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.
- nothrabannosir 11mo agoWhich 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.
- epistasis 11mo agoAre 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.
- nothrabannosir 11mo agoNo I got distracted by the word yubikey. Arguably not the same subject. :)
- epistasis 11mo agoNonetheless 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.
- traceroute66 11mo ago> 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 ?
- Nextgrid 11mo agoThis 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.
- arianvanp 11mo agoCheck 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 A581E5404ED157C4C73FFDBDFC1339E0D873FCAE -f ssh-exportable.pem Enter a password which will be used to protect the exported items: Verify password: You can then re-import it on another device % sc_auth import-ctk-identities -f ssh-exportable.pem.p12 -t bio Enter PKCS12 file password: I'll add this to the guide
- sroussey 11mo ago“ This is might be considered secure but is convenient for key backup.” Might want to clean up that sentence.
- rjdj377dhabsn 11mo agoHow is this method any different from encrypting the private key without any secure enclave? Isn't it just using a password derived key?
- arianvanp 11mo agoThe 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.
- gruez 11mo ago>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.
- deleted 11mo ago[deleted]
- cedws 11mo agoYou'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.
- jedberg 11mo agoI'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.
- pi-rat 11mo agoYou 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?
- morshu9001 11mo agoYeah 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.
- yjftsjthsd-h 11mo agoThere is an easier way: Create a SSH CA, add that to your authorized_keys everywhere, use it to sign the individual public keys.
- 11mo ago
- hylaride 11mo agoStrictly 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.
- deleted 11mo ago[deleted]
- midtake 11mo agoYou use multiple keys, if you need a key usable across different systems then buy a yubikey.
- jeroenhd 11mo agoYes, 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.
- TacticalCoder 11mo ago[dead]
- UltraSane 11mo agoThis 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.
- notepad0x90 11mo agoposting late in the discussion, but you shouldn't back up our private keys. The ideal setup is with ssh-ca's anyways.
- WhyNotHugo 11mo agoRight, 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.
- mritzmann 11mo 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? 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.
- nedt 11mo agoI 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.