Quelques Réflexions sur l’Ingénierie Cryptographique

Il y a quelques semaines, j’ai écrit un long article sur le projet « BULLRUN » de la NSA visant à renverser les normes de cryptage modernes. J’avais l’intention d’y revenir à un moment donné, car je n’avais pas le temps de discuter des problèmes en détail. Mais ensuite, les choses se sont mises en travers. Beaucoup de choses, en fait. Certains dont j’espère écrire dans un proche avenir.

Mais avant d’y arriver, et au risque de vous ennuyer tous aux larmes, j’ai voulu revenir au moins une fois de plus sur ce sujet, ne serait-ce que pour pontifier un peu sur une question qui m’a dérangé.

Vous voyez, la fiche d’information de la NSA BULLRUN mentionne que la NSA a cassé pas mal de technologies de cryptage, dont certaines sont plus intéressantes que d’autres. Une de ces technologies me surprend particulièrement, car je ne peux tout simplement pas comprendre comment la NSA pourrait le faire. Dans ce post extrêmement long, je vais essayer de creuser un peu plus profondément la question la plus importante à laquelle Internet est confronté aujourd’hui.

Plus précisément: comment diable la NSA brise-t-elle SSL?

Section de la feuille de briefing BULLRUN. Source: New York Times.

Pour garder les choses sur la cible, je vais établir quelques règles de base de base.

Tout d’abord, je suis bien conscient que la NSA peut installer des logiciels malveillants sur votre ordinateur et pwn n’importe quelle cryptographie de votre choix. Cela ne m’intéresse pas du tout, pour la simple raison que cela ne s’adapte pas bien. La NSA peut vous le faire, mais elle ne peut pas le faire pour toute une population. Et c’est vraiment ce qui me préoccupe au sujet des fuites récentes: la possibilité que la NSA brise le cryptage à des fins de surveillance de masse.

Pour la même raison, nous n’allons pas nous inquiéter des attaques de l’homme du milieu (MITM). Bien que nous sachions que la NSA les exécute, il s’agit également d’une attaque très ciblée. Non seulement les MITM sont détectables si vous les faites à grande échelle, mais ils ne correspondent pas à ce que nous savons sur la façon dont la NSA intercepte à grande échelle – principalement via des séparateurs de faisceaux et des robinets. En d’autres termes: nous sommes vraiment préoccupés par la surveillance passive.

Les règles ci-dessus ne sont pas absolues, bien sûr. Nous envisagerons des attaques ciblées limitées sur les serveurs, à condition qu’elles permettent par la suite le décryptage passif de grandes quantités de trafic; par exemple, le décryptage du trafic vers les principaux sites Web. Nous envisagerons également des modifications arbitraires des logiciels et du matériel – ce que nous savons que la NSA fait déjà.

Un dernier point: pour éviter que les choses ne déraillent, j’ai utilement divisé ce post en deux sections. La première couvrira les attaques qui utilisent uniquement des techniques connues. Tout dans cette section peut être mis en œuvre par un employé de TAO avec suffisamment de gumption et d’accès au logiciel. La deuxième section, que j’ai intitulée « Spectre du chapeau en papier d’aluminium » couvre les choses amusantes et spéculatives — allant des nouvelles attaques de canaux secondaires jusqu’à cet énorme ordinateur quantique que la NSA garde à côté de l’IBB.

Nous allons commencer par le « pratique ».

Attaques utilisant des techniques connues

Vol de clés RSA. Le moyen le plus évident de « casser » SSL n’implique pas vraiment de craquer quoi que ce soit. Pourquoi perdre du temps et de l’argent sur la cryptanalyse alors que vous pouvez simplement voler les clés? Ce problème est particulièrement préoccupant dans les serveurs configurés pour la prise de contact TLS RSA, où une seule clé de serveur de 128 octets est tout ce dont vous avez besoin pour déchiffrer chaque connexion passée et future établie à partir du périphérique.

