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)
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.
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.
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.
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.
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.
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.
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”?
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).
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.
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.
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.
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.
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 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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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...
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?
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!
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.
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.
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.
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.
> 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.
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.
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.
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 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.
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.
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.
