Mise en place rapide

Le processus débute par la création d’une identité non‑extractable dans le Secure Enclave à l’aide de 

sc_auth create-ctk-identity -l ssh-key -k p-256-ne -t bio
. L’option -k p-256-ne indique l’utilisation de la courbe elliptique P‑256 avec le suffixe -ne (Non‑Extractable) qui empêche toute exportation de la clé privée. Le paramètre -t bio lie l’accès à l’authentification biométrique, ici Touch ID. Une fois l’identité créée, l’utilisateur exécute 
ssh-add -K -S /usr/lib/ssh-keychain.dylib
pour enregistrer la clé auprès de l’agent SSH. Le flag -K active le support des authentificateurs de type FIDO, tandis que -S indique le chemin de la bibliothèque de traduction ssh-keychain.dylib. Après redémarrage, la même commande doit être relancée car l’agent ne conserve pas la référence en mémoire.

Pour récupérer la partie publique à ajouter sur un serveur (par ex. GitHub), on lance 

ssh-add -L
. La sortie commence typiquement par sk-ecdsa-sha2-nistp256..., qui constitue le handle partageable de l’identité Secure Enclave.

Fonctionnement du Secure Enclave

Le Secure Enclave est un coprocesseur isolé dédié au stockage de secrets cryptographiques. Lors de la création d’une identité, sc_auth génère d’abord de l’entropie interne, puis dérive une clé privée liée à la courbe P‑256. Le suffixe -ne garantit que la clé reste confinée dans le module matériel ; aucune opération d’exportation n’est possible, même pour le système d’exploitation. La protection bio ajoute une contrainte d’accès : chaque utilisation déclenche une requête Touch ID, ce qui oblige l’utilisateur à valider physiquement l’opération. Cette double barrière (non‑extraction + biométrie) élimine le risque de vol de la clé via le système de fichiers ou un malware capable de lire ~/.ssh/id_*.

Intégration avec le client SSH

OpenSSH ne comprend pas nativement les identités stockées dans le Secure Enclave. La bibliothèque ssh-keychain.dylib, fournie par Apple, agit comme un adaptateur : elle expose une interface compatible FIDO2 que l’agent SSH peut charger via -S. Lorsqu’une connexion SSH est initiée, l’agent interroge la bibliothèque, qui transmet la requête de signature au Secure Enclave. Le module effectue alors la signature à l’intérieur du hardware et renvoie le résultat, sans jamais révéler la clé privée. Le serveur distant reçoit une signature conforme au format sk-ecdsa-sha2-nistp256, reconnu par OpenSSH comme une clé de type « security key ». Ainsi, la chaîne d’authentification repose entièrement sur le matériel et sur la validation biométrique.

Limites et considérations pratiques

Le principal inconvénient réside dans la perte de l’identité en cas de défaillance du Mac : la clé étant liée physiquement au Secure Enclave, elle disparaît avec le matériel. Il faut alors recréer une identité et mettre à jour tous les serveurs qui utilisent la clé publique précédente. De plus, la prise en charge de la courbe P‑384 n’est pas disponible dans OpenSSH, ce qui contraint le choix à P‑256‑ne. Enfin, la configuration nécessite de relancer ssh-add -K -S … après chaque redémarrage, car l’agent ne persiste pas les références en mémoire. Malgré ces contraintes, la solution offre une protection supérieure aux clés privées stockées sur disque, notamment contre les attaques de type « steal‑private‑key ».