Un petite analyse critique de « l'affaire » de la NSAKEY

Posté par  . Modéré par Benoît Sibaud.
Étiquettes :
0
30
nov.
2002
Microsoft
Un article sur le site uZine (portail communautaire de publication sur Internet) propose une intéressante analyse de l'affaire de la fameuse NSAKEY, qui aurait été une backdoor intégrée par la NSA à l'interface de programmation cryptographique de NT4.
Il rassemble plusieurs sources, et essaye de déméler la vérité, qui paraît bien difficile à saisir.

Note du modérateur : ce sujet étant souvent revenu sur le tapis dans les commentaires, et même s'il est un peu hors sujet ici, j'ai accepté cette dépêche. L'accès au code source aurait permis de trancher la question (un des intérêts du logiciel libre dans le domaine de la sécurité).

Aller plus loin

  • # La vrai question derriere tout ca ?

    Posté par  . Évalué à 10.

    En fait, qu'il y ai eut une backdoor ou pas, n'est pas la vraie question. A partir du moment où l'on a un doute, cela détruit toute l'impression de sécurité que l'on avait avant.

    Comment peut-on faire une confiance aveugle à un logiciel fermé pour gérer notre sécurité ? Notre intimité ?

    À une époque où les états et les organismes internationaux bafouent les libertés individuelles en se disant "lutter contre le terrorisme", il est important de se prémunir contre tous.

    Sans vouloir pousser au "tout logiciel ouvert", je pense qu'il existe toute une gamme de logiciels "critiques" qui se doivent d'être ouverts. L'exemple des logiciels de cryptographie n'est une occurence de ce problème. On devrait avoir le même réflexe pour les format de documents (écrits, sonores ou audio-visuels), ou encore pour les protocoles réseaux (inter-opérabilité).

    • [^] # Re: La vrai question derriere tout ca ?

      Posté par  . Évalué à 5.

      http://www.security-labs.org/index.php3?page=403(...)
      Thompson avait mis un systéme d'accés caché sur les systémes unix
      seul le binaire le contenait pas les sources

      • [^] # Re: La vrai question derriere tout ca ?

        Posté par  (site web personnel) . Évalué à 0.

        Mais les sources du compilo contenaient ce qu'il fallait pour compiler le binaire avec le "trou".

        Sous Linux, les sources du noyau et de tout ce qui va au dessus sont disponibles... et les sources du compilateur aussi, ce qui évite autant que faire se peut ce genre de gag.

        • [^] # désolé je me suis mal exprimé

          Posté par  . Évalué à 1.

          le binaire en question était le compilateur ,dont les sources était propre

          • [^] # Re: désolé je me suis mal exprimé

            Posté par  (site web personnel) . Évalué à 2.

            Comme Thompson le dit lui même :

            First we compile the modified source with the normal C compiler to produce a bugged binary. We install this binary as the official C. We can now remove the bugs from the source of the compiler and the new binary will reinsert the bugs whenever it is compiled

            Donc c'est un Trojan tout ce qu'il y'a de classique obtenu par distribution d'un binaire infecté. La recompilation de ces sources sur un système "sain" génèrerait un binaire différent et non infecté.

            On peut faire confiance aux principes de fonctionnement du logiciel libre pour qu'un tel trojan soit normalement assez vite détecté (mais ce cas de trojan est bien sur toujours possible).

            • [^] # Re: désolé je me suis mal exprimé

              Posté par  . Évalué à 2.

              La différence est que le compilateur de Thompson était le compilateur C pour Unix à l'époque, je crois ;)

              Mais si à partir d'aujourd'hui les binaires de gcc se mettaient à contenir un tel dispositif, une grande partie des systèmes seraient vérolés d'ici un à deux ans, car pour y échapper il faudrait non seulement compiler gcc soi-même, mais en plus le faire à partir d'un binaire suffisamment ancien ou d'un autre compilateur.

      • [^] # Re: La vrai question derriere tout ca ?

        Posté par  . Évalué à 4.

        Donnons directement l'URL de la chose, qui est un chef d'oeuvre que tout informaticien féru de théorie devrait connaître :

        http://www.acm.org/classics/sep95/(...)

      • [^] # Re: La vrai question derriere tout ca ?

        Posté par  (site web personnel) . Évalué à 1.

        Comme quoi la garantie contre les jolies backdoor n'est là avec le libre que si on audite le code source ET qu'on l'utilise (qu'on utilise pas le binaire qu'on a recu, sinon l'audit du code source ne sert à rien de ce coté là).

        Combien le font ? (manque de compétences et de temps)

        C'est toujours bon à rappeler

  • # Re: Un petite analyse critique de « l'affaire » de la NSAKEY

    Posté par  . Évalué à -7.

    TouT logiciel crée aux Usa voué à être exporté doit passé par la nsa
    qui forcément integrera un système de backdoor dans le produit concerné (office, mail, etc...) alors que ce soit pgp ou debian(version us), c"est pareil, c'est compromis.
    c'est une extension au système echelon déjà en place depuis longtemps...

    • [^] # Re: Un petite analyse critique de « l'affaire » de la NSAKEY

      Posté par  (site web personnel) . Évalué à 1.

      Regarde moins X-Files... Maintenant explique-nous où est le cheval de Troie dans GPG ou dans Debian ? Tu peux me filer le diff entre la version Debian US et la version non-US s'il te plaît ?

      • [^] # Re: Un petite analyse critique de « l'affaire » de la NSAKEY

        Posté par  (site web personnel) . Évalué à 1.

        Hmm j'oubliais, la prochaine fois, lis l'article avant de commenter.

        • [^] # Re: Un petite analyse critique de « l'affaire » de la NSAKEY

          Posté par  . Évalué à -2.

          tu m'explikera l'interet de sortir une version us et une non us.... ?

          Ensuite je n'ai pas dit gpg mais pgp
          la nsa par définition (agence national de securité) se charge de contrôler par echelon et carnivore toute communication electronique dans le monde.
          Si la loi americaine impose l'exportation de logiciels avec moins de 128 bits, c'est pourquoi à ton avis, à part écouter ou decrypter d com ou d fichiers crées (au hasard) sous du word ou une com par netmeeting?

          • [^] # Re: Un petite analyse critique de « l'affaire » de la NSAKEY

            Posté par  (site web personnel) . Évalué à 3.

            Sur la version US vs non-US : la raison est la limitation de la crypto à l'exportation. Cela dit il a eu du changement et les logiciels de crypto sont passés de non-US à normal. Il reste dans non-US les logiciels concernés par des lois stupides genre DMCA, les brevets logiciels, etc.

            Carnivore c'est le FBI, pas la NSA. Et c'est pour les états-uniens (contrairement à Echelon).

            Concernant la limitation de la crypto à l'exportation (qui a évolué), oui c'est pour pouvoir faire des écoutes plus facilement. ça ne veut absolument pas dire que tous les logiciels produits aux Etats-Unis sont truffés de chevaux de Troie. D'ailleurs il n'y a pas besoin de ça... La plupart des infos circulent en clair, et les logiciels ont suffisamment de bogues à exploiter.

            Au passage, ton style IRC et ta théorie du complot nuisent à ta crédibilité.

          • [^] # Théorie du complot

            Posté par  . Évalué à 5.

            "à quoi ça servirait si ce n'était pour..."

            Théorie classique du complot, qui invoque la nécessité d'une finalité rationnelle et calculée à chaque action humaine. Il y a des tas de législations bancales ou apparemment arbitraires, si on appliquait une théorie du complot à chacune il y aurait de quoi remplir des bibliothèques.

            En général il y a des partisans de la libéralisation de la crypto (c'est bon pour le commerce, les libertés civiques...) et des partisans d'une limitation très stricte (c'est bon pour la surveillance et les intérêts supérieurs de l'Etat). Les législations actuelles (France, USA) sont le reflet d'un compromis adopté entre ces deux positions, compromis qui n'a rien de technique mais correspond simplement à une nécessité de ne pas laisser croire à un des deux camps que ses préoccupations ne sont pas partagées par le gouvernement en place. C'est le jeu démocratique : on cherche à ne provoquer de mécontentements violents chez aucun des groupes qui disposent de gros moyens de pression, ici : d'un côté les entreprises voulant développer le commerce électronique et le marché de la confidentialité, de l'autre les services secrets et de police qui n'aiment pas se voir ignorés. Si tu mécontentes trop les flics, c'est très mauvais pour l'image ; si tu mécontentes trop les entreprises, c'est très mauvais pour l'économie (et donc aussi pour l'image).

            D'un point de vue purement technique une clé de 128 bits avec un bon algo symétrique (Blowfish, AES) est incassable si l'on en croit les spécialistes du genre - même 80 bits sont hors de portée pour au moins quelques années. Bien sûr, dans une bonne théorie du complot, les spécialistes se trompent ou sont vendus à l'ennemi :-))

    • [^] # Re: Un petite analyse critique de « l'affaire » de la NSAKEY

      Posté par  . Évalué à 0.

      Lol mdr ptdr, comme on dit : )

    • [^] # Re: Un petite analyse critique de « l'affaire » de la NSAKEY

      Posté par  . Évalué à 10.

      Ouais de toutes façons ils peuvent casser toutes les clefs grâce aux ordinateurs quantiques que leur ont donné les aliens en échange de leur collaboration pour la colonisation de la Terre. Je le sais c'est Elvis qui me l'a dit !

  • # Re: Un petite analyse critique de « l'affaire » de la NSAKEY

    Posté par  . Évalué à 2.

    L'accès au code source N'aurait PAS permis de trancher la question.

    au plus, il aurait permis de recompiler les bouts de code d'origine douteuse afin de les remplacer, ou aurait pu faciliter le rétro engineering (décompilage) du code à vérifier.

    les différentes affaires récentes de sources contaminées (tcpdump, ...) auraient dû relativiser ce que permet l'accès aux sources :

    si suite à un moment d'égarement ou un acte de malveillance, une distribution Linux de type Red Hat ou Mandrake fournissait un utilitaire vérolé, ce n'est pas l'accès aux sources génériques de cet utilitaire qui va permettre de découvrir le problème.

    • [^] # Re: Un petite analyse critique de « l'affaire » de la NSAKEY

      Posté par  (site web personnel) . Évalué à 1.

      L'accès aux sources du paquet peut etre par contre, non ?

      • [^] # Re: Un petite analyse critique de « l'affaire » de la NSAKEY

        Posté par  (site web personnel) . Évalué à 2.

        Si est seulement si le binaire a bien été compilé avec ces sources là.
        Faut pas prendre les gens pour des idiots, ils sont toujours capable de bidouiller les sources avant de te les donner.
        Ou en inversant : ils ont pu bidouiller légerement les sources avant de compiler le binaire officiel et ne pas reporter le bidouillage dans l'archive des sources.

        L'accès aux sources n'est une sécurité contre les backdoor/failles cachées intentionnellement _que_ si tu peux certifier que ca a bien été compilé avec les sources que tu as en main (bref, que c'est toi qui a compilé), que tu as les sources de toute la chaine (compilo par exemple, et que là aussi tu peux certifier la correspondance entre les sources que tu as et le binaire)

      • [^] # Re: Un petite analyse critique de « l'affaire » de la NSAKEY

        Posté par  . Évalué à 1.

        au mieux, les sources du paquet (ou un paquet de sources) peuvent reconstruire le logiciel concerné, mais pas d'être assuré que les binaires du logiciel sont bien ce qu'on veut me faire croire.

        et qu'on ne me parle pas de signature MD5, ça n'apporte ici qu'une sensation de confiance, potentiellement indue.

  • # Re: Un petite analyse critique de « l'affaire » de la NSAKEY

    Posté par  . Évalué à 4.

    Note du modérateur : ce sujet étant souvent revenu sur le tapis dans les commentaires, et même s'il est un peu hors sujet ici, j'ai accepté cette dépêche. L'accès au code source aurait permis de trancher la question (un des intérêts du logiciel libre dans le domaine de la sécurité).

    Ca tombe bien, car l'acces aux sources est possible: http://www.microsoft.com/licensing/sharedsource/enterprise.asp(...) simplement il n'est pas gratuit vu qu'il faut avoir au minimum 1500 licences de Windows.

    Cette question sur la NSAKEY n'a plus lieu d'etre depuis longtemps, car un nombre enorme de gens ont acces aux sources de Windows, et personne n'a encore mis au grand jour cette pretendue backdoor.

    Alors soit il est possible de cacher dans des sources ouvertes des backdoors, et dans ce cas le meme genre de doutes se pose a l'encontre des LL, soit cette backdoor n'existe pas.

    A vous de choisir l'explication qui vous plait le plus.

    • [^] # Re: Un petite analyse critique de « l'affaire » de la NSAKEY

      Posté par  . Évalué à 1.

      > Alors soit il est possible de cacher dans des sources ouvertes des backdoors, et dans ce cas le meme genre de doutes se pose a l'encontre des LL, soit cette backdoor n'existe pas.

      Non il y a 2 autres possibilites :
      - soit c'est le compilo qui installe la backdoor ( faut aussi fouiller les sources de VC++ ! )
      - soit il y a une clause juridique qui interdit de parler de ce que l'on aura trouvé dans le code

      • [^] # Re: Un petite analyse critique de « l'affaire » de la NSAKEY

        Posté par  . Évalué à 1.

        Il y a pire que ça: rien ne garantit que les sources fournis sont exactement les bons ! MS précise que d'ailleurs que certains sources confidentiels ne sont pas fournis.

        La licence des sources MS dit que on a pas le droit de les recompiler ni de les modifier: on a juste le droit de les lire ou de les utiliser avec un debugger MS !

        Dans ces conditions les sources MS n'inspirent absolument pas la meme confiance que les sources d'un logiciel libre que tout le monde peut tester dans les conditions qu'il veut.

    • [^] # Arf, arf, arf ...

      Posté par  . Évalué à 1.

      Ah, le Shared Source de Microsoft ... Toujours un bon moment de rigolade. Et après, on parle de viralité de la GPL ? Quelle bande de déconneurs, chez Microsoft :)

    • [^] # Re: Un petite analyse critique de « l'affaire » de la NSAKEY

      Posté par  (site web personnel) . Évalué à 2.

      <<>>

      Argument vraiment bancal. Ca n'y est pas parce que "si ca y etait, on l'aurait surement vu" que ca n'y est pas. Un bug, une faille ou un trojan peut tres bien rester cache des annees [et ca faut pour tous types de logiciels, libre et proprio ]. Le troyen de Ken Thompson n'a jamais ete decouvert, alors que les sources de son compilateur sont certainement beaucoup beaucoup plus petites que celle de Windows. Et a mon avis, bien plus d'experts y avaient acces.

      Je commencerai a croire que cette "porte de service" n'est pas presente quand j'aurai vu le rapport d'un expert independant qui a acces librement a toutes les sources et a la preuve que ces sources sont bien celles qui sont utilises pour les windows qu'on nous impose et a le droit de parler librement de ce qu'il a trouve. Et j'y croirai vraiment quand j'aurai vu deux rapports d'experts.

      En plus, corrige moi si je me trompe mais tu as un le programme shared-source va de pair avec un NDA qui te donne a peu pres autant de pouvoir de divulgation que pour un document secret-defense.

      Bref, meme si tu as acces aux sources et que tu trouves le vilain backdoor (et je ne doute pas qu'il existe), tu n'auras pas le droit d'en parler.

      Le logiciel libre ne garantit pas qu'on decouvrira un tel backdoor, mais au moins, il rend bien plus facile une analyse.

      • [^] # Re: Un petite analyse critique de « l'affaire » de la NSAKEY

        Posté par  . Évalué à 1.

        C'est marrant, tu ne doutes absolument pas qu'il existe ce backdoor, et tu te bases sur quoi comme preuve pour cela ?

        Le NDA tu ne sais rien de ce qu'il contient, et tu arrives pourtant a affirmer qu'il ne te permet pas d'en dire quoi que ce soit.

        Pourtant certains (cf. plus haut) arrivent a sortir des articles de recherche sur le code de MS sans probleme.

        Tu as vu des experts independants certifier que les xxx softs GPL qui existent sont libres de backdoor ? Non. MS devrait etre traite differement que les autres ? Pourquoi ?

        Bref, tu fais du delit de sale gueule envers MS, car tu n'as RIEN pour affirmer que cette backdoor existe, a la limite tu pourrais avoir un doute, mais toi tu te permets d'affirmer qu'elle existe sans AUCUNE preuve.

        Bref, vive l'objectivite.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.