Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Pas de porte dérobée dans TrueCrypt, mais des failles de sécurité

L'ombre désormais permanente de la NSA

Pas de porte dérobée dans TrueCrypt, mais des failles de sécurité

Le 17 avril 2014 à 06h20

TrueCrypt est un logiciel connu servant à chiffrer intégralement le contenu d’un disque dur ou d’un périphérique de stockage. Gratuit et open source, il fait l’objet d’un audit en deux parties, dont la première vient de révéler ses résultats : TrueCrypt ne contient aucune porte dérobée, mais plusieurs failles de sécurité ont bien été détectées.

truecrypt

Pas de porte dérobée 

En octobre dernier, une demande répétée d’un audit de sécurité complet dans la solution TrueCrypt avait mené à une campagne d’appel aux dons afin de financer l’opération. Plus de 48 000 dollars avaient ainsi été récupérés, dont 10 000 obtenus sur le don unique réalisé par la société Ionic Security. Après plusieurs mois de discussions et de mise en place, la première partie de cet audit conséquent vient de livrer ses premiers résultats.

 

Réunis dans un document d’une trentaine de pages, ils sont globalement positifs. TrueCrypt a ainsi vu son code analysé de fond en comble et la société iSec, chargée de l’étude, indique ainsi que le logiciel ne contient aucune porte dérobée. Si cette « trouvaille » semble tomber sous le sens, il faut savoir que la solution est particulièrement utilisée et que le contexte général de la sécurité a particulièrement changé depuis les premières révélations d’Edward Snowden sur les activités de la NSA.

Des failles à colmater et des problèmes à régler 

Pour autant, même si iSec n’a mis la main sur aucun code volontairement malveillant, elle a quand même révélé une série de failles de sécurité et indiqué que plusieurs aspects devraient être améliorés. Parmi les brèches, aucune n’est de rang « critique » mais quatre sont quand même classées dans la catégorie « moyenne ».

 

Il faut savoir en outre que durant cette première partie de l’audit, seule la version Windows du logiciel a été examinée, étant de loin la plus utilisée. Or, dans le code source, iSec a détecté plusieurs éléments problématiques. D’une part, un manque de commentaires qui perturbent la lecture dudit code. D’autre part, l’utilisation de fonctions devenues obsolètes dans Windows ou qui sont reconnues comme non sécurisées. Enfin, l’utilisation de types de variables incohérents. Plusieurs autres problèmes de cet acabit ont été pointés, mais iSec tient à mettre en avant la qualité de la documentation fournie par le site officiel.

 

Matthew D. Green, professeur de cryptographie à l’université Johns Hopkins, a indiqué à Ars Technica que les résultats n’étaient en fait pas réellement surprenants : « Je pense que la qualité du code n’est pas aussi bonne qu’elle devrait être, mais d’un autre côté, il n’y a rien d’horrible non plus, c’est donc rassurant ». Il indique d’ailleurs que la deuxième phase de l’audit se penchera plus spécifiquement sur le chiffrement lui-même des données.

Commentaires (65)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar







Ricard a écrit :



Question bête… iPSEC, c’est une boite américaine. Qu’est-ce quinous dit que cet audit n’est pas “enjolivé” par la NSA sous couvert du Patriot Act ?







Pas grand chose. Mais que la boite soit americaine ou pas, ce probleme demeure, et tu dois choisir si tu fais confiance ou non…


votre avatar

Je veux pas troller, ou si peu.. mais la sécurité de l’ensemble est limité à celle de sa partie la plus faible, non?

Donc la sécu d’un prgm tournant sous W$: <img data-src=" /> ?

votre avatar







Bross a écrit :



C’est pas comme si Truecrypt etait encore développé….



Ca fait plus de 2ans que aucune version n’a vu le jour





+1

Il suffit de jeter un coup d’œil au source pour voir que ce genre de soft requiert d’y foutre son nez en permanence pour y comprendre quelque chose (et donc pouvoir l’améliorer).







papinse a écrit :



Cet audit sera peut-être justement l’occasion d’une nouvelle version. <img data-src=" />



Après, pour un soft destiné à la sécurité, sans faille découverte à ce jour, sans besoin flagrant de nouvelle fonctionnalité (support futur de Keccak/SHA-3 après SHA-2 512 ?), y a-t-il vraiment besoin de changer quoi que ce soit ?





La fonction de dérivation de clé scrypt serait plus utile, mais c’est une vraie misère à implémenter, même avec le code source de référence (scrypt utilise une fonction PBKDF2, laquelle utilise une fonction HMAC, laquelle utilise une fonction de hash, et le seul hash présenté avec les vecteurs de test est du SHA-256).



