Secretive: Store SSH Keys in the Secure Enclave | Hacker News Reader

Secretive: Store SSH Keys in the Secure Enclave

github.com

292 pointsValentineC125 comments

Secretive has to function as both a key generation utility and an SSH agent because of a restriction in Apple's Secure Enclave functionality - only the app that generates a key is allowed to use it. There's actually a workaround for this, which is to use https://developer.apple.com/documentation/cryptotokenkit to expose keys to the user keychain, which then means the tool used for key generation doesn't have to be the same tool that allows applications to make use of that key. We're using this internally to generate keys that are then combined with user creds to receive x.509 and ssh certificates, and exposing the ssh certs to ssh using the SSH agent protocol. Our next step is to take that a step further and use https://developer.apple.com/documentation/devicecheck/access... to verify that the device asking for a cert is a device that we own (IT will be able to set one of those bits during device provisioning, and then we query that data during certificate issuance to show that the request comes from something we provisioned)

Make sure you sign the information that indicates the requestor.

I've always been afraid to invest in something like a yubikey or even to use the TPM on any devices I own. I don't ever want to depend on "something I have" that can't be backed up or recovered in any way.

As an example, when I started using a password manager last year, I also made sure to start hosting the (encrypted) passwords database publicly (on a web server) so that if I ever lose it for any reason (SSD fails, etc) I'll be able to download it back onto a computer and unlock it with my master password.

If I ever lose my passwords database I'll also lose access to every internet account I've ever made. It would be far too risky to make it rely on any physical possession of mine.

Some people (most people??) would feel safe knowing that it's impossible for anyone to get into their accounts without their yubikey, but I'd just always be afraid of losing the yubikey.

Have more than one Yubikey, use paperbackup keys.

Best practice is to have multiple Yubikeys, at least 2-3. You could leave one with a trusted person or family member. The odds of losing all of them simultaneously are slim.

Oh, I need a new account. Hang on, can we book a new meeting in two weeks? I have to gather all my security keys first.

This is great, if you rarely add/update secrets and you also have easy, quick access to that offsite storage.

It's not so great if you're constantly tapping your friend because you need to swap Yubikeys again and you both just get sick of that rigmarole.

When setting up Yubikey, I discovered a tool, I think it's called "paperkey" and it lets you print out a GPG key after minting it. Have fun typing that back in! OCR ahoy!

It's lower-tech, but my solution is to always have a comprehensive catalog of plaintext backup secrets stored offsite. This won't rely on anything electronic and it's easy to use. You just have to make a good effort to guard it from prying eyes, at least any eyes that also know your username and password.

And likewise to some of the GPs, I'm skeptical of anything based on possession of an electronic thing that functions properly. The Yubikey is the best yet, because it's simple, purpose-built, and "virtually indestructible" as the marketing copy says. I would even love one of those RSA gadgets with a built-in display for purpose-built TOTP functionality. But paper's the best backup yet. Don't discount paper!

I've read this a lot, but honestly is this really the future of security? Keep a Yubikey in your wallet, another in a bank safe, bury another in the family's farm... It doesn't scale at all. And in the end, it's all social-dependent, because one can always cry out in a Hacker News post or in a viral Twitter thread and you'll get access to your account back. But if things happened the way security experts seem to want, losing your two Yubikeys means you should just start life from scratch.

I'd rather we find a way to actually involve real-world security instead of pretending the digital world doesn't depend on it.

devices like trezor offer fido2 and backup/restore.

There's a fairly excellent guide on creating a robust key system here: https://github.com/drduh/YubiKey-Guide. Primary and backup Yubikey for use, offline cert keys, and paper backups.

If you're wanting to protect things further you can also also split your backups via a secret sharing scheme (like http://point-at-infinity.org/ssss/) and distribute the fragments to people or places your at least partially trust.

yubikey support for GPG has always been meh for me. FIDO2 ssh keys seem really promising. GPG definitely still has its place though

Both are useful.

