[HN Gopher] Secretive: Store SSH Keys in the Secure Enclave
___________________________________________________________________
Secretive: Store SSH Keys in the Secure Enclave
Author : ValentineC
Score : 273 points
Date : 2023-03-10 04:06 UTC (18 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| ahepp wrote:
| 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!
| dewey wrote:
| If you are using 1Password it's also possible already:
| https://blog.1password.com/1password-ssh-agent/
| VoxPelli wrote:
| I opted for this instead when I decided to look this up,
| works really great!
| throwawayacc5 wrote:
| Practically an anti-pattern nowadays. Get a YubiKey and leverage
| SSH certificates.
| daave wrote:
| 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.
| tptacek wrote:
| 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.
| daave wrote:
| 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.
| camgas wrote:
| 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.
| tptacek wrote:
| 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.
| camgas wrote:
| 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.
| tptacek wrote:
| 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.
| [deleted]
| blueflow wrote:
| 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.
| tptacek wrote:
| No, that's not true. SSH keys are long-lived secrets, and
| certificates often deliberately aren't.
| [deleted]
| nyolfen wrote:
| 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.
| encryptluks2 wrote:
| 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?
| yunohn wrote:
| 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.
| tptacek wrote:
| 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.
| geocar wrote:
| I think it's a critical difference that the Apple enclave has
| direct access to inputs (the touchid).
| [deleted]
| geocar wrote:
| 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.
| mjg59 wrote:
| 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.
| alwillis wrote:
| 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...
| mjg59 wrote:
| 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)
| smoothgrammer wrote:
| Make sure you sign the information that indicates the
| requestor.
| nixpulvis wrote:
| 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?
| als0 wrote:
| YubiKey already supports those scenarios, I think.
| MadQ wrote:
| 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
| nixpulvis wrote:
| 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.
| acdha wrote:
| 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/
| trevorthejag wrote:
| 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.
| mimsee wrote:
| 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...
| ratorx wrote:
| 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.
| nixpulvis wrote:
| 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.
| ratorx wrote:
| 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.h
| t...
| nixpulvis wrote:
| 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 :)
| TacticalCoder wrote:
| > 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.
| nixpulvis wrote:
| 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.
| phaer wrote:
| 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.
| nixpulvis wrote:
| Ugh, now I'm having the dreaded ERROR: Failed to connect
| to YubiKey when running ykman fido info. :(
| ratorx wrote:
| 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.
| zikduruqe wrote:
| 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.
| ratorx wrote:
| 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.
| zikduruqe wrote:
| 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.
| goodpoint wrote:
| What real security risk is it mitigating tho?
| nixpulvis wrote:
| Um... it replaces a password (or manual management of keys)
| with a USB device I can carry around like a proper key.
| goodpoint wrote:
| You described what it does and missed the point of my
| question. What real security risk is it being handled?
| buildbot wrote:
| 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!
| runeks wrote:
| The trick is to have multiple SSH keys -- spread out over
| several physical devices -- all of which are in your server's
| authorized_keys.
| riobard wrote:
| Correct me if wrong, but I thought that you cannot extract the
| private key from the Secure Enclave at all?
| olliej wrote:
| 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.
| pocketarc wrote:
| 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.
| fulafel wrote:
| 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.
| friendzis wrote:
| 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.
| drdaeman wrote:
| 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.
| ikiris wrote:
| 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.
| booi wrote:
| hmm, where do you store the CA private key? We're just going
| around in circles
| mbreese wrote:
| 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.
| [deleted]
| ikiris wrote:
| 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.
| chasil wrote:
| 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.
| friendzis wrote:
| > 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.
| adastra22 wrote:
| The whole point is that you literally can't backup the key.
| rgreen wrote:
| 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!)
| [deleted]
| macrolime wrote:
| 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...
| MaxMatti wrote:
| 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?
| aprilnya wrote:
| What if someone gets 2 of the yubikeys?
| kylehotchkiss wrote:
| 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
| mjg59 wrote:
| 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.
| exabrial wrote:
| 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.
| computerfriend wrote:
| If you're already using a Yubikey, you can use FIDO2-based SSH
| keys which work natively with ssh-agent.
| zoidb wrote:
| Also check out https://github.com/FiloSottile/yubikey-agent
| which simplifies the setup quite a bit.
| meepmorp wrote:
| 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.
| drdaeman wrote:
| > 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.
| rollcat wrote:
| Unfortunately the SEP only supports ECDSA keys.
| https://blog.cr.yp.to/20140323-ecdsa.html
| dang wrote:
| Related:
|
| _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)
| obscurette wrote:
| 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
| mjg59 wrote:
| It's not really so much that Secretive doesn't support RSA
| keys, it's that the SE doesn't
| LoganDark wrote:
| 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.
| sneak wrote:
| > _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.
| trallnag wrote:
| This sounds ridiculous.
| sneak wrote:
| 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.
| LoganDark wrote:
| > 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.
| sneak wrote:
| Almost everyone who supports U2F or WebAuthn also supports
| enrolling multiple keys.
| kimburgess wrote:
| 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.
| RockRobotRock wrote:
| yubikey support for GPG has always been meh for me. FIDO2 ssh
| keys seem really promising. GPG definitely still has its
| place though
| palata wrote:
| Once setup, for me it's working like a charm. I use GPG for
| signing (git commits + java jars/aars/apks), it just works.
| kimburgess wrote:
| 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.
| foobiekr wrote:
| 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.
| konha wrote:
| > 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
| trompetenaccoun wrote:
| Fair enough but at that point, why not just use a software
| based PW manager?
| foobiekr wrote:
| 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.
| Hamuko wrote:
| What's wrong with having your Yubikeys on your keys?
| foobiekr wrote:
| 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.
| aaomidi wrote:
| Have more than one Yubikey, use paperbackup keys.
| user3939382 wrote:
| 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.
| tjoff wrote:
| 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.
| drowsspa wrote:
| 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.
| NoZebra120vClip wrote:
| 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!
| smaudet wrote:
| 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.
| ikiris wrote:
| 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.
| smaudet wrote:
| 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.
| ikiris wrote:
| 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.
| mbreese wrote:
| 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"?
| ikiris wrote:
| 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.
| muppetman wrote:
| 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.
| smaudet wrote:
| 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).
| nathants wrote:
| devices like trezor offer fido2 and backup/restore.
| nelox wrote:
| 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.
| WhyNotHugo wrote:
| 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.
| mjg59 wrote:
| 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.
| wslh wrote:
| I don't think the secure enclave is the solution. Identities
| should be independent than general computation devices with many
| attack vectors.
| yunohn wrote:
| 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.
| wslh wrote:
| 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_Overvie
| w_of_Vulnerabilit...
|
| [2] https://www.google.com/search?q=security+enclave+vulnerab
| ili...
| yunohn wrote:
| 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.
| wslh wrote:
| > 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.
| VoxPelli wrote:
| 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
| e1g wrote:
| 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.
| PointyFluff wrote:
| [dead]
___________________________________________________________________
(page generated 2023-03-10 23:02 UTC)