Architecture et mise en œuvre du chiffrement de fichiers EFS

Présentation au sujet: "Architecture et mise en œuvre du chiffrement de fichiers EFS"— Transcription de la présentation:

1 Architecture et mise en œuvre du chiffrement de fichiers EFS
Jean-Yves Poublan Consultant Principal Microsoft

2 Agenda Rappel du fonctionnel Architecture
Mise en œuvre/meilleures pratiques

3 Point sur le fonctionnel EFS

4 Fonctionnel Protection des fichiers par chiffrement
Vol de portable, disque dur Attaque hors ligne, boot d’un autre OS Intégration sécurité Windows et Active Directory Chiffrement/Déchiffrement pour des comptes Windows Pas de groupes Mais chiffrement pour plusieurs utilisateurs possible Intégré au système de fichiers NTFS EFS est une fonction de NTFS Transparent pour les programmes et applications EFS n’est pas conçu pour le partage et l’échange de fichiers

5 Fonctionnel EFS est une application PKI
Chiffrement du contenu AES 256 par défaut 3DES configurable par Policy System cryptography: Use FIPS compliant algorithms for encryption HKLM\SYSTEM\CurrentControlSet\Control\LSA\FipsAlgorithmPolicy Driver Fips.sys FIPS 140-1 DESX pour accès aux fichiers Windows 2000 Chiffrement clé de session RSA 1024 par défaut HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EFS\RSAKeyLength Certificats X509v3 Certificats spécifiques EFS Extensions Application Policy/EKU Encrypting File System – oid File Recovery – oid EFS ne peut fonctionner qu’avec les CSP RSA « logiciels » de la plateforme Pas de certificat EFS sur Smartcard

6 DDF Chiffrement RSA de la FEK
Fonctionnel Modèle dit « data recovery » (en contraste avec « key recovery ») Mise en œuvre optionnelle d’une politique de récupération Agents de récupération (DRA) File Encryption Key (FEK) Chiffrement RSA de la FEK n fois avec clés publiques des n entités qui devront accéder au fichier DDF Key Ring – Data Decryption Field – Utilisateurs DRF Key Ring – Data Recovery Field – Agents de récupération (DRA) Peut être vide (pas de politique de récupération) Key Rings font partie du fichier (metadata NTFS) DDF Chiffrement RSA de la FEK DDF Key Ring DDF

7 Fonctionnel Attribut des dossiers et des fichiers Explorateur Windows
État chiffré ou non chiffré (comme la compression) E = Encrypted Explorateur Windows Couleur verte Clé de configuration Click droit propriétés/général/avancé Menu contextuel HKLM\Software\Microsoft\Windows\Explorer EncryptionContexteMenu Désignation des utilisateurs par leurs certificats Visualisation des agents de récupération Politique de récupération Scénario typique, et recommandé On active le chiffrement sur un dossier On place les fichiers à protéger dans ce dossier

8 Fonctionnel Chiffrement sur serveur du fichiers SMB possible
Transport en clair Utiliser IPSEC Chiffrement redirecteur WebDAV (préféré) Serveur WebDAV Partage de fichier sur HTTP Alternative à SMB, RFC 2518 Chiffrement sur la station, transport chiffré IIS supporte Webdav de par les Web folders SPS ne supporte pas EFS EFS n’est pas adapté pour le partage des fichiers chiffrés Son rôle premier est la protection contre le vol Pour la protection d’informations confidentielles à partager, on s’orientera vers RMS, et/ou S/MIME Redirecteur WebDAV nécessite station Windows XP EFS n’est pas du tout adapté au partage de fichiers chiffres. Sa fonction principale est la protection des informations sur les stations contre le vol de disque ou de portable. Pour une protection par partage, utiliser RMS, ou encore S/MIME.

9 Fonctionnel Pas de chiffrement des fichiers et dossiers système
Logique d’initialisation système et drivers %systemroot% Attribut SYSTEM Pas de chiffrement des fichiers compressés possible C’est l’un ou l’autre (chiffrement, ou compression) Droits propriétaire non nécessaire Permission écriture suffisante API de programmation La plus part des opérations EFS peuvent être effectuées par programmation Intégration backup Backup des fichiers sous leur forme chiffrée