GPG is good for signing, particularly when that signature is written into some form of immutable history (e.g. git). That signing key can be revoked or time windowed to expire. There are mechanism for distributing that revocation and its validity at the time of signing can be verified at any point in the future.

SSH keys are excellent for authentication. They are simple to verify at the time of use, and can also be revoked or for a specific system or usage context. Using these short-term keys for potentially long-term proofs is going to lead to some avoidable pain IMO.

Once setup, for me it's working like a charm. I use GPG for signing (git commits + java jars/aars/apks), it just works.

I think the other (IMO completely valid) concern is that you don't know what the Yubikey does, really.

The protocols are open source, sure, but how sure are you there aren't back-doors in them? The firmware tends to be closed source, I found https://onlykey.io/ but I can't speak to how truly open they are, having never used them (do they have e.g. specialized hardware/software requirements for building one?)

In the end, it strikes me as a security over-complication - 1. have key, 2. keep secret, 3. match key/password to situation (don't re-use keys). These dongles do 1. and 2. but miss the mark wildly on 3.

You can say all you like about "backups" but in the end I actually want some things to be less secure than others - if I have to throw out a device every time I forget a password, life becomes some combination of expensive, wasteful, un-tennable, unsafe. I should never need a password to get into my fridge, e.g., and after the key is in the ignition the car should just "work", no messing with SSO while changing lanes.

This is a fundamental misunderstanding of how this security model works. You don't have to throw away anything, it just means you reinit that specific key.

Have multiple of them for redundancy, trust them all at your central auth point and this isn't an issue.

I disagree > Have multiple of them for redundancy.

Yes so when I have 40 such tokens then I must worry about which ones to bring when for which devices, it's a usability nightmare.

I contend you should rarely if ever use one, they are (often) more trouble than they are worth. Or, you are reusing them everywhere, and so you violate the principle of re-use. Yeah, you can daisy chain things and the like, but now you are just making your life needlessly complicated and error prone.

Again you are fundamentally misunderstanding how this works. The key proves who you are. You don’t need 40 different ones. Just at least one.

But that’s a problem in and of itself… you don’t want to have 40 different keys that all prove that the bearer is “you”. Instead of having one thing to a worry about losing, you now have to worry about 40? And any of them would authenticate as “you”?

So don't have 40 different keys that prove they're you that you didn't password protect and keep track of?

This straw man is close to sentience at this point.

I am really not, you are not understanding my core point - you should NOT have a single identifying key.

direct quote from my previous reply "Have multiple of them for redundancy, trust them all at your central auth point and this isn't an issue."

You don't put the password to your FRIDGE in a Yubikey tears

I mean I don't even understand the "throw out a device if you forget a password" bit. That's not how secure elements (Apple, Yubikey) work. They're just a "write private key once, never read again" device.

I would agree though, based on your comment, please don't waste your money on a Yubi or other similar "secure element" platform.

To clarify, throw out as in, device (armed with a key/lock mechanism) becomes unusable (because said key is corrupted lost, lost amid mountain of other keys).

I am using password/key here somewhat interchangeably despite common (mis)understanding of what both words imply i.e. phrase versus some random(ish) bits, because the only distinction between the two is the algorithms used to compare (if you want to get pedantic pub/sub and splitting schemes are a bit more different, nevertheless they share the common theme of "secret used to protect something"). So no your YUBI has no password (that I know of) but it is effectively a password (by scanning it and reproducing it at a molecular level you could in fact reproduce it, it's as much a password with protection by obscurity in this sense as writing down a pass phrase backwards is, albeit one is much more difficult to reproduce than another).

I used to be very pro yubikey for a long time but have mostly concluded it doesn't really solve any of the problems people think it solves. It basically just provides a (1) a means to prove that you have access to a key, which isn't actually yubikey dependent, and (2) a way to demonstrate that said key is bound to a hardware device that makes it hard to steal/exfiltrate.

People are incredibly laissez faire about their yubikeys - leaving them plugged in, leaving them on their keys, etc. They are an obvious DOS vulnerability.

Another basic issue that key theft is actually mostly not a real attack that matters for most people.

Spearphishing and faked sites are handled by any password manager worth using. If your threat is protection from key loggers, either don't use a wired keyboard or you are likely in a place where your local device is assumed to be already compromised (by the logger and probably a RAT) so now things like session cookies theft, TOCTOU swapping between authenticated operations, etc. are all in scope and the yubikey offers essentially nothing.

On top of that, most sites that "support FIDO", including google, will almost always be configured to fall back to other means.

It does allow one to make a clever device into a shibboleth, though.

What's wrong with having your Yubikeys on your keys?

Evil maid attacks for pin theft, stolen YubiKey and denial of service, etc. it depends on whether you’re one of the people who leaves their keys sitting on their desk.

> People are incredibly laissez faire about their yubikeys - leaving them plugged in, leaving them on their keys, etc.

You can (should) protect your YubiKey with a pin. They will lock/reset after a couple of failed attempts.

> On top of that, most sites that "support FIDO", including google, will almost always be configured to fall back to other means.

Google accounts can be configured to require hardware tokens for 2FA without fallback to less secure methods. [0] Apple has a similar program. [1]

[0] https://landing.google.com/advancedprotection/

[1] https://support.apple.com/en-us/HT212520

Fair enough but at that point, why not just use a software based PW manager?

Yes, you can configure google that way. People mostly don’t, however.

Yes, you can (and should) configure a pin. Now you have a DOS problem.

> I don't ever want to depend on "something I have" that can't be backed up or recovered in any way.

Just put one in each computer and one on your key ring and one in a safe. I have like 7. authorized_keys can have multiple lines in it.

> authorized_keys can have multiple lines in it.

I'm talking about more than just SSH keys—it just happens to include SSH keys as well. This isn't an opinion against Secretive specifically, for what it's worth, but rather against "something you have" in general, which includes TPMs (or Secure Enclaves, as it may be). It's my personal reason for not relying on something like that.

Almost everyone who supports U2F or WebAuthn also supports enrolling multiple keys.

This sounds ridiculous.

I have a lot of computers because some of my clients are in regulated industries and if I ever get subpoenaed I can prune my company's proprietary non-customer-specific dotfiles and just hand over that laptop in full with 100% of that specific client's data on it and not compromise any personal/my-company's data or any other client data.

I don't like switching yubikeys and they make little tiny ones that live 24/7 in a USB-C port and they are cheap, so I literally just put one in each and every computer I type on. It's simple and easy.

Secretive: An app for storing and managing SSH keys in the Secure Enclave - https://news.ycombinator.com/item?id=28853329 - Oct 2021 (11 comments)

Secretive – macOS native app to store SSH keys in the Secure Enclave - https://news.ycombinator.com/item?id=23664129 - June 2020 (106 comments)

I wish Apple would add more native support for this somehow. Until then, I’ve enjoyed using 1Pass for SSH key which continently allows me to share keys across machines, work confidently knowing my key isn’t accessible if a machine is lost, and asks me for Touch ID permission

Apple actually made this much harder than it should be by special-casing P256 ECDSA in their build of libressl, which means trying to use it with PKCS#11 breaks: https://mjg59.dreamwidth.org/64968.html . The approach Secretive uses (which is what I ended up mimicking) is using the SSH agent protocol rather than PKCS#11, which lets you do the crypto in your own codebase instead.

I was considering this but ultimately opted for 1Password’s SSH Agent instead and storing my SSH keys there and unlocking it with Touch ID: https://developer.1password.com/docs/ssh/agent/

Also use it to sign my git commits: https://developer.1password.com/docs/ssh/git-commit-signing

I have the same setup and can vouch that it works very well. My primary threat vector is data exfiltration by a compromised binary/node_module. A script reads everything in $HOME and sends it offsite. This is challenging to defend against, considering how many secrets want to live in plain text files (dot files, DB, AWS configs, backups, ssh keys, etc.), and file permissions do not help when the script runs with my user privileges.

NB: If you use this, make sure to backup the key somehow. About a year ago I tested this with a few servers and lost all of the keys when my Mac had a kernel panic that wiped the state of the Secure Enclave! Updates can do this too!

Correct me if wrong, but I thought that you cannot extract the private key from the Secure Enclave at all?

Yes, you can’t extract it, the Secure Enclave can just create a key and has it to sign stuff.

You can never actually grab it or access it for backing up, so it shouldn’t be your only way of accessing a server, there should be another authorised key that you do have access to.

This is true for any [citation needed] hardware security module. The interface allows to store/generate secrets and request cryptographic operations (encryption, signing, etc). Aside from physically tampering with the chip to access bits in raw silicon there is no way for the secret itself to leave the chip. Software security modules behave the same way, with the exception that one does have software access to the backing encrypted storage.

Yubikeys can be backed up, using what they call export under wrap. It requires you initially created the key with exportable flag. The idea is you do this on first use to create an encrypted backup and then instantly remove the exportable flag from the key you carry around day to day.

As others already noted, having more than one key is a good idea anyway. If you are really serious, use ssh certificates so you don’t have to update every server with new keys. Just sign them with the root CA.

It's designed to make it hard, but it does crypto operations using the key so it's in there and possible to extract similarly as other tamper resistant chips have been successfully physically attacked.

It depends on the setup. You can generally only ask an hsm to perform a few specific operations “encrypt this data”, “sign this data”, etc and you’re restricted to the exact formats that it supports.

Because they are generally not very configurable (their design goal is to be secure and so the less complexity the better) it’s fairly common for them to just not directly support any specific cryptographic protocol.

Given that, what you can choose to do instead is have the hsm generate a key for you, and then you use that key to wrap your specific secret - say an ssh key - then you decrypt it when you need it which requires user authentication through the hsm - use the raw key and then clear it from memory.

But if the only record of the external key is wrapped by the hsm, if the hsm loses that decryption key then you’ve lost access to the ssh (or whatever) key as well.

No, this is what ssh certs are for.

You can use any key you want as long as you get a CA that everything trusts to sign it.

hmm, where do you store the CA private key? We're just going around in circles

in a safe at the bottom of the ocean? who cares, put an intermediate signer in a cloud somewhere that requires 2FA with multiple valid tokens, and everything is now much more secure and not tied to your specific key.

I think it's more nuanced.

SMP and hyperthreading are risky for security. Closed firmware is also concerning. Older systems without these architectural features are more difficult to abuse.

I would find one of these if I needed a secure SSH CA for myself, and use OpenBSD.

I probably couldn't get away with that in a larger organization.

> hmm, where do you store the CA private key?

On another device.

> We're just going around in circles

Depends on attack vector. Both solutions store private key in HSM and hence protect against "attacker gains access to local memory/storage". However, ssh certs allow key to be "regenerated". HSM'd keys are subject to "device got lost/destroyed" attack, HSM'd certs are subject to "CA got compromised". Pick your poison.

The point isn’t how to secure the CA’s private key. The point is that this is a separate system that is probably easier to secure. Physically, it’s probably in a data center. If you want to, you could have the CA key loaded into memory at boot time with a removable USB drive.

That key should be easier to protect than a private key on an end user computer, Secure Enclave or not.

The whole point is that you literally can’t backup the key.

The trick is to have multiple SSH keys -- spread out over several physical devices -- all of which are in your server's authorized_keys.

There is no export or import functionality with Secure Enclave. Unlike with Yubikeys or similar HSMs, you can't even migrate your pre-existing private key(s) into SE.

What I kinda want is a way to use a detachable hardware key like a Yubikey as a primary factor for SSH and login authentication. I have multiple computers and I provision new OSes frequently and I always find it irritating depending on either network or flash drive synchronization for secret material when I could just be plugging in a smartcard device.

Anyone gone down this path?

YubiKey already supports those scenarios, I think.

This is possible with PGP Keys stored on the Yubikey and used as the SSH keys. Check the Repo of drduh as a starting point

https://github.com/drduh/YubiKey-Guide#ssh

Correct me if I'm wrong or missing something, but doesn't the use of SSH resident keys still require a file to be present on the client before it can authenticate? I'm prompted to use the SK to prove my 'presence' after the standard identity secret keyfile is checked.

To be clear, my goal is to simply plug in my SK to a fresh OS install and "magically" be able to SSH into my servers.

That’s how it works for me. I generated a new key on the device, installed the public key where appropriate, and tap to authenticate.

https://support.apple.com/en-us/HT208372

https://playbooks.idmanagement.gov/piv/engineer/ssh/

Maybe not “magic” but you can get very close to that with “Discoverable Credentials” on a FIDO2 key.

The process for using a discoverable key on a new machine re-imports the relevant public key and private key handle to the new machine when you “ssh-keygen -K”. Its roughly equivalent to copying key material around with a flash drive, but without the need to remember two physical items.

GPG keys are one option, but only recommended if you need compatibility. Having to deal with GPG + GPG agent is enough to make them a pain to use.

The modern way is SSH resident keys. However, this requires a “modern” SSH version (8.2), but does not add a dependency on GPG. Modern in this case, is a version from 2020.

See my other comment for why I don't think SSH resident keys accomplish what I'm looking for. I'll have to experiment with using gpg-agent a bit, that sounds promising although potentially irritating to configure cross platform.

You don’t need a file on the client for resident keys. You have to run a command to load them into the SSH agent, but you don’t need any information for that.

https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.ht...

Ahhhh. The key thing I was missing was `ssh -K`. This works, but isn't really quite what I was hoping for. It's effectively using the SK as a glorified flash drive to transfer the secret key. I was kinda hoping to avoid storing the private key on the local machine at all. There are upsides to this strategy however, especially given how simple it is and how it maintains compatibility with tools which require secret key material directly.

I may end up using a mix of this and a GPG integration once I learn more about how that works with SSH. I still need to dig into PIV/PAM/Keychain/FileVault/etc...

Thanks for the top though :)

I’m not sure, but I’d be surprised if the secret key leaves the SK. If you remove it, SSH doesn’t work. `-K` configures a pointer so SSH knows where to look to find the private key (on the SK). It is the same as non-resident keys, but stores the private key pointer on the SK as well.

> I was kinda hoping to avoid storing the private key on the local machine at all.

I may be misunderstanding but I use U2F with OpenSSH (8.3). The private key is not on the local machine. It's still SSH public/private key pair but the private key on the computer is only a "key handle", not the real private key. The private key is protected on the security key. I don't mind copying that private key around: although it looks like a private key, it's just a key handle and not the actual private key.

Good point. I'm not being precise, sorry.

Still, I'm trying to avoid leaving so many breadcrumbs on my systems if they aren't needed.

Not using SSH resident keys myself yet, but you also require key identifiers for your gpg keys on the local machine if you use yubikeys with gpg afaik.

Ugh, now I'm having the dreaded ERROR: Failed to connect to YubiKey when running ykman fido info. :(

Of all the tech stacks that I have to deal with on a daily basis, I just don't get how GPG is hard. It is just like any other tool.

But, I just copy my ~/.gnupg directory to my new machine or to some backup server and all my gpg backed ssh keys/configs are portable. It's not terribly hard.

IMO, GPG has a pretty terrible CLI. GPG agent config is complicated and is more of a pain to get working with forwarding etc. I don’t like the fact that GPG requires config at all. I also have no use for it, that I can’t solve with something nicer. I use age/sops for my encryption-related use cases. If I needed signing, I’d probably use minisign or signify. For authentication, Wireguard/SSH.

But for the SSH key use case, none of this matters. Unless you need compatibility with old SSH servers/clients, resident keys are substantially simpler, because they cut out 1 tool entirely and don’t require copying any directories to other machines.

I get it. The man pages for GPG are like reading War And Peace, whereas the man pages for Age is easily digestible. I too use Age for certain things, but have to use GPG in some of my workflows. But I find it no harder than some insane Helm chart values.yaml files, or some crazy assed Terraform runs with a tfvars file that has hundreds of lines to merely spin up a bucket or vpc. It's just another tool that you need to config and understand.

> But for the SSH key use case, none of this matters.

Agreed.

You can use the security-key variants of ssh keys. Those would be ecdsa-sk, ed25519-sk and others[0]. This does require a newer OpenSSH version to work. GitHub has added support for these keys back in 2021.

[0]: https://news.ycombinator.com/item?id=22324074

[1]: https://github.blog/2021-05-10-security-keys-supported-ssh-g...

What real security risk is it mitigating tho?

Um... it replaces a password (or manual management of keys) with a USB device I can carry around like a proper key.

You described what it does and missed the point of my question. What real security risk is it being handled?

A hacker who got into your laptop can’t simply copy your id_rsa file to get further access to all your servers, it’s physically stored in the usb dongle with no way to get it out and requires physically touching it each time key is used.

A hacker who got into your laptop can piggy back on your SSH connections (and also extract all sort of vital data).

Not being able to extract SSH keys helps very little.

Helps more than you might think! Because the other thing Secretive can do is require touch ID for each use of the key. Similarly, you can require a button push from your yubikey.

Look up ssh -sk keys. OpenSSH has been supporting FIDO2 secured keys for quite a while now. You're specifically looking for "resident" keys.

Looked at it at some point with hope that it'd provide easier user experience to use SSH with Yubikey PIV functionality on Mac. Unfortunately it doesn't support RSA keys we have to use for various reasons.

https://github.com/maxgoedjen/secretive/issues/10

It's not really so much that Secretive doesn't support RSA keys, it's that the SE doesn't

How I'm setting up SSH access currently is to use two factor authentication where one of the factors is a device identifier, i.e. SSH key stored in TPM or with this on the Secure Enclave on a Mac, allowing only access from trusted devices. The second is a user identifier, stored in a yubikey.

In sshd_config, you can enable multifactor authentication with a comma separated list after AuthenticationMethods, for example publickey, publickey to require two keys.

https://manpages.debian.org/bullseye/openssh-server/sshd_con...

Wouldn't that mean that I can login with any two keys? So instead of laptop+yubikey I could login with the keys from two laptops? Or from two yubikeys?

What if someone gets 2 of the yubikeys?

Wow, this is really exciting! I have wished something like this existed, I'll have to try it out. I would love to use touchID to protect my ssh keys instead of a password!

If you are using 1Password it's also possible already: https://blog.1password.com/1password-ssh-agent/

I opted for this instead when I decided to look this up, works really great!

This is excellent.

A different way of enhancing the security of a private key is to use a passphrase and store the passphrase in the macOS Keychain. Then, configure ssh-agent to always use the Keychain. When you login to your Mac user account, it will unlock it for use with ssh.

The encryption key needed to decrypt the Keychain is stored inside the Secure Enclave.

If someone manages obtain your private key, they would also need guess your passphrase or gain access to the Secure Enclave.

Doesn't Secure Enclave offer a smartcard-like interface on macOS?

SSH already supports using hardware-backed keys via smartcard interfaces, so such an interface would allow it to work without any extra moving parts.

I keep seeing lots of new programs that are basically "Secure Enclave for X", where X already supports hardware-based keys via existing interfaces.

Not directly - you can use CryptoTokenKit to bind SE keys into the keychain as if they were a smartcard, but there's no shipped tooling for that.

I’ll definitely give this a spin!

My go to right now is using a gpg key with ssh subkey. The key is actually on YubiKey. Similar security properties but portable.

If you're already using a Yubikey, you can use FIDO2-based SSH keys which work natively with ssh-agent.

Assuming both client and server are recent enough to recognize the resident key types and are configured to allow them.

Source: I have to deal with some machines I can’t fix.

> I can't fix

Do not be afraid! (I've messed with quite a few very ancient and messy systems, like Gentoos of a legal drinking age. Dissected their guts, extracted their hearts, made LD_PRELOAD crutches, containerized stuff to run on modern hardware - this kind of mix of software necromancery and archeology. It's not trivial, but quite doable.)

Fortunately, SSH daemons are quite isolated components, so they can almost always be updated without affecting the system.

It's possible to build a completely static OpenSSH daemon binary, and replace the ancient /usr/bin/sshd on the most ancient OS. And it will work. Of course, test ahead of time by running your `~/tmp/your-new-sshd -d -p 10022` and ensuring you still can log in.

For cleanliness (not to screw the system even further), as long as that machine still has a functional packaging system - even if package repos are long gone, I would recommend wrapping this binary in a OS-native package format (.deb, .rpm or whatever it uses), making a quick-and-dirty backport (from a custom built static binary), and feeding it to the low-level package manager. Preferably, taking a backup of the original sshd package from the local package cache (or finding that exact same package in some online archive).

I mean, I've put `sshd`s on all sort of embedded systems, Docker containers and whatnot. Even if you have some Gentoo or Slackware machine from early 2000s (or worse), I don't really see much problem in modernizing an SSH daemon there.

The only exception I can imagine is if someone already runs a patched sshd and they can't (or won't risk) backport new stuff in there.

