| ▲ | jedberg an hour 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. |
|
| ▲ | arianvanp an hour ago | parent | next [-] |
| 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 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 |
| |
| ▲ | rjdj377dhabsn 34 minutes ago | parent | next [-] | | How is this method any different from encrypting the private key without any secure enclave? Isn't it just using a password derived key? | | |
| ▲ | arianvanp 23 minutes ago | parent [-] | | 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. | | |
| ▲ | gruez 20 minutes ago | parent | next [-] | | >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. | | |
| ▲ | arianvanp 11 minutes ago | parent [-] | | 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. |
| |
| ▲ | 14 minutes ago | parent | prev [-] | | [deleted] |
|
| |
| ▲ | sroussey 34 minutes ago | parent | prev [-] | | “ This is might be considered secure but is convenient for key backup.” Might want to clean up that sentence. |
|
|
| ▲ | cedws an hour ago | parent | prev | next [-] |
| 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. |
| |
| ▲ | jedberg 40 minutes ago | parent | next [-] | | 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. | | |
| ▲ | pi-rat 24 minutes ago | parent | next [-] | | 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? | |
| ▲ | philsnow 6 minutes ago | parent | prev | next [-] | | > 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) | |
| ▲ | eptcyka 8 minutes ago | parent | prev [-] | | In what scenario would you prefer to backup an SSH key in favor of generating new SSH keys? |
| |
| ▲ | asteroidburger 36 minutes ago | parent | prev [-] | | 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. |
|
|
| ▲ | justincormack an hour ago | parent | prev | next [-] |
| Correct. Set up multiple keys as backups. Thats also a positive, as nothing can leak the key. |
|
| ▲ | hylaride 36 minutes ago | parent | prev | next [-] |
| 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. |
|
| ▲ | comprev an hour ago | parent | prev | next [-] |
| Inability to export the private key is no different from using an YubiKey? You can't "backup" the private key they generate either. |
| |
| ▲ | johnisgood an hour ago | parent | next [-] | | 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. | | |
| ▲ | eptcyka 6 minutes ago | parent | next [-] | | You are talking about GPG keys. The featured article only refers to SSH keys. Know the difference. | |
| ▲ | epistasis an hour ago | parent | prev [-] | | 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. | | |
| ▲ | johnisgood 34 minutes ago | parent [-] | | 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! |
|
| |
| ▲ | nothrabannosir 44 minutes ago | parent | prev | next [-] | | 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. | | |
| ▲ | epistasis 37 minutes ago | parent [-] | | 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. | | |
| ▲ | nothrabannosir 33 minutes ago | parent [-] | | No I got distracted by the word yubikey. Arguably not the same subject. :) | | |
| ▲ | epistasis 28 minutes ago | parent [-] | | 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. |
|
|
| |
| ▲ | an hour ago | parent | prev [-] | | [deleted] |
|
|
| ▲ | morshu9001 36 minutes ago | parent | prev | next [-] |
| If you set this up on two devices, you can put both their public keys into authorized_keys at least. |
|
| ▲ | an hour ago | parent | prev [-] |
| [deleted] |