10 Copie et déplacement Opérations locales
Shell glisser/déplacer, copier/coller Vers un dossier chiffré Le fichier arrive chiffré quelque soit son état initial et que l’opération soit une copie ou un déplacement Vers un dossier non chiffré Le fichier conserve son état Commande Copy IDEM shell Le fichier arrive chiffré quelque soit son état initial Commande Move

11 Copie et déplacement D’un fichier chiffré vers un serveur distant (SMB) Le transport est en clair: utiliser IPSEC lorsque possible Serveur ne supporte pas le chiffrement EFS Message d’avertissement (Windows XP/2003) et possibilité pour l’utilisateur d’annuler l’opération Serveur supporte EFS et le compte machine du serveur est « trusted for delegation » dans AD Déchiffrement, transport en clair, et rechiffrement sur le serveur Options ligne de commande pour permettre la copie vers une destination en clair Copie /D Xcopy /G Serveur supporte EFS (Windows 2000/2003) mais ne peut le mettre en œuvre (pas de délégation Kerberos) Access denied Le code d’erreur et le message « Access Denied » est necessaire pour la transparence d’EFS vis-à-vis des applications. Un autre message d’erreur pourrait poser problème aux applications existantes.

12 API de programmation FILE_ATTRIBUTE_ENCRYPTED (0x00000040)
GetFileAttribute/SetFileAttribute (ne chiffre pas) CreateFile FILE_ATTRIBUTE_ENCRYPTED (chiffre) EncryptFile/DecryptFile (chiffre/déchiffre) FileEncryptionStatus FILE_ENCRYPTABLE, FILE_IS_ENCRYPTED, FILE_SYSTEM_ATTR AddUsersToEncryptedFile, QueryUsersOnEncryptedFile QueryRecoveryAgentsOnEncryptedFile SetUserFileEncryptionKey EncryptionDisable Désactive chiffrement sur un répertoire EncryptFile échouera FileEncryptionStatus ne retournera pas FILE_ENCRYPTABLE ReadEncryptedFileRaw, WriteEncryptedFileRaw Backup, non documenté Plateform SDK A creuser la desactivation du chiffrement sur un répertoire

13 Outils Cipher EFSInfo Chiffrement/déchiffrement
Lister et localiser les fichiers chiffrés Mise à jour des fichiers pour une nouvelle clé EFS et agents de récupération (touch) Remise à zéro de l’espace disque non utilisé Obtenir un nouveau certificat EFS d’une CA en ligne EFSInfo Windows Support Tools Affichage des utilisateurs pour des fichiers/dossiers Affichage des « thumbprint » des certificats pour des fichiers/dossiers Affichage du « thumbprint » du certificat EFS courant HKCU\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys\CertificateHash Affichage agents de recovery pour des fichiers/dossiers

14 Révocation Vérification de la révocation lors de l’ajout de certificats sur un fichier chiffré Si le certificat s’avère être révoqué, il est rejeté Pas de vérification si l’utilisateur possède la clé privée correspondante au certificat Pas de vérification de révocation si le certificat ne contient pas de CDP Si le certificat est « self-signed », on demande à l’utilisateur s’il veut y faire confiance et l’utiliser Rajout du certificat dans le store « trusted people » Lors que la clé privée est disponible, il n’y a pas de vérification de révocation, pour des raisons de performance. Selon David Cross, si le certificat ne contient pas de CDP, la CRL n’est pas checkée, même si elle présente dans le cache.

15 Architecture

16 Chiffrement Symmétrique
EFS - Architecture Application (Explorer) LSASS API Win32 Service EFS lsasrv.dll advapi32.dll Chiffrement RSA (PKI) EncryptFile DecryptFile efsadu.dll feclient.dll LPC Crypto API kernel32.dll Certificat Clé Privée CreateFile ReadFile/WriteFile DeviceIOControl DeviceIOControl FSCTL_ENCRYPTION_FCTL_IO EFS_SET_ENCRYPT User Mode Kernel Mode FSRTL: File System Run Time Library Efsadu.dll => boite de dialogue utilisateur (click droit proprietes/avance/details) NTFS Driver ntfs.sys Callouts (FSRTL): EfsRead/EfsWrite EfsOpenFile EfsFileControl FILE_ATTRIBUTE_ENCRYPTED EFS Layered Driver efs.sys Partition Disk Chiffrement Symmétrique