En fait, cette technique est si évidente qu’il est difficile d’imaginer que la NSA dépense beaucoup de ressources pour des attaques cryptanalytiques sophistiquées. Nous savons que le GCHQ et la NSA sont parfaitement à l’aise pour suborner même les fournisseurs américains à l’étranger. Et à l’intérieur de nos frontières, ils ont démontré leur volonté d’obtenir des clés TLS / SSL en utilisant des pouvoirs d’assignation et des ordres de bâillon. Si vous utilisez une connexion RSA à un site Web majeur, il peut être judicieux de supposer que la clé est déjà connue.

Bien sûr, même lorsque la NSA n’a pas recours à des mesures directes, il est toujours possible d’obtenir des clés via un exploit logiciel distant. La beauté est que ces attaques ne nécessitent même pas d’exécution de code à distance. Compte tenu de la vulnérabilité appropriée, il peut simplement nécessiter une poignée de requêtes SSL mal formées pour mapper le contenu complet du tas OpenSSL / SChannel.

Source: New York Times

Puces de chiffrement matériel subornage. Une fraction importante du trafic SSL sur Internet est produite par des périphériques matériels tels que les terminateurs SSL et les routeurs compatibles VPN. Heureusement, nous n’avons pas à spéculer sur la sécurité de ces appareils — nous savons déjà que la NSA / GCHQ a collaboré avec les fabricants de matériel pour « activer » le décryptage sur plusieurs puces de cryptage VPN majeures.

Les documents de la NSA ne sont pas clairs sur le fonctionnement de cette fonctionnalité, ou si elle implique même SSL. Si c’est le cas, la supposition évidente est que chaque puce crypte et exflitrate des bits de la clé de session via des champs « aléatoires » tels que les IV et les nonces de poignée de main. En effet, ceci est relativement facile à mettre en oeuvre sur un dispositif matériel opaque. La question intéressante est de savoir comment on s’assure que ces portes dérobées ne peuvent être exploitées que par la NSA — et non par des agences de renseignement rivales. (Quelques réflexions à ce sujet ici.)

Attaques de canaux latéraux. Traditionnellement, lorsque nous analysons des algorithmes cryptographiques, nous nous préoccupons des entrées et des sorties attendues du système. Mais les systèmes réels fuient toutes sortes d’informations supplémentaires. Ces « canaux secondaires » — qui incluent le temps de fonctionnement, la consommation de ressources, la synchronisation du cache et les émissions RF – peuvent souvent être utilisés pour extraire du matériel de clé secrète.

La bonne nouvelle est que la plupart de ces canaux ne sont exploitables que lorsque l’attaquant se trouve à proximité physique d’un serveur TLS. La mauvaise nouvelle est qu’il existe des conditions dans lesquelles l’attaquant peut s’approcher. L’exemple le plus évident concerne les serveurs TLS virtualisés dans le paramètre cloud, où un attaquant intelligent peut partager des ressources physiques avec l’appareil cible.

Une deuxième classe d’attaque utilise des informations de synchronisation à distance pour récupérer lentement une clé RSA. Ces attaques peuvent être désactivées via des contre-mesures telles que l’aveuglement RSA, bien que, de manière amusante, certains co-processeurs matériels « sécurisés » peuvent en fait désactiver ces contre-mesures par défaut! À tout le moins, cela rend le matériel vulnérable aux attaques d’un utilisateur local et pourrait même faciliter la récupération à distance des clés RSA.

Générateurs de nombres aléatoires faibles. Même si vous utilisez des suites de chiffrement à secret avancé parfaites, la sécurité de TLS dépend fondamentalement de la disponibilité de nombres aléatoires imprévisibles. Ce n’est pas par hasard que la falsification des normes de générateur de nombres aléatoires semble avoir été au centre des efforts de la NSA.

