40 comments

[ 3.5 ms ] story [ 60.6 ms ] thread
It's a total pain in the ass to try to have password encrypted gpg or ssh keys in mac. Nothing better that another way to make it even more painful and complicated, so that people will just store plain text keys to not be annoyed.
It’s been easy since the 2000s. This makes it easier to be safer than the built in SSH agent + Keychain but pure usability was a solved problem around by the turn of the century.
Whoa, that is pretty cool.

I've been using Secretive for years, and prefer it to all the physical key/card based systems I've tried to get going over the years. I know exactly when my SSH key is used for any operation, because I need to hit a button or do a fingerprint scan. I can keep ssh-agent tunnels to remote boxes so that I can sign git commits remotely without having to worry about a rogue system getting complete access to key ops without me knowing what's going on.

However the Tahoe version of secretive is buggy and frequently locks up on initial key op requests. I don't have the bandwidth to debug it and file a bug report, and honesty I'm not sure I want to relearn all that knowledge of SSH to figure it out.

I think the smart card SSH UX is worse than secretive's, IIRC my past pain, but if it is reliable, worth a shot.

Awesome.

Won't be ditching Yubikeys just yet but I can see a number of use-cases for this already.

I’m a bit confused as to why you can export the keys. Can someone explain this?
If I understand correctly, this means you can't back up the private key, correct? It's in the Secure Enclave, so if you lose your laptop, you also lose the key? Since it looks like export only really exports the public key not the private one?

Probably not the worst thing, you most likely have another way to get into the remote machine, or an admin who can reset you, but still feels like a hole.

Or am I missing something?

ps. It amuses me that my Mac won't let me type Secure Enclave without automatically capitalizing it.

Edit: I understand good security is having multiple keys, I was simply asking if this one can be backed up. OP answered below and is updating their webpage accordingly.

> If I understand correctly, this means you can't back up the private key, correct? It's in the Secure Enclave, so if you lose your laptop, you also lose the key?

In a business environment, that's what you want. The key is then burned, and you ask your coworkers (who still have access) to remove the old key and store your new one on the servers.

I had being using krypton, with the private key being on my iPhone, and am now using secretive. Never had much of an issue with not having access to my private key. We made rolling out public keys to the servers very easy by using the gitlab key file. So when I get a new Macbook I'd just need to create a new key and upload it to gitlab. We have multiple devops that can run the playbook to roll it out to the servers. And if they have a new Macbook I roll it out for them. And we don't have that many Macbook upgrades anyway.
(comment deleted)
Oh, this is neat! I wonder if apple just added support for the secure enclave as a provider or if this might help fix the bad experience of yubikeys on the mac. Last time I tried it, the distributed ssh and ssh-agent didn't play well with security keys
Does anybody know if there is something similar for gpg keys? E.g. for commit signing?

That is, natively with the Secure Enclave, not exportable.

This is just so perfect. No longer a 3rd party glue and separate ssh agent is needed.
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...
Clearly I'm hazy on this stuff. But if I can export the private key from my Mac, is there any use for it on my iPhone, and any way to get it in there ?
Does anybody know why 'p-384-ne' (instead of 'p-256-ne') cannot be used?

Key can be generated, but 'ssh-keygen -w /usr/lib/ssh-keychain.dylib -K -N ""' cannot find the key to export.

Does the hardware only support the NIST curves? Or is that just the example that happens to be given?
Is there a way to make the lifetime of the key last more than a year?
The key itself appears to have no validity period, the validity period is only for the certificate made for the key. Maybe you could create a CSR for the key/identity and then sign it with your own CA (or self-sign with openssl) for whatever validity period you like. Then `sc_auth import-ctk-certificate`.
Why would you want the private key file if you store it within the secure enclave?
If you're willing to go a bit further you can also do GPG signing with ECDSA, though it requires a patched GPG due to bugs and a patched SSH agent that allows raw signing. We have a packaged version with a macOS UI [0], but the same backend [1] works on Linux using the tpm via PKCS#11.

We have a blog post on this, but I guess it was never made public, but the only difference between GPG and SSH is the way in which keys and signatures are wrapped and listed through the various layers -- it's all just fundamentally ECDSA with a named curve.

[0] https://github.com/KeetaNetwork/agent

[1] https://github.com/KeetaNetwork/agent/tree/main/Agent/gnupg/...

Its worth noting that this is the likely NSA backdoored curve under the hood and probably should not be used.
This may be the thing to get me to upgrade to MacOS 26.
It’s not new to Tahoe. I use it on Sequoia.
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.
The command is available on Sequoia too!