- Dans la version Tahoe de macOS, la création et l’utilisation de clés SSH via Secure Enclave sont prises en charge nativement
- La bibliothèque
/usr/lib/ssh-keychain.dylib implémente l’interface SecurityKeyProvider en plus du PKCS11Provider existant pour les smart cards, ce qui permet de communiquer directement avec Secure Enclave au lieu d’un périphérique FIDO2
- Avec la commande
sc_auth, il est possible de créer des clés avec authentification biométrique via Touch ID et, via ssh-keygen ou ssh-add, de charger et utiliser directement les clés depuis la zone sécurisée
- En définissant la variable d’environnement
SSH_SK_PROVIDER dans .zprofile, SSH, ssh-agent et ssh-keygen la reconnaissent automatiquement
- Il est possible de mettre en place une architecture d’authentification SSH alliant sécurité et simplicité en n’utilisant que les fonctions natives de macOS, sans outil externe
Aperçu de la prise en charge des clés SSH basées sur Secure Enclave
- macOS Tahoe prend en charge la création et l’utilisation de clés SSH basées sur Secure Enclave
- Auparavant, un projet externe comme
secretive était nécessaire, mais les fonctions natives de macOS peuvent désormais le remplacer
/usr/lib/ssh-keychain.dylib implémente SecurityKeyProvider, ce qui permet d’accéder à Secure Enclave d’une manière similaire à un périphérique FIDO2- Cette fonctionnalité permet d’effectuer une authentification SSH avec la puce de sécurité intégrée à macOS, sans matériel externe comme une YubiKey
Création et gestion des clés
- La commande
sc_auth create-ctk-identity -l ssh -k p-256-ne -t bio permet de créer une clé Secure Enclave nécessitant une authentification Touch ID
- La commande
list-ctk-identities permet de vérifier la liste des clés créées et leurs hachages
- La commande
delete-ctk-identity permet de supprimer une clé
- L’option
list-ctk-identities -t ssh permet de vérifier l’empreinte de clé SSH (fingerprint)
Utilisation dans SSH
- La commande
ssh-keygen -w /usr/lib/ssh-keychain.dylib -K -N "" permet de charger une paire de clés depuis Secure Enclave
- Aucune saisie de PIN n’est requise, l’authentification se fait via Touch ID
- La “private key” générée n’est pas la véritable clé secrète, mais une valeur de référence d’identifiant FIDO
- Après avoir copié la clé publique sur le serveur avec
ssh-copy-id,
la connexion est possible avec la commande ssh -o SecurityKeyProvider=/usr/lib/ssh-keychain.dylib localhost
Intégration avec ssh-agent
- La commande
ssh-add -K -S /usr/lib/ssh-keychain.dylib permet d’enregistrer directement une clé Secure Enclave dans ssh-agent
- Les clés enregistrées peuvent être vérifiées avec
ssh-add -L
- L’authentification peut ensuite être effectuée avec la commande
ssh -o SecurityKeyProvider=/usr/lib/ssh-keychain.dylib
Configuration par défaut de SecurityKeyProvider
- Il est possible de le définir directement dans
.ssh/config ou d’ajouter dans .zprofile
export SSH_SK_PROVIDER=/usr/lib/ssh-keychain.dylib pour une détection automatique
- Ensuite, une connexion SSH basée sur une clé de sécurité est possible simplement avec les commandes
ssh-add -K ou ssh my-server
Clés exportables (Exportable Keys)
- La commande
sc_auth create-ctk-identity -l ssh-exportable -k p-256 -t bio permet de créer une clé exportable chiffrée par Secure Enclave
- Elle peut être exportée en fichier PEM avec
export-ctk-identity, puis réenregistrée sur un autre appareil avec import-ctk-identities
- Cette approche est un peu moins sûre, mais plus pratique pour les sauvegardes
Discussion entre développeurs et extension du code
- Dans les commentaires, la possibilité d’utiliser le drapeau
.biometryCurrentSet est évoquée
- Actuellement, seul l’usage ou non de l’authentification biométrique (on/off) est pris en charge, sans contrôle plus fin
- L’auteur a procédé à de la rétro-ingénierie (reverse engineering) de
ssh-keychain.dylib pour étudier la possibilité d’ajouter une fonctionnalité biometryCurrentSet à la fonction sk_enroll()
- L’exemple de code proposé nécessite une signature de code (codesign) avec un compte Apple Developer Program pour pouvoir accéder à Secure Enclave
- Le code inclut la logique de création de clé, signature et enregistrement (
sk_enroll, sk_sign, etc.),
et implémente le processus de génération et de signature d’une clé ECDSA P-256 dans Secure Enclave
Résumé
- macOS prend désormais en charge nativement une authentification SSH utilisant directement Secure Enclave
- L’authentification biométrique via Touch ID et une architecture compatible FIDO2 améliorent à la fois la sécurité et la simplicité d’usage
- Il est possible de gérer les clés SSH uniquement avec les fonctions intégrées du système, sans matériel externe ni logiciel supplémentaire
- Les développeurs expérimentent l’extension de
ssh-keychain.dylib pour obtenir un contrôle biométrique plus fin
1 commentaires
Avis Hacker News
Si j’ai bien compris, cela signifie qu’il est impossible de sauvegarder la clé privée
Comme elle est stockée dans le Secure Enclave, si vous perdez votre ordinateur portable, la clé disparaît aussi
Il semble qu’on ne puisse exporter que la clé publique. Bien sûr, il existe peut-être d’autres approches ou une réinitialisation administrateur, mais cela reste un peu inquiétant
Plus tard, l’OP a indiqué qu’il répondrait et mettrait à jour la page web
man sc_auth. Au lieu de générer directement dans le Secure Enclave, on peut créer une clé exportable chiffréeAvec une commande d’exemple comme
sc_auth create-ctk-identity -l ssh-exportable -k p-256 -t bio, puis ensuiteexport-ctk-identitypermet de créer un fichier.pemOn peut le réimporter sur un autre appareil avec
import-ctk-identities. Cela sera ajouté au guideLe principe central de la PKI est de ne déplacer que la clé publique, tandis que la clé privée doit n’exister qu’à un seul endroit
Ainsi, la clé n’est exposée en aucune circonstance
Une clé privée générée sur une YubiKey ne peut pas non plus être sauvegardée
L’idéal est d’en avoir une par appareil, afin qu’aucun problème ne survienne en cas de perte ou de vol
Je garde une YubiKey protégée par PIN dans un coffre. Ainsi, même si mon ordinateur portable, mon téléphone et ma YubiKey du quotidien disparaissent tous, je suis couvert
En allant un peu plus loin, les signatures GPG basées sur ECDSA sont également possibles
En revanche, à cause d’un bug, il faut un GPG patché et un agent SSH
Il existe une version packagée avec une UI pour macOS (KeetaNetwork/agent),
et le même backend fonctionne aussi sous Linux avec un TPM via PKCS#11
La différence entre GPG et SSH tient seulement à la manière d’encapsuler la clé et la signature ; fondamentalement, tout repose sur ECDSA
Secretive est plus simple à configurer, mais je pense passer à cette méthode pour supprimer une application
J’ai détaillé sur mon blog comment configurer des clés SSH adossées à un TPM sous Windows 11
C’est une fonctionnalité assez sympa
J’utilise Secretive depuis longtemps, et je l’ai trouvé bien plus pratique qu’une clé physique ou une carte
À chaque utilisation de la clé SSH, il faut appuyer sur un bouton ou utiliser l’empreinte digitale, ce qui permet de savoir clairement quand elle est utilisée
On peut conserver un tunnel ssh-agent et signer des commits git en toute sécurité même sur un serveur distant
En revanche, la version Tahoe a beaucoup de bugs et se fige souvent. Je n’ai pas le temps de la déboguer, donc je la laisse telle quelle
L’UX SSH basée sur Smart Card m’a déjà causé bien des soucis, mais si c’est stable, cela vaut le coup d’essayer
Via
ssh-askpass, il est possible de demander une confirmation à chaque utilisation d’une clé privée. En revanche, cela ne distingue pas le local du distantIl faut faire attention, car cette méthode utilise une courbe soupçonnée d’avoir une porte dérobée par la NSA
Je me demande pourquoi il faut un fichier de clé privée si elle est stockée dans le Secure Enclave
skd’OpenSSH. Même avec l’option « resident key », un fichier de clé privée reste nécessaireIl ne s’agit en réalité que d’une référence vers un identifiant FIDO et il ne contient pas les véritables données secrètes de la clé
Dans le cas des clés
sknon résidentes, ce fichier est nécessaire parce que l’authentificateur matériel ne stocke pas d’étatJe ne sais pas avec certitude si l’implémentation de macOS est à état persistant ou non ; il est possible qu’elle casse lors d’une réinstallation de l’OS
Il existe un projet appelé facebookincubator/sks
C’est une bibliothèque golang qui abstrait diverses clés SSH matérielles et prend en charge Linux, Windows et macOS
C’est pourquoi j’avais commencé à créer moi-même ssh-tpm-agent il y a quelque temps
J’aimerais aussi signer des e-mails ou des fichiers sur iPhone avec la même clé privée
Je me demande si iCloud pourrait s’en charger
En revanche, les passkeys le sont. Il faudrait créer un nouveau SecurityKeyProvider qui communique avec l’API Passkey
Les passkeys sont liées à un bundle ID d’application spécifique ou à un domaine
Par exemple, si Secretive prenait en charge les passkeys, cette paire de clés ne pourrait pas être utilisée dans d’autres applications, mais
elle serait synchronisée entre plusieurs appareils pour cette même application
Il est temps d’ajouter une nouvelle fonctionnalité à KeyMux
Cet outil prend en charge des clés enclave pour SSH, SSL et PGP,
et permet par exemple d’accéder à un serveur Vault avec un certificat SSL basé sur le Secure Enclave afin d’effectuer une authentification SSH avec une clé privée Vault non exportable
À voir sur keymux.com et via le lien App Store