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.
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.
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.
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.
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 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.
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.
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.
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 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.
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.
Readit News
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.
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.
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
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.
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.
Have multiple of them for redundancy, trust them all at your central auth point and this isn't an issue.
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.
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'd rather we find a way to actually involve real-world security instead of pretending the digital world doesn't depend on it.
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.
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.
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)
Also use it to sign my git commits: https://developer.1password.com/docs/ssh/git-commit-signing
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.
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.
You can use any key you want as long as you get a CA that everything trusts to sign it.
Anyone gone down this path?
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.
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.
[0]: https://news.ycombinator.com/item?id=22324074
[1]: https://github.blog/2021-05-10-security-keys-supported-ssh-g...
https://github.com/drduh/YubiKey-Guide#ssh
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.
https://github.com/maxgoedjen/secretive/issues/10