Vous n'avez pas encore de notification

Page d'accueil

Options d'affichage

Abonné

Actualités

Abonné

Des thèmes sont disponibles :

Thème de baseThème de baseThème sombreThème sombreThème yinyang clairThème yinyang clairThème yinyang sombreThème yinyang sombreThème orange mécanique clairThème orange mécanique clairThème orange mécanique sombreThème orange mécanique sombreThème rose clairThème rose clairThème rose sombreThème rose sombre

Vous n'êtes pas encore INpactien ?

Inscrivez-vous !

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

L'ombre désormais permanente de la NSA

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.

65 commentaires
Avatar de Edtech Abonné
Avatar de EdtechEdtech- 17/04/14 à 06:28:45

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.

Avatar de SPlissken Abonné
Avatar de SPlisskenSPlissken- 17/04/14 à 06:33:33

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
Avatar de SPlissken Abonné
Avatar de SPlisskenSPlissken- 17/04/14 à 06:34:14

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

Avatar de Edtech Abonné
Avatar de EdtechEdtech- 17/04/14 à 06:37:05

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 ? :transpi:), tu peux occuper tes équipes à des choses beaucoup plus rentable pour la société !

Édité par edtech le 17/04/2014 à 06:37
Avatar de jamian Abonné
Avatar de jamianjamian- 17/04/14 à 06:38:13

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 ?

Édité par jamian le 17/04/2014 à 06:39
Avatar de Ksass`Peuk INpactien
Avatar de Ksass`PeukKsass`Peuk- 17/04/14 à 06:44:48

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 ! :yes:

Avatar de Edtech Abonné
Avatar de EdtechEdtech- 17/04/14 à 06:57:41

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 :D

Avatar de Yangzebul INpactien
Avatar de YangzebulYangzebul- 17/04/14 à 07:07:15

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 :bravo::bravo:

Avatar de Boudh INpactien
Avatar de BoudhBoudh- 17/04/14 à 07:08:27

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:censored::mad::cartonrouge:

Avatar de Edtech Abonné
Avatar de EdtechEdtech- 17/04/14 à 07:10:15

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:censored::mad::cartonrouge:

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 ? :transpi:).

Il n'est plus possible de commenter cette actualité.
Page 1 / 7