Enfin sinon oui, il y aurait besoin de changer un paquet de trucs : une implémentation SSE2 de Serpent se bricole en une heure et multiplie les perfs de cet algo par environ 2,5. Le problème est que dans leur cas, il faut rajouter au mieux une grosse journée de boulot pour la modification du mode XTS, vu le bazar de leur implémentation, modification requise par le fait que l’optimisation de Serpent consiste à traiter 4 blocs de 128-bit à la fois.



Ils pourraient aussi prendre en compte XTS dans leur benchmark histoire d’avoir un truc un peu plus réaliste, vu que les algos de chiffrement ne sont jamais utilisés seuls. Mais le résultat pourrait faire peur…



Et puis éviter d’écrire tout ce qu’on fait avec TrueCrypt dans le journal des évènements et la base de registre…


votre avatar







pamputt a écrit :



Quelle niveau de confiance peut-on avoir dans la société iSec qui a audité le code source ?







C’est une entreprise qui vend probablement le même service pour d’autres logiciels, et d’autres services. Elle joue donc sa réputation dans cette opération. Si plus tard on trouve une backdoor, ça risque d’être mauvais pour eux. C’est déjà un élément de confiance. (bon après s’ils sont payés plus cher que tout ce que peut leur rapporter cette com pour cacher une backdoor…)


votre avatar

Concernant la confiance à accorder à iSec, je note simplement qu’elle a publié les résultats de son audit.



Alors bon, je vais vois débouler les sarcasmes sur le fait qu’on est bien avancé si on peut auditer l’audit, mais c’est pas si différent d’accorder sa confiance à du code open ou libre sous prétexte qu’on peut l’auditer soi-même sans jamais le faire.

votre avatar







SPlissken a écrit :



Je ne voulais pas dire ça.

Un projet open source a souvent peu de moyen , ya qu a voir comment OpenBSD peine a boucler son budget. Donc passer du budget pour faire de l audit de code ouvert , je trouve pas ca tres malin.







Ei tu avais bien lu l’article tu aurais vu que l’audit a ete financé via crowdfunding :)


votre avatar

Effectivement, TrueCrypt ne subit plus de màj depuis un moment, ça serait bien que cet audit aboutisse à un changement de licence vers une vraie licence libre, la mise en place d’un bugtracker par ex.

votre avatar







vampire7 a écrit :



+1

Il suffit de jeter un coup d’œil au source pour voir que ce genre de soft requiert d’y foutre son nez en permanence pour y comprendre quelque chose (et donc pouvoir l’améliorer).



La difficulté à se replonger dans un code de cette ampleur justifie de maintenir le soft, ne serait-ce que pour des modifs mineures, je te l’accorde.





vampire7 a écrit :



La fonction de dérivation de clé scrypt

(…)

Mais le résultat pourrait faire peur…



D’accord, mais as-tu suggéré ces fonctionnalités ou remonté ces bugs ?







vampire7 a écrit :



Et puis éviter d’écrire tout ce qu’on fait avec TrueCrypt dans le journal des évènements et la base de registre…



<img data-src=" /> même si ça ne concerne que Windows…





Crysalide a écrit :



Effectivement, TrueCrypt ne subit plus de màj depuis un moment, ça serait bien que cet audit aboutisse à un changement de licence vers une vraie licence libre, la mise en place d’un bugtracker par ex.



Étant donné que le choix d’un licence Open Source mais non libre est délibéré, je doute qu’ils changent d’avis.


votre avatar







le podoclaste a écrit :



Moi, j’applique le rasoir d’Occam. Je constate que la lib porte un nom bien yankee, et j’ai même pas besoin de me préoccuper des auditeurs pour me méfier.





Mouais, c’est une solution comme une autre<img data-src=" />


votre avatar







papinse a écrit :



Ce n’est pas tout à fait le même audit mais KeePass 2.10 Portable a été audité et validé par l’Agence Nationale de la Sécurité des Systèmes d’Information. <img data-src=" />





voila une nouvelle qu’elle est bonne. :)


votre avatar







papinse a écrit :



D’accord, mais as-tu suggéré ces fonctionnalités ou remonté ces bugs ?





A quoi bon, si le soft n’est plus développé ? Pour moi, TrueCrypt a trop de problèmes, que ce soit les traces qu’il laisse dans le système ou ses performances rachitiques (le code en C que j’utilise pour AES est plus rapide que leur code ASM, et ce n’est qu’un exemple). Sans parler de toutes ces fonctionnalités stupides et dangereuses comme celle de la clé dans un fichier (juste à tester chaque fichier de la machine un par un), celle du “déni plausible” (comme si on avait l’air “plausible” en disant “oui oui, ce gros volume chiffré en FAT32 avec presque rien dedans ne contient absolument pas de volume caché, promis-juré-craché”), l’OS chiffré où il n’y qu’à regarder le secteur de démarrage pour savoir s’il y en a un, etc…