17 Protection de la clé privée CSP logiciel
Chiffrement via DPAPI (Data Protection API) CryptProtectData, CryptUnprotectData Seul le même utilisateur peut retrouver l’information en clair – c’est le même utilisateur qui doit invoquer protect et unprotect Source d’entropie Crédentiels de l’utilisateur (NTHash du mot de passe) Entropie supplémentaire spécifique à l’information Phrase secrète utilisateur Non utilisé par EFS (transparence) Gestion des changements de mot de passe Implications syskey Stockage du « blob » DPAPI dans le profil de l’utilisateur c:\Documents and Settings\<username>\Application Data\Microsoft\Protect\<textual user SID> Fichier CREDHIST: Utilisé que pour les comptes locaux Chiffré avec mot de passe courant Contient les NTHash des anciens mots de passe

18 DPAPI Principe de fonctionnement
Chiffrement 3DES Clé dérivée d’un secret maître Unique à chaque protection par l’ajout d’aléa et de l’entropie additionnelle Secret maître Stocké dans le profil utilisateur Chiffrement 3DES avec clé dérivée du NTHash du compte SHA-1 et PBKDF2 Pour machines domaine, chiffrement une deuxième fois RSA avec clé publique du DC Renouvellement du secrets maîtres tous les trois mois Historique des secrets maîtres (fichiers) Secret maître identifié par GUID GUID fait partie du blob DPAPI Les clés privées des DC sont dans les « global secrets » dans Active Directory. Cela veut dire que les DC partagent leurs clés privées. Après un changement de mot de passe, DPAPI peut effectuer une récupération auprès de n’importe quel contrôleur. PBKDF2 => PKCS#5

19 DPAPI Changement de mot de passe
Machine hors domaine (compte local) DPAPI utilise l’événement de changement de mot de passe Le secret maître est déchiffré avec l’ancien NTHash, rechiffré avec le nouveau NTHash En case de perte de mot de passe Utiliser le Password Recovery Disk Machine du domaine Scénario pour lequel le mot de passe a été changé à partir d’une autre machine Nouveau NTHash ne permet pas de déchiffrer le secret maître DPAPI invoque le DC, lui fournit le secret maître chiffré, et le DC renvoie le secret maître déchiffré DPAPI rechiffre le secret maître avec le nouveau NTHash Fonctionne en cas de perte de mot de passe Reset du mot de passe par l’administrateur Les clés privées des DC sont dans les « global secrets » dans Active Directory. Cela veut dire que les DC partagent leurs clés privées. Après un changement de mot de passe, DPAPI peut effectuer une récupération auprès de n’importe quel contrôleur.

20 Syskey Chiffrement des NTHash dans la SAM et/ou AD SYSKEY mode 1
RC4 128/MD5 Clé unique à chaque champ, toutefois dérivée d’une clé de boot: « syskey » SYSKEY mode 1 La clé de boot est dissimulée et éparpillée sur le disque Permet le démarrage sans intervention de l’utilisateur SYSKEY mode 2 La clé est dérivée d’un mot de passe de démarrage, que l’utilisateur doit connaître et saisir SYSKEY mode 3 La clé est générée par le système et stockée sur une disquette Nécessite la disquette pour démarrer Syskey ne protège que contre Le vol d’un disque dur/portable Le boot d’un autre OS Syskey ne protege plus rien une fois le système démarré

21 Syskey Protection de la clé EFS
DPAPI avec un compte local à la machine Le NTHash de compte se trouve sur le disque de la machine Syskey mode 1 vulnérable Il faut appliquer Syskey en mode 2 ou 3 DPAPI avec un compte du domaine Le NTHash du compte ne se trouve pas sur le disque de la machine* *Sauf Smartcard logon, en quel cas le NTHash se trouve sur le disque sous sa forme chiffrée RSA avec la clé publique de la Smartcard

22 Mise en œuvre d’EFS

23 Gestion certificats et clés
Notion de certificat/clé courant HKCU\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys\CertificateHash EFSINFO /Y Stores utilisés My Trusted People Trust explicite de certificats self-signed Other People Office de cache Typiquement les certificats émis par une CA Obtenus depuis l’annuaire Active Directory (userCertificate), sont conservés dans ce store

24 Gestion certificats et clés Machines hors domaine
Lors d’un chiffrement de fichier… S’il y a un certificat courant, EFS l’utilise S’il n’y a pas de certificat courant, ou le certificat courant n’existe pas, EFS recherche un certificat acceptable (Application Policy/EKU) S’il en trouve un, il l’utilise Il le configure comme certificat courant Si aucun certificat EFS n’existe, une paire de clé et un certificat auto-signé sont créés Mise à jour du certificat courant dans le registre La validité du certificat self-signed est de 100 ans

25 Gestion certificats et clés Machines du domaine
Lors d’un chiffrement de fichier… S’il y a un certificat courant, EFS l’utilise S’il n’y a pas de certificat courant, ou le certificat courant n’existe pas, EFS recherche un certificat acceptable (Application Policy/EKU) S’il en trouve un, il l’utilise Il le configure comme certificat courant Sinon, EFS tente de localiser une CA d’Entreprise et d’enrôler un certificat EFS Il faut qu’une CA d’Entreprise « serve » une template EFS et que la template ait l’ACE « Enroll » pour l’utilisateur Mise à jour du certificat courant dans le registre Finalement, lorsque les étapes ci-dessus ont échoué, une paire de clé et un certificat auto-signé sont créés

26 Déploiement de certificats EFS
Auto-Enrôlement Positionner les droits « Enroll » et « AutoEnroll » sur une template EFS dans Active Directory Enrôlement par EFS S’assurer des droits « Enroll » sur une template EFS dans Active Directory Templates de base supportant EFS User Administrator Basic EFS Dans les deux cas, s’assurer qu’une CA Entreprise joignable « serve » cette/ces templates Si l’utilisateur a déjà un ou des certificats EFS, il y a de fortes chances pour que l’enrôlement EFS ne se déclenche pas, ou que le certificat obtenu par Auto-Enrôlement ne soit pas utilisé Forcer le certificat courant par script de logon

27 Politique de récupération
Politique de récupération = mise en place et utilisation de un ou plusieurs agents de récupération (DRA) DRA matérialisé par un certificat/clé privée A chaque ouverture de fichier chiffré, EFS applique la politique en vigueur S’assure que les DRF existent pour chaque DRA défini par la politique Cipher /U L’existence d’une politique de récupération est facultative sur Windows XP/Windows 2003 Un fichier peut être chiffré sans DRA Risque de perte des informations Sur Windows 2000, elle est obligatoire L’absence d’agent de récupération désactive EFS Pour créer l’équivalent d’un chiffrement sans politique de récupération, on peut utiliser un DRA pour lequel la clé privée a été détruite

28 Politique de récupération Machine hors domaine
Pas de politique de récupération par défaut Windows XP/2003 ne crée pas d’agent de récupération lors de l’installation ou du premier logon Ce n’était pas le cas pour Windows 2000 Pour mettre en œuvre un agent de récupération Utiliser Local Security Settings (secpol.msc) Public Key Policies/Encrypting File System On désigne un ou des certificats d’agents de récupération sur le disque (fichiers CER) CIPHER /R Crée une paire de clés et certificat auto-signé correspondant Génère un fichier PFX et un fichier CER Mettre le fichier PFX en sécurité, et installer le fichier CER en tant qu’agent de récupération

29 Politique de récupération Domaine
Définie par stratégie de groupe (Group Policy) S’applique aux machines sous son influence Site, Domaine, OU Précédence OU, Domaine, Site Distinction policy vide vs pas de policy Créée automatiquement lors du premier logon de l’administrateur Désigne l’administrateur du domaine en tant que DRA Certificat auto-signé au nom de l’administrateur Clé privée dans le profil de l’administrateur L’administrateur peut modifier la stratégie de groupe (dompol.msc) Public Key Policies/Encrypting File System Rajouter des DRA en désignant des certificats d’agents de récupération Fichiers CER sur le disque userCertificate dans Active Directory Supprimer des DRA Supprimer la policy/Créer une policy vide Créer un DRA le désignant Certification par une CA d’Entreprise plutôt que auto-signé Note: la template Agent de récupération EFS ne publie pas les certificats émis dans AD. Donc si on ne fait rien, en principe, userCertificate ne contient pas de certificats d’agent de récupération. Si on veut publier les certificats d’agents de récupération émis pas une CA d’Entreprise dans AD, il faut dupliquer la template, et activer sur la nouvelle template cette publication.

30 Désactiver EFS Machine du domaine Stratégie de groupe (Group Policy)
Public Key Policies/Encrypting File System/Properties Allow users to encrypt files using EFS Machine hors domaine Utiliser clé registre HKLM\Software\Microsoft\Windows NT\CurrentVersion\EFS Valeur EfsConfiguration DWORD 0x1 Sur Windows 2000, l’absence d’au moins un agent de récupération désactive le chiffrement EFS

31 Récupération Mise en œuvre
Agent de récupération déchiffre le fichier avec l’explorateur Windows ou la commande Cipher Station de récupération centralisée Si suffisamment en sécurité, la clé privée de l’agent de récupération peut s’y trouver en permanence Sinon, au moment d’effectuer des récupérations: Importer la clé Effectuer les récupérations Exporter la clé Les utilisateurs doivent faire un backup (NTBackup) du fichier EFS et le déposer sur un share L’agent de récupération obtient le fichier de backup, le restore sur la station, vérifie les droits de l’utilisateur, puis déchiffre le fichier Intervention sur site de l’agent de récupération Accède à la station, importe la clé, effectue la récupération, exporte la clé On peut utiliser une page web avec instructions pour NTBackup pour les utilisateurs

32 Chiffrement sur serveur SMB Globalement complexe
Chiffrement sur le serveur, pour le compte de l’utilisateur Transport en clair, utiliser IPSEC Délégation Kerberos Serveur « trusted for delegation » Compte utilisateur n’est pas « sensitive and cannot be delegated » Si profile errant, le serveur l’utilise Sinon, le serveur crée un profile pour l’utilisateur Contient le certificat et clé privée Logique d’enrôlement (CA d’Entreprise ou auto-signé) identique à celle d’une station Support des technologies cluster (Windows 2003) Nécessite profiles errants (clé unique) Support multi-utilisateurs Nécessite profiles errants Mise en cache des handles (CryptoAPI) de clés de utilisateurs Par défaut 15, paramétrable registre Pas de support cross forest Méthode préférée reste WebDAV Nécessite stations Windows XP EFS n’est pas adapté au partage de fichiers chiffrés Il faut aussi backuper les profiles.

33 Fichiers hors ligne Client Side Caching (CSC)
Base unique sur la station Contient tous les fichiers de tous les utilisateurs Accès aux fichiers sous contrôle des ACL Affichage reproduit la structure des répertoires et fichiers du serveur Chiffrement EFS pour le compte local SYSTEM Ne pas utiliser pour des informations sensibles, à moins d’être prêt a passer en SYSKEY mode 2 ou 3

34 Best Practices Chiffrement EFS
Chiffrement au niveau des dossiers Utiliser des dossiers chiffrés, plutôt que conversion d’un fichier de clair en chiffré (problème copie en texte clair lors de la conversion, dont les blocs restent sur la partition NTFS) My Documents RootDirectory\Temp %systemroot%\system32\spool Activer la purge du fichier de pagination Utilisation de mémoire non-paginée pour le driver – pas de pagination des clés (FEK) Cependant les données en clair peuvent être paginées (applications) Policy de groupe ou locale « Security Options » « Shutdown: Clear virtual memory pagefile » Utiliser Cipher /W (wipe) S’il y a eu des conversions (clair -> chiffré)

35 Best Practices Comptes utilisateurs
Utiliser des comptes du domaine, et non des comptes locaux Protection effective même en SYSKEY mode 1 Si le chiffrement est mis en œuvre avec des comptes locaux, utiliser SYSKEY mode 2 ou 3 Mettre en œuvre une politique de mots de passe renforcée Longueur minimum, historique, caractères spéciaux, etc… Le mot de passe est le maillon faible du chiffrement EFS

36 Best Practices Politique de récupération
Mettre en œuvre une politique de récupération au niveau du domaine Séparer les rôles d’agents de récupération des administrateurs du domaine Changer la politique par défaut Mettre à l’abri les clés des agents de récupération Copies hors site Pour les agents de récupération, utiliser des certificats émis par une CA, plutôt que auto-signé Contrôler/maîtriser les droits d’enrôlement sur les templates d’agents de récupération

37 Best Practices Politique de récupération
Définir précisément la procédure de récupération Utiliser une station centrale sécurisée Ne pas importer de clé de récupération sur les stations des utilisateurs Tester la capacité à dérouler la procédure et à effectuer la récupération Limiter nombre d’agents de récupération Lors de changements de la politique de récupération mettre à jour les fichiers utilisateurs Cipher /U

38 Best Practices Data recovery vs key recovery
Data recovery est spécifique à EFS Ne nécessite pas d’infra PKI (certificats auto-signés) Récupération fichier par fichier Key recovery est une fonction de l’infrastructure PKI CA Windows Récupération globale On peut cumuler les deux fonctions CA d’Entreprise Auto-enrolement pour les certificats EFS avec séquestre des clés Ou n’en mettre en œuvre aucune Selon la politique de l’entreprise

39 Références Encrypting File System in Windows XP and Windows Server 2003 The Windows Server 2003 Family Encrypting File System Network Associates Laboratories Windows Data Protection Network Associates Laboratories Windows NT Magazine. Mark Russinovich. Articles reproduits dans MSND: Inside Encrypting File System, Part 1 Inside Encrypting File System, Part 2

40 Questions?

41

42 Transparents supplémentaires Pour référence

43 EFS - Architecture Service EFS – lsass.exe (lsasrv.dll) Applications
Au sens Win32, c’est en fait le service Security Account Manager (SAM) Gestion de la clé FEK Chiffrement/déchiffrement RSA pour FEK Gestion/formatage des DDF/DRF pour le Key Ring Application des policies Implémentation/exécution de l’API EFS N’invoque que NTFS Applications N’invoquent que NTFS et le service EFS API cliente spécifique EFS advapi32.dll Invocation service EFS via LPC API fichiers classique kernel32.dll Invocation driver noyau NTFS Driver EFS Chiffrement symétrique des données N’est invoqué que par le driver NTFS (appel direct sur les callbacks) S’enregistre auprès de NTFS au démarrage (NtOfsRegsiterCallbacks) Invoque le service EFS pour chiffrement/déchiffrement FEK LPC ksecdd.sys – messages LPC sécurisés

44 EFS – Chiffrement d’un fichier
Application invoque EncryptFile Advapi32.dll -> feclient.dll LPC message vers LSASRV ->EfsRpcEncryptFileSrv LSASRV - préliminaire Impersonne l’appelant Crée fichier journal pour la conversion clair - chiffrés Efs[n].log Charge profile utilisateur si nécessaire Invoque NTFS pour connaître les streams présents dans le fichier (il faudra chiffrer tous les streams)

45 EFS - Chiffrement d’un fichier
LSASRV Invoque CryptoAPI pour générer une FEK Provider RSA par défaut CryptGenRandom 16 octets = 128 bits Obtient certificat/clé privée EFS de l’utilisateur pour chiffrement HKCU\Software\Microsoft\Windows NT\CurrentVersion\EFS\CurrentKeys\CertificateHash Si existe, retrouve certificat dans le store personnel (My) Retrouve nom du container pour la clé privée Sinon, crée paire de clé RSA et obtient certificat Génération paire de clés dans un container du CSP Si Enterprise CA de localisée -> obtention auprès de cette CA Sinon, construit et self-signe un certificat Stocke certificat dans le store personnel, positionne clé registry

