Data Protection API
Cet article ne cite aucune source et peut contenir des informations erronées (signalé en octobre 2022).
Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ».
La mise en forme de cet article est à améliorer ().
La mise en forme du texte ne suit pas les recommandations de Wikipédia : il faut le « wikifier ».
Cet article est orphelin. Moins de trois articles lui sont liés ().
Vous pouvez aider en ajoutant des liens vers [[Data Protection API]] dans les articles relatifs au sujet.
Sous Windows, le gestionnaire d'identification permet de sauvegarder des identifiants de connexion à une cible définie.
Ces identifiants peuvent par exemple concerner une connexion à un partage de fichiers (SMB) ou à une connexion Bureau à distance (RDP).
Afin de garantir la sécurité des identifiants enregistrés, ces derniers sont chiffrés grâce à une API appelée Data Protection, via la fonction "CryptProtectData".
Cette API établit un tunnel RPC local chiffré pour se connecter au processus LSASS et utilise ensuite les fonctions de la librairie CryptAPI en utilisant le fichier Crypt32.dll. Les fonctions s'exécutent donc dans le contexte de sécurité de LSA.
Principe de chiffrement des secrets[modifier | modifier le code]
Dans un premier temps, l'API va générer une clé principale, appelée "Master Key". Cette clé est une sorte de gros mot de passe de 512 octets de données aléatoires. Cette clé n'est pas utilisée explicitement pour protéger les données. Au lieu de cela, une clé de session symétrique est calculée en fonction de la clé principale.
Pour protéger cette clé principale, le hash SHA-1 du mot de passe de l'utilisateur est utilisé. 16 octets aléatoires sont utilisés pour générer un grain de sel unique (appelé "IV") ainsi qu'un nombre aléatoire d'itérations. La fonction PBKDF2 (Password-Based Key Derivation Function 2.0) est utilisée avec autant d'itérations que définit précédemment, selon la norme cryptographique PKCS#5, pour obtenir une clé de chiffrement.
La clé de chiffrement est ensuite utilisée pour chiffrer la clé principale de manière symétrique grâce à un algorithme 3DES. Le grain de sel et le nombre d'itérations sont conservés de manière claire, sans chiffrement, et ensuite stockés avec la clé de chiffrement dans le répertoire AppData de l'utilisateur sous la forme d'un fichier MKF, pour "Master Key File", nommé par un GUID unique.
La clé principale de 512 octets précédemment générée est hashée via l'algorithme SHA-1, puis son hash est utilisé pour créer une clé de session symétrique via l'algorithme HMAC-SHA512. La clé de session permet de chiffrer les identifiants de l'utilisateur dans un fichier "blob" grâce à l'algorithme de chiffrement symétrique AES256.
Le fichier "blob", qui contient les informations d'identification chiffrées de l'utilisateur, est également stockée dans le répertoire AppData de l'utilisateur. Son contenu n'est qu'une suite de bytes parmi lesquels on retrouve de manière claire, sans chiffrement, le GUID du fichier Master Key File qui lui est lié.
Sauvegarde des identifiants dans un domaine Active Directory[modifier | modifier le code]
Lorsqu'un ordinateur est membre d'un domaine, DPAPI dispose d'un mécanisme de sauvegarde pour permettre la déprotection des données en cas de perte du mot de passe de l'utilisateur (appelé "Credential Roaming"). Lors de l'installation d'un nouveau domaine sur un contrôleur de domaine, une paire de clés publique et privée est générée, associée à DPAPI.
Lorsqu'une clé principale est générée sur un poste client, ce dernier communique via un appel RPC authentifié avec un contrôleur de domaine pour récupérer une copie de la clé publique du domaine. Le client chiffre la clé principale avec la clé publique du contrôleur de domaine. Enfin, il stock cette nouvelle clé principale de secours dans son répertoire AppData, comme dans le cas d'un stockage de clé principale traditionnel.
Si le déchiffrement de la clé principale ne peut pas s'effectuer via le hash du mot de passe de l'utilisateur, le client envoi la clé principale de secours à un contrôleur de domaine via un appel RPC authentifié. Le contrôleur de domaine peut déchiffrer la clé principale à l'aide de sa clé privée et la renvoi au client.
Risque de compromission irréversible[modifier | modifier le code]
Avec un compte Administrateur du domaine, il est possible d'extraire manuellement la clé privée du contrôleur de domaine via un appel RPC authentifié, sous la forme d'un fichier "PVK", pour "Private Key File", afin de déchiffrer des fichiers Master Key File d'un poste client de manière hors ligne.
Un attaquant pourrait donc, avec des accès privilégiés, récupérer cette clé privée pour déchiffrer les secrets de tous les utilisateurs du domaine.
Pour l'instant, la paire de clés générée lors de l'installation d'un domaine Active Directory ne peut pas être renouvelée. Cela signifie qu'en cas de compromission, seule la reconstruction d'un nouveau domaine peut garantir la sécurité du domaine.
Changement de mot de passe d'un utilisateur[modifier | modifier le code]
Dans le cas d'un changement de mot de passe d'un utilisateur, les fichiers Master Key File ne sont pas rechiffrés avec le nouveau hash du mot de passe automatiquement. Lors de la tentative de déchiffrement de la clé principale, si le hash SHA-1 du mot de passe de l'utilisateur n'est pas utilisable, le contenu du fichier CREDHIST, qui contient les hashs au format NT et au format SHA-1 des anciens mot de passe de l'utilisateur, sera récupéré afin de déchiffré le fichier Master Key File avec l'ancien mot de passe. La clé principale sera ensuite à nouveau chiffrée avec le nouveau mot de passe de l'utilisateur.