Mais je ne me contente pas de me plaindre, puisque j’ai fini par développer une alternative.


votre avatar







vampire7 a écrit :



…j’ai fini par développer une alternative.







Ça m’intéresse, peut-on en savoir plus ?


votre avatar







vampire7 a écrit :



A quoi bon, si le soft n’est plus développé ? Pour moi, TrueCrypt a trop de problèmes, que ce soit les traces qu’il laisse dans le système ou ses performances rachitiques (le code en C que j’utilise pour AES est plus rapide que leur code ASM, et ce n’est qu’un exemple). Sans parler de toutes ces fonctionnalités stupides et dangereuses comme celle de la clé dans un fichier (juste à tester chaque fichier de la machine un par un), celle du “déni plausible” (comme si on avait l’air “plausible” en disant “oui oui, ce gros volume chiffré en FAT32 avec presque rien dedans ne contient absolument pas de volume caché, promis-juré-craché”), l’OS chiffré où il n’y qu’à regarder le secteur de démarrage pour savoir s’il y en a un, etc…

Mais je ne me contente pas de me plaindre, puisque j’ai fini par développer une alternative.



OK, je vois ton point de vue.

Quelle est ton alternative ?


votre avatar







vampire7 a écrit :



A quoi bon, si le soft n’est plus développé ? Pour moi, TrueCrypt a trop de problèmes, que ce soit les traces qu’il laisse dans le système (…)



ça c’est vrai, et c’est fort dommage, car ça va quand même à l’encontre de ce pour quoi il est conçu.


votre avatar







Zorglob a écrit :



ça c’est vrai, et c’est fort dommage, car ça va quand même à l’encontre de ce pour quoi il est conçu.









Je ne suis pas d’accord avec vous. Truecrypt utilise actuellement les aglos de chiffrement et les protocoles les plus récents et les plus éprouvés. J’attends toujours qu’est-ce que vous voudriez rajouter à AES, Serpent et Twofish pour le chiffrement et mieux que SHA512 pour le hash …



Le code à revoir est du côté du code du software en lui-même. En terme de sécurité changer trop souvent le code ou venir rajouter des fonctions “plus modernes” adaptées aux OS et aux pratiques récentes risquerait de créer des brèches dans la sécurité. Il semble encore aujourd’hui être l’Etat de l’Art dans son domaine donc moi je pense que garder des versions de long terme comme ici avec l’audit à côté semble être une bonne idée.


votre avatar







Glyphe a écrit :



Je ne suis pas d’accord avec vous. Truecrypt utilise actuellement les aglos de chiffrement et les protocoles les plus récents et les plus éprouvés. J’attends toujours qu’est-ce que vous voudriez rajouter à AES, Serpent et Twofish pour le chiffrement et mieux que SHA512 pour le hash …





Les algos de chiffrement, tout comme les les fonctions de hashs, ne s’utilisent pas seuls. C’est pas AES qui est utilisé dans TrueCrypt mais XTS-AES. Idem pour SHA-512 : c’est en réalité PBKDF2/SHA-512.

Et PBKDF2 est aujourd’hui considérée comme insuffisante (surtout avec seulement 1000 itérations), car facile à paralléliser (et donc à implémenter sur GPU…). Scrypt est une solution destinée à réduire ce problème.







Glyphe a écrit :



Le code à revoir est du côté du code du software en lui-même. En terme de sécurité changer trop souvent le code ou venir rajouter des fonctions “plus modernes” adaptées aux OS et aux pratiques récentes risquerait de créer des brèches dans la sécurité. Il semble encore aujourd’hui être l’Etat de l’Art dans son domaine donc moi je pense que garder des versions de long terme comme ici avec l’audit à côté semble être une bonne idée.





Qu’est-ce que tu appelles une “brèche dans la sécurité” pour ce genre de logiciel ?

Même la chaîne “TRUE” qu’on trouve dans les en-têtes de volume TrueCrypt n’est pas encore une véritable vulnérabilité. Pas encore. Mais il est vrai que c’est un peu con, parce que ça pourrait le devenir (au lieu d’avoir 2^128 blocks déchiffrés différents possibles, on n’en a plus que 2^96).

Pour le reste, il est infiniment plus simple de chercher à foutre un keylogger, voir même un truc qui repère directement le volume déchiffré (jette donc un coup d’œil dans la clé de registre HKLM\SYSTEM\MountedDevices…) que de chercher à reconstituer une clé que TrueCrypt aurait permis de retrouver quelque part dans la RAM.



