9 ms·

Not exactly connected but the same crowd interested in this topic may also be interested in this tool to store SSH private keys in the Secure Enclave, kind of l

Not exactly connected but the same crowd interested in this topic may also be interested in this tool to store SSH private keys in the Secure Enclave, kind of like what can be done with a YubiKey: https://github.com/maxgoedjen/secretive https://github.com/maxgoedjen/secretive I've been looking for something like this for 3-4 years but only found it six months ago (in an HN thread). I use separate keys for every use case, and now know every time a key is used for any purpose, whether it's connecting to source control or my text editor is connecting to a remote VM. Only thing I haven't figured out is how to do git signatures with these sorts of keys, but I haven't debugged it at all.

maxique 4y ago
I think 1Password's SSH agent does this now, too
- CharlesW 4y ago
  I didn’t know that was a thing, thank you! https://blog.1password.com/1password-ssh-agent/ https://blog.1password.com/1password-ssh-agent/
- microtonal 4y ago
  But it’s not really the same. Having private key material in the secure enclave means that it’s not extractable (except perhaps by state-level attackers with hardware access). With an SSH private key in 1Password there are still many possible software-level attack vectors (vulnerabilities in 1Password, a compromised 1Password update, etc.).
kitsunesoba 4y ago
Secretive is great. I use it on my T2 and M-series Macs and feel much better with keys sitting in those machines' secure enclaves than I did back when it was just sitting in ~/.ssh/ for anything to grab. I just wish there were something as clean as Secretive for using generic PC TPMs or YubiKeys in place of a Secure Enclave under Windows and Linux. Currently have a Linux laptop halfway through setting that up and it's messy in comparison.
- judge2020 4y ago
  For Windows, it seems it's possible[0, see footnote], however there are problems like general incompatibilities [1], and official support status is " We have this in our backlog. At this point it's not prioritized.". 0: https://github.com/tavrez/openssh-sk-winhello https://github.com/tavrez/openssh-sk-winhello 0.footnote: "Windows Hello also supports other types of authenticators like internal TPM device(if they support generating ECDSA or Ed25519 keys, they can be used instead of FIDO/U2F security keys)." 1: https://github.com/tavrez/openssh-sk-winhello/issues https://github.com/tavrez/openssh-sk-winhello/issues 2: https://github.com/PowerShell/Win32-OpenSSH/issues/1804#issuecomment-850500721 https://github.com/PowerShell/Win32-OpenSSH/issues/1804#issu...
  - redninja83 4y ago
    Its possible to do, and once set up its a reasonably smooth process. - Init Your TPM - Create a key+cert on your TPM using certutil.exe - Grab your public key - Use WinCryptSSH (https://github.com/buptczq/WinCryptSSHAgent https://github.com/buptczq/WinCryptSSHAgent) as your SSH agent and away you go These are very simplified steps, but there are howtos floating around (eg https://blog.habets.se/2016/10/Windows-SSH-client-with-TPM.html https://blog.habets.se/2016/10/Windows-SSH-client-with-TPM.h...)
- boustrophedon 4y ago
  It's actually very easy on linux now: You just use the two -sk key types released in Feb 2020 https://www.openssh.com/txt/release-8.2 https://www.openssh.com/txt/release-8.2 `ssh-keygen -t ed25516-sk` or `ecdsa-sk` and then you touch your yubikey when unlocking the key, the same time as you would type a password. Question for anyone else reading: Does it make sense to use a password with -sk keys? I don't think it would make a difference either way.
  - frutiger 4y ago
    > Does it make sense to use a password with -sk keys? I don't think it would make a difference either way. Only if you want to protect your keys from being used by someone that has access to the private key + yubikey (i.e. someone physically present). In other words, the -sk type private key is useless without the yubikey as well.
vbezhenar 4y ago
Why those things are not built-in to macOS. I don't understand. It should not be hard to implement for Apple engineers and it could be a good example for corresponding API. I don't use sudo often enough to warrant system changes, so I don't use those programs, but if they would be enabled by default, I would gladly use them.
- dmitriid 4y ago
  Another pet peeve is: why can you auth with your watch but not your phone?
  - Jtsummers 4y ago
    It would be nice, but the phone would have to be unlocked at the same time you try to authenticate on the computer for this to work. Part of why it works with the watch is that you have to have an unlocked (but pin-lockable) watch near the computer. Most of the time when you're wearing the watch it will be unlocked (this is the default behavior, after unlocking it stays unlocked while worn) whereas the phone will relock itself. So it would be useful, if you happened to have already unlocked your phone near your laptop, but probably not as consistently useful as the watch. Most of the time, you'd find yourself unlocking your phone to unlock your computer which is not really convenient, so you'll just unlock the computer itself.
    - dmitriid 4y ago
      This would be useful in the case when laptop lid is closed. TouchID/FaceID are still very fast
      - jacobsenscott 4y ago
        You can do this with a chromebook and an android phone. I find it is more comfortable and faster to just type in the pin vs unlocking the phone, so I don't use it much.
        4y ago
Axsuul 4y ago
Note that there are some pretty significant caveats to Secretive: - You cannot import your existing SSH keys - You cannot transfer SSH keys if you get a new machine
- adastra22 4y ago
  That’s the whole point, no? Tie identity to the machine itself, not a piece of data that can be stolen. BTW, if you have a key that you copy around to multiple machines, you’re doing it wrong!
  - rgoulter 4y ago
    It's not sufficient to be the whole point. With some security mechanism, I'd consider: 1. prevent other people from being able to use it. 2. recover from it in case it gets lost. If your perspective is "if I lose this laptop, I have some other way to access the systems", then it's good to never access the SSH key secret. If your perspective is that you want your secret key to be the only way to access some system, you'll want to have some way to recover the secret. I think in any case, it's understood that having an unrecoverable secret being the only way to access some system is a bad idea.
- epistasis 4y ago
  Exactly, these are precisely the features I'm looking for. They are not caveats, they are the way I want my keys to behave. If there is some sort of use case where I want to be able to backup a key, or share it with someone else I can always fall back to SSH keys on a hard disk. But those are usually anti-patterns.
- howinteresting 4y ago
  Backup and availability is where all of these systems fail. Even the new passkey sync thing is pure vendor lock-in.
  - epistasis 4y ago
    I'd prefer for a backup to be a second key on a different hardware device, personally. I might also be ok if somebody like Apple had engineered a cloud solution for securely keeping backups, but only maybe.
trhway6552 4y ago
I've been using https://github.com/sekey/sekey https://github.com/sekey/sekey for years now! It handles gpg as well
buildbot 4y ago
I actually tried this and was glad I left myself an out - I had a kernel panic, after which the contents of the secure enclave where wiped with the rest of the system state (to restart from known good settings???). Bye-bye SSH private key. I would recommend caution if you use it.
- nano9 4y ago
  The same could happen with a hardware token like Yubikey, if it were to suffer from an irrecoverable software or hardware error. It's still useful, because spoofed authentication prompts will no longer get a chance at plaintext access to your password.
  - kitsunesoba 4y ago
    This is also why it's a good idea to have multiple keys instead of having everything riding on one. With a T2/M-series machine it's easy to have at least two (one in Secure Enclave, one in a USB key), and USB keys are tiny enough to hide away another one or two.
    - filleokus 4y ago
      I've always felt that the suggestion of having two keys seems kinda cumbersome, especially for webauthn. If understand it correctly I need to enroll both keys, by physically having them present? Then I need to remember to enroll the second one whenever I sign up for something (or keep both keys with me, which kinda negates the backup perspective). For SSH it's probably easier since I can just have both public keys accessible for adding it to new servers and keep the token somewhere safe. My preferred solution would be to generate the private key material outside of the secure enclave (but on a offline device or something), write it down on a piece of paper and then transfer it in to the enclave/hardware device. That way I could just restore the same private key if the physical secure enclave is destroyed.
      - Avamander 4y ago
        > If understand it correctly I need to enroll both keys, by physically having them present? Yes. > Then I need to remember to enroll the second one whenever I sign up for something (or keep both keys with me, which kinda negates the backup perspective). Alternatively you print out the backup codes. > My preferred solution would be to generate the private key material outside of the secure enclave (but on a offline device or something), write it down on a piece of paper and then transfer it in to the enclave/hardware device. The primary reason why we want to do hardware at all, is that to the best extent we know the key is generated by it and will remain in it. That most of the threat becomes someone in the physical world stealing it from you. Though some more open-source webauthn tokens would allow you to do what you described. Secure key management procedures are just not something we should encourage people to do themselves, it's difficult.

maxique 4y ago

I think 1Password's SSH agent does this now, too

CharlesW 4y ago
I didn’t know that was a thing, thank you! https://blog.1password.com/1password-ssh-agent/ https://blog.1password.com/1password-ssh-agent/
microtonal 4y ago
But it’s not really the same. Having private key material in the secure enclave means that it’s not extractable (except perhaps by state-level attackers with hardware access). With an SSH private key in 1Password there are still many possible software-level attack vectors (vulnerabilities in 1Password, a compromised 1Password update, etc.).

kitsunesoba 4y ago

Secretive is great. I use it on my T2 and M-series Macs and feel much better with keys sitting in those machines' secure enclaves than I did back when it was just sitting in ~/.ssh/ for anything to grab. I just wish there were something as clean as Secretive for using generic PC TPMs or YubiKeys in place of a Secure Enclave under Windows and Linux. Currently have a Linux laptop halfway through setting that up and it's messy in comparison.

judge2020 4y ago
For Windows, it seems it's possible[0, see footnote], however there are problems like general incompatibilities [1], and official support status is " We have this in our backlog. At this point it's not prioritized.". 0: https://github.com/tavrez/openssh-sk-winhello https://github.com/tavrez/openssh-sk-winhello 0.footnote: "Windows Hello also supports other types of authenticators like internal TPM device(if they support generating ECDSA or Ed25519 keys, they can be used instead of FIDO/U2F security keys)." 1: https://github.com/tavrez/openssh-sk-winhello/issues https://github.com/tavrez/openssh-sk-winhello/issues 2: https://github.com/PowerShell/Win32-OpenSSH/issues/1804#issuecomment-850500721 https://github.com/PowerShell/Win32-OpenSSH/issues/1804#issu...
- redninja83 4y ago
  Its possible to do, and once set up its a reasonably smooth process. - Init Your TPM - Create a key+cert on your TPM using certutil.exe - Grab your public key - Use WinCryptSSH (https://github.com/buptczq/WinCryptSSHAgent https://github.com/buptczq/WinCryptSSHAgent) as your SSH agent and away you go These are very simplified steps, but there are howtos floating around (eg https://blog.habets.se/2016/10/Windows-SSH-client-with-TPM.html https://blog.habets.se/2016/10/Windows-SSH-client-with-TPM.h...)
boustrophedon 4y ago
It's actually very easy on linux now: You just use the two -sk key types released in Feb 2020 https://www.openssh.com/txt/release-8.2 https://www.openssh.com/txt/release-8.2 `ssh-keygen -t ed25516-sk` or `ecdsa-sk` and then you touch your yubikey when unlocking the key, the same time as you would type a password. Question for anyone else reading: Does it make sense to use a password with -sk keys? I don't think it would make a difference either way.
- frutiger 4y ago
  > Does it make sense to use a password with -sk keys? I don't think it would make a difference either way. Only if you want to protect your keys from being used by someone that has access to the private key + yubikey (i.e. someone physically present). In other words, the -sk type private key is useless without the yubikey as well.

vbezhenar 4y ago

Why those things are not built-in to macOS. I don't understand. It should not be hard to implement for Apple engineers and it could be a good example for corresponding API. I don't use sudo often enough to warrant system changes, so I don't use those programs, but if they would be enabled by default, I would gladly use them.

dmitriid 4y ago
Another pet peeve is: why can you auth with your watch but not your phone?
- Jtsummers 4y ago
  It would be nice, but the phone would have to be unlocked at the same time you try to authenticate on the computer for this to work. Part of why it works with the watch is that you have to have an unlocked (but pin-lockable) watch near the computer. Most of the time when you're wearing the watch it will be unlocked (this is the default behavior, after unlocking it stays unlocked while worn) whereas the phone will relock itself. So it would be useful, if you happened to have already unlocked your phone near your laptop, but probably not as consistently useful as the watch. Most of the time, you'd find yourself unlocking your phone to unlock your computer which is not really convenient, so you'll just unlock the computer itself.
  - dmitriid 4y ago
    This would be useful in the case when laptop lid is closed. TouchID/FaceID are still very fast
    - jacobsenscott 4y ago
      You can do this with a chromebook and an android phone. I find it is more comfortable and faster to just type in the pin vs unlocking the phone, so I don't use it much.
      - 4y ago

Axsuul 4y ago

Note that there are some pretty significant caveats to Secretive: - You cannot import your existing SSH keys - You cannot transfer SSH keys if you get a new machine

adastra22 4y ago
That’s the whole point, no? Tie identity to the machine itself, not a piece of data that can be stolen. BTW, if you have a key that you copy around to multiple machines, you’re doing it wrong!
- rgoulter 4y ago
  It's not sufficient to be the whole point. With some security mechanism, I'd consider: 1. prevent other people from being able to use it. 2. recover from it in case it gets lost. If your perspective is "if I lose this laptop, I have some other way to access the systems", then it's good to never access the SSH key secret. If your perspective is that you want your secret key to be the only way to access some system, you'll want to have some way to recover the secret. I think in any case, it's understood that having an unrecoverable secret being the only way to access some system is a bad idea.
epistasis 4y ago
Exactly, these are precisely the features I'm looking for. They are not caveats, they are the way I want my keys to behave. If there is some sort of use case where I want to be able to backup a key, or share it with someone else I can always fall back to SSH keys on a hard disk. But those are usually anti-patterns.
howinteresting 4y ago
Backup and availability is where all of these systems fail. Even the new passkey sync thing is pure vendor lock-in.
- epistasis 4y ago
  I'd prefer for a backup to be a second key on a different hardware device, personally. I might also be ok if somebody like Apple had engineered a cloud solution for securely keeping backups, but only maybe.

trhway6552 4y ago

I've been using https://github.com/sekey/sekey https://github.com/sekey/sekey for years now! It handles gpg as well

buildbot 4y ago

I actually tried this and was glad I left myself an out - I had a kernel panic, after which the contents of the secure enclave where wiped with the rest of the system state (to restart from known good settings???). Bye-bye SSH private key. I would recommend caution if you use it.

nano9 4y ago
The same could happen with a hardware token like Yubikey, if it were to suffer from an irrecoverable software or hardware error. It's still useful, because spoofed authentication prompts will no longer get a chance at plaintext access to your password.
- kitsunesoba 4y ago
  This is also why it's a good idea to have multiple keys instead of having everything riding on one. With a T2/M-series machine it's easy to have at least two (one in Secure Enclave, one in a USB key), and USB keys are tiny enough to hide away another one or two.
  - filleokus 4y ago
    I've always felt that the suggestion of having two keys seems kinda cumbersome, especially for webauthn. If understand it correctly I need to enroll both keys, by physically having them present? Then I need to remember to enroll the second one whenever I sign up for something (or keep both keys with me, which kinda negates the backup perspective). For SSH it's probably easier since I can just have both public keys accessible for adding it to new servers and keep the token somewhere safe. My preferred solution would be to generate the private key material outside of the secure enclave (but on a offline device or something), write it down on a piece of paper and then transfer it in to the enclave/hardware device. That way I could just restore the same private key if the physical secure enclave is destroyed.
    - Avamander 4y ago
      > If understand it correctly I need to enroll both keys, by physically having them present? Yes. > Then I need to remember to enroll the second one whenever I sign up for something (or keep both keys with me, which kinda negates the backup perspective). Alternatively you print out the backup codes. > My preferred solution would be to generate the private key material outside of the secure enclave (but on a offline device or something), write it down on a piece of paper and then transfer it in to the enclave/hardware device. The primary reason why we want to do hardware at all, is that to the best extent we know the key is generated by it and will remain in it. That most of the threat becomes someone in the physical world stealing it from you. Though some more open-source webauthn tokens would allow you to do what you described. Secure key management procedures are just not something we should encourage people to do themselves, it's difficult.