Secretive – macOS native app to store SSH keys in the Secure Enclave

After researching this for a while, it seems there is no documented, native option to do this. The only option is to unlock all SSH keys all the time, which makes them less secure than the passwords for websites managed by the exact same keychain. Which, in my opinion, is weird.

Do they employees at Apple use a different system altogether? Because the built-in one doesn't seem very secure. Or maybe I am using it wrong, who knows.

In a similar vein, is there an exhaustive manual for macOS? It bugs me that Apple machines cost a small fortune, the OS is full of nifty features, but there is no non-superficial manual shipped with it.

To be clear, that would be a privacy issue (a malicious server could tell what keys you have), but wouldn't allow a malicious server to log in to anything else with your keys. You don't send the private key when you log in.

My general understanding is that -A is generally discouraged in the first place: especially when connecting to an untrusted server. But, it just seems to me to be a bad idea to ever let a private key leave your computer. Instead, you should generate a key on the new box and authorize that one somehow (the lowest friction way would be to use an ssh ca to sign the key and then have the servers you want to log into trust only public keys that have been signed by the CA’s key.

> random server

use this:

    Host *
      IdentitiesOnly yes

1. with pubkeyauthentication, you don’t send your private key. Your public key, which is stored on the server, is used to encrypt something. You prove you have the corresponding private key by sending back a decrypted version of the something. Attempting to log in to a server, whether they have zero or more of your public keys poses no risk.

2. You can control which private keys are used for which remote server using .ssh/config. You can look up the man page for more.

3. There is a risk of using ssh-sgent key forwarding that while you are connected to a server with key forwarding turned on, a super user sudo to your user and log in to a second host. This risk can be minimized by only enabling key agent forwarding to hosts you trust and limiting the keys available to each host.

Edit: Maybe OpenSSH does offer resident keys. On the one hand their release notes say they do but on the other hand I was 100% sure somebody who should know insisted they didn't. A trawl of my records cannot find such a communication so perhaps I dreamt it. If resident keys are an option then you need to make sure to buy FIDO2 authenticators and to explicitly tell OpenSSH you want resident keys.

The current SSH FIDO behaviour doesn't do resident keys AFAIK. The OpenSSH team has discussed it, but not as I understand it written an implementation.

In a PIV setup Jim, Sarah and Gary can each have a device (say a Yubikey) with their own private key inside it. Both their workstations and shared desktop/ interactive servers can use these keys, when they're plugged in. So when Jim is sat at this workstation, Jim's key uses Jim's private key to authenticate Jim over SSH. If Sarah wants to use a machine she's never previously used, but it was set up for Jim and Gary, her key, Sarah's key, just works to authenticate as Sarah over SSH. Simple and easy to think about.

With FIDO non-resident keys a similar team Beth, Larry and Zoe have personal FIDO authenticators, let's say from Titan, they each set up their personal laptop to require their personal FIDO authenticator. Both elements are needed to authenticate. Beth's laptop, plus Beth's Titan key is enough to authenticate via SSH. But if Beth is at a Workstation she's never used before she can't use her Titan key to authenticate, it has no idea how to help on its own. If Beth sets that workstation up (a multi-step process) this isn't re-usable, Zoe can't use her Titan key without also going through that enrolment process.

The reason why is a mixture of differences between typical Web authentication journeys and SSH, and the deliberate (privacy preserving) feature paucity of FIDO Security Keys when used without resident keys.

The FIDO authenticator genuinely has no idea what your private key is (this is unlike for resident keys like Apple's recent announcement). It first needs to be presented with an ID, a large random-looking byte string. It has in fact encrypted your private key using AEAD mode with a secret symmetric key that's baked inside it and then used that as the ID. So when the ID comes back it decrypts it, the AEAD checks out, it now has a private key and can use that to authenticate you before it forgets it again.

On the Web in this case (again not the resident case like Apple's cool Safari feature) the ID is being delivered by a remote server to your web browser when you enter a username and the browser passes it to the FIDO authenticator. But in SSH authentication doesn't work that way.

So, OpenSSH stores the ID locally on a computer. It isn't secret, so it's not a huge deal if someone somehow steals it. But without that ID the authenticator can't do its job.

Maybe you could arrange to synchronise the IDs across machines in an organisation. But AFAIK nothing exists to sort that out today. So without either resident credentials (which need a more expensive FIDO2 authenticator) or some further synchronisation framework PIV is easier today if you want employees to authenticate from machines that aren't "their" personal machine.

Indeed, PGP smartcards should work too, as should cards using the open-source ISOApplet.

I also played around with tpm2-pkcs11 last year and it worked nicely, and has support on a lot of devices like the XPS (which works really well on Linux!)

Your idea for using TPM as host verification makes a lot of sense to me - as it stands right now, I'm playing around with this for a side project right now, and a TPM-backed key which is bound to the right PCRs should give you assurance secure boot is enabled, with your own custom keys, and that it loaded your signed Grub, booting your signed kernel.

Got all the secure boot stuff working, now need to figure out what to use the TPM for - options are remote attestation, where server verifies the attestation signature (but this wouldn't be particularly standardised), network level authentication (actually easier - IIRC NetworkManager supports 802.1x authentication using PKCS11, so you can use tpm2-pkcs11 for that), or disk encryption.

Assuming you mean for the remote-end host key, and assuming your server has a TPM available, I reckon that could be quite interesting, but it doesn't look like openssh supports using PKCS11 for HostKey access. Would need to see if the key is used often, or if it's just used to establish connections (since PKCS11 crypto is usually pretty slow, but fine for one-off authentications).

As a closing note for time-travellers from the future etc, worth remembering TPM is far from perfect, and there's quite a few nice attacks if you can "sniff" the serial lines from the motherboard to the TPM itself. And if using the fTPM (firmware TPM), the regular Intel SGX/TXE holes will likely compromise the TPM security properties.

Ya problem is it’s all NIST “approved” and US companies love that because it means the government is happy to use their products.

This is not what it does though. It says the private key can't be exported, and this wouldn't be the case if it was just a regular SSH keyfile encrypted using the Enclave's key.

Unwrapping it puts the private key into memory, from which it can be extracted (it’s hard, of course, but looking at the state of Intel security, everything is possible). Secure Enclave is supposed to sign with non-extractable private key without putting it into RAM.

I know! But I wanted to write something very clear, and I chose the clearest word in my mind to convey my idea. That word is steeped in old tech, it so happens.

Oh and by the way, I was shopping for a cheap laptop for a non-profit this week, and I still had to be careful to pick a laptop with an SSD. Those spinning horrors are still jammed into laptop cases to this day.

I wonder what a better term for disk storage would be. Block storage, in the way that cloud services refer to it? Just plain "storage"?

That's how language works. We call people "engineers" who have never and will never work on any engines.

Many words are like this. Music albums haven’t been actual albums for decades. Now we barely remember how a collection of songs was distributed as multiple shellac 78 RPM records stored in an album.

Oh cool didn't not know that. That’s awesome.

Thankfully (i believe) everything that goes into it is open source https://github.com/kryptco

Ouch! I am a happy user too. But Akamai is all about the enterprise, it seems, and most likely don't care about us common folks. We can only hope that they will allow the former kryptco developers to spend time maintaining it, if it becomes necessary.

So, a non-portable YubiKey?

You are supposed, yes, but it is not necessary with Yubikeys. You can still import private keys into your Yubikey. At work we are using this for group access to some appliances that annoyingly limit the number of SSH authorized keys you can teach them.

Is there a convenient way to manage and maintain those keys? Keeping the public key of each device and easily select which ones to place on servers.

By "you just use multiple", you mean I would have to generate extra private keys, add them to authorized_keys, and store them somewhere other than my mac, right?

Because just by using multiple keys I would still be locked out if all of them were stored in this 'Secretive' app.

"now" is at least 16 years now (with PKCS11 and opensc)

Thanks.

Intentional hyperbole to sling blog spam. That link is to a site the OP claims in profile.

Thanks, that reminded me of upcoming iOS 14 support for WebAuth/FIDO. Perhaps that can be extended to SSH auth.

Note that they were bought by Akamai last year. I wouldn't count on the Krypton apps staying around, at least not in their current incarnation. A fork could survive, though.