Code : Tentative d'insertion d'une porte dérobée dans le noyau Linux
Posté par helicopunch (). Modéré le 06 novembre 2003.
Fort heureusement, une mise à jour du miroir CVS compromis depuis les serveurs principaux hébergeant l'arborescence BitKeeper des sources du noyau a permis de corriger le problème.
![[en]](../images/en.png)
L'article sur kerneltrap.org (2701 hits)-
La dépêche OSNews (1008 hits)
> Lire la dépêche (146 commentaires, moyenne: 4,2).
Vous avez demandé le commentaire #296110.
Run by 
Cette page a été générée par Templeet en 0.0887s (dont 0.0258 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Re: Tentative d'insertion d'une backdoor dans le noyau Linux
cholie pub pour bitkeeper :)
Groar !
[^]solutions libres
il n'y a heureusement pas besoin de bitkeeper pour s'assurer qu'un miroir CVS est conforme à l'original, l'utilisation d'un digest/hash de type sha2 suffit amplement !
sinon pour le commun des mortels qui n'utilise pas les CVS pour avoir leur noyau il y a les signatures GPG des miroirs de kernel.org
http://kernel.org/signature.html(...)
[^]Re: solutions libres
l'utilisation d'un digest/hash de type sha2 suffit amplement !
Pourquoi toujours sha2 (sha-256|384|512 en fait) ? SHA-1 est toujours considéré comme très sur par rapport à l'emploi qui en est fait.
[^]plusieurs algos avec grosses clés
Pourquoi ne pas utiliser ce qui se fait de mieux si ça ne ralentit pas ?
En dehors du onetimepad (et sous certaines conditions) aucun algo de crypto n'est démontré sûr mathématiquement.
Et régulièrement des failles sont publiées sur des algos qu'on croyait fiables...
Tout dépend aussi de l'importance des données à protéger: dans le cas du noyau Linux,
il mérite de larges précautions puisqu'il peut être utilisé par certains pour des données très importantes !
Quand on est "parano" (à tort ou raison) je pense qu'il vaut mieux utiliser plusieurs algos en même temps et avec des tailles de clé importantes ! (sans compter les bugs dans les implémentations de ces algos...)
[^]Re: plusieurs algos avec grosses clés
Sans preuve de sécurité, un algo n'est jamais garanti.
La notion d'algorithme "sûr" telle que je l'ai entendue pratiquer en séminaires/groupes de travail, c'est:
* la force brute va mettre potentiellement des millions d'années à le casser avec les machines actuelles;
* tous les trucs que l'on connaît et qui permettent d'affaiblir au moins une méthode de crypto ancienne, n'apportent pas d'amélioration fulgurante sur cette force brute.
Cette notion de sécurité non garantie est pratique, mais a quelques inconvénients puisqu'une méthode sûre dans ce sens peut tomber:
* par chance: vous commencez votre attaque d'une clef à un endroit choisi au hasard, et vous tombez pile à côté de la clef réelle (très improbable);
* par progrès technologique: les machines deviennent des millions de fois plus puissantes soudainement (relativement improbable);
* par progrès scientifique: on trouve une nouvelle attaque (c'est souvent)
Pour info, les labos de crypto jouent à "la mienne est meilleure" (de méthode de cryptage); certains proposent une nouvelle méthode (ou une variante d'une méthode existante), et les autres rétorquent "Non, en faisant comme ci, comme ça, on la casse, ta méthode, essaie plutôt ça..."; bref, c'est assez amusant d'être assis dans les tribunes et d'admirer le spectacle.
Si vous voulez perdre votre confiance mal placée dans les méthodes de crypto actuelles, allez lire les conditions qu'on se donne sur les nombres premiers avant de les utiliser pour crypter, et dites-vous que chaque condition est apparue en réponse à une attaque possible...
Snark
PS1: si vous trouvez une liste qui se contente de demander "p, q: deux grands nombres premiers", vous n'avez pas trouvé une bonne page, les bonnes commencent par ça, puis enchainent sur:
* pas trop près l'un de l'autre
* pas congrus à bidule modulo machin
* p-1 ne doit pas se décomposer avec des nombres premiers trop petits
* ...
PS2: avant qu'on me pose la question, oui, j'utilise ssh et pas telnet, parce qu'entre rien du tout et une passoire, je préfère encore la passoire!
[^]Re: plusieurs algos avec grosses clés
Le one time padding a ete prouve mathematiquement sur, pas cryptographiquement sur. Ca veut notamment dire que meme si tu tombes sur la bonne cle (meme au premier essai), et bien ca ne change rien puisque tu ne peux pas savoir que cette cle etait la bonne.
Par contre, c'est inutilisable pour proteger le noyau. Ca ne peut servir grosso-modo qu'aux ambassades, genre tu envoies le CD contenant la cle dans la valise dilomatique, et tu peux ensuite t'en servir deux mois plus tard pour envoyer un email securise.
[^]OTP pour tous
Ca ne peut servir grosso-modo qu'aux ambassades
Non car je peux donner un CD ou un DVD contenant du random (=clé OTP) à des amis que je rencontre en personne sans être ambassadeur !
et en compressant bien les données à échanger, je peux ensuite échanger avec eux plusieurs messages textes (voir téléphoniques) par jour pendant des années en toute sécurité (et sans avoir besoin de les rencontrer en personne à nouveau)
[^]Re: plusieurs algos avec grosses clés
Le one-time-pad n'entrait pas dans le champ de ce que je racontais... C'est un truc quand même à part... le seul à ma connaissance qui soit (quasi-)utilisable et théoriquement prouvé simultanément.
Snark
PS: je dis "quasi" utilisable, parce que d'une part remplir un CD avec des données bien aléatoires, c'est pas tout à fait trivial, et d'autre part, son utilisation demande à ce qu'au préalable on ait réussi à faire transiter toutes ces données par un canal sûr...
[^]Re: plusieurs algos avec grosses clés
* la force brute va mettre potentiellement des millions d'années à le casser avec les machines actuelles;
* tous les trucs que l'on connaît et qui permettent d'affaiblir au moins une méthode de crypto ancienne, n'apportent pas d'amélioration fulgurante sur cette force brute.
Moi je n'utiliserais pas ça comme définition de sûr. C'est beaucooup trop subjectif, et peut évoluer.
Je dirais plutôt :
* L'attaque par force brute est la meilleure attaque possible (connue ou pas).
Après, le truc du million d'année ne veut pas dire grand chose, disons
* L'attaque par force brute est au moins de complexité exponentielle en une donnée de la méthode de cryptage.
Note que je n'ai vraiment que des connaissances très basiques en crypto (ce qui se voit certainement dans la naïveté de mes définitions), je suis plutôt matheux (ce qui se voit certainement dans...;)
[^]Re: plusieurs algos avec grosses clés
Mais... ce sont des mathématiciens (moi aussi d'ailleurs). La raison pour laquelle c'est si foireux, c'est que si on tente de pondre des définitions bien propres, elle ne seront pas applicables aux algos actuels!
Il suffit de jeter un coup d'oeil à:
http://csrc.nist.gov/encryption/aes/rijndael/Rijndael-ammended.pdf(...)
et comparer les parties 8 et 9... Respectivement "Ce contre quoi on s'est arrangé pour qu'il puisse résister" et "Les garanties". C'est pas une chambre à air avec une ou deux rustines, c'est un paquet de rustines.
En résumé: les définitions sont à la mesure de nos connaissances dans ce domaine: ridicules!
Snark
[^]Re: plusieurs algos avec grosses clés
Et régulièrement des failles sont publiées sur des algos qu'on croyait fiables...
Attention, il faut bien distinguer algorithmes et protocoles. En crypto, l'un et l'autre sont importants.
Par exemple si tu prends RSA, considéré aujourd'hui comme sûr : l'algo est très simple, il peut être expliqué en quelques lignes (http://www.rsasecurity.com/rsalabs/faq/3-1-1.html(...)). En revanche pour chiffrer ou signer un e-mail par exemple, il faut un protocole qui va expliquer comment appliquer cet algo à un flux de caractères pour le transmettre comme un e-mail classique (cf CMS rfc 2630 et S/MIME rfc 2311).
Deux exemples ou l'utilisation d'un protocole foireux peut compromettre un algo sûr :
- on peut utiliser les messages d'erreurs concernant le padding pour réussir à trouver 1 à 1 les bits de clé. voir problèmes d'implémantation de la cryptographie : les attaques par effet de bord dans MISC n°4
- on peut utiliser les propriétés multiplicatives de RSA afin de forger des signatures valides. C'est très bien expliqué ici : http://www.eleves.ens.fr/home/coron/publications/thesis/node8.html(...)
Hurd will be out in a year (or two, or next month, who knows)
-- Linus Benedict Torvalds, 1991
[^]Re: plusieurs algos avec grosses clés
Absolument pas, SHA-1 et SH1-2 sont basés sur le même principe, il y a une forte chance qu'une attaque qui marche sur l'un marche sur les autres. Et SHA-2 n'est pratiquement utilisé que pour des hashes de données très volumineuses. SHA-2 n'est pas fondamentalement meilleur que SHA-1, c'est juste une adaptation.
[^]Re: plusieurs algos avec grosses clés
tu oublies que beaucoup d'attaques ne font qu'éliminer rapidement un % de cleartext possibles tout en laissant un % non négligeable de possibilités à explorer par de la force brute.
Dans ce cas le fait d'avoir une clé plus grande (512 bits vs 128) reste un (exponentiel) avantage !
[^]Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Oui tout à fait.
De là à dire que c'est Linus lui-même qui a introduit la backdoor...
[^]Re: Tentative d'insertion d'une backdoor dans le noyau Linux
Dailleur : Linus Torvald VS RMS au sujet de Bitkeeper...
http://linuxfr.org/2002/10/23/10070.html(...)