Also check out https://github.com/FiloSottile/yubikey-agent which simplifies the setup quite a bit.

Secretive is one of my favorite tools on mac os. it's the best ssh workflow i've used: key material never leaves the device, can auth with touch id, and forward the agent as necessary. i've also sent him $ on github as a small thank you for a tool i use daily (and i'd encourage you to, too!)

there was a cool app called krypt that did this for ios, with push notifications to your phone when you ssh'd, where requests were authenticated against your secure enclave. then it got bought by akamai and turned into some b2b saas crap.

Unfortunately the SEP only supports ECDSA keys. https://blog.cr.yp.to/20140323-ecdsa.html

I don't think the secure enclave is the solution. Identities should be independent than general computation devices with many attack vectors.

Not sure what you mean?

The point of storing SSH keys in the Secure Enclave is to prevent against the default of /literally any/ program from reading them in plain text off your file system.

I mean [1] and [2]. General computation devices have wide attack vectors than specific security devices.

[1] An Overview of Vulnerabilities and Mitigations of Intel SGX Applications: https://cyber.ee/uploads/D_2_116_An_Overview_of_Vulnerabilit...

[2] https://www.google.com/search?q=security+enclave+vulnerabili...

Sure, nobody said there can’t be vulnerabilities in the Secure Enclave or similar options.

