Internet : Un petite analyse critique de « l'affaire » de la NSAKEY
Posté par djrom (page perso, ). Modéré le 30 novembre 2002.
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é).
![[fr]](../images/fr.png)
L'article en question (1152 hits)-
Le site uZine (347 hits)
> Lire la dépêche (33 commentaires, moyenne: 1,8).
Vous avez demandé le commentaire #153260.
Run by 
Cette page a été générée par Templeet en 0.0539s (dont 0.0032 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
La vrai question derriere tout ca ?
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 ?
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 ?
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é
le binaire en question était le compilateur ,dont les sources était propre
[^]Re: désolé je me suis mal exprimé
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é
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 ?
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 ?
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