Faut arrêter de penser que de poser le doigt sur le code va casser tout un assemblage fragile. C’est même tout le contraire : tu préfèrerais que ton OS n’ait pas de mise à jour pendant 2 ans ?

Les techniques informatiques évoluent, et la cryptographie ne fait pas exception.


votre avatar

Si ça pouvait faire évoluer les comportement côté développement :





  • Séparer code et interface correctement.

  • Faire des objets stables et des fonctions monotâches.

  • Faire des tests unitaires prenant en charge le maximum de cas d’erreur possibles.

  • Utiliser un système de suivi de version.

  • Utiliser un système de revue de code pour relecture par tout le monde.

  • Mise en place de tests automatisés globaux quand c’est possible.

  • Tests en conditions réels.

  • Prise en compte des remontées effectués par les “Store” comme les rapports de crash fournis par Microsoft (je ne sais pas s’il y a des rapports sous Linux, mais il y a des sites de remontés de bogues, à condition que les gens participent).



    Quand on voit de grosses boîtes comme Blizzard qui ont des régressions monstrueuses avec leurs patchs “correctifs”, on devine tout de suite qu’elles n’ont pas utiliser ce genre d’outils pendant des années, en espérant que ça soit le cas maintenant.



votre avatar

Audit de securité , c est une bonne chose mais cet article amene plusieurs remarques de ma part :





  • Quand j’entend ou lit le mot “audit” ,j ai toujours l impression que c est une fumisterie.

  • Si j ai bien compris cet audit est payant, je vois pas trop l interet, le truc etant Open Source, il aurait pu surement etre vérifié sans payer ce genre de boite.

  • Ils ont pas l air d avoir trouvé grand chose et pinaille sur des details , faut bien trouver quelque chose a dire justifiant la mission

votre avatar







Edtech a écrit :



Si ça pouvait faire évoluer les comportement côté développement :





  • Séparer code et interface correctement.

  • Faire des objets stables et des fonctions monotâches.

  • Faire des tests unitaires prenant en charge le maximum de cas d’erreur possibles.

  • Utiliser un système de suivi de version.

  • Utiliser un système de revue de code pour relecture par tout le monde.

  • Mise en place de tests automatisés globaux quand c’est possible.

  • Tests en conditions réels.

  • Prise en compte des remontées effectués par les “Store” comme les rapports de crash fournis par Microsoft (je ne sais pas s’il y a des rapports sous Linux, mais il y a des sites de remontés de bogues, à condition que les gens participent).



    Quand on voit de grosses boîtes comme Blizzard qui ont des régressions monstrueuses avec leurs patchs “correctifs”, on devine tout de suite qu’elles n’ont pas utiliser ce genre d’outils pendant des années, en espérant que ça soit le cas maintenant.







    Trop cher mon fils


votre avatar







SPlissken a écrit :



Trop cher mon fils