The default alternative is globally-readable plain text.

Don’t let perfection be the enemy of good/better.

> Don’t let perfection be the enemy of good/better.

I agree, it is just that we add a new element of security which has other security issues while we can move directly outside the computer. Apple move to U2F as a 2FA is a clear execution.

This is already possible and has been for some time on Linux using TPM. What is different about secure enclave, or is it just Apple lingo?

The Apple enclave is closer to a general-purpose computer (with a bunch of cryptographic infrastructure) than a TPM, but I think for this purpose the two concepts line up.

I think it's a critical difference that the Apple enclave has direct access to inputs (the touchid).

Using the Secure Enclave allows you to tie use of the key to biometric auth (which also serves as proof of physical presence). Even if someone compromises your system, they can't SSH as you without tricking you into mashing touchID.

    The Secure Enclave is a dedicated secure subsystem integrated into Apple
    systems on chip (SoCs). The Secure Enclave is isolated from the main
    processor to provide an extra layer of security and is designed to keep
    sensitive user data secure even when the Application Processor kernel
    becomes compromised. It follows the same design principles as the SoC
    does—a boot ROM to establish a hardware root of trust, an AES engine
    for efficient and secure cryptographic operations, and protected
    memory.

From "Apple Platform Security"—https://support.apple.com/guide/security/secure-enclave-sec5...

