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

111–120 of 204 posts

Re: Native Secure Enclave backed SSH keys on macOS

#111

Post by lxgr »

johnisgood wrote: post #26
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.

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

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

Re: Native Secure Enclave backed SSH keys on macOS

#112

Post by lxgr »

traceroute66 wrote: post #62
johnisgood wrote: post #26

Earlier quoted context omitted.

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

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

A lot of absolutes are being thrown around in the comments here, unfortunately. It really depends on your scenario.

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

Re: Native Secure Enclave backed SSH keys on macOS

#113

Post by lxgr »

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.

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

Re: Native Secure Enclave backed SSH keys on macOS

#115

Post by fragmede »

jedberg wrote: post #34
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.

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.

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.

Re: Native Secure Enclave backed SSH keys on macOS

#116

Post by lxgr »

Nextgrid wrote: post #105
nothrabannosir wrote: post #32

Earlier quoted context omitted.

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

I agree that it's inconvenient in many cases, but what vendor am I being locked into, exactly? My primary hardware key can be from a completely different vendor than the backup one, so I don't quite buy the conspiracy angle.

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.

Re: Native Secure Enclave backed SSH keys on macOS

#117

Post by rkeene2 »

If you're willing to go a bit further you can also do GPG signing with ECDSA, though it requires a patched GPG due to bugs and a patched SSH agent that allows raw signing. We have a packaged version with a macOS UI [0], but the same backend [1] works on Linux using the tpm via PKCS#11.

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

Re: Native Secure Enclave backed SSH keys on macOS

#118

Post by lxgr »

Nextgrid wrote: post #110
lxgr wrote: post #108

Earlier quoted context omitted.

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…

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

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?

Re: Native Secure Enclave backed SSH keys on macOS

#119

Post by lxgr »

conradev wrote: post #98
gruez wrote: post #50

Earlier quoted context omitted.

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

Unlike a TPM and like a YubiKey, you can configure the secure enclave to require presence (via Touch ID) so that a stealer script would be stopped with a prompt.

Until the next time you touch your Touch ID for any other operation. It seems realistic for an attacker script to anticipate that and open its own prompt at the right moment (i.e. with your finger already on the way to the button).
Post reply on HN