Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Native Secure Enclave backed SSH keys on macOS

gist.github.com

Post reply on HN
Print view View original

101–110 of 204 posts

Re: Native Secure Enclave backed SSH keys on macOS

#101

Post by lxgr »

arianvanp wrote: post #25
jedberg wrote: post #13

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 somet…

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 A581E5404ED157C4C73FFDBDF…

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.)

Re: Native Secure Enclave backed SSH keys on macOS

#102

Post by Nextgrid »

jedberg wrote: post #76
eptcyka wrote: post #56

Earlier quoted context omitted.

In what scenario would you prefer to backup an SSH key in favor of generating new SSH keys?

When I have my pub key in the authorized_keys files of many machines, especially machines where I don't control the authorized_keys file.

In this case you can maintain an offline SSH CA and trust that on the remote machines, and then sign yourself leaf certificates against a non-exportable HSM-backed key. In case of loss you just make a new key and sign a new certificate.

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.

Re: Native Secure Enclave backed SSH keys on macOS

#103

Post by arianvanp »

jcalvinowens wrote: post #94
arianvanp wrote: post #86

Earlier quoted context omitted.

Only supports NIST curves and ECDSA yes. 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 don't trust the NIST curves: they were generated in a dubious way which has been written about extensively elsewhere (the coefficients for P-256 were generated by hashing the unexplained seed c49d360886e704936a6678e1139d26b7819f7e90). I always avoid them unless I have to use them. It makes me sad when hardware forces me to use them. > I've heard people make the point before that EdDSA is not great for secure enclav…

https://romailler.ch/project/eddsa-fault/

I think this can be solved by using hedged eddsa (Signal does this)

Re: Native Secure Enclave backed SSH keys on macOS

#104

Post by Nextgrid »

asteroidburger wrote: post #37
cedws wrote: post #31

Earlier quoted context omitted.

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.

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.

Re: Native Secure Enclave backed SSH keys on macOS

#105

Post by Nextgrid »

nothrabannosir wrote: post #32
comprev wrote: post #17

Earlier quoted context omitted.

Inability to export the private key is no different from using an YubiKey? You can't "backup" the private key they generate either.

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.

Re: Native Secure Enclave backed SSH keys on macOS

#106

Post by lxgr »

pi-rat wrote: post #46
jedberg wrote: post #34

Earlier quoted context omitted.

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…

That can work really well for systems where you don't need to share your key material very often, or where sharing is optimized for n-key scenarios.

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.

Re: Native Secure Enclave backed SSH keys on macOS

#107

Post by lxgr »

yjftsjthsd-h wrote: post #81
morshu9001 wrote: post #64

Earlier quoted context omitted.

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.

There is an easier way: Create a SSH CA, add that to your authorized_keys everywhere, use it to sign the individual public keys.

But now you need to worry about revocation or at least key lifetimes.

Re: Native Secure Enclave backed SSH keys on macOS

#108

Post by lxgr »

Nextgrid wrote: post #102
jedberg wrote: post #76

Earlier quoted context omitted.

When I have my pub key in the authorized_keys files of many machines, especially machines where I don't control the authorized_keys file.

In this case you can maintain an offline SSH CA and trust that on the remote machines, and then sign yourself leaf certificates against a non-exportable HSM-backed key. In case of loss you just make a new key and sign a new certificate. 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…

But how do you revoke any compromised certificate if you don't control the remote machines?

Re: Native Secure Enclave backed SSH keys on macOS

#109

Post by palata »

gruez wrote: post #75
arianvanp wrote: post #72

Earlier quoted context omitted.

The export operation is guarded by TouchID. So the malware needs to trick you into performing the TouchID gesture. 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.

> So the malware needs to trick you into performing the TouchID gesture. 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?

> That's not meaningfully more difficult than tricking you into revealing your key file password.

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.

Re: Native Secure Enclave backed SSH keys on macOS

#110

Post by Nextgrid »

lxgr wrote: post #108
Nextgrid wrote: post #102

Earlier quoted context omitted.

In this case you can maintain an offline SSH CA and trust that on the remote machines, and then sign yourself leaf certificates against a non-exportable HSM-backed key. In case of loss you just make a new key and sign a new certificate. 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…

But how do you revoke any compromised certificate if you don't control the remote machines?

Keeping the certificate’s key as non-exportable in the HSM means you do not need to revoke it as it cannot be compromised (not permanently at least), once you’ve regained access to the HSM you can assume the bad guys are out.

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).

Post reply on HN