VeraCrypt : un audit révèle plusieurs failles critiques, la version 1.19 en corrige la plupart

VeraMoitiéPlein ?

VeraCrypt : un audit révèle plusieurs failles critiques, la version 1.19 en corrige la plupart

VeraCrypt : un audit révèle plusieurs failles critiques, la version 1.19 en corrige la plupart

L'outil de chiffrement de disques VeraCrypt revient d'un audit en profondeur, qui a révélé plusieurs failles, dont certaines directement liées à l'entrée du mot de passe au démarrage. Avec la version 1.19, son développeur revoit et supprime certaines fonctions peu sûres, et corrige d'autres problèmes hérités de TrueCrypt.

VeraCrypt, successeur affiché de TrueCrypt, a encore quelques problèmes à régler. À la mi-août, son développeur principal Mounir Idrassi mettait en ligne la version 1.18, apportant le chiffrement UEFI et plusieurs algorithmes non-occidentaux. Comme il nous l'expliquait longuement, il espère imposer VeraCrypt comme un logiciel de confiance, ne tenant pas uniquement compte des outils occidentaux habituels.

Surtout, la version 1.18 était le point de départ d'un audit commandité par l'organisation OSTIF, et réalisé par la société française Quarkslab. Un audit qui s'est conclu le 14 septembre, sans que la société ne donne le détail des problèmes trouvés sur le coup. Il a fallu attendre hier, et la sortie de la version 1.19 de VeraCrypt, pour que les soucis détectés dans le logiciel soient révélés.

Une vingtaine de problèmes trouvés

Pour son étude, Quarkslab est parti de l'hypothèse d'un ordinateur portable perdu ou volé, dont un attaquant voudrait déchiffrer (ou décrypter) le disque dur. Au total, 26 failles ou soucis ont été trouvés, dont huit vulnérabilités critiques, qui demandaient à être corrigées avant d'être révélées. Si la vaste majorité d'entre eux ont été éliminés avec la version 1.19, « certains de ces problèmes n'ont pas été réglés, à cause de la forte complexité des corrections proposées, mais des contournements ont été ajoutés dans la documentation de VeraCrypt ».

Concrètement, la majorité des problèmes critiques concerne la rétention du mot de passe quand il est tapé, l'algorithme russe GOST 28147-89 (que l'équipe recommande de supprimer) et les outils de compression XZip et XUnzip. Certains soucis datent d'ailleurs de l'époque de TrueCrypt, dont une partie avait déjà été relevée lors de précédents audits.

Dans un billet de blog, Quarkslab affirme que les problèmes non-résolus réclament une modification importante du code ou de l'architecture du logiciel. L'implémentation d'AES est ainsi considérée comme un souci majeur, car sensible à des attaques liées au cache. Pour l'équipe, le projet avance tout de même dans la bonne direction, la compatibilité UEFI demandant encore du travail, « même si elle ne pose pas de problème d'un pur point de vue cryptographique ».

Ce dernier audit a d'ailleurs rendu ses commanditaires nerveux. L'organisation avait exploré publiquement la piste d'une ingérence étatique dans l'audit suite à la disparition d'emails... Avant que Quarkslab n'indique à Threatpost qu'il s'agissait en fait d'un simple problème d'envoi de messages. Dans son rapport d'audit (PDF), Quarkslab estime surtout que « l'audit régulier de projets de sécurité d'une telle complexité n'est pas une option ».

VeraCrypt 1.19 supprime un algorithme de chiffrement

La dernière version de l'outil, mise en ligne hier matin, règle donc une bonne partie des problèmes signalés dans l'audit. Les notes de version indiquent ainsi qu'une fuite de mot de passe dans le secteur de démarrage (MBR) « hérité de TrueCrypt » a été colmatée, tout comme plusieurs autres fuites. Le cache du clavier est aussi maintenant vidé une fois le mot de passe tapé. La bibliothèque de compression « vulnérable » XUnzip a été, elle, remplacée par libzip pour la gestion du fichier de secours (Rescue Disk).

Cette version supprime aussi la fonction de chiffrement de l'algorithme GOST 28147-89, mal implémenté... Même si celle de déchiffrement reste bien disponible. Mounir Idrassi a également nettoyé une partie du code et, cerise sur le gâteau, rendu le chiffrement UEFI compatible avec les systèmes Windows 32 bit. Contacté, il n'était pas encore disponible pour discuter de ces dernières nouvelles.

Commentaires (23)


“rendu le chiffrement UEFI compatible avec les systèmes Windows 32 bit”



J’ai du mal à comprendre là,  je croyais que l’UEFI ne permettait de booter que des OS 64bits?


Pour GOST c’est dommage, le but était justement d’implémenter des algos non occidentaux.

j’ai ouvert le doc pour voir, c’est imbitable (pour le commun des mortels). ^^


UEFI compilé en 64 bits = Windows x64 uniquement



Dans de rares petits PC ou tablettes, UEFI compilé en 32 bits = Windows x86 uniquement


D’acc merci, j’étais même pas au courant que l’UEFI puisse faire boot un OS 32 bits sur un dd en GPT. Mais ça a l’air rare comme cas.