They're not the same.

The TPM chip is really just another little computer your main computer talks to over a special network; it has no access to the rest of your computer hardware, so when you type your pin or passphrase in, your computer needs to put it in memory and send it to your TPM chip over this special network cleartext.

The touchid interface is part of the secure enclave packaging, so the activation command (fingerprint, nearby hotdog, whatever you've trained the sensor with) isn't ever in memory.

This difference makes attacking keys stored in the secure enclave a lot harder than attacking keys stored in TPM, because with TPM, you have this second thing to attack (the cleartext channel) but with secure enclave you don't.

If you want to do this on Linux, you can get bluetooth fido2 apps for your phone which work pretty well, but bluetooth is very complicated and Linux doesn't have good support for pre-login bluetooth setup afaik, so (re)provisioning can be tricky. I like these little USB-attached smart-card readers with integrated PIN-pads (either on the reader or on the card itself) because USB seems a little bit more reliable, but you may need one that also supports bluetooth or NFC in order to use your token (easily) with mobile devices if you like to login from your phone sometimes.

Could you point me to an easy-to-use Linux app that handles SSH keys on TPM for me? Would love to use it on my non-Mac devices.

Perhaps tpm2-pkcs11 and its ptool are approachable enough? https://github.com/tpm2-software/tpm2-pkcs11/blob/master/doc...

Practically an anti-pattern nowadays. Get a YubiKey and leverage SSH certificates.

This is a non-sequitur, even if you use SSH certificates you still need a public/private keypair, hosts just authorize the key by checking the signature from a trusted CA on the public half of the user key. The OP is about a way to store the private key part of the user key that can't be extracted even with physical access to the machine. So, this is an equivalent/alternative to using a YubiKey, that is conveniently built in to a popular piece of hardware; not something orthogonal to using SSH certificates.

It's not really a non-sequitur. The idiom for SSH certificates is to be issued extremely short-term certificates in response to MFA authentication. You don't get long-term secrets in most SSH CA schemes.

You're certainly more of an authority on it than I, so I trust when you say most schemes don't keep long-term keypairs around; but of the two companies I've worked at that use SSH CAs: one used Teleport, and the other had long-lived keypairs, but fairly-short-lived certificates -- you had to get your public key re-signed each day. They used Yubikeys to store (or maybe just unwrap?) the private key material during the SSH handshake; much as a TPM or the Secure Enclave could be used to do this.

My experience (over maybe 10 years of using SSH-CAs) was similar, I mean by using long-term key pairs (mostly for humans) and shorter certificates. I can imagine secretive to be a very useful tool for SSH-CAs and other uses. I also like the fact that you can't import a key, makes it pretty clear that A- it's a specific device, and B- there is a human adding their bio info to unlock it.

Your experience of SSH CAs is different from mine (that doesn't make it wrong). My experience is that the major motivation for SSH CAs is linking SSH authentication to MFA SSO. The long-lived secrets here are the MFA secrets.

Very useful to know, thanks for explaining more. I am curious to know (if you happen to remember) if this was an off-the-shelf product, and if so which one? I assume the product was either an MFA device or an SSH/SSO solution or both.

I've worked with teams that did bespoke versions, but Teleport is the most popular implementation of the idea right now. The underlying idea is trivial, right? You have an SSO RP that is a CA, and issues short-lived certs based on SSO IdP logins; the simple SSH certificate machinery makes this work across your fleet.

The certs are just an alternative to managing the authorized_keys server-side. That's it. What you said about MFA and not getting long-term secrets is some extra thing on top of it and not invalidating your parents point.

No, that's not true. SSH keys are long-lived secrets, and certificates often deliberately aren't.

This is not what it is, this is how you specifically use them.

I understand what you're trying to say, but "The certs are just an alternative to managing the authorized_keys server-side" is just not correct. Certs can do things plain authorized_keys can't.

Reply on news.ycombinator.com