Présentation de la solution native

Depuis macOS Sequoia (et Tahoe), le système d’exploitation intègre la prise en charge d’identités SSH stockées dans le Secure Enclave, un sous‑système matériel isolé du processeur principal. La clé privée est générée à l’intérieur du puce et reste non exportable ; chaque opération de signature nécessite une authentification biométrique (Touch ID). Cette approche élimine le stockage de la clé dans ~/.ssh/ et empêche tout script malveillant d’en extraire le secret, même en cas de compromission du système de fichiers.

Processus de création et de configuration

La première étape consiste à créer l’identité avec sc_auth, outil du framework CryptoTokenKit :

sc_auth create-ctk-identity -l "ssh-MacBook" -k p-256-ne -t bio

Le paramètre -k p-256-ne indique l’utilisation de la courbe NIST P‑256 en mode non‑exportable, tandis que -t bio impose Touch ID à chaque utilisation. En cas d’erreur -25293 (« Failed to generate keypair »), il faut ré‑enregistrer l’empreinte digitale dans les préférences système.

Après vérification avec sc_auth list-ctk-identities, on exporte un « key handle » que SSH consomme :

ssh-keygen -w /usr/lib/ssh-keychain.dylib -K -N ""

Le drapeau -w indique la bibliothèque ssh-keychain.dylib qui redirige les appels de signature vers le Secure Enclave. Le fichier id_ecdsa_sk_rk ainsi créé doit être déplacé dans ~/.ssh/ puis déclaré via la variable d’environnement :

export SSH_SK_PROVIDER=/usr/lib/ssh-keychain.dylib

Les anciennes options -K et -A de ssh-add sont obsolètes ; elles ciblent le trousseau macOS, pas CryptoTokenKit.

Intégration dans le client SSH

SSH ne recherche pas automatiquement les fichiers nommés id_ecdsa_sk_rk. Il faut donc les référencer explicitement dans ~/.ssh/config :

Host *
    IdentityFile ~/.ssh/id_ecdsa_sk_rk
    IdentityFile ~/.ssh/id_rsa
    IdentityFile ~/.ssh/id_ed25519

Placer le Secure Enclave en première position garantit son utilisation par défaut. Un conflit possible survient avec des agents externes (ex. : 1Password) qui doivent être désactivés pendant les tests.

Analyse de la sécurité et des limites

Le principal avantage réside dans le caractère « hardware‑backed » : la clé ne quitte jamais le Secure Enclave, rendant impossible son exfiltration même si le système d’exploitation est compromis. La contrainte biométrique empêche les malwares d’utiliser la clé sans interaction utilisateur.

En contrepartie, l’expérience utilisateur reste brute : le dialogue « ctccardtoken needs to authenticate to continue » provient d’une API bas‑niveau non personnalisée pour SSH. De plus, la compatibilité est limitée aux versions macOS récentes (Sequoia/Tahoe) et aux clés ECDSA P‑256 ; les algorithmes plus récents comme Ed25519 ne sont pas supportés nativement. Enfin, la configuration requiert plusieurs variables d’environnement et modifications de ssh_config, ce qui complique le déploiement automatisé.

Des alternatives comme Secretive (interface graphique) ou les YubiKey 5C (FIDO2) offrent une ergonomie supérieure, mais introduisent un composant matériel supplémentaire. Les gestionnaires de mots de passe (1Password, Bitwarden) restent des solutions logicielles : les clés sont chiffrées au repos mais déchiffrées en mémoire, ce qui ne satisfait pas le critère d’impossibilité d’extraction.

En résumé, le Secure Enclave de macOS fournit une protection robuste contre le vol de clés SSH, à condition d’accepter une interface utilisateur peu raffinée et de gérer manuellement les paramètres de découverte de clés.