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

121–130 of 204 posts

Re: Native Secure Enclave backed SSH keys on macOS

#121

Post by lxgr »

daft_pink wrote: post #114

Why would you want the private key file if you store it within the secure enclave?

Probably for the same reason that OpenSSH's `sk` implementation also still needs a private key file (even for the "resident key" option): You need to be able to point OpenSSH's various tools to something in an identity context, and that something traditionally is a private key file.

The article even mentions that it doesn't contain any sensitive data:

> Note that the "private" key here is just a reference to the FIDO credential. It does not contain any secret key material.

It's a slightly different story for non-resident `sk`-backed keys; these actually require the private key file since the hardware authenticator itself is (or at least can be) stateless. (It's still not a security risk if it ever leaks, but it's an availability risk if it's ever lost.)

Not sure if macOS's backing implementation is stateful or stateless (or some unfortunate hybrid of both; i.e., it might just store a stateful wrapped key in some system-level keychain in a way that intransparently breaks if the OS is ever reinstalled, but also doesn't allow querying an intact system for any existing credentials).

Re: Native Secure Enclave backed SSH keys on macOS

#122

Post by lxgr »

epistasis wrote: post #3

Whoa, that is pretty cool. I've been using Secretive for years, and prefer it to all the physical key/card based systems I've tried to get going over the years. I know exactly when my SSH key is used for any operation, because I need to hit a button or do a fingerprint scan. I can keep ssh-agent tunnels to remote boxes so that I can sign git commits remotely without having to worry about a rogue system getting comple…

> I can keep ssh-agent tunnels to remote boxes so that I can sign git commits remotely without having to worry about a rogue system getting complete access to key ops without me knowing what's going on.

I also really like secretive, but at least this part is not exclusive to it; OpenSSH's `ssh-agent` and `ssh-add` have long supported confirmation of each private key use with `ssh-askpass` (although it unfortunately can't distinguish between remote and local key uses).

Re: Native Secure Enclave backed SSH keys on macOS

#123

Post by Nextgrid »

lxgr wrote: post #116
Nextgrid wrote: post #105

Earlier quoted context omitted.

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

Being locked into a set of a handful of vendors who offer "secure" sync (of course, this is not a true PKI and actual key material is being synced, meaning it's only as secure as the syncing protocol and your authentication to it).

Authenticator implementations who allow exports outside of the vendor cartel are threatened to be blacklisted: https://github.com/keepassxreboot/keepassxc/issues/10407

> My primary hardware key can be from a completely different vendor than the backup one, so I don't quite buy the conspiracy angle.

The fundamental flaw is that enrolling an authenticator requires it to be present, making a backup strategy much less resilient as it means your secondary device needs to be constantly present and thus exposed to the same local/environmental risks the primary one is (theft/fire/faulty USB port that fries everything plugged in and you only realize after nuking both your keys). It makes an offline backup scenario like with SSH (where you copy a public key and otherwise leave the authenticator out of reach in a safe place) impossible.

Making it hard/impractical to maintain a reliable backup yourself sure makes those proprietary sync-based services attractive, which also doubles as reducing security since key material is being synced and can potentially be extracted (impossible with a true HSM + PKI implementation).

> preventing anyone from creating "paired" hardware authenticators

Don't certain types of keys involve writing something to the authenticator, fundamentally preventing this (as the backup authenticator won't get this written value)?

> cabal

It doesn't have to be explicit coordinated action like intentionally wanting to prevent people from self-managing passkeys (in fact any hint of it being intentional would be a liability in a potential anti-trust situation, so that's a big no-no); it can be done by simply omitting this scenario, by accident or for "security" purposes, or deprioritizing it to hell. In fact the Credential Migration spec is still a draft and appears quite recent, despite passkeys being heavily promoted for a while: https://fidoalliance.org/specs/cx/cxp-v1.0-wd-20241003.html - you'd think that such as basic feature would be sorted before the push to switch to passkeys no?

In fact you see this exact strategy playing out: https://github.com/keepassxreboot/keepassxc/issues/11363#iss...

> For the initial delivery of Credential Exchange, we focused on the most wide use case [emphasis mine]

