NSA, decryptage et Debian

Pause Café
#1

Un article apparemment alarmant:
liberation.fr/monde/2013/09/ … ret_929807

puis un autre plus fouillé

propublica.org/article/the- … encryption

indiquant que ce prétendu décryptage repose essentiellement sur une généralisation de porte dérobée sur les machines et serveurs.
La plupart de ses portes ont été imposées par la NSA aux concepteurs.

Debian est le nom du projet d’une organisation (SPI) fondée aux USA et soumis à ses lois (par exemple tout don à Debian est déductible des impôts aux USA). Dans quelle mesure la NSA ne peut elle obliger cette organisation à insérer elle même des portes dérobées dans le code? À mon avis, elle en a le pouvoir. Le seul garde fou est l’organisation du projet qui consiste à publier les sources, les patchs et à les soumettre à un contrôle, contrôle fait en grande partie par des étrangers qui ne manqueraient pas de les signaler. Ça signifie sans doute que Debian ne peut être corrompu de cette manière. Par contre on peut se poser des questions sur les codes propriétaires rajoutés (virtualbox d’Oracle par exemple ou encore les firmwares propriétaires des cartes WIFI…).

Conclusion: Les personnes convaincues de leur importance au point d’intéresser la NSA ou les paranos vont voir leur vie se compliquer, les personnes attachées aux principes et convaincues que l’abandon de ceux ci par un gouvernement se voulant démocratique et respectueux de ces principes constituent en soi une victoire du terrorisme vont avoir une baisse de moral…

#2

c’est clair que c’est alarmant.
Cependant, c’est un argument de plus pour l’opensource: les sources étant publiée, dur de cacher des backdoors…, mais au vu de la complexité et le volume representé par le code, il peut être délicat de trouver des “experts” aptes à valider l’abscence de code “frauduleux”.
Pour le clampin lambda, c’est pas supersuper, mais s’il n’a rien à se reprocher, mis à part ses photos avec la voisine… il ne risque pas d’ennuis.
Pour des entreprises, il s’agit clairement d’ouvrir la porte aux espions, et donc une perte économique possible
Et pour les moyens publics (armée, energie, etc…) d’une porte ouverte au blocage posssible d’un pays (comme ce fut plsu ou moins le cas en Iran…).

#3

Concernant les problèmes survenus en Iran il faut remercier Siemens et son usine à gaz de système de supervision. Ceci dit les intrusions sur les systèmes industriels sont beaucoup plus faciles à réaliser avec du matériel Rockwell, qui lui est américain. C’est même tellement facile qu’on jurerait que c’est fait exprès.

#4

pour la confidentialité des échanges courriels il reste gpg,garanti par snowden lui même:

http://www.slystone.legtux.org/?p=518

mais crypter les mails suppose que ceux à qui ils sont destinés acceptent d’installer gpg sur leur bécane,et comme l’immense majorité des gens s’en fout complètement…vu le nombre d’utilisateurs de fesse de bouc…et autres passoires tournant sur le système passoire majoritairement utilisé…
Ce qui est plus inquiétant c’est la possibilité avérée et fondée de casser les codes qui garantissent la confidentialité, des paiements en ligne quand nous payons des achats sur internet,si ces cons ouvrent des portes dérobées il devient évident que d’autres malfrats s’engouffreront aussi dans la brèche.Concernant oracle virtualbox auquel fran.b fait allusion il faut savoir que le code source est disponible.

#5

Fran.b parlait du code propriétaire de virtualbox (le pack d’extensions)

#6

Si ça ressort sur un site holé-holé et que le/la coucou tombe dessus, il risque de gros problèmes.
:049 :018

#7

et donc https et ssl ca sert plus a grand chose …apparement…

lemonde.fr/technologies/arti … 51865.html

#8

Il faut lire l’article. Ils n’ont pas cassé le code, ils ont «trichés» en mettant des portes dérobées interceptant le message ou les clefs. Cela signifie que sur des machines non «sûres», il y a un réel problème. SSL (et donc https), SSH, gpg, etc sont fondées sur des codes asymétriques avec une clef secrète jamais diffusée. En gros

  • Les deux machines échangent leurs clefs publiques
  • Puis à l’aide de cela elles échangent un clef de codage très longue qui leur sert à chiffrer le trafic à venir pour un certain temps avec un codage symétrique beaucoup plus rapide.

À aucun moment la clef privée est envoyée donc il est impossible à la NSA de l’obtenir autrement que par un mouchard sur ta machine.

