Le cryptage via le système de fichiers cryptés (EFS) [25 mn de lecture - paru le 5/10/2004 12:42:54 AM - Public : Confirmé]

Auteur

Alexandre LAMOUR Elève-Ingénieur Supinfo Paris Promotion SUPINFO 2006    Lui écrire    Tous les projets de cet auteur    Le mini-CV de cet auteur

3 - L’architecture du système EFS

Afin de bien comprendre le mécanisme, nous allons étudier respectivement les différents composants du système EFS, le processus de cryptage, les informations de cryptage EFS, ainsi que le processus de décryptage.

3.1. Les différents composants du système EFS

Pour comprendre le système de cryptage-décryptage de Windows, il est intéressant de le situer dans l’architecture générale du système d’exploitation. Le système d’exploitation s’étale sur deux modes : le mode utilisateur, et le mode noyau.
Lors du développement du processus de cryptage des données, les concepteurs du système EFS ont été amenés à choisir le mode d’exécution du code de cryptage.
Le cryptage des données uniquement en mode utilisateur aurait conduit à la création de fichiers temporaires non cryptés, et donc à un défaut inacceptable dans la sécurité.
Sous Windows, les activités découlant de la mise en œuvre du système EFS se déroulent dans l’un et l’autre de ces modes.

Sous Windows (depuis Windows 2000), les applications sont toujours exécutées en mode utilisateur.Par conséquent, lorsqu’un utilisateur sollicite un cryptage à partir de l’Explorateur, ou via Cipher, c’est en mode utilisateur que commence le processus de cryptage.

Le schéma suivant présente les différents composants EFS.

Les composants EFS

Pilote EFS : il constitue réellement un pilote de périphérique connecté avec le pilote NTFS. Ces deux pilotes sont tous deux exécutés en mode Noyau.

Fonction de rappel EFS : il s’agit de fonctions que le pilote EFS peut mettre en œuvre sur la demande du pilote NTFS. Ces fonctions sont déclarées au cours de l’initialisation du pilote EFS.

KsecDD : Ce composant récupère les requêtes EFS, et communique avec le sous-système de sécurité au nom du pilote EFS.

Services EFS : Ils font partie du serveur d’autorité locale (LSAS), qui constitue lui-même un élément du sous-système d’autorité de sécurité locale (LSASS).
Les services EFS sont utilisés pour obtenir et renforcer le processus de récupération des données cryptées, et pour localiser la paire de clés de l’utilisateur.

Fournisseur de services cryptographiques : Un des rôles majeurs du fournisseur de services cryptographiques consiste à fournir des opérations de cryptage RSA.

3.2. Le processus de cryptage

L’installation du pilote EFS est indispensable pour qu’un cryptage des données puisse être mis en œuvre sous Windows.
Au cours de son initialisation, le pilote EFS informe le pilote NTFS de son existence, et déclare les sept fonctions de rappel dont le pilote NTFS pourra ensuite solliciter l’exécution.

Lorsque le pilote NTFS reçoit une requête d’opération EFS, il consulte la table des fonctions de rappel EFS disponibles, et invoque la fonction appropriée. Le pilote EFS se charge ensuite d’exécuter la fonction demandée.
Le pilote EFS envoie la requête de cryptage de fichier vers le sous-système LSASS, mais un pilote intermédiaire vient intercepter cette requête en mode noyau. Le pilote KsecDD, qui est utilisé pour envoyer le message LPC réel au sous-système LSASS, réside en mode noyau.
Le serveur d’autorité de sécurité locale, ou LSASRV, qui constitue un sous-système LSASS est à l’affût de ces messages LPC.

Lorsqu’il reçoit un appel du client FE (File Encryption) pour le cryptage d’un fichier, le serveur LSASRV invoque une fonction interne (EfsRpcEncryptFileSrv).
La prise d’identité de l’utilisateur par la fonction EfsRpcEncryptFileSrv permet l’utilisation de la clé privée appropriée lors de la manipulation du fichier.
Cette fonction va ensuite invoquer la fonction EncryptFileSrv qui va se charger des dernières tâches du processus de cryptage :

