Terminaux Android et puces Qualcomm : le chiffrement intégral peut être cassé

matériel non libre donc possibilité d’intégrer un backdoor: c’est techniquement facile de générer une seconde clé qui marche aussi bien que la clé normale, mais que seul l’OEM constructeur du matériel connait à la fabrication (en théorie) mais que la NSA (ou une agence chinoise… vu que le matériel est fabriqué en Chine) peut aussi obtenir… y compris pour espionner sa population ou ses opposants politiques, ou voler des secrets à l’étranger.



Les algos à clé publique, même avec beaucup de bits (et surtout ces clés là, supposées fortes) peuvent très bien utiliser 3 clés différentes et pas seulement deux; avec l’algo RSA, les deux clés normales sont deux nombres: la clé publique est le produit des deux, une clé est détenue par le propriétaire qui peut décrypter le message encodé par la clé publique; mais avec 3 nombres ça marche aussi (tout dépend de la façon dont on crée la fonction “produit”: la clé privée peut être en fait le produit de deux nombres, dont un est détenu par le fabriquant… résultat un backdoor.



Il y a d’autres techniques encore dans la génération des clés privées qui ne sont pas si aléatoires qu’on le voudrait. L’algo RSA d’ailleurs (dans sa forme publiée) ne cherche même pas à assurer que les deux nombres sont premiers, juste qu’ils ont une FORTE probabilité de l’être. Produire une paire de nombres premiers très longs est très couteux en calcul et factoriser la clé privée l’est tout autant: les clés privées de 1024 bits ne sont pas réellement aléatoires et ce ne sont pas les matériels qui les génère directement: ils créent eux aussi des clés dérivées.



Apple ne veut pas le dire mais son algo doit certainement ne pas utiliser les clés au hasard (et Apple s’en sert pour arriver à bloquer des iPhones volés même quand ils ont été “complètement” effacés logiciellement).



Les appareils militaires en revanche utilisent leurs propres générateurs de clés aléatoire avec des matériels bien plus sophistiqués (au résultat réellement imprédictibles) tels que des mesures d’effets quantiques. On n’a pas ça dans nos matériels grand public, même si on en a des versions limitées tels que les capteurs de température ou de bruit électronique (mais à la résolution très limitée). Pour faire des clés privées avec nos matériels ils faut combiner un très grand nombre de sources matérielles aléatoire, un nombre tellement grand que cela demanderait un temps énorme à les obtenir en nombre suffisant, peut-être même plsu que la dure de vie du matériel.



On attend encore sur le marché une puce de génération de nombres quantiques permettant d’alimenter le fameux “/dev/random” ou similaire utilisé dans les OS et les bibliothèques de sécurité pour générer les clés à la demande en un temps raisonnable. Mais nos générateurs de clés sont très rapides, trop rapides (donc pas fiables: ils se contentent que d’un nombre limité de mesures, pas réellement totalement indépendantes entre elles). Il n’y a pas d’appareil grand public disposant de réels générateurs aléatoires forts: on fait tous confiance aux constructeurs et éditeurs de logiciels, même quand on utilise un noyau Linux libre.



Si on voulait sécuriser les OS libres, ce serait bien de développer une petite puce de mesure de bruit quantique (avec une grande précision des mesures), et pas seulement mesurer des varaibles faibles comme la rotation d’un disque, le nombre de “memory page faults” dans un kernel, les mouvements d’une souris, la vitesse de frappe ou même un périphérique de capture audio (bruit de fond, vent), ou le bruit électrique de charge ou de décharge d’une batterie (les capteurs de batterie ont une fréquence de capture et une résolution très faible: Un noyau Linux peut mettre des années avant que le contenu de ses variables d’état pour /dev/random soit réellement aléatoire et il n’est pas dit qu’il ne produit pas des “boucles” d’états identiques.



 De plus on sollicite beaucoup trop souvent ce générateur “faible”: les clés successives obtenues sont trop liées entre elles: si on arrive à obtenir une clé générée peut de temps après celle qu’on cherche à casser, on peut déduire de cette clé des propriétés que la clé recherchée peut vérifier, en nombre suffisant pour que l’attaque en force brute soit techniquement facile à peu de frais (sans solliciter votre appareil: la clé sera cassée à distance sur une autre machine, il n’y aura pas d’activité suspecte que celle de demander à votre appareil quelques clés aléatoires “nouvelles”: c’est facile à faire avec une application commune qui utilise un protocole SSL: il suffit que cette application se connecte assez souvent: genre appli Facebook, ou Google ou un jeu en ligne: ces nombres pseuo-aléatoires peuvent être diffusés en grand nombre par votre appareil, assez pour permettre de casser une autre clé privé qui aurait été générée longtemps avant et que votre appareil n’a pas révélée et qu’un craqueur n’a meêm pas tenté de demander ou d’utiliser indirectement).



Bref un truc à développer: une petite clé USB ou une puce MicroSD qui génère de vrais nombres aléatoires pour alimenter le jeu de données du générateur aléatoire du système, et aussi souvent que les applications demandent de nouvelles clés aléatoires via une API de l’OS. Là nos systèmes auront une vraie sécurité nous mettant à l’abri des intrusions par les constructeurs (et indirectement via eux, par les agences d’espionnage américaines ou chinoises). Mais est-ce que ce type de matériel sera autorisé à l’exportation par les agences de sécurité nationales, qui les réserve pour leur usage militaire?



En attendant il doit y avoir moyen de bricoler ça avec des appareils de mesure à haute fréquence (genre oscilloscope), et un peu de matériel générateur de bruit quantique mesurable (par exemple certains transistors en limite de stabilité sur leur jonction, ou une zimple diode zéner, ou même la cellule CCD d’une caméra). Un bon bricoleur pourrait installer ça dans une alim et sortir le résultat sur une prise USB et un minicontroleur avec un tout petit peu de mémoire pour stocker des mesures inutilisées ou les raffraichir en quantité suffisante pour l’usage par un OS, et un tout petit pilote pour lire les données de ce port USB et raffraichir le générateur aléatoire de l’OS, puis quelques tweaks poru que ce générateur demande des mesures plus souvent à ce petit appareil.



Autre paliatif en attendant: quand on ne prend pas de photo sur un smartphone, régler l’appareil photo  à la limtie de la saturation pour lui faire observer les zones “noires” avec une forte amplification. Le résultat c’est du bruit comparable à ce qu’on voit dans les trames d’une photo numérique non traitée (on en voit moins dans les photos JPEG, là on parle de photos en mode “RAW”). Idem en utilisant le micro en suramplification (ça marchera dans une atmospère sonore pas trop bruyante), ou en mettant le micro devant un ventilo de refroidissement sur les PC de bureau et notebooks.



Mais sans ça nos PC et smartphones ont des générateurs aléatoires très faibles. Générer des clés RSA sur ces appareils produit des clés cassables si on dispose d’autres clés générées de la même façon (et faciles à obtenir par des tiers pas tellement de confiance).



Toute la sécurité des algos à clé publiques (SSL, HTTPS…) tient à la qualité du générateur aléatoire de votre machine. Mais elle est très médiocre.