Is there a way to make the lifetime of the key last more than a year?
Native Secure Enclave backed SSH keys on macOS
91–100 of 204 posts
Re: Native Secure Enclave backed SSH keys on macOS
#92Earlier quoted context omitted.
The export operation is guarded by TouchID. So the malware needs to trick you into performing the TouchID gesture. But yeh the malware only needs to trick you to hit TouchID once. Instead of on each sign operation. So if that's in your threat model don't make the key exportable.
> So the malware needs to trick you into performing the TouchID gesture. That's not meaningfully more difficult than tricking you into revealing your key file password. >Instead of on each sign operation. But from your video each sign operation also requires a touchid prompt?
[deleted]
Re: Native Secure Enclave backed SSH keys on macOS
#93Earlier quoted context omitted.
I've been in the security space for 25 years, and understand the theory of PKI. But I've also been in the ops space for 30 years, and understand that if you don't balance security theory with operational practice, critical business functions can fail. Ideally yes, the private key is never seen. In reality, it needs to be backed up in a secure place so it can be restored in the event of a failure.
I think you are mixing up concerns. You need a backup key. That doesn't mean you need to backup your key. Anything (everything?) using SSH authentication supports multiple authentication keys. Have a yubikey in a locked deposit box or something.
Today I make a private/public keypair, and the private key is on my laptop in my encrypted home folder. It also gets backed up to my encrypted offsite backup. That way if my laptop breaks or is stolen, I can restore from backup and be up and running as before.
I was simply asking if that is still possible with this method, nothing more.
And not every service that uses ssh auth allows multiple keys.
Re: Native Secure Enclave backed SSH keys on macOS
#94Does the hardware only support the NIST curves? Or is that just the example that happens to be given?
Only supports NIST curves and ECDSA yes. I've heard people make the point before that EdDSA is not great for secure enclaves due to being suspictable to Fault Attacks which could lead to (partial) key extraction
I don't trust the NIST curves: they were generated in a dubious way which has been written about extensively elsewhere (the coefficients for P-256 were generated by hashing the unexplained seed c49d360886e704936a6678e1139d26b7819f7e90). I always avoid them unless I have to use them. It makes me sad when hardware forces me to use them.
> I've heard people make the point before that EdDSA is not great for secure enclaves due to being suspictable to Fault Attacks which could lead to (partial) key extraction
Huh, got a link? My understanding is that eddsa is better with respect to side channels in every way, that was part of the intent of it's design. I've worked with crypto hardware which supports it.
Re: Native Secure Enclave backed SSH keys on macOS
#95Earlier quoted context omitted.
Why is it more secure: a key file on disk is decrypted into memory every time you enter your passphrase. It means the key is around in plain text in the memory of ssh or ssh-agent. Which means it's extractable by an attacker. An exportable key does all the signing inside the secure enclave and never exposes the decrypted key to OS memory. The exported key you can keep in a safe for disaster recovery. You shouldn't ke…
>It means the key is around in plain text in the memory of ssh or ssh-agent. Which means it's extractable by an attacker. An exportable key does all the signing inside the secure enclave and never exposes the decrypted key to OS memory. But malware can just tell the secure enclave to export the key? Yes, they'll have to write new code to do that, but it's not particularly hard (it's 1 line code from your example abov…
As a user I prefer a single touch to typing a passphrase every time. A passphrase also has other attack vectors like keylogging, etc., which would allow replays.
But even if security was exactly the same, I'd prefer the touch to the typing.
Re: Native Secure Enclave backed SSH keys on macOS
#96Earlier quoted context omitted.
>It means the key is around in plain text in the memory of ssh or ssh-agent. Which means it's extractable by an attacker. An exportable key does all the signing inside the secure enclave and never exposes the decrypted key to OS memory. But malware can just tell the secure enclave to export the key? Yes, they'll have to write new code to do that, but it's not particularly hard (it's 1 line code from your example abov…
The malware would have to prompt for biometric authentication before exporting.
So it just has to wait until you’re about to do a legitimate operation requiring authentication, intercept that to export the key, and cancel the real one with a bogus error (and you’ll just try again without any second thoughts).
MacOS has also no concept of secure desktop/etc where the OS can use some privileged UI to explicitly tell you what you are signing and prompt for PIN/biometrics. It’s in fact a well-known problem where legitimate dialogs for system/Apple ID password have no distinguishing features from fake ones.
Re: Native Secure Enclave backed SSH keys on macOS
#97Earlier quoted context omitted.
You can use more than one key you know. Keep the private key you actively use in the secure enclave. The system you actively use is most at risk. Keep a secondary offline private key as backup. You can generate and store it in a secure location, and never move it around. Airgapped even if you want. You could even use a yubikey or other hardware for the secondary key giving you two hard to export keys. Distribute pub…
Yeah but if you get a new device, you have to go add its pubkey to every server you ever use. I wish there were an easier way, otherwise it's understandable that people copy privkeys.
If you’re operating at the scale this is too cumbersome to do manually surely you already have a configuration management system in place to automate this no?
Re: Native Secure Enclave backed SSH keys on macOS
#98Earlier quoted context omitted.
The key is stored encrypted with a unique symmetric key that only your secure enclave knows until the point that you export it. It then re-encrypts it with the password. Until you export it it's just as strong as an enclave-generated one. Obviously don't keep the exported password encrypted key around and don't use a weak password for export.
>The key is stored encrypted with a unique symmetric key that only your secure enclave knows until the point that you export it. It then re-encrypts it with the password. But what's the security benefit of this compared to having a keyfile? So far as I can tell from the commands you provided, there's no real difference, aside from a hacker having to modify their stealer script slightly.
Unlike a TPM and like a YubiKey, you can configure the secure enclave to require presence (via Touch ID) so that a stealer script would be stopped with a prompt.
Re: Native Secure Enclave backed SSH keys on macOS
#99Earlier quoted context omitted.
I think you are mixing up concerns. You need a backup key. That doesn't mean you need to backup your key. Anything (everything?) using SSH authentication supports multiple authentication keys. Have a yubikey in a locked deposit box or something.
Today I make a private/public keypair, and the private key is on my laptop in my encrypted home folder. It also gets backed up to my encrypted offsite backup. That way if my laptop breaks or is stolen, I can restore from backup and be up and running as before. I was simply asking if that is still possible with this method, nothing more. And not every service that uses ssh auth allows multiple keys.
It’s possible but would not bring you any extra security.
The advantage of non-exportable, HSM-backed keys is that you are guaranteed that the only way to use that key is to have online access to the HSM, and you can recover from HSM access compromise without having to replace the keys.
If you make the key exportable it is no better than if it was stored on your disk to begin with.
Re: Native Secure Enclave backed SSH keys on macOS
#100Earlier quoted context omitted.
You can use more than one key you know. Keep the private key you actively use in the secure enclave. The system you actively use is most at risk. Keep a secondary offline private key as backup. You can generate and store it in a secure location, and never move it around. Airgapped even if you want. You could even use a yubikey or other hardware for the secondary key giving you two hard to export keys. Distribute pub…
Yeah but if you get a new device, you have to go add its pubkey to every server you ever use. I wish there were an easier way, otherwise it's understandable that people copy privkeys.
> if you get a new device, you have to go add its pubkey to every server you ever use
It’s not too bad, if the number of servers is not too high.
I have different client pub keys on my phone, multiple laptops and desktop computers and manage my authorized keys to be able to ssh into my servers from the devices, as well as from one laptop to another or from my phone to one of the laptops, etc.
Because I already have several client devices I don’t really need any backup ssh keys. The fact that each device has a different key means that if one laptop breaks or my phone is stolen, I can still ssh into everything from one of the remaining devices and remove the pub key of the broken or stolen device from authorized keys and generate new keys on new devices and then using one of the existing devices to add the pub key of the new device to the authorized keys of the servers and other devices.
For me it’s manageable to do it manually. But if you have very many servers you’d probably want to use a configuration management tool like Chef, Ansible, Puppet or Saltstack. Presumably if you have a very high number of servers you’d already be using a configuration management tool like one of those for other configs and setup anyways.