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.
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.
But those are per site right?
Re hardware and that above is not something for most people:
Yeah I agree. Something like https://uni.horse/notes/solo-key-backups.html, but it shouldn’t be a solution for most people.
But I still think the backup story is flawed, and could be improved to work in a easy and secure way:
Using some easy vendor GUI tool, with a simple clone button:
1: Generate on-hardware webauthn master key on device A. 2: Generate on-hardware key-par on device B 3: Export B’s public key to A 4: Encrypt A’s private key with B’s public key 5: Export encrypted master key to B 6: Decrypt on B
But I guess we ideally would want some standardized protocol for doing this so you can do cross vendor backup.
(Most likely this will be solved by the mobile os vendors who will sync and backup your private key for you. Using your phones HSM instead of an external device)
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.
I'm glad my windows PC only requires a PIN :)
There is probably low priority/ignored because most developers can easily do this on their own, so it's not really worth the hassle.
20 million / 1 billion = 2%
So yes, it seems like a small market relatively.
Developers are incredibly important for an ecosystem and having them a bit more optimistic about a platform can be quite beneficial (for a very low price, even).
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.
`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.
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.
It's nice not to have to rely on an external yubikey
Any laptop that is listed as supported by Windows 11 will have an onboard TPM.
0: 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
2: https://github.com/PowerShell/Win32-OpenSSH/issues/1804#issu...
- Init Your TPM
- Create a key+cert on your TPM using certutil.exe
- Grab your public key
- Use WinCryptSSH (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.h...)
- You cannot import your existing SSH keys
- You cannot transfer SSH keys if you get a new machine
BTW, if you have a key that you copy around to multiple machines, you’re doing it wrong!
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.
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.
I might also be ok if somebody like Apple had engineered a cloud solution for securely keeping backups, but only maybe.
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.