Le chiffrement de données EFS intégré à Windows NT 5.0 (Windows 2000)
Article (c) Alexandre PUKALL 1998
[Utilisation de tout ou partie autorisée si le nom de l'auteur est mentionné et à condition que cet entête ne soit pas retiré]
Microsoft renonce à son passé grâce à Windows NT 5.0 et le nouveau système EFS : Encrypting File System
Jusqu'à présent les logiciels Microsoft n'étaient pas vraiment à la pointe du progrès en matière de protection des données.
On se souvient de Word 2.0, Word 6.0 et Word 95 qui utilisaient le système Vigenère pour crypter les fichiers des utilisateurs avec un mot de passe. Ce système dérive le mot de passe, par un système simple de rotations, en une clé fixe de 16 octets puis mixe par XOR cette clé avec le texte clair pour former le texte crypté. Or, ce système n'offre aucune sécurité et on a vu se propager sur Internet des logiciels pour 'casser' les mots de passe de Word.
Ces logiciels retrouvent la clé fixe de 16 octets par attaque statistique puis inversent les rotations pour retrouver le mot de passe original.
Avec Office 97, le système reste le màme en France ( légalité oblige ), mais pour les autres pays le système utilisé est le RC4-40 bits de la société américaine RSA. Le mot de passe est transformé en une clé aléatoire de 16 octets non inversible grâce à la fonction de hachage à sens unique MD5 également de la société RSA.
5 octets sont alors utilisés pour initialiser le système de chiffrement en continu RC4. RC4 produit une suite aléatoire d'octets pratiquement infinie qui est mixée par XOR avec le texte clair.
Cependant aucune valeur de salage n'est utilisée. Une valeur de salage est une suite aléatoire d'octets ajoutée au mot de passe de l'utilisateur pour créer une clé différente à chaque cryptage.
Comme Office 97 ne l'utilise pas, la suite aléatoire d'octets est toujours la màme si on ne change pas le mot de passe.
Ceci permet d'attaquer le système. Si on connaît un seul fichier crypté et son équivalent non crypté on peut décoder tous les autres fichiers codés avec la même clé ( de longueur inférieure ou égale à ce premier fichier ).
Quant à Windows NT 4.0, Microsoft ne cesse de marteler sa grande sécurité. Cependant une partition NTFS avec des droits d'accès réservés ne protège absolument pas, si on peut avoir un accès physique à la machine. De nombreux logiciels sont disponibles sur Internet, comme NTFSDOS.EXE . Il suffit alors de booter sur une disquette DOS puis de lancer NTFSDOS pour avoir accès à la partition NTFS complète même si on ne possède aucun droit d'accès sur les fichiers.
Si on ne possède pas ce programme mais que l'on peut ouvrir la machine, il suffit de récupérer le disque dur et de l'installer en esclave sur une autre machine NT 4.0 sur laquelle on connaît le mot de passe Administrateur. On récupère automatiquement les droits d'accès aux fichiers du nouveau disque dur, même si le mot de passe Administrateur n'est pas le màme sur les deux disques.
Pour ceux disposant de NT 4.0 sans service Pack supplémentaire, le programme GETADMIN.EXE ( disponible aussi sur Internet ) permet d'exploiter un bug du système d'exploitation ( réglé dans les services Pack suivants ) et transforme tout utilisateur normal en Administrateur avec tous les droits d'accès associés, ceci en introduisant le nom de l'utilisateur dans le groupe local 'administrateurs'.
Sécurité et Microsoft ne faisaient pas bon ménage.
Cependant cela va bientôt prendre fin avec Windows NT 5.0
NT 5.0, outre toutes les améliorations tournées vers Internet qu'il va apporter, procure également un nouveau système de fichiers : EFS ( Encrypting File System ).
Cela faisait longtemps que les spécialistes de la sécurité attendaient un système fiable.
Ce système permet de crypter tous les fichiers d'un disque dur de façon automatique et transparente.
Sous NT 4.0 lorsque l'on applique l'attribut 'compressé' à un fichier ou un répertoire, tous les fichiers sont compressés automatiquement et ceux que l'on rajoute par la suite également.
Sous NT 5.0, la compression des fichiers sera toujours possible mais en plus on disposera d'un attribut 'crypté'.
En ce qui concerne la gestion des attributs 'crypté' des fichiers, rien de plus simple, on peut activer cet attribut dans les propriétés du fichier par l'explorateur Windows NT.
Ainsi, un fichier crypté sera protégé des accès physiques au disque dur car même si on y accède, son contenu ne sera pas déchiffrable.
Tous les fichiers temporaires peuvent être cryptés également, ne laissant ainsi aucune brèche à un éventuel pirate.
Jusqu'à présent les logiciels de cryptage de fichiers étaient lourds à utiliser car il fallait les lancer, donner un mot de passe et choisir les fichiers à crypter ou décrypter. Or, ce qui est lourd n'est jamais utilisé par les utilisateurs.
Sécuriser les fichiers d'une entreprise était alors pratiquement impossible.
Avec NT 5.0, le mot de passe que l'utilisateur donne au login ( connexion sur NT ) est utilisé par la suite pour toutes les procédures de cryptage/décryptage de façon transparente. Mais NT 5.0 permet aussi de stocker les clés sur une carte à puce que l'utilisateur insère dans un lecteur pour décrypter ses fichiers ( ou même pour se connecter à NT ).
En fait, le système est plus complexe car il apporte de nombreuses sécurités supplémentaires.
A la création de chaque utilisateur, une clé privée et une clé publique sont créées.
Rappelons qu'une clé publique permet de crypter une information mais ne permet pas de la décrypter ( le système est basé sur la factorisation des nombres premiers ). Pour décoder l'information il faut disposer de la clé privée.
Sous NT 5.0, chaque utilisateur dispose d'une clé publique et d'une clé privée de type RSA ( Rivest Shamir Adleman ) à 1024 bits pour la version NT 5.0 US et 512 bits pour la version export.
La clé privée est elle-màme cryptée avec le mot de passe de l'utilisateur.
Chaque fois qu'un fichier doit être crypté, une clé aléatoire est créée. Cette clé est appelée clé de session et ne sera jamais réutilisée une seconde fois. Cette clé est utilisée pour crypter le fichier avec l'algorithme DES ( Data Encryption Standard ).
Ainsi chaque fichier sera toujours crypté avec une clé différente et un même fichier décodé puis recodé à nouveau aura une clé différente lors du nouveau codage.
Cette clé de session est insérée en début du fichier et est elle-màme codée avec la clé publique de l'utilisateur. On l'appelle alors 'champ de décryptage de données'.
Lorsque l'utilisateur veut avoir accès à son fichier, le système décode sa clé privée ( en mémoire protégée ) avec son mot de passe ( resté en mémoire après le login ) puis décrypte le 'champ de décryptage des données' avec cette clé privée. La clé de session est alors utilisée pour décrypter le fichier en lui-màme.
Sans clé privée ou sans la bonne clé privée, le fichier ne sera pas accessible ( et ne pourrait d'ailleurs pas être décrypté ).
Microsoft a bien pensé le système : si certains fichiers doivent être partagés entre plusieurs utilisateurs, la clé de session du fichier est dupliquée autant de fois qu'il y a d'utilisateurs et chaque copie de la même clé de session est cryptée par chaque clé privée de chaque utilisateur. Toutes ces copies de la clé de session ( plusieurs 'champ de décryptage de données' ) sont intégrées en début de fichier avec, pour chaque clé, un identificateur de l'utilisateur.
Le système EFS réside en mode noyau, ce qui a pour effet d'éviter que les clés de session puissent être enregistrées par le système d'exploitation dans le fichier d'échange sur le disque dur. Les clés de session restent donc toujours en mémoire pendant leur utilisation et sont effacées après. Cette mémoire est inaccessible à tous les autres programmes, même ayant un privilège d'accès 'système' ( le plus élevé ).
Ce qui pourrait poser problème, c'est le départ d'un salarié de l'entreprise : si un utilisateur a crypté tous ses fichiers et qu'il ne veut pas donner son mot de passe pour décrypter sa clé privée ( ou qu'il ne s'en souvient plus ), alors tous ses fichiers sont perdus.
Là encore, Microsoft fait fort : chaque clé de session des fichiers est dupliquée et cryptée avec une clé publique de 'recouvrement de clés'. Cette copie de clé de session cryptée est également insérée en début de fichier. Elle est appelée 'Champ de recouvrement de données'.
Pour décrypter alors un fichier, il faut soit avoir la clé privée de l'utilisateur, soit avoir la clé privée de 'recouvrement de clés'.
La paire clé privée-clé publique de 'recouvrement de clés' est créée par l'Administrateur lors de l'installation de NT 5.0. Elle est cryptée par le mot de passe de l'Administrateur ( par défaut ) mais ce dernier peut déléguer la gestion de cette clé à un opérateur de 'recouvrement de clés' comme cela existe déjà sur NT 4.0 pour les opérateurs de sauvegarde.
NT 5.0 permet même de créer plusieurs clés de 'recouvrement de clés' pour autoriser différents opérateurs à récupérer les fichiers.
A noter que le système de 'recouvrement de clés' permet de retrouver les clés de session ( uniques par fichier ) des fichiers, pour décoder ceux-ci mais ne donne aucune information sur la clé privée de l'utilisateur, afin que celle-ci ne puisse pas être diffusée par un opérateur de 'recouvrement de clés' malveillant.
Autre chose importante, Microsoft a également pensé aux temps de codage/décodage pour les fichiers. Lorsqu'il s'agit de bases de données partagées par divers utilisateurs, si le système devait décoder toute la base puis la recoder à chaque fois, cela prendrait énormément de temps.
Le système EFS, travaillant au niveau des secteurs du disque dur, il n'est pas capable d'interpréter le contenu des fichiers pour voir s'il s'agit d'un texte, d'une image ou d'une base de données. Microsoft a donc intégré un système permettant de ne décoder qu'une partie du fichier si nécessaire ( comme les enregistrements d'une base de données).
Le système paraît être extrêmement sûr et va clouer définitivement la bouche de tous les opposants ê Microsoft ... A moins que ...
Eh oui, pour rester honnête il faut indiquer que pour le moment tous les systèmes de chiffrement qui sortent des Etats-Unis ne peuvent disposer que de 40 bits pour les clés de session ( DES-40 ) Ainsi, un pirate pourra toujours passer quelques jours à rechercher toutes les clés de session possibles pour décrypter le fichier et ceci sans devoir s'attaquer à la clé privée de l'utilisateur.
Cependant, Microsoft est en train de négocier avec le gouvernement américain l'autorisation d'exporter son système avec 56 bits ( DES-56 ). S'il y parvient ce système pourra alors sûrement être utilisé tel quel en France puisque le Premier Ministre a annoncé récemment que les clés de 56 bits allaient être légalisées. ( NB : Depuis Mars 1999, les clés de 128 bits sont autorisées en France mais les américains ne peuvent exporter de systèmes avec des clés de plus de 40 bits. Il faut bien que la NSA puisse décoder )
Enfin dernier problème, si le système permet de décoder des parties de fichiers sans devoir décoder tout le fichier, cela donne une porte d'entrée aux pirates. Le système DES utilise une clé de 56 bits pour crypter un bloc de 8 octets ( 64 bits ). Le bloc crypté de 8 octets dépend alors entièrement du texte clair et de la clé.
Le système DES n'est vraiment fiable que s'il est utilisé avec une clé de session unique ( ce qui est le cas ) et en mode CBC ( Cipher Block Chaining ), mode oó le résultat du cryptage des 8 octets précédents est combiné par XOR avec les 8 octets clairs suivants qui vont alors être eux-màme cryptés ... et ainsi de suite jusqu'à la fin du fichier.
Le mode CBC ne permet cependant pas de décrypter une portion de fichier : tout le fichier doit être décodé ou rien ne pourra l'àtre.
Si le système DES est utilisé en mode EBC ( Electronic CodeBook ) oó chaque portion de 8 octets est codée par la même clé de session mais sans chaînage entre les blocs, ceci permet de décoder des portions de fichier par blocs de 8 octets mais permet également des attaques par les pirates sur les bouts de 8 octets qui sont indépendants les uns des autres et codés avec la même clé.
Microsoft ne donne pas de détails, pour le moment, sur le mode utilisé. Espérons qu'ils y ont réfléchi un peu et qu'ils utilisent un système fiable mixant les deux : au lieu de crypter les blocs de 8 octets en mode EBC, on code les blocs de 8 octets en mode CBC jusqu'à concurrence de 512 octets ( taille d'un secteur ). Chaque secteur du fichier sera alors codé avec la même clé de session, ce qui permet d'accéder à des portions de fichier par blocs de 512 octets mais en même temps rend beaucoup plus difficile une attaque sur les différents blocs de 512 octets qui sont bien plus gros qu'un simple bloc de 8 octets.
Après vérification Windows NT 5.0 utilise bien le mode CBC avec les algorithmes suivants ( DES-40 bits pour l'export et DES-56 et 3-DES 168 bits pour les USA et le Canada ). Microsoft utilise le mode CBC en cryptant les informations secteur par secteur ( du disque dur ) et non pas fichier par fichier. Ceci permet l'acces aleatoire dans base de données, sans perte de performance ( sans devoir décoder toute la base entière ).
Mais n'oublions pas que lorsqu'un nouveau système sort, les pirates inventent de nouvelles techniques.
On peut augurer que la lutte du " canon contre la cuirasse " continuera encore longtemps.
Alexandre PUKALL