Est-ce que l’ANSSI va qualifier cette version ?


Merci de l’infaux … a suivre !


” VeraMoitiéPlein ? “<img data-src=" />


Concernant l’implémentation d’AES, il est à noté quand même que non seulement c’est hérité de TrueCrypt, mais en plus si le CPU supporte AES-NI, l’attaque sur le cache n’est pas présente. Donc ça limite.

Ce qui est aussi rassurant c’est que à priori Mounir Idrassi est bien réceptif aux audits donc ça promet un bon suivi.


Marrant d’encore utiliser du vieux GOST en 2016…



Leur slogan aurait pu être “chiffrez comme des cochons avec VerratCrypt”…


C’est pas obligatoire en même temps hein <img data-src=" />








Vilainkrauko a écrit :



Merci de l’infaux … a suivre !





<img data-src=" />









ragoutoutou a écrit :



Marrant d’encore utiliser du vieux GOST en 2016…



Leur slogan aurait pu être “chiffrez comme des cochons avec VerratCrypt”…





<img data-src=" />



Non, mais c’est pas malin d’avoir laissé l’option si longtemps vu ce qu’on sait sur ce chiffrement…



Je comprend qu’on puisse avoir du mal psychologiquement à utiliser des standards de chiffrement promus par la NSA après tout ce qu’on a découvert ces dernières années, mais de là à confier ses données à un algo soviétique notoirement foireux…


De ce coté la c’est clair que je préfère envisager Camelia (aussi ajouté à Vera dernièrement) par exemple en remplacement, il a l’air sûr et moins dépendant de la NSA mais sa vitesse et son manque de support matériel l’empêche de vraiment décoller.








ragoutoutou a écrit :



Non, mais c’est pas malin d’avoir laissé l’option si longtemps vu ce qu’on sait sur ce chiffrement…





L’algo russe incriminé n’a été mis en place que depuis la version 1.18 (donc août de cette année). Je trouve que ça aurait pu être pire <img data-src=" />









hellmut a écrit :



Pour GOST c’est dommage, le but était justement d’implémenter des algos non occidentaux.

j’ai ouvert le doc pour voir, c’est imbitable (pour le commun des mortels). ^^





C’est un audit, et un audit de code qui plus est.



Le début c’est bitable, j’ai pas parcouru tout le doc par contre.





Jarodd a écrit :



Est-ce que l’ANSSI va qualifier cette version ?





Faut que l’ANSSI reçoive une demande pour le faire, c’est pas gratos.

En plus, la qualification n’est valable que dans un contexte bien défini généralement pour ce type de soft.

Usage X sur machine avec OS type Y et logiciel Z installés.









Etre_Libre a écrit :



UEFI compilé en 64 bits = Windows x64 uniquement



Dans de rares petits PC ou tablettes, UEFI compilé en 32 bits = Windows x86 uniquement





Oui, certaines tablettes sont en effet UEFI 32 bits, telle les certaines Lenovo Thinkpad 8 et 10 (sous windows 8.1 puis 10).

Mais en effet, le support logiciel n est pas terrible: par ex, pas moyen de restaurer une image complete du systeme avec Acronis True Image, car ce soft ne supporte pas l UEFI en 32 bits.





Retour au sujet avec les résultats présentés par les commendataires, l OSTIF:

https://ostif.org/the-veracrypt-audit-results/



Bcp de pb semblent être liés au chiffrement de la partition système, ce qui reste AMHA le plus délicat. Comme je me méfie du bordel que peut faire l’installeur de Windows, je préfère éviter le chiffrement de la partition système mais me concentrer sur les fichiers perso, soit en partition complète non sys, soit en conteneur.&nbsp;









EricB a écrit :



Comme je me méfie du bordel que peut faire l’installeur de Windows, je préfère éviter le chiffrement de la partition système mais me concentrer sur les fichiers perso, soit en partition complète non sys, soit en conteneur.







Perso je suis aussi suer méfiant d’un chiffrage intégral de ce type, mais c’est surtout car j’ai un très mauvais souvenir de FileVault, il y a longtemps, qui pouvait en cas de plantage au mauvais moment, rendre une session utilisateur indéchiffrable. Tu perdais alors tous tes docs perso. Au bout de la 2ème fois, j’ai abandonné l’idée, et j’ai pas osé retenter depuis, même avec un autre système style VeraCrypt ou Bitlocker.



Vera bien qui verra le dernier !



<img data-src=" />


Du coup ce qui ressort de l’audi est seulement lié à cet algo Russe ainsi qu’au chiffrement d’une partition complète. Rien à dire sur le chiffrement de fichier en conteneur ?


Pendant ce temps… à Vera Cruzypt

&nbsp;




… une fuite de mot de passe dans le secteur de démarrage (MBR) « hérité de TrueCrypt » …





Fix leak of password length in MBR bootloader inherited from TrueCrypt.



une fuite de la longueur du mot de passe dans le secteur de démarrage (MBR)



<img data-src=" />



Ctrl + F : “souci’

Bingo, encore un logiciel qui contient des soucis.

Bravo les mecs.


Fermer