"Initial" delivery focuses on the most widespread use-case (how convenient it also happens to be the most corporation-friendly use-case), with everything else coming "later", meaning never. I'm sure it'll rot in some Jira backlog as a liability shield so they can promise they did plan for it and just never got around to it, but everyone understands it will never actually get implemented.

Re: Native Secure Enclave backed SSH keys on macOS

#124

Post by doctorpangloss »

jedberg wrote: post #93
adastra22 wrote: post #89

Earlier quoted context omitted.

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.

Today I make a private/public keypair, and the private key is on my laptop in my encrypted home folder. It also gets backed up to my encrypted offsite backup. That way if my laptop breaks or is stolen, I can restore from backup and be up and running as before. I was simply asking if that is still possible with this method, nothing more. And not every service that uses ssh auth allows multiple keys.

yes, you can export keys using this method, and they will be simlarly secure as password encrypted keys you generate without the secure enclave with openssh, but with the convenience that you can decrypt the key using TouchID on macOS.

Such a setup is marginally more secure than just typing in the passwords, since it is much harder to intercept the TouchID chain from touch to decrypting the SSH key compared to your keyboard to the terminal.

All that said, here are the priorities of a few security technologies:

TouchID:

  #1 environment integrity, that is to say, to protect Apple services monopolies and fees such as eliminating password sharing of services accounts, #2 convenience as an alternative to passwords reducing friction when you buy stuff, #3 security.
1password:

  #1 convenience, #2 security
I cannot tell you really what is "#1" in security among packaged ready to buy commercial products, Everyone, practically, makes affordances for convenience ahead of security. I suppose there isn't really a great product for normal people that puts security first. Of course, there are an ad hoc collection of practices that amount to, #1 security. But a product? No. Even Apple Lockdown mode... well, they can still just push an update that makes it pretend it is enabled when it is not, so...

Re: Native Secure Enclave backed SSH keys on macOS

#125

Post by lxgr »

Nextgrid wrote: post #123
lxgr wrote: post #116

Earlier quoted context omitted.

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

Being locked into a set of a handful of vendors who offer "secure" sync (of course, this is not a true PKI and actual key material is being synced, meaning it's only as secure as the syncing protocol and your authentication to it). Authenticator implementations who allow exports outside of the vendor cartel are threatened to be blacklisted: https://github.com/keepassxreboot/keepassxc/issues/10407 > My primary hardwar…

How can the "cartel" "blacklist" anyone? The only thing the FIDO alliance can do is not include a vendor's attestation key as trusted in their vendor database, and software solutions aren't on that list to begin with.

> The fundamental flaw is that enrolling an authenticator requires it to be present [...]

Yes, but that doesn't mean you can't backup the full authenticator state.

Here's a toy WebAuthN implementation that is backed by a passphrase that you remember or write on a piece of paper which works on many websites supporting passkeys and not enforcing attestation (which is the vast majority, since Apple, Google, 1Password, and Bitwarden all don't support attestation for synchronized credentials a.k.a. passkeys): https://github.com/lxgr/brainchain

> Making it hard/impractical to maintain a reliable backup yourself sure makes those proprietary sync-based services attractive

It's also completely open source and can be backed up :) (But again, it's a toy demo – don't use it for anything sensitive!)

Re: Native Secure Enclave backed SSH keys on macOS

#126

Post by Nextgrid »

lxgr wrote: post #125
Nextgrid wrote: post #123

Earlier quoted context omitted.