Pourtant au bout du compte, ça fait faire de sacrées économies ! Quand tu ne dois pas sortir des correctifs pendant 6 mois parce que ton soft est bancal (qui a dit Battle Field 4 ? <img data-src=" />), tu peux occuper tes équipes à des choses beaucoup plus rentable pour la société !


votre avatar







SPlissken a écrit :



Audit de securité , c est une bonne chose mais cet article amene plusieurs remarques de ma part :





  • Si j ai bien compris cet audit est payant, je vois pas trop l interet, le truc etant Open Source, il aurait pu surement etre vérifié sans payer ce genre de boite.







    Comme OpenSSL, tu veux dire ?




votre avatar







Edtech a écrit :





  • Faire des tests unitaires prenant en charge le maximum de cas d’erreur possibles.

    […]



    • Mise en place de tests automatisés globaux quand c’est possible.

    • Tests en conditions réels.





      Mieux vaut ne pas avoir de soft avec du (vrai) parallélisme alors. Parce les synchros sans lock foireuses, elles feront des conneries allé, une fois sur 1000, mais dans un soft secure c’est déjà de trop.

      Les tests c’est trop facile, donnez moi la preuve ! <img data-src=" />



votre avatar

Tu peux toujours vérifier mathématiquement comme le fait Microsoft maintenant pour le noyau de Windows, mais à mon avis, c’est pas dans les moyens de tout le monde <img data-src=" />

votre avatar







SPlissken a écrit :





  • Si j ai bien compris cet audit est payant, je vois pas trop l interet, le truc etant Open Source, il aurait pu surement etre vérifié sans payer ce genre de boite.







    Open source = bénévolat <img data-src=" /><img data-src=" />


votre avatar







Edtech a écrit :



Pourtant au bout du compte, ça fait faire de sacrées économies ! …tu peux occuper tes équipes à des choses beaucoup plus rentable pour la société !







Va dire à ton chef que la qualité passe par des phases de recette plus longues et qu’il faut prendre le temps d’avoir un dev propre et commenté pour ne pas trop galérer par la suite (je ne parle même pas de rentabilité, ça c’est du bonus)… On t’explique qu’il faut montrer aux hiérarchiques n+1000 que les choses avances même si, au final, le cout sera sans comparaison…



Entre politique et bon sens, les gros groupes ont fait leur choix<img data-src=" /><img data-src=" /><img data-src=" />


votre avatar







Boudh a écrit :



Va dire à ton chef que la qualité passe par des phases de recette plus longues et qu’il faut prendre le temps d’avoir un dev propre et commenté pour ne pas trop galérer par la suite (je ne parle même pas de rentabilité, ça c’est du bonus)… On t’explique qu’il faut montrer aux hiérarchiques n+1000 que les choses avances même si, au final, le cout sera sans comparaison…



Entre politique et bon sens, les gros groupes ont fait leur choix<img data-src=" /><img data-src=" /><img data-src=" />







Hélas, c’est très souvent la réalité (mais non pas tout le temps, on doit bien trouver une exception quelque part, non ? <img data-src=" />).


votre avatar







SPlissken a écrit :



Audit de securité , c est une bonne chose mais cet article amene plusieurs remarques de ma part :





  • Quand j’entend ou lit le mot “audit” ,j ai toujours l impression que c est une fumisterie.

  • Si j ai bien compris cet audit est payant, je vois pas trop l interet, le truc etant Open Source, il aurait pu surement etre vérifié sans payer ce genre de boite.

  • Ils ont pas l air d avoir trouvé grand chose et pinaille sur des details , faut bien trouver quelque chose a dire justifiant la mission







    Un audit, c’est un projet. Si tu y mets les moyens et les bonnes personnes, tu peux en faire un outil très puissant. Sinon, tu as 99% de chances de n’en sortir rien d’intéressant.


votre avatar







SPlissken a écrit :





  • Si j ai bien compris cet audit est payant, je vois pas trop l interet, le truc etant Open Source, il aurait pu surement etre vérifié sans payer ce genre de boite.





    Et qui aurait audité le code ? Toi ?


votre avatar







Edtech a écrit :



Pourtant au bout du compte, ça fait faire de sacrées économies ! Quand tu ne dois pas sortir des correctifs pendant 6 mois parce que ton soft est bancal (qui a dit Battle Field 4 ? <img data-src=" />), tu peux occuper tes équipes à des choses beaucoup plus rentable pour la société !





Tout ceci est bien jolie, mais ce n’est fait que dans les partie critique du code. Le reste peut être fini à la pisse, c’est de l’enrobage. Pour les bug, la technique est celle du 80-20 (principe de Pareto) : 80% des erreurs que les utilisateurs sont confronté proviennent de 20% des bugs contenu dans ton code. De même, 80% des bug de ton code ne prennent à corriger que 20% du temps qu’il aurait fallut pour tous les corriger. Même si ce n’est pas clairement dit, c’est souvent fait de manière inconsciente.



Faire un code sans bug possible est une tache fastidieuse, ça prendrait un temps fou de le faire.


votre avatar







mistigrite a écrit :



Et qui aurait audité le code ? Toi ?





moi, j’ai audité chez moi le code, et le résultat est que ça compile bien. Faut dire, je n’ai vérifié que ça, le reste ne faisant pas partie de mon plan d’audition.


votre avatar







gokudomatic a écrit :



moi, j’ai audité chez moi le code, et le résultat est que ça compile bien. Faut dire, je n’ai vérifié que ça, le reste ne faisant pas partie de mon plan d’audition.





Bah, quand ça compile ça veut dire que ça marche non ? <img data-src=" />


votre avatar







Edtech a écrit :



Si ça pouvait faire évoluer les comportement côté développement :





  • Séparer code et interface correctement.

  • Faire des objets stables et des fonctions monotâches.

  • Faire des tests unitaires prenant en charge le maximum de cas d’erreur possibles.

  • Utiliser un système de suivi de version.

  • Utiliser un système de revue de code pour relecture par tout le monde.

  • Mise en place de tests automatisés globaux quand c’est possible.

  • Tests en conditions réels.

  • Prise en compte des remontées effectués par les “Store” comme les rapports de crash fournis par Microsoft (je ne sais pas s’il y a des rapports sous Linux, mais il y a des sites de remontés de bogues, à condition que les gens participent).



    Quand on voit de grosses boîtes comme Blizzard qui ont des régressions monstrueuses avec leurs patchs “correctifs”, on devine tout de suite qu’elles n’ont pas utiliser ce genre d’outils pendant des années, en espérant que ça soit le cas maintenant.







    C’est ce que j’aimerai mais impossible dans ma petite boite les clients ne payeront jamais…


votre avatar







Ksass`Peuk a écrit :



Mieux vaut ne pas avoir de soft avec du (vrai) parallélisme alors. Parce les synchros sans lock foireuses, elles feront des conneries allé, une fois sur 1000, mais dans un soft secure c’est déjà de trop.

Les tests c’est trop facile, donnez moi la preuve ! <img data-src=" />





+1, mais ça coute cher.


votre avatar



Ionic SECurity et ISec, rien à voir?


votre avatar

A quand le même genre d’audit sur keepass et ses extensions ? <img data-src=" />

votre avatar

Quelle niveau de confiance peut-on avoir dans la société iSec qui a audité le code source ?

votre avatar

Comment cela se passe en réalité



Après ,j’aurai pu mettre celle où le mec code et dit qu’il corrigera son code plus tard et qu’au final, son collègue le reprends et repart de zéro <img data-src=" />

votre avatar







SPlissken a écrit :



Audit de securité , c est une bonne chose mais cet article amene plusieurs remarques de ma part :





  • Quand j’entend ou lit le mot “audit” ,j ai toujours l impression que c est une fumisterie.

  • Si j ai bien compris cet audit est payant, je vois pas trop l interet, le truc etant Open Source, il aurait pu surement etre vérifié sans payer ce genre de boite.

  • Ils ont pas l air d avoir trouvé grand chose et pinaille sur des details , faut bien trouver quelque chose a dire justifiant la mission



    Je t’invite à visiter IsTrueCryptAuditedYet? pour plus d’infos sur cet audit.



    Sachant que TrueCrypt est aujourd’hui une solution de sécurité majeure et que c’est OpenSource (mais non libre), ils ont décidé de faire un audit complet et approfondi du soft.



    La première étape a été de prouver que le binaire fourni sur le site correspond bien aux sources présentes. Ce qui a été fait dès le départ et sans payer une boîte pour ça parce que c’est à la portée de beaucoup de bons développeurs (et même de certains mauvais <img data-src=" />).



    La seconde étape, dont on voit ici le résultat, a été d’analyser le code pour voir les problèmes de développement au sens général. Bien qu’il existe des outils gratuits permettant de faire des analyses automatiquement et que la communauté a des compétences pour ce genre de vérifications, la boîte qui a été payée a plus de moyens et plus de temps à consacrer à ça. C’est leur métier.



    L’étape suivante sera l’analyse formelle de la crypto. Là encore, cette analyse à un coût en temps et en compétences (c’est même encore plus vrai que pour l’étape précédente), d’où l’appel à une société spécialisée.



    Si cet audit permet d’avoir une 7.2 encore plus sécurisée, c’est loin d’être de l’argent jeté par les Fenêtres®. <img data-src=" />


votre avatar







pamputt a écrit :



Quelle niveau de confiance peut-on avoir dans la société iSec qui a audité le code source ?







Il faudrait en effet l’auditer cette société.


votre avatar







mistigrite a écrit :



Bah, quand ça compile ça veut dire que ça marche non ? <img data-src=" />







+1 <img data-src=" />


votre avatar







pamputt a écrit :



Quelle niveau de confiance peut-on avoir dans la société iSec qui a audité le code source quelle qu’elle soit ?





la confiance n’est qu’un consensus autour d’un choix (en l’occurrence, accepter ce que dit X ou Y pour argent comptant et jusqu’à preuve du contraire)







chien a écrit :



Il faudrait en effet l’auditer cette société.





par qui ? voir ci-dessus



On dirait un sujet de bac philo ou un plan de relance de l’économie sur la base de la paranoïa <img data-src=" />


votre avatar



la société iSec, chargée de l’étude, indique ainsi que le logiciel ne contient ne semble contenir aucune porte dérobée



<img data-src=" />









SPlissken a écrit :





  • Si j ai bien compris cet audit est payant, je vois pas trop l interet, le truc etant Open Source, il aurait pu surement etre vérifié sans payer ce genre de boite.





    Lire un code de fond en comble est chiant. Si tu veux que ce soit fait (et par des gens compétents) il faut payer.





    Les tests c’est trop facile, donnez moi la preuve ! <img data-src=" />



    Tests et preuves ne se recouvrent pas en général, avoir l’un ne dispense pas d’avoir l’autre.


votre avatar







sksbir a écrit :



A quand le même genre d’audit sur keepass et ses extensions ? <img data-src=" />



Ce n’est pas tout à fait le même audit mais KeePass 2.10 Portable a été audité et validé par l’Agence Nationale de la Sécurité des Systèmes d’Information. <img data-src=" />


votre avatar







Yangzebul a écrit :



Open source = bénévolat <img data-src=" /><img data-src=" />







Je ne voulais pas dire ça.

Un projet open source a souvent peu de moyen , ya qu a voir comment OpenBSD peine a boucler son budget. Donc passer du budget pour faire de l audit de code ouvert , je trouve pas ca tres malin.


votre avatar







papinse a écrit :



Ce n’est pas tout à fait le même audit mais KeePass 2.10 Portable a été audité et validé par l’Agence Nationale de la Sécurité des Systèmes d’Information. <img data-src=" />







Comme pour l’HADOPI, c’est un scandale, c’est le contribuable qui paye <img data-src=" />


votre avatar







WereWindle a écrit :



la confiance n’est qu’un consensus autour d’un choix (en l’occurrence, accepter ce que dit X ou Y pour argent comptant et jusqu’à preuve du contraire)





par qui ? voir ci-dessus



On dirait un sujet de bac philo ou un plan de relance de l’économie sur la base de la paranoïa <img data-src=" />





Il suffit à un moment de réutiliser la première société d’audition pour faire une référence circulaire.


votre avatar







SPlissken a écrit :



Je ne voulais pas dire ça.

Un projet open source a souvent peu de moyen , ya qu a voir comment OpenBSD peine a boucler son budget. Donc passer du budget pour faire de l audit de code ouvert , je trouve pas ca tres malin.







C’est sûr que si tu considères qu’un audit est une fumisterie (cf ton 1er post), tu ne trouveras pas ça très malin. Mais apparemment, eux ont trouvé utile de se faire auditer.


votre avatar







Edtech a écrit :



Tu peux toujours vérifier mathématiquement comme le fait Microsoft maintenant pour le noyau de Windows, mais à mon avis, c’est pas dans les moyens de tout le monde <img data-src=" />







On réussit à prouver des programmes de plus de 10 lignes maintenant ?


votre avatar







v1nce a écrit :



On réussit à prouver des programmes de plus de 10 lignes maintenant ?







hey… on a deja vu du 20 lignes prouvé ! (il suffisait de rajouter suffisamment de commentaires en fait)


votre avatar

C’est pas comme si Truecrypt etait encore développé….



Ca fait plus de 2ans que aucune version n’a vu le jour

votre avatar







Bross a écrit :



C’est pas comme si Truecrypt etait encore développé….



Ca fait plus de 2ans que aucune version n’a vu le jour



Cet audit sera peut-être justement l’occasion d’une nouvelle version. <img data-src=" />



Après, pour un soft destiné à la sécurité, sans faille découverte à ce jour, sans besoin flagrant de nouvelle fonctionnalité (support futur de Keccak/SHA-3 après SHA-2 512 ?), y a-t-il vraiment besoin de changer quoi que ce soit ?


votre avatar







SPlissken a écrit :



Je ne voulais pas dire ça.

Un projet open source a souvent peu de moyen , ya qu a voir comment OpenBSD peine a boucler son budget. Donc passer du budget pour faire de l audit de code ouvert , je trouve pas ca tres malin.







Ce n’est pas truecrypt qui est à l’initiative de cet audit…

Ca part de là:

http://blog.cryptographyengineering.com/2013/10/lets-audit-truecrypt.html


votre avatar







chien a écrit :



Il faudrait en effet l’auditer cette société.





Le cercle vicieux <img data-src=" />


votre avatar







v1nce a écrit :



On réussit à prouver des programmes de plus de 10 lignes maintenant ?





seL4, microkernel composé de 9000 lignes de code C, prouvé avec Isabelle/HOL.


votre avatar







RaYz a écrit :



Le cercle vicieux vertueux <img data-src=" />





<img data-src=" />


votre avatar







SPlissken a écrit :



Je ne voulais pas dire ça.

Un projet open source a souvent peu de moyen , ya qu a voir comment OpenBSD peine a boucler son budget. Donc passer du budget pour faire de l audit de code ouvert , je trouve pas ca tres malin.





Dans le domaine de la sécurité, utiliser une partie de son budget pour vérifier que le code ne présente pas de faille, c’est même carrément stupide ! <img data-src=" />


votre avatar







mistigrite a écrit :



Dans le domaine de la sécurité, utiliser une partie de son budget pour vérifier que le code ne présente pas de faille, c’est même carrément stupide ! <img data-src=" />







Bah, puisqu’ils ont pas trouvé de failles, y a qu’a pas les payer, et puis c’est tout.


votre avatar







mistigrite a écrit :



Dans le domaine de la sécurité, utiliser une partie de son budget pour vérifier que le code ne présente pas de faille, c’est même carrément stupide ! <img data-src=" />





Probablement une idée de consultant senior (stagiaire).









<img data-src=" />


votre avatar

Question bête… iPSEC, c’est une boite américaine. Qu’est-ce quinous dit que cet audit n’est pas “enjolivé” par la NSA sous couvert du Patriot Act ?

votre avatar







Ricard a écrit :



Question bête… iPSEC, c’est une boite américaine. Qu’est-ce quinous dit que cet audit n’est pas “enjolivé” par la NSA sous couvert du Patriot Act ?







Moi, j’applique le rasoir d’Occam. Je constate que la lib porte un nom bien yankee, et j’ai même pas besoin de me préoccuper des auditeurs pour me méfier.


votre avatar







le podoclaste a écrit :



Bah, puisqu’ils ont pas trouvé de failles, y a qu’a pas les payer, et puis c’est tout.





Ah tient ça me rappelle mon taff ça <img data-src=" />


votre avatar







SPlissken a écrit :



Audit de securité , c est une bonne chose mais cet article amene plusieurs remarques de ma part :





  • Quand j’entend ou lit le mot “audit” ,j ai toujours l impression que c est une fumisterie.

  • Si j ai bien compris cet audit est payant, je vois pas trop l interet, le truc etant Open Source, il aurait pu surement etre vérifié sans payer ce genre de boite.

  • Ils ont pas l air d avoir trouvé grand chose et pinaille sur des details , faut bien trouver quelque chose a dire justifiant la mission







    Avoir un regard exterieur et desinteresse (a priori) sur ce que tu produis, c’est une bonne idee pour ramasser des critiques constructives et te faire avancer dans le bon sens.


votre avatar







vampire7 a écrit :



Faut arrêter de penser que de poser le doigt sur le code va casser tout un assemblage fragile. C’est même tout le contraire : tu préfèrerais que ton OS n’ait pas de mise à jour pendant 2 ans ?

Les techniques informatiques évoluent, et la cryptographie ne fait pas exception.







Sauf que les techniques de crypto évoluent beaucoup moins vite que les taches dévolues à l’OS (pas pour ses fonctions premières mais bien pour le confort “grand public”), d’ailleurs la comparaison entre un soft comme TrueCrypt et un OS n’est pas très judicieuse. tant l’écart entre les 2 est immense.



Tu as raison il y a mieux en développement mais comme tu l’as bien dis toi-même, décrypter un fichier chiffré via TrueCrypt demande tout simplement du matos que seuls quelques agences ou grosses boites privées peuvent se payer, du coup il faut employer des techniques annexes : accès à la RAM, keylogger, ou des techniques tout autant de pointe comme l’analyse acoustique.

Je voulais surtout dire que même si bien sur, que ce soit pour les suites de chiffrement ou les protocoles de hash et de chiffrement il y a toujours des nouveautés à considérer, l’état actuel du chiffrement de TrueCrypt est largement suffisant même pour des usages professionnels ou sensibles.


votre avatar

Un banquier brésilien indélicat avait chiffré des données compromettantes avec TC, le HDD est parti au FBI après un échec des services de police brésiliens à lire les données. Il est revenu intact, échec aussi.

votre avatar







vampire7 a écrit :



A quoi bon, si le soft n’est plus développé ? Pour moi, TrueCrypt a trop de problèmes, que ce soit les traces qu’il laisse dans le système ou ses performances rachitiques (le code en C que j’utilise pour AES est plus rapide que leur code ASM, et ce n’est qu’un exemple). Sans parler de toutes ces fonctionnalités stupides et dangereuses comme celle de la clé dans un fichier (juste à tester chaque fichier de la machine un par un), celle du “déni plausible” (comme si on avait l’air “plausible” en disant “oui oui, ce gros volume chiffré en FAT32 avec presque rien dedans ne contient absolument pas de volume caché, promis-juré-craché”), l’OS chiffré où il n’y qu’à regarder le secteur de démarrage pour savoir s’il y en a un, etc…

Mais je ne me contente pas de me plaindre, puisque j’ai fini par développer une alternative.





C’est quoi l’alternative? Tu l’as développé? Seul? C’est au moins aussi safe que TC?



Et sinon, autant crypter des données je comprends le besoin, et je vais m’y mettre aussi (d’où ma lecture de la news sur TC). Mais, autant je comprends les points que tu cites, autant j’ai énormément de mal à voir en quoi le particulier lambda peut en avoir quoi que ce soit à faire… (à part pour l’histoire de la clef dans le fichier mais après tout, le fait qu’il offre la possibilité de retire rien au logiciel, si la clef est elle-même stockée autre part pourquoi pas)


Pas de porte dérobée dans TrueCrypt, mais des failles de sécurité

  • Pas de porte dérobée 

  • Des failles à colmater et des problèmes à régler 

Fermer