Live data from Hacker News

Native Secure Enclave backed SSH keys on macOS

gist.github.com

141–150 of 204 posts

Re: Native Secure Enclave backed SSH keys on macOS

#141
post #46

Earlier 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.

There is an easier way, it's called TLS certificates, it's just that SSH decided not to use it for some reason.

Other systems of this nature have figured out long ago that you should be able to have one personal certificate (stored securely in an airgapped environment), from which you'd generate leaf certificates for your devices every year.

Re: Native Secure Enclave backed SSH keys on macOS

#142
post #107

Earlier quoted context omitted.

There is an easier way: Create a SSH CA, add that to your authorized_keys everywhere, use it to sign the individual public keys.

But now you need to worry about revocation or at least key lifetimes.

I would argue that doing both of those is still less work than maintaining authorized_keys in many places.

Re: Native Secure Enclave backed SSH keys on macOS

#143
post #49

Earlier quoted context omitted.

With an ssh agent and time-bounded key expiration one can have very strong password on the key that is convenient to use. Also password managers like 1password or Bitwarden support ssh-agent protocol so one can have a master password that protects both stored passwords and keys.

How short of a time-bound do you use on your SSH keys?

It is set to 15 minutes due to specifics of automation scripts that we use so they can run uninterrupted.

Re: Native Secure Enclave backed SSH keys on macOS

#144
post #101

Earlier quoted context omitted.

Check out `man sc_auth`. There's also an exportable variant where the private key is encrypted using the secure enclave as opposed to generated on the secure enclave: % sc_auth create-ctk-identity -l ssh-exportable -k p-256 -t bio % sc_auth list-ctk-identities p-256 A581E5404ED157C4C73FFDBDFC1339E0D873FCAE bio ssh-exportable ssh-exportable 23.11.26, 19:50 YES % sc_auth export-ctk-identity -h A581E5404ED157C4C73FFDBDF…

Is there a way to import an existing (compatible) key and still mark it as non-exportable? That seems more useful for the SSH key scenario: Generate a key in memory and back it up to offline storage once, and otherwise only use it in a way totally non-exportable by any malware. This sentence > The exportable private key is encrypted with Elliptic Curve Encryption Standard Variable IVX963 algorithm which is backed by…

No. There is no way to import an existing key into the Secure Enclave. Only Apple is allowed to do that.

The best you can do is use the SE to decrypt the key and then use the clear text key for encryption/decryption.

This also means that passkeys on macOS/iOS are (at some point) exposed as clear text.

Re: Native Secure Enclave backed SSH keys on macOS

#145

Earlier quoted context omitted.

Yeah, that is why you should not [always (depends on your use case)] generate it on a YubiKey. You need to have: - an offline master private key backup (air-gapped) - primary YubiKey (daily use) - backup YubiKey (locked away) - revocation certificate (separate storage) (it is your kill-switch) Having a second YubiKey enrolled is the standard practice. What people do wrong is: - They generate directly on YubiKey - The…

Do you have a good guide/video/write up on this? I’ve been putting off remaking my GPG and SSH keys using a Yubikey.

This guide [1] mostly follows the practices the previous poster outlined.

[1] https://github.com/drduh/YubiKey-Guide

Re: Native Secure Enclave backed SSH keys on macOS

#146

How can I get such a key into my iPhone too, so that I can sign emails and file and such with the same private key when I'm on my phone, and my public key is valid for all such operations ? Will iCloud take care of that ? And then I want it all usable from my (multiple) email clients...

This is for SSH, not GPG.

Re: Native Secure Enclave backed SSH keys on macOS

#147

Earlier quoted context omitted.

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.

There is an easier way, it's called TLS certificates, it's just that SSH decided not to use it for some reason. Other systems of this nature have figured out long ago that you should be able to have one personal certificate (stored securely in an airgapped environment), from which you'd generate leaf certificates for your devices every year.

ssh has supported signed certs for literal years

Re: Native Secure Enclave backed SSH keys on macOS

#148

Earlier quoted context omitted.

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…

Couldn’t any type of dialogue be faked? What are you suggesting is possible but not implemented?

Generally dialogs that require sensitive input provide some way for the user to ensure they are issued by the OS and not a random program. Windows historically used the Secure Attention Key (that's why domain-linked machines used to require pressing Ctrl+Alt+Del to login, to train users to only enter credentials in secure contexts) which is a key combo that the OS always intercepts and thus once pressed you can be assured you are typing into a trusted UI and not a piece of malware emulating the trusted UI.

Of course, this was back in the day when computers were primarily a productivity tool and not an ad delivery vehicle, so it's unlikely this problem will ever be solved.

Re: Native Secure Enclave backed SSH keys on macOS

#149
side note: It's interesting that the `sc_auth` CLI tool to create the SSH key, is just a bash script! It seems truly ancient, and has comments referencing mac OS Tiger (20+ years old) and non-existent files from old macOS. It calls out to '/System/Library/Frameworks/CryptoTokenKit.framework/ctkcard' (not on PATH) to actually create the ssh key.

Re: Native Secure Enclave backed SSH keys on macOS

#150

Earlier quoted context omitted.

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.

There is an easier way, it's called TLS certificates, it's just that SSH decided not to use it for some reason. Other systems of this nature have figured out long ago that you should be able to have one personal certificate (stored securely in an airgapped environment), from which you'd generate leaf certificates for your devices every year.

SSH CA is what you’re looking for. It’s a thing apparently (but I haven’t tried it yet).
Post reply on HN