Being locked into a set of a handful of vendors who offer "secure" sync (of course, this is not a true PKI and actual key material is being synced, meaning it's only as secure as the syncing protocol and your authentication to it). Authenticator implementations who allow exports outside of the vendor cartel are threatened to be blacklisted: https://github.com/keepassxreboot/keepassxc/issues/10407 > My primary hardwar…

How can the "cartel" "blacklist" anyone? The only thing the FIDO alliance can do is not include a vendor's attestation key as trusted in their vendor database, and software solutions aren't on that list to begin with. > The fundamental flaw is that enrolling an authenticator requires it to be present [...] Yes, but that doesn't mean you can't backup the full authenticator state. Here's a toy WebAuthN implementation t…

> How can the "cartel" "blacklist" anyone?

All they have to do is publish a "best practices" statement or some RP certification program mandating attestation to be used (and some PR around how only "certified" RPs are secure) and job done. The only reason they didn't do that yet is that Apple is refusing to play ball and support attestation (but this may change).

The threat was clearly there in the original Github issue, and it's just a temporary inconvenience they can't currently follow through on it.

> Yes, but that doesn't mean you can't backup the full authenticator state.

Having the secondary authenticator present in the same vicinity as the primary one exposes it to risks. Having to dump authenticator state at regular intervals now means your backup authenticator must be reachable for writing online, so it can't be a simple "cold storage" backup like a Yubikey in a safe anymore. This also opens up security concerns since you're now dumping and syncing private keys left and right over a network and you lose the peace of mind of using an HSM-backed non-exportable private key where the HSM being unplugged guarantees nobody is currently using your keys.

Seems like a shit ton of complexity and effort to work around a problem OpenSSH elegantly solved 30 years ago.

> Here's a toy WebAuthN implementation

Thanks, I will check it out and read up on it. I'd be genuinely happy to move to WebAuthn if I could build my own hardware authenticators that allow the backup one to remain fully offline in a safe, and not have private keys flying around (if I'm doing that, it's not much of an improvement over syncing passwords - except those I can at least type or tell over the phone in an emergency when I need someone else to act on my behalf).

Edit: so it seems like I am mostly right? Only discoverable credentials count as "passkeys", and those generate per-site private keys, meaning offline, cold-storage backups are impossible. I guess I'm sticking to my password manager then since passkeys would provide no improvement in this case.

Re: Native Secure Enclave backed SSH keys on macOS

#128

Post by Nextgrid »

lxgr wrote: post #118
Nextgrid wrote: post #110

Earlier quoted context omitted.

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

I was thinking the HSM in this case is your Macbook and its TPM/Secure Enclave, in which case you'd either recover it or assume the attacker is unable to use it due to biometrics/PIN. I guess the Yubikey has a PIN too with a limited number of tries.

Either way, you either recover the HSM and then don't need to rotate the keys, or you don't in which case you either use OpenSSH's key revocation mechanism (which I believe involves distributing some some sort of CRL to every server), use time-limited SSH certificates and wait out the expiry of the compromised key, or scrap the whole CA and start fresh.

Again this depends on your threat model. The somewhat uncommon requirement where you can't manage your own `authorized_keys` on the remote host complicates things a lot; if you could, then you'd use your existing access (sign yourself a new certificate using your SSH CA) to rotate the whole CA... or just keep two keys in there (primary and backup) and skip the whole CA dance, since it's purely a workaround for the hard requirement of only being able to put one key in authorized_keys.

Re: Native Secure Enclave backed SSH keys on macOS

#129

Post by johncolanduoni »

WhereIsTheTruth wrote: post #85

I would not trust it personally, specially since the Chip Security Act is looming https://www.centerforcybersecuritypolicy.org/insights-and-re...

If the Secure Enclave on your Mac is backdoored, the fact that the key from your Yubikey (or whatever HSM) is un-extractable will be a very cold comfort.

Re: Native Secure Enclave backed SSH keys on macOS

#130

Post by johncolanduoni »

fpoling wrote: post #49
traceroute66 wrote: post #9

Earlier quoted context omitted.

> It's a total pain in the ass to try to have password encrypted gpg or ssh keys in mac. Who uses password encrypted keys anyway ? No exfiltration protection, and a sitting duck for unlimited automated password guessing attempts. Pre-Tahoe people used Yubikeys or Secretive. But now this native tool is a better option than Secretive, even if Yubikeys still have their uses for the power-users.

With an ssh agent and time-bounded key expiration one can have very strong password on the key that is convenient to use. Also password managers like 1password or Bitwarden support ssh-agent protocol so one can have a master password that protects both stored passwords and keys.

How short of a time-bound do you use on your SSH keys?
Post reply on HN