Conséquence, dans le cas où ta machine est sûre, seule la transaction en cours peut poser problème si la machine de l’autre coté est «corrompue». Par contre si celle ci est sûre, alors le NSA peut se brosser, on ne sait pas à l’heure actuelle décoder de manière efficace le cryptage asymétrique utilisé ((lis le deuxième article).

Toutes ces révélations vont avoir comme conséquence une plus grande méfiance et inciter à la méfiance vis à vis des entreprises américaines. À moyen terme, c’est loin d’être négligeable. Un email gpg entre deux personnes sous linux/debian avec des machines sans code propriétaire n’a aucune chance d’être décodé par la NSA à cette heure.

#9

Ce n’est pas ce que je comprends du dernier article que j’ai lu. Ils ont semble t-il réussi à introduire des failles dans les bibliothèques SSL/TLS. Évidement pour l’implémentation de MS, ils n’ont pas grand chose à faire. Mais il semble sous-entendre qu’OpenSSL et GnuTLS peuvent aussi être toucher. Faut pas croire une backdoor ce n’est pas forcément une socket ouverts sur le monde extérieur. Des fois simplement en implémentant de manière naïve un algo, il peut perdre de sa force ou permettre à un autre processus du même système de retrouver la clef privé. Je ne retrouve plus le lien mais il y a une bibliothèque importante qui était touché par ce problème il y a encore peu de temps.

Si seulement tu avait raison… Mais le manque de réaction politique (ça ça me rend particulièrement triste, on se fait b??s?r par les USA et on continue de leur faire la lèche…) et le manque de réaction des gros hors USA pour construire des alternatives (trouve un navigateur web non américain (c’est une application critique)). Il faudrait un sursaut (y compris des LL), pour ne plus être américano-centré (parce que bon Debian, Red Hat, Mozilla, github, etc c’est aux US).

C’est très peu utilisé et assez contraignant. De plus ce n’est pas vraiment sans code propriétaire, mais « sans code propriétaire et uniquement avec des logiciels libres relativement connu/réputés (à fin d’être sûr qu’ils aient étaient audités) ».

#10

…donc en gros la nsa utilise le Man In The Middle…

#11

Grhim: Non, elle intercepte avant chiffrage.

MisterFreez: [quote]Ce n’est pas ce que je comprends du dernier article que j’ai lu. Ils ont semble t-il réussi à introduire des failles dans les bibliothèques SSL/TLS. [/quote]
C’est ce que je voulais dire, si tu utilises une bibliothèque SSL/TLS propirétaire (code de Microsoft, Oracle, Apple, etc), il y a possibilité de l’existence d’une faille. Sinon, non. Le principe du chiffrage utilisé dans SSL/TLS reste sûr au stade actuel des connaissances.

Tu as des failles envisageables: citons par exemple l’utilisation du clef privée trop petite (pas en nombre de bits, mais en tant qu’entier (restant écrit sur 4096 bits par exemple), j’ai fait une feuille de calcul réalisant un tel craquage), il y a aussi la bibliothèque de génération de clef qui peut être bugguée et limiter le nombre de clefs fabriquées. C’est ce que était arrivé il y a quelques années à Debian et c’est à l’origine du paquet openssh-blacklist.
Il n’y a pas de faiblesse systématique exploitable découverte dans SSL/TLS actuellement.

#12

merci à fran.b et à tous les pros de ce forum pour éclairer la lanterne des non- spécialistes dont je fais partie.Petit à petit les choses deviennent plus claires et nous font mieux comprendre le bien fondé de notre choix d’un OS non proprio et non contrôlé par les US.Comment comprendre le manque de réactions de nos “élus” face à cette menace de se faire dépouiller de cette façon?

#13

[quote=“marcastro”]Comment comprendre le manque de réactions de nos “élus” face à cette menace de se faire dépouiller de cette façon?[/quote]pourtant on a bien des pare-feux OpenOffice :stuck_out_tongue:

#14

[quote=“basil.garlic”][quote=“chuck_73”]
Pour le clampin lambda, c’est pas supersuper, mais s’il n’a rien à se reprocher, mis à part ses photos avec la voisine… il ne risque pas d’ennuis.
[/quote]

Si ça ressort sur un site holé-holé et que le/la coucou tombe dessus, il risque de gros problèmes.
:049 :018[/quote]

Ce qui est bien une des activités principale des employés de la NSA même s’ils restent très discret sur le sujet.

#15

C’est ce que je voulais dire, si tu utilises une bibliothèque SSL/TLS propirétaire (code de Microsoft, Oracle, Apple, etc), il y a possibilité de l’existence d’une faille. Sinon, non. Le principe du chiffrage utilisé dans SSL/TLS reste sûr au stade actuel des connaissances.[/quote]
On est d’accord là dessus on ne sait toujours pas décomposer de grands nombres en facteurs premiers de manière assez performante (ça reste un problème NP). L’augmentation de la taille des clef augmente déraisonnablement le temps de décomposition.

Il faut tout de même noter, que la NSA est probablement la plus avancé dans l’étude fondamentale de ses algo et qu’ils ont à la fois une armée de mathématiciens, mais aussi la plus grosse concentration de supercaculateur au monde (pour ceux qui regardent le top500 tous les 6 mois : les militaires n’y participent pas).

[quote=“fran.b”]Tu as des failles envisageables: citons par exemple l’utilisation du clef privée trop petite (pas en nombre de bits, mais en tant qu’entier (restant écrit sur 4096 bits par exemple), j’ai fait une feuille de calcul réalisant un tel craquage), il y a aussi la bibliothèque de génération de clef qui peut être bugguée et limiter le nombre de clefs fabriquées. C’est ce que était arrivé il y a quelques années à Debian et c’est à l’origine du paquet openssh-blacklist.
Il n’y a pas de faiblesse systématique exploitable découverte dans SSL/TLS actuellement.[/quote]
La faille Debian était une connerie. La sécurité informatique c’est pire que ça : la faille peut être dans le compilateur ou dans la CPU (c’est qui qu’a conçu votre CPU ? :slightly_smiling: ). De plus même s’il ne s’agit pas de faille systématique nous avons aujourd’hui 2 grosses implémentations qui représentent l’énorme majorité de ce qui est utilisé (en libre ou non d’ailleurs).

@Grhim > Bien sûr qu’ils peuvent (oui oui François), mais ce n’est pas le sujet. Ils leur suffit d’éditer un certificat pour le site que tu cherche à joindre avec comme autorité racine l’une de celles inclus dans tous les navigateurs (il en suffit d’une, il y en a combien qui sont soumis au patriot act ?). Tu pense contacter le bon serveur (ton DNS résoud bien machin.com vers ce serveur et il a un certificat pour le nom de domaine machin.com tout ce qu’il y a plus valide) et eux s’occupe de contacter le destinataire pour toi. Cette technique n’a rien de nouveau et est déjà utilisé dans certaines entreprises (elles configurent les machines avec leur propre autorité). Ça demande évidement d’empoisonner les DNS, mais ça c’est possible (surtout quand tu es root des DNS racine…).

#16

[quote=“Blacksad”][quote=“basil.garlic”][quote=“chuck_73”]
Pour le clampin lambda, c’est pas supersuper, mais s’il n’a rien à se reprocher, mis à part ses photos avec la voisine… il ne risque pas d’ennuis.
[/quote]

Si ça ressort sur un site holé-holé et que le/la coucou tombe dessus, il risque de gros problèmes.
:049 :018[/quote]

Ce qui est bien une des activités principale des employés de la NSA même s’ils restent très discret sur le sujet.[/quote]

Dans le cas où il y a déjà eu des fuites à la NSA, vers la presse, on ne peut pas exclure qu’il y ait des fuites dans les organes de presses, fuites en cascades, sans jeux de mots.

#17

je décroche :confusion-seeingstars: les turpitudes de tous ces cerveaux malades me font gerber;j’avais rêvé d’un monde plus simple… :078

#18

C’est à se demander si la faille openssl debian de 2008 n’était pas volontaire, plutôt qu’une légère erreur, “par mégarde”, dans le générateur de nombres aléatoires…

Le jour où RSA est cassé, il y a les courbes elliptiques pour “échanger” des clefs secrètes en asymétriques avec une méthode à la Diffie Heilmann sur une courbe elliptique. Il y a déjà une implémentation dans Debian, aptitude install seccure. Reste à vérifier que le code fait ce qu’il dit et qu’il est robuste. Fran.b tu t’y atèles? Moi ça commence à remonter ces histoires de courbes elliptiques, déjà que quand j’étais étudiant j’avais pas tout pigé…

Le truc super classe en cryptologie c’est d’avoir cassé un protocole de chiffrement et d’être le seul à être au courant, c’est pas exclu que ça soit le cas pour RSA et variantes? Si ils ont un ordinateur quantique, BOUM, c’est fini.

#19

Probablement pas. Cette histoire a était complètement tracé et on sait pourquoi qui a fait quoi.

De ce que je sache personne ne fait de l’argent avec Pause Café donc pas la peine de faire du sensationnalisme… RSA n’est pas cassé, la NSA ne sait toujours pas décomposer en facteur premier de grands nombre, sinon PGP serait cassé. C’est SSL qui a une faille si on ne l’utilise pas avec le bon cypher.

Il y a nettement plus rigolo. Ne pas casser de chiffre, mais faire croire qu’on l’a cassé. Ça pousse l’ennemi à en changer sans raison. Ça a déjà était utilisé lors de la guerre froide. :slightly_smiling:

#20

Je cherchais cette page il y a quelques jours, pour montrer qu’il y a plusieurs problématiques importantes dans la confidentialité des échanges : linuxfr.org/news/sortie-de-gnup … rypt-1-5-3
Un algorithme peut être mathématiquement prouvé et incassable, son implémentation peut poser des problèmes (c’est le cas ici présent).