HSC
Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > Techno-Watch > Analyse du produit Security Box Classic - Versions 2.5 et 2.6
Go to: HSC Trainings
Télécharger le catalogue des formations
Search:  
Version française
   Services   
o Skills & Expertise
o Consulting
o ISO 27001 services
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o ARJEL
o Training courses
o E-learning
   Conferences   
o Agenda
o Past events
o Tutorials
   Resources   
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
   Company   
o Hervé Schauer
o Team
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
 communication
 
 
o HSC Newsletter
o Bulletin juridique HSC
o Press review
o Press releases
o Publications
   Contacts   
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|Analyse du produit Security Box Classic
Versions 2.5 et 2.6  
> Description Ce document est le compte-rendu brut d'une analyse rapide du fonctionnement interne du produit Security Box Classic édité par la société MSI.

Les éléments utilisés pour réaliser cette étude ont été :

  • Windows
  • Documentation et versions d'évaluation 2.5a, 2.6 et 2.6b du produit
  • Editeur hexadécimal

    Le but de cette analyse était de rassembler un maximum d'informations sur le fonctionnement du produit en un temps réduit et avec les moyens simples mentionnés ci-dessus.  

  • > Avertissements Ce document se présente sous la forme de notes structurées et non d'un résumé : les informations concernant un même point sont donc réparties à plusieurs endroits dans le document.
    Une grande partie des informations ci-dessous sont des suppositions faisant suite à une analyse rapide ; elles peuvent donc s'avérer erronnées.
    Cette étude est une simple analyse fonctionnelle et non une évaluation du produit.
    Voir aussi les informations légales sur ce site.  
    > Table des matières Présentation du produit

    Données utilisateur et principe général de chiffrement
        Données utilisateur
        Rôle du mot de passe utilisateur
        Rôle du diversifiant
        Rôle du mot de passe de fichier auto-décryptable
        Gestion des clefs de chiffrement des données
        Résumé du fonctionnement

    Analyse de l'organisation des fichiers chiffrés
        Fichiers locaux
        Fichiers auto-décryptables

    Détermination des algorithmes utilisés
        Chiffrement
        Intégrité

    Bilan  

    > Historique Version 1.2 - 23/09/99 - Reformulations diverses
    Version 1.1 - 18/09/99 - Première publication, avec mise à jour pour Security Box Classic 2.6b
    Version 1.0 - 18/03/99 - Analyse de Security Box Classic 2.5a et 2.6  
    > Auteur Ghislaine Labouret  
    > Copyright © 1999, Hervé Schauer Consultants, all rights reserved.

     


    Présentation du produit

    Security Box Classic permet principalement deux choses :

    • Chiffrement de fichiers en local ; le fichier résultant a le même nom que l'original.
    • Génération, à partir d'un fichier en clair, d'un exécutable contenant le fichier original chiffré sous forme auto-extractible ; ces fichiers sont appelés auto-décryptables (sic).

    La version 2.5 de Security Box utilise du chiffrement en DES simple ; la version 2.6 permet de choisir entre DES simple et DES triple. Au niveau du mode de fonctionnement comme de l'organisation des fichiers chiffrés, la version 2.5 est en fait équivalente à la version 2.6 en mode DES simple.


    Données utilisateur et principe général de chiffrement

    Données utilisateur

    L'utilisation du produit passe par la création d'un utilisateur Security Box. A chaque utilisateur est associé :

    • un login de 8 caractères maximum ;
    • un mot de passe utilisateur, comportant 6 à 15 caractères dont au moins un caractère non inclus dans [a-z|A-Z] (tous les caractères du clavier français semblent être acceptés) ;
    • un second élément appelé diversifiant et comportant de 4 à 32 caractères ;
    • en version 2.6, le fait de savoir si l'utilisateur utilise chiffre en DES simple ou en DES triple.

    Indépendamment de ces données propres à un utilisateur, chaque fichier auto-extractible est protégé par un mot de passe choisi par l'utilisateur lors de sa génération. Ce mot de passe comporte entre 8 et 32 caractères. Tous les caractères du clavier français, à l'exception des majuscules, semblent être accepté.

    Le programme crée un fichier de configuration par utilisateur, appelé login.USR et situé dans le répertoire d'installation du programme, qui contient les éléments suivants :

    Mode DES simple (versions 2.5 et 2.6)

    login.USR contient un champ appelé Key (exemple : Key=C75D9D8E476C8B80 F592411465302EB7). Ce champ est toujours composé de 16 octets codés en hexadécimal, quelle que soit la taille du mot de passe utilisateur et du diversifiant.

    • Les 8 derniers octets dépendent uniquement du mot de passe.

    • Les 8 premiers octets champ Key dépendent du mot de passe et du diversifiant ; ils ne dépendent ni du nom d'utilisateur, ni d'un sel : deux utilisateurs qui ont le même mot de passe et le même diversifiant se retrouvent avec les mêmes 8 premiers octets.

    En résumé, Key = f(diversifiant, mot de passe) | g(mot de passe)

    Ce champ est le même pour un utilisateur 2.5 et un utilisateur 2.6 ayant le même diversifiant et le même mot de passe. Il est donc construit de la même façon. En revanche, le champ Key d'un utilisateur DES triple est, avec les même paramètres, totalement différent.

    Mode DES triple (version 2.6)

    login.USR contient :
    • un champ appelé Key (exemple : Key=A750ECBD8DFCA40E 04DAD5ECCD4B4604).
      Ce champ est toujours composé de 16 octets codés en hexadécimal, quelle que soit la taille du mot de passe utilisateur et du diversifiant.
      • Les 8 derniers octets sont constants (04DAD5ECCD4B4604 pour les tests effectués).
      • Les 8 premiers octets dépendent uniquement du diversifiant.
      En résumé, Key = f(diversifiant) | 04DAD5ECCD4B4604.
      Supprimer ou modifier le champ Key du fichier login.USR n'a aucun effet sur le fonctionnement du logiciel. Ce champ n'est donc apparemment pas utilisé.

    • un champ appelé Key3 (exemple : Key3=803FCAEF4DCDBBAE42ACBBB146BDC5B4B89B0034FAEA08B8 A2A8DA2734390A87).
      Ce champ est toujours composé de 32 octets codés en hexadécimal, quelle que soit la taille du mot de passe utilisateur et du diversifiant.
      • Les 8 derniers octets dépendent uniquement du mot de passe.
        Un même mot de passe ne donne pas la même empreinte en DES simple (champ Key) et en DES triple, donc la fonction de condensation utilisée n'est pas la même dans les deux cas.
      • Les 24 premiers octets dépendent du mot de passe et du diversifiant ; ils ne dépendent ni du nom d'utilisateur, ni d'un sel : deux utilisateurs qui ont le même mot de passe et le même diversifiant se retrouvent avec les mêmes 24 premiers octets.
      En résumé, Key3 = f(diversifiant, mot de passe) | g(mot de passe)

    Rôle du mot de passe utilisateur

    Il est possible de changer de mot de passe utilisateur sans que cela n'empêche de déchiffrer des fichiers chiffrés lorsque l'ancien mot de passe était en place, et il est possible de récupérer les fichiers chiffrés en connaissant juste le diversifiant (en créant un nouveau compte avec ce diversifiant). Donc le mot de passe utilisateur n'intervient pas du tout dans le chiffrement des données. Il sert uniquement à :

    • Contrôler l'utilisation du logiciel, puisque tout utilisateur potentiel doit s'authentifier par login + mot de passe ;
    • Protéger en confidentialité un élément dérivé du diversifiant, que nous appelerons D.

    Les champs Key (DES simple) et Key3 (DES triple) doivent probablement contenir :

    • 8/24 premiers octets (champ K1) : une donnée permettant de retrouver D en connaissant le mot de passe, par exemple D chiffré avec une clef dérivée du mot de passe.
    • 8 derniers octets (champ K2) : un élément dérivé du mot de mot de passe et permettant de vérifier la validité du mot de passe fourni par l'utilisateur au lancement du programme.

    Si l'on suit cette hypothèse, alors il est probable que, lorsque l'utilisateur entre son mot de passe :

    • L'exactitude du mot de passe est vérifiée en recalculant les 8 derniers octets du champ Key ou Key3.
      Avec la version 2.5, un autre mécanisme de vérification est également mis en oeuvre, car changer ces 8 octets dans le fichier utilisateur ne suffit pas pour accéder à Security Box avec le mot de passe correspondant : celui-ci et l'ancien mot de passe sont tous deux refusés. En revanche, avec la version 2.6, cette vérification est la seule mise en oeuvre, car remplacer le bloc en question par un autre permet d'accéder au programme avec le mot de passe du nouveau bloc. Il va de soi que D ne sera alors pas déchiffré correctement et qu'une erreur se produira lors des tentatives de déchiffrement de fichiers chiffrés précédemment.

    • D est déchiffré ; lui seul sera utilisé pour les opérations de chiffrement/déchiffrement de fichiers.

    Remarque relative à la sécurité du mot de passe :

    Si un attaquant connaît l'algorithme exact utilisé pour le calcul de K2, il lui sera possible d'utiliser ce champ pour tenter de deviner le mot de passe, au moyen d'une attaque par dictionnaire par exemple.

    Suivant l'algorithme de dérivation utilisé, une telle attaque est plus ou moins réaliste. Il est donc probable que l'algorithme de dérivation a été choisi afin de limiter l'impact de ce type d'attaque. Il est par exemple possible de jouer sur :

    • La fréquence des collisions :
      Une collision a lieu lorsque plusieurs mots de passe donnent un même champ K2. L'algorithme utilisé peut présenter comme propriété le fait que les collisions soient fréquentes. Lorsque l'attaquant trouvera un mot de passe qui se dérive en K2, il ne sera alors pas du tout sûr d'avoir trouvé le bon mot de passe car il sera peut-être simplement tombé sur un de ses synonymes. Il devra alors mettre en oeuvre une autre vérification (comme utiliser ce mot de passe pour lancer Security Box et tenter de faire déchiffrer un fichier), ce qui lui fera perdre du temps et rendra donc l'attaque plus longue.
    • Le temps de calcul nécessaire :
      Suivant la méthode de dérivation utilisée, le calcul du champ K2 à partir du mot de passe sera plus ou moins long. Allonger ce temps de calcul ne pénalise pas beaucoup l'utilisateur à la connexion mais rend l'attaque plus fastidieuse. Au delà d'un certain temps, elle perd son intérêt.

    Cependant, comme aucun sel n'est utilisé, l'attaque peut se faire avec précalcul, c'est-à-dire que l'attaquant peut calculer une seule fois pour toutes une liste de couple (mot de passe, transformée), puis utiliser cette liste pour tenter de deviner les mots de passe de différents utilisateurs. Accessoirement, l'absence de sel implique également que si deux utilisateurs ont le même mot de passe, l'accès au fichier login.USR de l'autre permet de s'en rendre compte tout de suite et de tirer parti de cette coïncidence pour se faire passer pour lui et déchiffrer ses fichier.

    Il va de soi que le choix d'un mot de passe suffisamment long et complexe permettra de contrer une attaque contre celui-ci.

    Rôle du mot de passe de fichier auto-décryptable

    Pour déchiffrer un fichier auto-décryptable, il suffit de connaître le mot de passe ayant servi à protéger ce fichier.

    Le mot de passe utilisé pour protéger un fichier auto-décryptable comporte entre 8 et 32 caractères ; tous les caractères du clavier français sont utilisables, à l'exception des lettres majuscules.

    Security Box Classic possède une fonction qui permet à l'utilisateur ayant généré l'auto-décryptable de récupérer le mot de passe en cas d'oubli.

    Un mot de passe donné semble toujours être représenté, dans l'auto-décryptable, par un même bloc de 8 octets, et ce quel que soit le fichier chiffré et l'utilisateur qui l'a généré (voir plus loin, "analyse du contenu des fichiers").

    Remarque relative à la sécurité du mot de passe : voir paragraphe similaire ci-dessus.

    Le mot de passe peut comporter jusqu'à 32 caractères alors que le champ identifié ci-dessus n'en comporte que 8. Comme il est possible de récupérer le mot de passe d'un auto-décryptable par le menu adapté dans l'interface Security Box, cette zone n'est pas la seule à comporter des informations sur le mot de passe.

    Rôle du diversifiant

    Fichiers locaux

    Le diversifiant (ou plutôt son dérivé D) est le seul élément nécessaire pour pouvoir déchiffrer des fichiers chiffrés en local.

    Deux utilisateurs distincts qui ont le même diversifiant ne peuvent néanmoins pas déchiffrer les fichiers l'un de l'autre car le login du propriétaire est stocké dans le fichier chiffré et protégé en intégrité. Il est toutefois possible de contourner cette restriction, soit en modifiant le nom de son fichier .USR pour changer de login, soit en désactivant la vérification de l'intégrité du fichier chiffré (voir plus loin).

    Fichiers auto-décryptables

    Security Box possède une fonction de récupération du mot de passe protégeant un auto-décryptable. Pour que cette fonction fournisse un résultat, il faut et il suffit que le diversifiant de l'utilisateur qui y fait appel soit le même que le diversifiant de l'utilisateur qui a généré l'auto-décryptable. D joue donc également un rôle dans la génération des auto-décryptables.

    Deux utilisateurs distincts qui ont le même diversifiant peuvent récupérer le mot de passe d'un auto-décryptable généré par l'autre : le nom de l'utilisateur qui a généré l'auto-décryptable n'est pas stocké dans ce fichier.

    Conséquences du rôle du diversifiant

    L'avantage de ne pas faire dépendre le chiffrement des fichiers locaux du mot de passe utilisateur est que l'utilisateur peut changer de mot de passe sans avoir à rechiffrer tous ses fichiers.

    De plus, si un utilisateur oublie son mot de passe, il lui suffit de recréer un compte avec le même login, le même diversifiant et un nouveau mot de passe pour accéder de nouveau à ses fichiers chiffrés.

    Le revers de la médaille est que, si Alice connaît le diversifiant de l'utilisateur Bob, alors elle peut créer sur sa machine un utilisateur Security Box ayant le même diversifiant, le même login et un mot de passe de son choix, puis utiliser le logiciel pour déchiffrer les fichiers chiffrés par Bob. Le secret du diversifiant est donc primordial.

    D'autre part, si Alice connaît le fichier .USR de Bob et a réussi à trouver son mot de passe, elle peut se faire passer pour lui auprès du logiciel. En recopiant le fichier bob.USR sur sa machine, elle conserve la possibilité de déchiffrer les fichiers de Bob même s'il change de mot de passe par la suite.

    Gestion des clefs de chiffrement des données

    Pour les fichiers locaux comme pour les auto-décryptables, chiffrer deux fois de suite le même fichier, dans les mêmes conditions, donne des cryptogrammes différents. Une nouvelle clef de chiffrement (et/ou un nouveau vecteur d'initialisation) est donc générée à chaque fois. Aucune information sur le type de générateur utilisé n'est disponible.

    Les fichiers chiffrés peuvent être déplacés et aucune information de déchiffrement (autre que le diversifiant) n'est stockée dans un fichier global comme le fichier de configuration utilisateur. L'ensemble des données nécessaires au déchiffrement (clef, vecteur d'initialisation... à l'exception du diversifiant) est donc déductible, pour le logiciel, à partir du fichier chiffré.

    Résumé du fonctionnement

    Fichier local

    1. Pour chiffrer un fichier, Security Box génère une clef et chiffre le fichier avec.
    2. Une donnée permettant de recalculer cette clef en connaissant le dérivé D du diversifiant est stockée avec le fichier chiffré.
    3. D, quant-à-lui, est chiffré avec une clef dérivée du mot de passe et stocké sous forme hexadécimale dans le fichier de configuration de l'utilisateur (début des champs Key et Key3).

    Autrement dit :

    1. Une clef de chiffrement différente protège chaque fichier
    2. Un dérivé du diversifiant protège toutes les clefs de chiffrement
    3. Un mot de passe protège le dérivé du diversifiant

    On retrouve là les trois anneaux de protection mentionnés dans la documentation du produit. Il va de soi que casser l'anneau extérieur (mot de passe) fait tomber toutes les protections.

    Fichier auto-décryptable

    1. Pour chiffrer un fichier, Security Box génère une clef et chiffre les données avec.
    2. Une donnée permettant de recalculer cette clef en connaissant le mot de passe associé à l'auto-décryptable est stockée avec le fichier chiffré.
    3. Le mot de passe est également stocké dans l'auto-décryptable sous forme chiffrée, pour la fonction de récupération du mot de passe.
    4. Un autre champ contient également un dérivé du mot de passe de 8 octets de long.

    Fichiers locaux

    Contenu d'un fichier chiffré

    • Le cryptogramme, qui comporte un nombre d'octets égal au nombre d'octets du texte en clair.
    • Une série de x00 (121 en DES simple, 97 en DES triple).
    • [DES triple seulement] 24 octets qui varient à chaque fois [Champ A3]
    • 4 octets qui varient à chaque fois et qui ne sont pas nécessaires au déchiffrement (cf. test de mise à zéro ci-dessous) [Champ B]
    • L'extension du fichier, sur 3 octets (par exemple, txt) ou x00 x00 x00 si elle fait plus de trois caractères.
    • x20 x00.
    • Le login de l'utilisateur SBox qui a chiffré le fichier, sur 8 octets (complété par des x00 si moins de 8 caractères).
    • x00 x00.
    • La longueur du cryptogramme en hexadécimal, codée à l'envers sur 4 octet (exemple : texte en clair de longueur x0177 : le fichier chiffré contient x77 x01 x00 x00).
    • [DES triple seulement] x03 x00 x00 x00 x65 x00 x3A x00.
    • [DES simple seulement] 8 octets qui varient à chaque fois ; modifier ce champ fait échouer le déchiffrement. [Champ A1]
    • 16 octets qui varient à chaque fois ; modifier ce champ fait échouer le déchiffrement. [Champ C]
    • 6F 4A 18 F1 7A 77 2F 20 (oJ..zw/ ).
    • 128 octets (1024 bits) qui varient à chaque fois et ne sont pas nécessaires au déchiffrement (cf. test de mise à zéro ci-dessous) : clef de chiffrement chiffrée en RSA 1024 pour recouvrement/séquestre ? [Champ D]
    • Le numéro de version apparent de Security Box sur 3 octets, soit 32 2E 35 (2.5) ou 32 2E 36 (2.6). Ce numéro semble être prévu pour gérer la compatibilité entre versions, le diminuer désactive le contrôle d'intégrité (cf. ci-dessous).
    • 5 octets x00.
    • Le numéro de version réel de Security Box sur 4 octets, soit x00 x00 x02 x01 en DES simple et x00 x00 x02 x02 en DES triple ; ce numéro est utilisé pour savoir comment traiter le fichier.
    • Le nom du produit, soit ici 4D 53 49 20 53 44 4D 20 53 65 63 20 42 6F 78 (MSI SDM Sec Box)
    • x00
    Quelque part dans les blocs non identifiés, il doit y avoir :
    • un vecteur d'initialisation pour le chiffrement des données (facultatif),
    • des données permettant de retrouver la clef de chiffrement en connaissant le dérivé D du diversifiant,
    • des données protégeant le fichier en intégrité,
    • des données pour recouvrement/séquestre.
    A priori, je dirais (il s'agit de suppositions non vérifiées) :
    • Vecteur d'initialisation implicite et sans doute fixe (ne pose aucun problème compte-tenu du fait que la clef de chiffrement change à chaque fois).
    • Champs A1 (8 octets) et A3 (24 octets) : la clef de chiffrement de données, chiffrée respectivement en DES ou 3DES avec une clef dérivée de D (il fait aussi 8/24 octets...).
    • Champ B (4 octets) : ?, inutile au déchiffrement.
    • Champ C (16 octets) : sceau, la fonction de hachage étant probablement MD5 (la taille de l'empreinte est de 128 bits avec MD5)
    • Champ D (1024 bits) : recouvrement (RSA 1024 bits).

    Protection en intégrité et conséquences de modifications

    La liste ci-dessous résume la présence ou non de protection pour les différents champs d'un fichier et les conséquences d'une modification de ce champ :

    Champ Protection Conséquences d'une modification
    Cryptogramme (blocs complets) Non protégé directement par le sceau, mais détection d'erreur
    Modification de bits
    Pas d'erreur de sceau, mais en fin de déchiffrement s'affiche "le déchiffrement du fichier a échoué : votre fichier est endommagé ou les éléments de sécurité de votre compte sont erronés"
    Ajout ou suppression d'un octet
    Sans modification du champ longueur : erreur dans le traitement du fichier ; avec modification du champ longueur : erreur de sceau ou erreur de déchiffrement si contrôle d'intégrité désactivé.
    Cryptogramme (dernier bloc si incomplet) Pas de protection Une modification d'un bit entraîne la modification du bit correspondant dans le texte en clair.
    Le déchiffrement de ce bloc se termine visiblement par un XOR avec cette partie du cryptogramme.
    Série de x00 Protégé * Erreur de sceau
    Champ A3 (24 octets)
    Clef 3DES
    Protégé * Erreur de sceau.
    Erreur de déchiffrement si contrôle d'intégrité désactivé
    Champ B (4 octets)
    ?
    Protégé * Erreur de sceau
    Modification sans conséquence si contrôle d'intégrité désactivé
    Extension du fichier (3 octets) Protégé * Erreur de sceau
    Modification sans conséquence si contrôle d'intégrité désactivé
    x20 x00 Protégé * Erreur de sceau
    Login (8 octets) Protégé * Avec un mauvais nom d'utilisateur : "Le fichier xxx a été chiffré par l'utilisateur yyy".
    Avec le bon login : erreur de sceau ou fonctionnement normal si contrôle d'intégrité désactivé.
    x00 x00 Protégé * Erreur de sceau
    Longueur du cryptogramme Protégé * Sans modification de la longueur du cryptogramme en conséquence : erreur lors du traitement du fichier.
    Avec modification adaptée, erreur de sceau ou erreur de déchiffrement si contrôle d'intégrité désactivé.
    x03 x00 x00 x00 x65 x00 x3A x00 Protégé * Erreur de sceau.
    Modification sans conséquence si contrôle d'intégrité désactivé.
    Champ A1 (8 octets)
    Clef DES
    Protégé * Erreur de sceau.
    Erreur de déchiffrement si contrôle d'intégrité désactivé.
    Champ C (16 octets)
    Sceau
    Protégé * Erreur de sceau.
    Erreur de déchiffrement si contrôle d'intégrité désactivé.
    6F 4A 18 F1 7A 77 2F 20 (oJ..zw/ ) Protégé * Erreur de sceau.
    Modification sans conséquence si contrôle d'intégrité désactivé.
    Champ D (128 octets)
    Recouvrement/séquestre
    Protégé * Erreur de sceau
    Modification sans conséquence si contrôle d'intégrité désactivé, donc ce champ ne sert pas au déchiffrement.
    Numéro de version apparent (3 octets) Partiellement protégé Si nouveau numéro < numéro de version utilisée, désactivation de la vérification du sceau et fonctionnement normal car c'est le numéro réel et non le numéro apparent de version qui est utilisé pour décider comment traiter le fichier.
    Sinon, erreur de sceau.
    5 octets x00 Protégé * Erreur de sceau.
    Numéro de version réel Non protégé Modification des deux premiers octets sans conséquence.
    Modification des deux derniers octets : "Le fichier a été chiffré avec la version :", "Le fichier a été chiffré avec une version incompatible :".
    Si version = x00 x00 x02 x02 en version 2.6 DES simple : Erreur de sceau
    Occasionnellement en version 2.5, plantage de l'application par violation d'accès.
    Nom du produit Non protégé Non-détection du fait que le fichier est déjà chiffré et rechiffrement
    x00 Non protégé Non détection du fait que le fichier est déjà chiffré et rechiffrement

    L'ordre d'apparition des messages d'erreur révèle que la vérification du sceau est effectuée avant le déchiffrement des données.

    La détection des erreurs de déchiffrement intervient en fin de déchiffrement. Elle semble faire intervenir le champ identifié comme contenant a priori le sceau (champ C), car modifier ce champ seul entraîne une erreur de déchiffrement.

    * La diminution du numéro de version a pour effet de désactiver la vérification du sceau.

    Fichiers auto-décryptables

    Contenu d'un auto-décryptables

    Un auto-décryptable se compose du programme de déchiffrement, suivi d'une zone de données qui comporte les données protégées et les éléments permettant de les déchiffrer/vérifier. Cette zone commence à l'octet x8E00 en version 2.5 et x9A00 en version 2.6 ; elle contient :
    • Le cryptogramme, qui comporte un nombre d'octets égal au nombre d'octets du texte en clair.
    • x2E
    • L'extension du fichier sur 3 octets (par exemple, txt) ou x00 x00 x00 si elle fait plus de trois caractères.
    • Un groupe d'octets qui varient à chaque fois : 16+8 en DES simple, 16+3x8 en DES triple. [Champ A]
    • Un dérivé du mot de passe protégeant le fichier, sur 8 octets. La valeur de ce champ, tous paramètres égaux, n'est pas la même en DES et en 3DES.
      Ce champ est probablement utilisé pour vérifier le mot de passe fourni par l'utilisateur qui demande le déchiffrement sans avoir à se lancer dans le déchiffrement, lequel peut-être long.
    • 4 octets qui varient à chaque fois. [Champ B]
    • La longueur du cryptogramme en hexadécimal, codée à l'envers sur 4 octet (exemple : texte en clair de longueur x0177 : le fichier chiffré contient x77 x01 x00 x00)
    • 6F 4A 18 F1 7A 77 2F 20 (oJ..zw/ )
    • 88 octets qui varient à chaque fois. [Champ C].
    • Numéro de version : DES simple x01 x00 / DES triple x01 x01
    • Le nom du produit, soit ici 53 65 63 75 72 69 74 79 20 42 6F 78 20 41 75 74 6F 44 65 63 72 79 70 74 20 46 69 6C 65 (Security Box AutoDecrypt File)
    • x00

    Quelque part dans les blocs non identifiés, il doit y avoir :

    • un vecteur d'initialisation pour le chiffrement des données (facultatif),
    • des données permettant de retrouver la clef de chiffrement en connaissant le mot de passe qui protège le fichier,
    • des données protégeant le fichier en intégrité,
    • des données permettant de retrouver le mot de passe dans son intégralité en connaissant D (rappel : le mot de passe peut comporter jusqu'à 32 caractères),
    • des données de recouvrement/séquestre.
    A priori, je dirais (il s'agit de suppositions non vérifiées) :
    • Vecteur d'initialisation implicite et sans doute fixe (ne pose aucun problème compte-tenu du fait que la clef de chiffrement change à chaque fois).
    • Champs A1 (16+8 octets) et A3 (16+3x8 octets) : 16 octets pour le sceau (MD5) et le reste pour la clef de chiffrement de données chiffrée.
    • Champ B (4 octets) : ?
    • Champ C (88 octets) : Vu le manque de place pour un chiffrement RSA, je penche pour le mot de passe chiffré avec le dérivé du diversifiant de l'utilisateur d'une part, et avec un dérivé de diversifiant de séquestre/recouvrement d'autre part + des sceaux pour vérifier la validité des dérivés de diversifiant. Si je compte 32 octets (4 blocs DES) pour le mot de passe, cela fait 2 x (32 + 12), donc un sceau de 96 bits : c'est cohérent... l'algorithme pourrait être par exemple HMAC-MD5-96 ou HMAC-SHA-1-96. Ce pourrait bien sûr être quelque chose de complètement différent.

    Conséquences de modifications

    La liste ci-dessous résume les conséquences d'une modification pour les différents champs de la zone de données :

    Champ Protection Conséquences d'une modification
    Cryptogramme (blocs complets) Détection d'erreur en fin de déchiffrement "Le fichier a été endommagé"
    Cryptogramme (dernier bloc si incomplet) Pas de protection Une modification d'un bit entraîne la modification du bit correspondant dans le texte en clair.
    Le déchiffrement de cette partie se termine visiblement par un ou exclusif avec cette partie du cryptogramme.
    x2E Protégé "Le fichier a été endommagé"
    Extension du fichier (3 octets) Protégé "Le fichier a été endommagé"
    Champ A (24 en DES, 40 en 3DES)
    (Sceau et clef de chiffrement)
    Protégé "Le fichier a été endommagé"
    Empreinte du mot de passe (8 octets) Protégé "Le fichier a été endommagé"
    Champ B (4 octets)
    ?
    Protégé "Le fichier a été endommagé"
    Longueur du cryptogramme (4 octet) Protégé "Le fichier a été endommagé"
    6F 4A 18 F1 7A 77 2F 20 (oJ..zw/ ) Protégé "Le fichier a été endommagé"
    Champ C (88 octets)
    (Recouvrement du mot de passe)
    Protégé "Le fichier a été endommagé"
    Numéro de version Protégé "Le fichier a été endommagé"
    Le nom du produit, soit 53 65 63 75 72 69 74 79 20 42 6F 78 20 41 75 74 6F 44 65 63 72 79 70 74 20 46 69 6C 65 (Security Box AutoDecrypt File) Protégé sauf les deux derniers octets "Le fichier a été endommagé" ou fonctionnement normal pour les octets non protégés
    x00 Non protégé Fonctionnement normal

    Détermination des algorithmes utilisés

    Chiffrement

    La documentation du produit indique que l'algorithme utilisé pour le chiffrement des données est DES, simple ou triple à trois clefs suivant la version et l'option choisie.

    La variation du cryptogramme prouve l'utilisation d'un mode avec chaînage de blocs (CBC) ou rétroaction (OFB, CFB). CBC nettement plus probable pour du chiffrement de fichiers, et il a été mentionné publiquement par plusieurs personnes de chez MSI.

    Le cryptogramme a la même taille que le texte en clair, alors que DES est un algorithme de chiffrement par blocs de 8 octets, donc une méthode spécifique est utilisée à cet effet. Il pourrait a priori s'agir d'un méthode de type vol de texte chiffré (ciphertext stealing), mais la façon dont les modifications du bloc incomplet du cryptogramme influencent le texte en clair pointe vers une méthode comme celle décrite page 207 du livre "Cryptographie appliquée" de Bruce Schneier, où les derniers bits sont combinés par ou exclusif avec le dernier bloc de texte chiffré, préalablement surchiffré.

    DES est dans doute également l'algorithme utilisé pour le chiffrement du diversifiant avec une clef dérivée du mot de passe (condensé sur 8 octets), dans les champs Key et Key3.

    Pour les fichiers locaux, la clef de chiffrement est sans doute chiffrée d'une part avec le même algorithme que les données (DES ou 3DES), avec le diversifiant condensé comme clef (8 ou 24 octets), et d'autre part en RSA 1024 avec une clef publique de recouvrement.

    Intégrité

    L'intégrité des données est sans doute assurée avec un algorithme basé sur MD5. La question est de savoir si cette fonction est utilisée avec une clef, et si oui comment celle-ci est déterminée.


    Bilan

    Les informations réunies au cours de cette analyse ne sont pas suffisantes pour comprendre tous les aspects du fonctionnement du logiciel Security Box, et encore moins pour se prononcer sur la sécurité fournie.

    Par exemple, le chiffrement utilisé en version DES triple est fort, mais il est nécessaire que le générateur aléatoire utilisé pour générer les clefs de chiffrement soit à la hauteur. Donc il faudrait connaître la méthode utilisée pour générer les clefs.

    A l'issue de cette analyse rapide, l'attaque la plus évidente (au sens celle qu'un attaquant tentera probablement en premier) contre Security Box Classic semble être une attaque contre le mot de passe d'un utilisateur ou d'un auto-décryptable ou contre le diversifiant, par dictionnaire puis par recherche exhaustive. Dans tous les cas, il semble que cette attaque puisse se faire avec précalcul. Cependant, il est probable que les algorithmes de dérivation appliqués à ces éléments ont été choisis pour limiter ce type d'attaque. D'autre part, choisir des mots de passe et un diversifiant longs et complexes met à l'abris de cette attaque. Il est également possible d'éviter une attaque directe sur le diversifiant en supprimant, en mode DES triple, le champ Key qui n'est visiblement pas utilisé par le programme mais qui contient un dérivé du diversifiant.

    Qu'apporte cette attaque ?
    Menée sur un mot de passe utilisateur, cette attaque permet de récupérer le mot de passe, ce qui, associé à la connaissance du champ Key, permet de déchiffrer tous les fichiers chiffrés par cet utilisateur (y compris les auto-décryptables), et ce même après un changement de mot de passe.
    Menée sur le mot de passe d'un fichier auto-décryptable donné, cette attaque permet uniquement de retrouver le mot de passe qui a servi à sa protection et donc de déchiffrer le fichier en question.

    Comment peut être menée cette attaque ?
    Une première façon de mener cette attaque consiste à "patcher" le source de l'exécutable (Security Box ou auto-décryptable) pour :

  • rendre possible l'essai successif et automatisé de nombreux mots de passe par son intermédiaire.
  • qu'il génère automatiquement une liste de transformées de mots de passe.
    Cette méthode se heurte à un problème légal et serait d'ailleurs probablement trop lente.
    Une seconde méthode consiste à créer un programme qui, à partir des données correspondante (champ Key ou Key3, octets concernés de l'auto-décryptable), testera la validité d'une liste de mots de passe ou de diversifiants. Cette méthode nécessite de connaître avec exactitude l'algorithme employé pour le calcul de ces champs. Suivant les propriétés de ces algorithmes, elle est ou non réaliste.

    En second lieu, un attaquant tentera sans doute de tirer parti du fait que diminuer le numéro de version inscrit dans les fichiers chiffrés a pour conséquence de désactiver le contrôle d'intégrité. Un utilisateur peut également tirer parti de ce fait pour annuler le séquestre éventuel mis en oeuvre sur ses fichiers.

  • Last modified on 12 January 2005 at 17:05:36 CET - webmaster@hsc.fr
    Mentions légales - Information on this server - © 1989-2013 Hervé Schauer Consultants