Les nombres aléatoires sont essentiels à un certain nombre d’éléments dans TLS, mais ils sont particulièrement importants à trois endroits:

  1. Côté client, lors de la poignée de main RSA. Le RNG est utilisé pour générer le secret pré-maître RSA et le remplissage de chiffrement. Si l’attaquant peut prédire la sortie de ce générateur, il peut ensuite décrypter toute la session. Ironiquement, une défaillance du RNG du serveur est beaucoup moins dévastatrice pour la poignée de main RSA.*
  2. Côté client ou serveur, lors de la ou des poignées de main Diffie-Hellman. Comme Diffie-Hellman nécessite une contribution de chaque côté de la connexion, un RNG prévisible de chaque côté rend la session complètement transparente.
  3. Pendant la génération de clés à long terme, en particulier des clés RSA. Si ça arrive, tu es foutu.
Et vous n’avez tout simplement pas besoin d’être aussi sophistiqué pour affaiblir un générateur de nombres aléatoires. Ces générateurs sont déjà étonnamment fragiles, et il est terriblement difficile de détecter quand on est cassé. Les responsables de Debian l’ont magnifiquement fait en 2008 lorsqu’un nettoyage de code erroné a réduit l’entropie effective d’OpenSSL à seulement 16 bits. En fait, les RNG sont si vulnérables que le défi ici n’affaiblit pas le RNG — tout idiot avec un clavier peut le faire – il le fait sans rendre l’implémentation trivialement vulnérable à tout le monde.

La bonne nouvelle est qu’il est relativement facile d’altérer une implémentation SSL pour la faire chiffrer et exfiltrer la graine RNG actuelle. Cela nécessite toujours que quelqu’un modifie physiquement la bibliothèque ou installe un exploit persistant, mais cela peut être fait intelligemment sans même ajouter beaucoup de nouveau code au code OpenSSL existant. (L’amour d’OpenSSL pour les pointeurs de fonction le rend particulièrement facile à manipuler ce genre de choses.)

Si la falsification n’est pas votre style, pourquoi ne pas mettre la porte dérobée à la vue? C’est l’approche adoptée par la NSA avec le RNG Dual_EC, normalisé par le NIST dans la Publication spéciale 800-90. Il existe des preuves convaincantes que la NSA a délibérément conçu ce générateur avec une porte dérobée — qui leur permet de casser toute connexion TLS / SSL établie en l’utilisant. Puisque le générateur est (était) la valeur par défaut dans la bibliothèque BSAFE de RSA, vous devez vous attendre à ce que chaque connexion TLS effectuée à l’aide de ce logiciel soit potentiellement compromise.

Et je n’ai même pas mentionné les plans d’Intel pour remplacer le RNG du noyau Linux par son propre RNG matériel.

Faiblesses ésotériques dans les systèmes PFS. De nombreux serveurs Web, y compris Google et Facebook, utilisent désormais des suites de chiffrement de secret Direct parfaites comme l’éphémère Diffie-Hellman (DHE et ECDHE). En théorie, ces suites de chiffrement fournissent le meilleur de tous les mondes possibles: les clés persistent pendant une session, puis disparaissent une fois la connexion terminée. Bien que cela ne vous évite pas de problèmes de RNG, cela rend le vol de clé beaucoup plus difficile.

Les suites de chiffrement PFS sont une bonne chose, mais une variété de problèmes subtils peuvent nuire à leur style. D’une part, le mécanisme de reprise de session peut être difficile: les clés de session doivent être stockées localement ou cryptées et remises aux utilisateurs sous forme de tickets de session. Malheureusement, l’utilisation de tickets de session diminue quelque peu la « perfection » des systèmes PFS, car les clés utilisées pour chiffrer les tickets représentent désormais une faiblesse majeure du système. De plus, vous ne pouvez même pas les garder internes à un serveur, car ils doivent être partagés entre tous les serveurs frontaux d’un site! En bref, ils ressemblent à une sorte de cauchemar.

