Contexte et évolution du login keychain

Jusqu’à macOS Monterey, le fichier login.keychain-db était un simple conteneur chiffré que l’on pouvait copier d’un Mac à l’autre. Depuis macOS Tahoe, Apple le stocke sous forme de base de données SQLite dans /Users/nom_utilisateur/Library/Keychains et modifie son schéma de protection. Le mot‑de‑passe de l’utilisateur reste la clé d’accès principale, mais il n’est plus suffisant pour déchiffrer le contenu lorsque le Mac possède un Secure Enclave.

Mécanisme de chiffrement lié au Secure Enclave

Apple utilise deux clés AES‑256‑GCM distinctes : une metadata key pour les attributs (hors kSecValue) et une secret key pour les valeurs réelles (kSecValueData). La metadata key est protégée par le Secure Enclave et mise en cache dans le processeur d’application afin d’accélérer les requêtes. En revanche, la secret key nécessite à chaque fois un aller‑retour cryptographique vers le Secure Enclave. Cette architecture crée une dépendance matérielle : les clés dérivées sont liées à l’ID unique du Secure Enclave du Mac d’origine.

Test de copie entre Apple Silicon et machine virtuelle

Le test décrit a suivi 12 étapes : création d’un compte username sur un Mac Apple Silicon, extraction du fichier login.keychain-db, puis remplacement du même fichier sur une VM macOS dépourvue de Secure Enclave. Après redémarrage, la connexion a généré un nouveau login.keychain-db au lieu d’utiliser celui copié. Les journaux système, obtenus avec la commande log show --predicate 'eventMessage contains "Keychain"', indiquent que l’opération d’unlock a reçu le bon mot‑de‑passe mais a échoué parce que la secret key n’était pas disponible. Le fichier copié a été renommé login_renamed_1.keychain-db, preuve que macOS a abandonné le fichier importé et en a créé un nouveau.

Implications et limites

Le résultat confirme que le Secure Enclave agit comme un facteur d’enracinement matériel : même si l’attaquant possède le mot‑de‑passe, il ne peut pas récupérer les clés de déchiffrement sans le même enclave. Cette contrainte renforce la protection contre le vol de fichiers de trousseau, mais elle complique les scénarios légitimes de migration de profils utilisateur entre machines équipées de Secure Enclave. Apple ne fournit pas de mécanisme de « export » du trousseau lié à l’enclave, ce qui laisse les administrateurs système sans solution automatisée. En l’absence de documentation supplémentaire, la seule voie de contournement reste la création d’un nouveau trousseau et la réimportation manuelle des éléments, processus qui peut entraîner la perte de mots‑de‑passe stockés ou de certificats non exportables.