La seconde partie de l’audit de TrueCrypt était très attendue, et elle a fini par livrer ses conclusions : il n’y a aucune faille majeure ni la moindre porte dérobée dans le code. Ce qui ne veut pas dire pourtant qu’il n’existe aucun problème de sécurité. Alors que la réécriture du fork CipherShed progresse, les développeurs devraient tenir compte de plusieurs points soulignés dans le rapport.
Pas de porte dérobée dans TrueCrypt
En mai dernier, l’équipe de développement de TrueCrypt mettait brutalement un terme au projet, en annonçant d’une part qu’il n’y aurait plus de nouvelles versions, et d’autre part que l’outil de chiffrement BitLocker (intégré à Windows) était meilleur. Des déclarations qui avaient surpris et beaucoup s’étaient perdus en conjecture : influence de la NSA ? Pressions extérieures ? Abandon sincère ? Les réponses n’ont jamais été données, mais un audit, issu d'un financement participatif, avait quand même été lancé sur la version 7.1a.
Les conclusions en étaient très attendues puisque Cryptography Services, engagée pour mener l’opération à bien, devait plonger profondément dans le code pour en trouver tous les éventuels problèmes. Or, des problèmes, les consultants en ont trouvé, mais pas nécessairement ce que beaucoup imaginaient : aucune porte dérobée n’a été découverte, ni aucune faille majeure. La conclusion est donc simple et démonte finalement les théories de complots envers TrueCrypt. Elle correspond d'ailleurs à celle de l'ANSSI qui, en octobre 2013, avait conclu que cette même version 7.1a méritait une certification de premier niveau.
Plusieurs failles potentielles de sécurité
Mais le fait que TrueCrypt n’ait pas subi d’influence extérieure ou de sabotage ne veut pas dire que le code n’avait pas de problèmes. Cryptography Services (CS) en a trouvé essentiellement quatre, dont le plus important est l’utilisation d’une API Windows pour la génération des nombres aléatoires pour les clés maitresses de chiffrement. Selon les consultants, ce n’est en fait pas un souci dans la plupart des scénarios, mais au moins un cas atypique peut entrainer l’utilisation « de mauvaises sources d’entropie ». Ils ne ferment cependant pas la porte à d’autres scénarios de chiffrement qui pourraient également être concernés.
Parmi les autres problèmes soulevés, on notera que le déchiffrement des en-têtes de volumes s’appuie sur de mauvaises vérifications d’intégrité pour détecter les falsifications ou encore certaines implémentations d’AES pouvant entrainer des vulnérabilités face aux attaques temporelles, qui se basent sur le temps mis par certaines opérations de chiffrement pour fournir des renseignements sur le fonctionnement du mécanisme de défense.
Simplifier le code et corriger les problèmes
Les recommandations de CS sont donc là. D’une part, continuer l’analyse du code effectuée notamment dans le cadre des forks et donc des réécritures de certaines fonctionnalités. La logique du logiciel devrait également être simplifiée : « La multitude de formats, de chiffrements et de cascades augmente la complexité de l’application et la rend plus difficile à vérifier ». L’équipe de consultants indique par exemple que le code visant certaines accélérations matérielles représente « une exception raisonnable » aux redondances, mais que les cascades devraient être éliminées.
CS recommande en outre que TrueCrypt et tous les projets qui en sont dérivés soient munis d’un système de gestion beaucoup plus robuste. Ainsi, s’il n’est pas impossible que le logiciel plante, son caractère critique implique par exemple une collecte des informations liées aux problèmes rencontrés et leur envoi aux développeurs pour analyse. « Ceci est d’autant plus utile qu’il est difficile de tester complètement le code sur de multiples systèmes d’exploitation et configurations ».
Aucune urgence à se débarrasser de TrueCrypt dans l'immédiat
Quelles conclusions tirer pour les utilisateurs actuels et les projets qui reprennent le code source de TrueCrypt ? D’une part, qu’il n’y a aucune urgence à se débarrasser du logiciel, puisqu’il n’existe aucune porte dérobée ni faille majeure. Les autres menaces mentionnées sont jugées peu probables, mais sont quand même là. De fait, pour des solutions CipherShed et VeraCrypt, cela signifie des aménagements pour tenir compte du rapport d’audit.
Si le premier n’est toujours pas disponible, le second est proposé depuis plusieurs mois. Ses développeurs ont d’ailleurs publié hier une nouvelle mouture (estampillée 1.0f-2) pour incorporer un correctif sur l’appel à l’API Windows. Pour le reste, notamment l’implémentation d’AES, tout figure sur la liste des corrections à apporter plus tard. Les attaques temporelles visent essentiellement, selon les développeurs, des environnements serveurs partagés, une situation qui n’est en fait pas recommandée pour l’utilisation du logiciel. Des solutions seront quand même cherchées, notamment avec d’autres projets open source.
Notez en outre que la nouvelle version de VeraCrypt ajoute la possibilité de monter des partitions systèmes chiffrées avec TrueCrypt sous Windows, ce qui n’était pas possible jusqu’à présent. Les volumes classiques étaient, quant à eux, déjà supportés. Pour ces derniers, les performances ont été augmentées de 20 % sur les systèmes 64 bits.