Un dernier sujet de préoccupation est la validation des paramètres de Diffie-Hellman. La conception SSL actuelle suppose que les groupes DH sont toujours générés honnêtement par le serveur. Mais une implémentation malveillante peut violer cette hypothèse et utiliser de mauvais paramètres, qui permettent l’écoute par des tiers. Cela semble être une avenue assez improbable pour permettre la surveillance, mais cela montre à quel point ces systèmes sont délicats.

Le spectre du chapeau en feuille d’aluminium

Je vais appeler le prochain lot d’attaques des vulnérabilités « chapeau en feuille d’aluminium ». Lorsque les numéros précédents utilisent tous des techniques bien connues, chacune des propositions suivantes nécessite des techniques cryptanalytiques totalement nouvelles. Tout cela est une façon de dire que la section suivante est de la pure spéculation. C’est amusant de spéculer, bien sûr. Mais cela nous oblige à supposer des faits qui ne sont pas des preuves. De plus, nous devons faire un peu attention à l’endroit où nous nous arrêtons.

Donc, à partir de maintenant, nous menons essentiellement une expérience de pensée. Imaginons que la NSA ait une capacité passive de rupture SSL; et de plus, qu’elle ne repose pas sur les astuces de la section précédente. Que reste-t-il ?

La liste suivante commence par les théories les plus « probables » et travaille vers les vraiment fous.

Rupture des clés RSA. Il y a une rumeur persistante dans notre domaine selon laquelle la NSA fissure des clés RSA 1024 bits. Il est douteux que cette rumeur provienne d’une connaissance réelle des opérations de la NSA. Plus probablement, cela est dû au fait que le craquage de clés 1024 bits est hautement réalisable pour une organisation disposant des ressources de la NSA.

Dans quelle mesure? Plusieurs chercheurs crédibles ont tenté de répondre à cette question, et il s’avère que le coût est inférieur à ce que vous pensez. En 2003, Shamir et Tromer estimaient 10 millions de dollars pour une machine spécialement conçue qui pourrait prendre en compte une clé 1024 bits par an. En 2013, Tromer a réduit ces chiffres à environ 1 million de dollars, en tenant compte des avancées matérielles. Et il pourrait être nettement inférieur. C’est de la monnaie de poche pour la NSA.

Dans des lignes similaires, Bernstein, Heninger et Lange ont examiné la faisabilité du craquage du RSA à l’aide de réseaux distribués de PC standard. Leurs résultats sont assez inquiétants: en principe, un cluster de la taille du botnet Conficker réel pourrait faire une violence sérieuse aux clés 1024 bits.

Compte tenu de tout cela, vous pourriez vous demander pourquoi cette possibilité est même dans la catégorie « chapeau en papier d’aluminium ». La réponse simple est: parce que personne ne l’a réellement fait. Cela signifie qu’il est au moins concevable que les estimations ci—dessus soient dramatiquement trop élevées, voire trop basses. De plus, les clés RSA-1024 sont rapidement éliminées. Le craquage de clés de bits 2048 nécessiterait des avancées mathématiques importantes, nous emmenant beaucoup plus profondément dans le chapeau en papier d’aluminium.**

Fissuration RC4. Sur le papier, TLS prend en charge une variété d’algorithmes de cryptage puissants. En pratique, environ la moitié de tout le trafic TLS est sécurisé avec l’ancien chiffrement RC4 grinçant. Et cela devrait vous inquiéter — car RC4 commence à montrer son âge. En fait, tel qu’utilisé dans TLS, il est déjà vulnérable aux attaques pratiques (limites). Il semble donc être un bon candidat pour une véritable avancée cryptanalytique de la part de la NSA.