46 EFS - Chiffrement d’un fichier
LSASRV Construit DDF KeyRing DDF: User SID, Provider/Container, EFS Certficate Hash, FEK chiffrée avec RSA Retrouve les agents de recovery de la policy en cours Construit DRF KeyRing Retrouve les certificats des agents DRF: même format que DDF Sérialise les rings dans un stream ($EFS) avec checksums MD5 (un pour chaque keyring) Crée une copie temporaire du fichier efs[n].tmp On copiera de la copie temporaire vers le fichier pour le chiffrement

47 EFS - Chiffrement d’un fichier
LSASRV LSASRV invoque le driver efs.sys pour transmettre les metadata et la clé FEK Le message est chiffré avec DES Clé de session échangée lors d’une initialisation antérieure Invocation par l’intermédiaire de NTFS DeviceIOControl: FSCTL_ENCRYPTION_FCTL_IO Commande pour efs.sys: EFS_SET_ENCRYPT Efs.sys Invoque NTFS pour rajouter le stream $EFS au fichier Fonctions internes NTFS mode noyau: NtOfsCreateAttributeEx, etc… En retour passe un contexte pour ce fichier a NTFS Le contexte contient la clé FEK Le contexte sera fourni a efs.sys a chaque invocation ultérieure Copie contenu du fichier vers la copie temporaire Invoque NTFS pour le chiffrement du fichier NTFS Efface le contenu du fichier Copie le contenu de la copie vers le fichier Puisque le fichier est chiffrée chaque écriture engendre le chiffrement Invocation de EfsWrite sur efs.sys avec le contexte (FEK) A ce point, l’auditeur a les éléments pour déduire le processus de déchiffrement, ainsi que la mécanique de lecture/écriture d’un fichier chiffré.

48 Credhist Comptes locaux seulement Fonction de robustesse uniquement
Reprise sur échec Lors du rechiffrement des master keys avec un nouveau NTHash, en cas d’échec il faut pouvoir repartir des NTHash precedents Contient les hash des mots de passe précédents Chaque précédent chiffré avec courant La longueur de l’historique n’est pas configurable, et il n’y a pas de limite (le fichier d’historique s’accroît indéfiniment). Credhist ne peut pas être désactivé, il est obligatoire mis en œuvre par DPAPI Credhist est spécifique à DPAPI et n’est pas utilise par d’autres composants du système ou applications En cas de perte du mot de passe, par de recovery possible => utiliser le password recovery disk

49 Secrets LSA SCM utilise les secrets LSA pour stocker les mots de passe des comptes de service LSAStorePrivateData, LSARetrievePrivateData API conçue pour le stockage des secrets par les services Win32 Stockage des secrets d’une machine, pas d’un utilisateur $MACHINE.ACC Accès privilégié (Administrator, SYSTEM) Registry HKLM/SECURITY/Policy/Secrets Chiffrement DES avec une constante Deplombable! Mais pas d’outil, à ma connaissance Protégé par SYSKEY Il faut appliquer SYSKEY! Les secrets LSA ne sont pas secret pour l’administrateur

50 Cache de crédentiels de logon sur une station
Permet le logon interactif avec un compte du domaine lorsque aucun contrôleur n’est accessible Entrée du cache contient un vérificateur pour le mot de passe d’un compte du domaine Ne contient ni le mot de passe, ni le NTHash Le vérificateur est MD4( NTHash) On ne peut dériver le NTHash du vérificateur Le vérificateur est salted Deux utilisateurs avec même mot de passe n’ont pas le même vérificateur L’attaque de dictionnaire contre le vérificateur reste possible Vérificateur, user et groupes sont conservés dans le registre Permet de créer un token lors de l’ouverture de session HKLM/SECURITY/Cache/NL$1, etc… Ce cache ne fait pas partie des secrets LSA – pas de protection Syskey Chiffrement RC4 128 bit avec clé dérivée d’une clé maître Clé maître conservée en tant que secret LSA NL$Km HKLM/SECURITY/Policy/Secrets Secrets LSA sont protégés par Syskey Cas Smartcard/Kerberos Le cache contient bien le NTHash, mais protegé par PKI (déchiffrable avec la clé privée) Mettre en œuvre une politique de logon par Smartcard, et affecter aux utilisateurs des mots de passe aléatoires et robustes dont il n’ont pas connaissance