Principe de fonctionnement d’EFS

l’utilisateur qui devrait avoir la capacité de décryptage, garde la clé privée en sécurité, la ressource protégée est à l’abri.

EFS est validé par défaut sur tous les systèmes Win2K et ultérieurs. Quand quelqu’un protège avec EFS un fichier ou un dossier pour la première fois, Windows vérifie si un serveur de PKI (public key infrastructure) et capable de générer des certificats numériques EFS est disponible. Certificate Services de Windows 2003 et Win2K peuvent générer des certificats EFS, ainsi que d’autres produits PKI non Microsoft.

Si Windows ne peut pas trouver un fournisseur de PKI acceptable, il génère un certificat EFS autosigné pour l’utilisateur, comme celui de la figure 1. Les certificats EFS autosignés sont utilisables pendant 100 ans ! Si Windows trouve un serveur Certificate Services, ce serveur génèrera et émettra automatiquement un certificat de 2 ans à l’utilisateur. L’idée est peut-être que si des services PKI sont actifs en interne, le serveur PKI peut facilement accorder ou renouveler des certificats EFS quand l’original expire. Dans l’un ou l’autre cas, vous pouvez visualiser vos certificats EFS en ajoutant le snap-in Certificates à la MMC (Microsoft Management Console) et en examinant le conteneur Personal.

La clé EFS privée de l’utilisateur (qui déverrouille les fichiers protégés par EFS) est cryptée avec la clé maîtresse de l’utilisateur et stockée dans le profil de celui-ci sous Documents and Settings, username, Application Data, Microsoft, Crypto, RSA. Si un profil itinérant est utilisé, la clé privée réside dans le dossier RSA sur le DC (domain controller) et est téléchargée sur l’ordinateur de l’utilisateur quand celui-ci se connecte. Windows utilise le mot de passe courant de l’utilisateur et l’un des algorithmes RCA à 56, 128 ou 512 bits, pour générer la clé maîtresse. Peut-être que la chose la plus importante à savoir sur l’EFS est que la clé EFS privée de l’utilisateur réside dans son profil et qu’elle est protégée par une clé maîtresse basée sur le mot de passe courant de l’utilisateur. Bien entendu, la puissance du mot de passe de l’utilisateur détermine la puissance du cryptage d’EFS. Si un utilisateur parvient à percer le mot de passe d’un utilisateur EFS ou s’il est capable de se connecter comme l’utilisateur légitime, la protection fournie par EFS est mise à mal.

Si le profil de l’utilisateur est perdu, ou si son mot de passe est redéfini (plutôt que changé par l’utilisateur), l’utilisateur pourrait facilement perdre toute possibilité d’accès à tous les fichiers protégés par EFS. C’est pourquoi la clé EFS privée de l’utilisateur devrait toujours être sauvegardée dans deux, ou plus, emplacements hors site sûrs et séparés, ou que un ou plusieurs DRA devrait être définis (et leurs clés privées exportées et sauvegardées dans deux, ou plus, endroits hors site séparés et sécurisés). Faute de suivre ces précautions, des données risquent d’être perdues.

Quand un fichier ou un dossier est crypté pour la première fois, Windows génère au hasard une clé symétrique en utilisant les algorithmes Data Encryption Standard X à 128 bits (DESX – par défaut dans XP et Win2K) ou Advanced Encryption Standard à 256 bits (AES – dans Windows 2003 et XP Pro Service Pack 1). Les deux algorithmes en question sont des standards officiels largement acceptés et éprouvés, même si le dernier des deux est le standard le plus actuel et le plus recommandé. Vous pouvez aussi valider l’ancien standard par chiffre symétrique du gouvernement américain, Triple DES (3DES) à 168 bits, dans le cas où votre entreprise en aurait besoin. Voir l’article Microsoft « Encrypting File System (EFS) files appear corrupted when you open them » () pour plus de détails. La clé symétrique générée au hasard est connue sous le nom de FEK (file encryption key) et ce sera la seule clé que Windows utilisera pour crypter le fichier ou le dossier, quel que soit le nombre de personnes qui accèdent à la ressource protégée par EFS.

Windows crypte ensuite la FEK en utilisant la clé EFS publique RSA 1024 bits de l’utilisateur et stocke la FEK dans les attributs étendus du fichier. Si des DRA sont définis, l’OS stocke une autre copie cryptée de la FEK avec la clé EFS publique du DRA. Ensuite, Windows stocke cette copie cryptée de la FEK avec le fichier. Dans XP et produits ultérieurs, plus d’un utilisateur peut avoir l’accès EFS à un fichier ou à un dossier particulier. Chaque utilisateur autorisé aura sa propre copie de la FEK cryptée avec une EFS publique unique. (A noter que dans Win2K, un seul DRA peut être défini.)

Désormais, quand un utilisateur autorisé accèdera à un fichier protégé, Windows décryptera sa copie de la FEK cryptée en utilisant la clé EFS privée associée de l’utilisateur. Ensuite, Windows utilisera la FEK pour déverrouiller le fichier crypté. Contrairement à ses premières versions dans Win2K, EFS gère désormais de façon sûre tout le cryptage et le décryptage des fichiers et des dossiers en mémoire, de sorte qu’il ne reste plus de texte clair pour une reprise non autorisée.