- Elle va interroger le pilote NTFS sur le flux de données utilisé dans le fichier.
- Elle invoque la fonction GenerateFEK.
- Elle construit les informations de cryptage EFS stockées avec le fichier crypté.
- Elle crée un fichier de sauvegarde.
- Elle initialise le fichier journal.
- Enfin, elle envoie une commande cryptée au pilote NTFS pour crypter ce fichier.

Lorsque le pilote NTFS reçoit une commande de contrôle cryptée, il sollicite l’exécution de la fonction de rappel EFS EfsFileControl.
Le pilote EFS applique alors sa clé de session pour décrypter la commande de contrôle, et ajoute les informations de cryptage EFS au fichier d’origine.

Une fois que les informations de cryptage ont été ajoutées au fichier d’origine, la fonction interne EncryptFileSrv reprend le contrôle des activités. Elle accomplit alors les tâches suivantes :

- Elle procède aux enregistrements dans le fichier journal qui a été créé par le fichier de sauvegarde.
- Elle envoie une autre commande de contrôle cryptée au pilote NTFS, pour obtenir le cryptage du fichier.

À la réception de la commande de contrôle cryptée, le pilote NTFS sollicite l’exécution de la fonction de rappel EFS EfsWrite. Celle-ci va effectuer un cryptage par clé secrète du fichier, secteur par secteur. En France, le système EFS utilise une clé de cryptage DESX standard sur 40 bits.

Lorsque le fichier a été entièrement écrit sur le disque au format chiffré, la fonction EncryptFileSrv achève le cryptage en effaçant la copie de sauvegarde du fichier d’origine, en supprimant le fichier de journal et en redonnant le contrôle à l’utilisateur.

L’ensemble des tâches que nous venons de décrire constitue ainsi le processus de cryptage intégré. Précisons qu’une copie de sauvegarde du fichier d’origine reste néanmoins toujours disponible jusqu’à l’achèvement du cryptage (afin de couvrir la moindre erreur).

3.3. Le processus de décryptage

L’accès d’un utilisateur à un fichier crypté déclenche le processus de décryptage, qui est lui aussi transparent pour l’utilisateur.
Comme toujours lors de l’accès à un fichier placé dans un volume NTFS, le pilote NTFS examine les attributs du fichier.

Si le fichier s’avère crypté, le pilote NTFS invoque la fonction de rappel EFS EfsOpenFile qui effectue les tâches suivantes :

- Elle invoque la fonction NTFS NtOfsQueryLength pour déterminer la longueur de l’attribut.
- Elle alloue l’espace nécessaire en mémoire tampon compte tenu de la longueur trouvée.
- Elle copie l’attribut EFS en mémoire tampon.

Si le système EFS ne parvient pas à lire l’attribut EFS du fichier crypté, l’utilisateur reçoit un message d’erreur.
Si cette lecture réussit, le pilote NTFS invoque à nouveau une fonction de rappel EFS : EfsFilePostCreate qui va vérifier que l’utilisateur est bien autorisé à accéder aux données cryptées. L’utilisateur doit donc posséder une clé privée apte au décryptage de sa clé FEK. Celle-ci, une fois décryptée, sera employée pour décrypter le fichier lui-même.

S’il apparaît qu’aucune clé FEK ne peut-être décryptée au moyen de la clé privée de l’utilisateur, alors ce dernier se voit refuser l’accès au fichier. En revanche, si une clé FEK peut être décrypté, alors une session cryptographique est établie avec le fournisseur Microsoft de services cryptographiques.

Une fois que la session es établie, le décryptage de la clé FEK est achevé au moyen de la clé privée de l’utilisateur. Pour renforcer encore la sécurité du processus, l’attribut EFS et la clé FEK décryptée sont soumis à un hachage, et le résultat obtenu est comparé au total de contrôle enregistré dans l’en-tête des informations EFS.
Au cours de cette session, la clé FEK et l’algorithme RSA sont employés pour décrypter complètement le fichier.