Native Secure Enclave backed SSH keys on macOS

Post by newsoftheday » Sun, Nov 23, 2025, 6:52 PM UTC

Xylakant wrote: post #20

newsoftheday wrote: post #12

Earlier quoted context omitted.

> Who uses password encrypted keys anyway ? Edit: I'm not suggesting an ssh key with a passphrase (or password) is better than what the article suggests; I'm only saying that adding a passphrase (or password) to an ssh key at least buys time to address the situation while the attacker is trying to break the encryption on the stolen key. I am anti-Mac in every way, but I do use passphrase protected ssh keys so if some…

The parent means that an attacker has unlimited attempts at breaking the passphrase on an exfiltrated key. Once the key passphrase is broken, they can log in using the key.

Post by newsoftheday » Sun, Nov 23, 2025, 6:54 PM UTC

lloeki wrote: post #18

newsoftheday wrote: post #12

Earlier quoted context omitted.

> Who uses password encrypted keys anyway ? Edit: I'm not suggesting an ssh key with a passphrase (or password) is better than what the article suggests; I'm only saying that adding a passphrase (or password) to an ssh key at least buys time to address the situation while the attacker is trying to break the encryption on the stolen key. I am anti-Mac in every way, but I do use passphrase protected ssh keys so if some…

> whether the ssh service is configured to allow or deny passwords. Given the consistent use of "password" instead of "passphrase", I think they meant an exfil'ed encrypted key is vulnerable to no-rate-limit bruteforcing, in contrast with hardware-backed keys.

Post by arianvanp » Sun, Nov 23, 2025, 6:54 PM UTC

jedberg wrote: post #13

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 somet…

    % 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 A581E5404ED157C4C73FFDBDFC1339E0D873FCAE -f ssh-exportable.pem
    Enter a password which will be used to protect the exported items:
    Verify password:

    % sc_auth import-ctk-identities -f ssh-exportable.pem.p12 -t bio
    Enter PKCS12 file password:

Post by [deleted] » Sun, Nov 23, 2025, 6:56 PM UTC

jedberg wrote: post #13

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 somet…

Post by lloeki » Sun, Nov 23, 2025, 7:03 PM UTC

newsoftheday wrote: post #23

lloeki wrote: post #18

Earlier quoted context omitted.

> whether the ssh service is configured to allow or deny passwords. Given the consistent use of "password" instead of "passphrase", I think they meant an exfil'ed encrypted key is vulnerable to no-rate-limit bruteforcing, in contrast with hardware-backed keys.

Right, but my context is that devs often use no passsphrase at all. If someone can get a copy, they have instant access to whatever it has access to. They don't need to even break encryption since the key has none if none has been applied. My stance is simply, at least add a passphrase to the key (though some call it a password).