Malheureusement, le problème avec cette théorie est que nous ne connaissons tout simplement aucune attaque qui permettrait à la NSA de pirater utilement RC4! Les techniques connues nécessitent qu’un attaquant collecte des milliers ou des millions de textes chiffrés qui sont (a) chiffrés avec des clés associées (comme dans WEP) ou (b) contiennent le même texte en clair. L’attaque la plus connue contre TLS prend cette dernière forme: elle oblige la victime à établir des milliards de sessions, et même dans ce cas, elle ne récupère que des éléments de texte en clair fixes tels que des cookies ou des mots de passe.

Le contre-argument est que la communauté de la recherche publique n’a pas beaucoup réfléchi au RC4 depuis une décennie – en partie parce que nous pensions que c’était tellement brisé que les gens avaient cessé de l’utiliser (oups!) Si nous avions concentré toute notre attention sur elle (ou mieux, l’attention de la NSA), qui sait ce que nous aurions aujourd’hui.

Si vous me disiez que la NSA avait une capacité cryptanalytique vraiment nouvelle, je serais d’accord avec Jake et pointerais du doigt RC4. Surtout parce que les alternatives sont beaucoup plus effrayantes.

Nouvelles attaques par canal latéral. Pour la plupart, les attaques de synchronisation à distance semblent avoir été éliminées par la mise en œuvre de contre-mesures telles que l’aveuglement RSA, qui confond le timing en multipliant un facteur d’aveuglement aléatoire dans chaque texte chiffré avant le déchiffrement. En théorie, cela devrait rendre les informations de synchronisation essentiellement sans valeur. En pratique, de nombreuses implémentations TLS implémentent des compromis dans le code aveuglant qui pourraient ressusciter ces attaques, comme la mise au carré d’un facteur aveuglant entre les opérations de déchiffrement, plutôt que d’en générer un nouveau à chaque fois. Il est peu probable qu’il y ait des attaques ici, mais qui sait.

Trucs loufoques. Peut-être que la NSA a quelque chose de vraiment incroyable dans sa manche. Le problème avec l’ouverture de cette boîte de Pandore est qu’il est vraiment difficile de la refermer. Jerry Solinas a-t-il vraiment préparé les courbes P du NIST pour supporter une nouvelle attaque étonnante (dont la NSA était au courant à la fin des années 1990, mais que nous n’avons pas encore découverte)? La NSA a-t-elle un superordinateur géant nommé TRANSLTR qui peut forcer n’importe quel cryptosystème? Y a-t-il un ordinateur quantique géant à l’annexe de l’amitié de l’IBB? Pour des réponses à ces questions, vous pouvez aussi bien secouer la boule magique 8, car je n’en ai aucune idée.

Conclusion

Nous ne savons pas et ne pouvons pas connaître la réponse à ces choses, et honnêtement, cela vous rendra fou si vous commencez à y penser. Tout ce que nous pouvons vraiment faire, c’est prendre la NSA / GCHQ au mot quand ils nous disent que ces capacités sont « extrêmement fragiles ». Cela devrait au moins nous donner de l’espoir.

La question est maintenant de savoir si nous pouvons deviner assez bien pour transformer cette fragilité d’un avertissement en promesse.
Remarques :

* Une défaillance du RNG du serveur peut entraîner certaines valeurs prévisibles telles que les ID ServerRandom et les ID de session. Un attaquant capable de prédire ces valeurs peut être en mesure d’exécuter des attaques actives contre le protocole, mais — dans la suite de chiffrement RSA, du moins — il n’admet pas de compromis passif.

** Même si les clés RSA 1024 bits sont éliminées, de nombreux serveurs utilisent toujours 1024 bits pour Diffie-Hellman (principalement pour des raisons d’efficacité). Les attaques sur ces clés sont similaires à celles utilisées contre RSA — cependant, la différence majeure est que de nouvelles clés « éphémères » Diffie-Hellman sont générées pour chaque nouvelle connexion. Briser de grandes quantités de trafic semble assez coûteux.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée.