Data Protection API
Cet article présente des problèmes à corriger.
Vous pouvez aider à l'améliorer ou bien discuter des problèmes sur sa page de discussion.
- Il ne cite pas suffisamment ses sources. Vous pouvez indiquer les passages à sourcer avec {{référence nécessaire}} ou {{Référence souhaitée}}, et inclure les références utiles en les liant aux notes de bas de page. (Marqué depuis septembre 2024)
- Il est orphelin : moins de trois articles lui sont liés. Aidez à ajouter des liens en plaçant le code
[[Data Protection API]]dans les articles relatifs au sujet. (Marqué depuis octobre 2022)
Le Data Protection Application Programming Interface (DPAPI) est une interface de programmation (API) cryptographique disponible sur les systèmes d'exploitation Windows 2000 et suivants. Son fonctionnement est décrit dans une publication d'Élie Bursztein (en) de 2011[1].
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
Dans un premier temps, l'API génère 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éfini 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é principale chiffrée dans le répertoire AppData de l'utilisateur sous la forme d'un fichier MKF (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é dans le répertoire AppData de l'utilisateur. Son contenu n'est qu'une suite d'octets parmi lesquels on retrouve de manière claire, sans chiffrement, le GUID du fichier Master Key File qui lui est lié.
Fontionnement
Sauvegarde des identifiants dans un domaine Active Directory
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 stocke 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 envoie 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 renvoie au client.
Risque de compromission irréversible
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 (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
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 mots de passe de l'utilisateur, sera récupéré afin de déchiffrer 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.
Notes et références
- ↑ (en) Elie Bursztein et Jean-Michel Picod, « Recovering windows secrets and efs certificates offline », Workshop On Offensive Technologies (WOOT) - 2010, (lire en ligne, consulté le ).
Liens externes
- « Windows Data Protection », sur Microsoft Learn (consulté le ).
- « Le fonctionnement de DPAPI », sur Lestutosdeprocessus.fr (consulté le ).
Content Disclaimer
Informasi ini disarikan dari Wikipedia dan disajikan kembali untuk tujuan edukasi. Konten tersedia di bawah lisensi CC BY-SA 3.0. Kami tidak bertanggung jawab atas ketidakakuratan data yang bersumber dari kontribusi publik tersebut.
- The information displayed on this website is sourced in part or in whole from Wikipedia and has been adapted for the purpose of restating it. We strive to provide accurate and relevant information, however:
- There is no guarantee of absolute accuracy. Wikipedia is an open, collaborative project that can be edited by anyone, so information is subject to change.
- It is not intended to constitute professional advice. The content displayed is for informational and educational purposes only. For important decisions (e.g., medical, legal, or financial), please consult a professional.
- Content copyright. Wikipedia is licensed under the Creative Commons Attribution-ShareAlike License (CC BY-SA). This means that content may be reused with appropriate attribution and shared under a similar license.
- Responsible use. Any risk arising from the use of information from this website is entirely the responsibility of the user.