Est-il vraiment impossible de dire ce que fait un processeur? [fermé]

24

Les programmeurs informatiques récitent souvent le mantra selon lequel les instructions x86 sont totalement opaques: Intel nous dit qu'ils font quelque chose, mais il n'y a aucun espoir que quiconque puisse vérifier ce qui se passe, donc si la NSA leur dit de détourner leurs RNG, alors nous ne pouvons pas vraiment faire quoi que ce soit.

Eh bien, je crois que les programmeurs informatiques ne peuvent rien faire pour résoudre ce problème. Mais comment un ingénieur électricien l'attaquerait-il? Existe-t-il des techniques qu'un ingénieur électricien pourrait utiliser pour vérifier qu'un circuit effectue réellement les opérations décrites dans ses spécifications, et aucune autre opération?

cpu reverse-engineering user14717
la source
5
Il faudrait faire quelque chose comme xray the die et tout analyser pour voir ce qu'il fait réellement. Fondamentalement, inversez l'ingénierie de la puce et tenez compte de la fonction de chaque circuit. Totalement impraticable.
DKNguyen
7
Aucun circuit électrique ne fonctionne à une spécification exacte en raison du bruit et de la légère possibilité qu'un jour il y aura un problème qui est "assez grand".
Andy aka
5
Information amusante: Ceci est vaguement lié au démon de Laplace .
Harry Svensson
6
Il sera plus facile de voler des documents internes de la base de données de contenu d'Intel que de procéder au reverse engineering même d'un seul processeur Intel complexe et moderne.
forêt
14
@Harper, votre attitude n'est pas constructive et votre affirmation qu'une porte dérobée ne peut pas être cachée dans le matériel n'est pas vraie.
pjc50

Réponses:

14

Le meilleur article que j'ai lu sur le sujet est «Les chevaux de Troie matériels furtifs au niveau des dopants» (Becker et al) de 2014.

Étant donné que le circuit modifié semble légitime sur toutes les couches de câblage (y compris tous les métaux et le silicium polycristallin), notre famille de chevaux de Troie est résistante à la plupart des techniques de détection, y compris l'inspection optique à grain fin et la vérification des «puces dorées». Nous démontrons l'efficacité de notre approche en insérant des chevaux de Troie dans deux conceptions - un post-traitement numérique dérivé de la conception RNG cryptographiquement sécurisée d'Intel utilisée dans les processeurs Ivy Bridge et une implémentation SBox résistante aux canaux latéraux - et en explorant leur détectabilité et leurs effets sur la sécurité.

Le document décrit comment le changement est effectué, comment il est extrêmement difficile de détecter l'inspection du silicium, les techniques pour le cacher du test de production et comment il peut être fait pour réduire la sécurité d'un RNG crypto matériel ou pour divulguer des informations clés via un canal latéral de rail d'alimentation d'une implémentation AES.

Les canaux secondaires sont un domaine d'intérêt émergent. Intel a été en proie à des problèmes liés à l'exécution spéculative qui fuit des informations de la mémoire qui n'étaient même pas utilisées par le programme. Cela aurait-il pu être une faille délibérée de conception? C'est presque impossible à dire.

pjc50
la source
Un canal latéral n'aurait-il pas besoin d'une sorte d'émetteur pour envoyer les informations à la NSA? Sinon, je remarquerais sûrement quelqu'un mesurer le courant du rail d'alimentation sur mon ordinateur portable pendant que j'y travaille.
Dmitry Grigoryev
24

Existe-t-il des techniques qu'un ingénieur électricien pourrait utiliser pour vérifier qu'un circuit effectue réellement les opérations décrites dans ses spécifications, et aucune autre opération?

En théorie, oui, je pense que c'est possible. Cependant, pour un processeur complexe, cela prendra beaucoup de temps et d'argent. De plus, si vous ne connaissez pas et ne comprenez pas complètement la conception, vous ne pourrez pas juger si une activité est "légitime" ou non.

Un CPU est "juste" un circuit numérique complexe composé de nombreuses cellules logiques.

Il est possible de désosser la puce et de reconstruire la conception en observant les connexions métalliques. Il peut y avoir plusieurs de ces couches de connexion comme jusqu'à 8 couches ou plus.

Vous aurez besoin d'experts dans le domaine pour reconnaître les cellules logiques, puis peut-être que certains logiciels pourront comprendre comment ils sont tous connectés afin que vous puissiez reconstruire la netlist.

Une fois que vous avez la netlist, vous "connaissez" le design. Cela ne signifie pas que vous savez maintenant aussi comment cela fonctionne!

Il se peut qu'une certaine fonction active 2 sections de la conception alors que vous pensez qu'une seule devrait suffire pour que vous suspectiez alors une activité suspecte. Cependant, la conception fait une astuce astucieuse que vous ne connaissez pas pour accélérer les opérations.

Sans connaître et comprendre la conception, toute conclusion que vous tirez peut encore être erronée. Seuls les ingénieurs qui ont conçu le CPU disposent de toutes les informations de conception et ont les meilleures chances de comprendre ou de deviner ce qui se passe ou devrait se passer dans un CPU.

Bimpelrekkie
la source
77
Seuls les ingénieurs qui ont conçu le CPU savent tout ce qui se passe - il se trouve que je suis un ingénieur travaillant dans cette industrie et je me permets d'évaluer cette affirmation comme étant très optimiste :)
Eugene Sh.
18
Non, les concepteurs de CPU ne sauraient pas tout ce qui se passe - la conception à ce niveau dépend des outils de synthèse, et ceux-ci pourraient injecter un comportement au-delà de cela dans la conception HDL. Pour prendre un exemple non néfaste, de nombreux outils FPGA vous permettront de compiler dans un analyseur logique.
Chris Stratton
9
Le reverse engineering d'une puce avec "des milliards de transistors" représenterait un défi. Spectre.ieee.org/semiconductors/processors/…
Pic de tension
4
@Wilson Parce que les circuits complexes (y compris les processeurs) contiendront de nombreuses conceptions propriétaires (et même secrètes, brevetées / brevetées) qui ne sont pas mises à la disposition du grand public parce que les sociétés propriétaires de ces conceptions veulent en tirer profit (gagner de l'argent). Le 6502 est un ancien design , il ne contient plus d'informations de conception précieuses, alors oui, il est entièrement ouvert et accessible à tous.
Bimpelrekkie
3
@Bimpelrekkie: S'ils sont brevetés, ils ne sont par définition pas secrets. C'est le point d'un brevet. Vous échangez un secret contre un monopole temporaire.
MSalters
9

Eh bien, je crois que les programmeurs informatiques ne peuvent rien faire pour résoudre ce problème. Mais comment un ingénieur électricien l'attaquerait-il?

Il n'y a pas de bons moyens de trouver des portes dérobées, une façon de trouver une porte dérobée matérielle serait de tester des combinaisons ou des instructions non documentées. Voici une bonne conversation de quelqu'un qui fait cela et fait des audits sur le matériel x86 . Cela peut être fait sans craquer la puce. Un problème avec Intel (je ne suis pas sûr des autres puces) est qu'il a en fait un processeur sous Linux, donc il y a aussi des logiciels sur certains processeurs, et vous n'y avez pas accès soi-disant.

Existe-t-il des techniques qu'un ingénieur électricien pourrait utiliser pour vérifier qu'un circuit effectue réellement les opérations décrites dans ses spécifications, et aucune autre opération?

Il existe des moyens de tester l'utilisation du matériel lui-même pour tester la fonctionnalité. Étant donné que x86 a une partie non documentée de son jeu d'instructions, il serait inhabituel d'introduire des portes dérobées dans des instructions normales car cela introduirait la possibilité de bogues (comme si vous aviez une porte dérobée dans une instruction add ou mult), donc le premier endroit à regarder serait dans les instructions non documentées.

Si vous aviez besoin de tester la fonctionnalité d'instructions régulières, vous pourriez regarder le temps qu'il faut pour exécuter les instructions, regardez la quantité d'énergie qu'il faut pour exécuter les instructions pour voir s'il y a des différences par rapport à ce que vous attendez.

Pic de tension
la source
3
Je ne serais pas d'accord, ce n'est pas impossible que quelqu'un fasse cela, mais peu probable. permet de dire que vous avez fait du backdoor sur une instruction normale comme une instruction add, et si vous avez exécuté une instruction supplémentaire, disons qu'elle a ouvert une backdoor. Ensuite, un client développe un programme qui a exactement cette combinaison, il l'examine, trouve la porte dérobée et tout le monde devient fou et vous êtes poursuivi. Beaucoup plus sûr de mettre une porte dérobée dans les instructions non documentées (ou l'ordinateur Linux intégré dans les processeurs)
Voltage Spike
4
IME exécute Minix qui n'est pas Linux et est beaucoup plus petit et plus simple. Linux a été inspiré par l'existence de Minix et a utilisé à l'origine son système de fichiers et a été annoncé sur son groupe de discussion, mais ils étaient assez différents à l'époque et le sont aujourd'hui.
Chris Stratton
5
@ user14717 - la possibilité désagréable serait une séquence de déclenchement dans un exécutable natif emprisonné, quelque chose comme un client natif. Mais il n'y a aucune raison que ce soit du code et non des données .
Chris Stratton
5
@ laptop2d Bugs où les CPU ne font pas ce que la documentation théorique du jeu d'instructions dit se produisent tout le temps ; personne n'est poursuivi, généralement: lisez la section des errata dans la mise à jour du doc ​​de la famille Core i7 Intel 7e génération, par exemple. L'utilisation d'une instruction non documentée sonnerait immédiatement l'alarme de tout chercheur de logiciels malveillants. L'utilisation d'une combinaison inhabituelle d'ADD rythmiques avec les bons MOV inter-registres est moins susceptible de déclencher une alarme.
Marcus Müller
6
@ laptop2d J'ai été stupéfait par la déclaration "Linux intégré dans le CPU". J'ai donc fait un peu de recherche, je suppose que vous parlez du moteur Intel ME. Eh bien, il ne fonctionne pas sur le CPU lui-même, mais sur le chipset North Bridge. Il semble qu'il y ait eu beaucoup de désinformation à ce sujet, voir itsfoss.com/fact-intel-minix-case
dim
6

La seule façon serait de décaper la puce couche par couche et d'enregistrer chaque transistor avec un microscope électronique, puis de l'intégrer dans une sorte de programme de simulation, puis de le regarder fonctionner.

Il s'agit essentiellement du problème de la Black Box dans lequel vous essayez de reconstruire les internes à partir des mesures des entrées et des sorties. Une fois que la complexité des internes, ou nombre d'E / S, dépasse le trivial, il y a une explosion combinatoire où le nombre d'états internes possibles devient astronomique. Où des numéros comme Googol sont lancés.

Dirk Bruere
la source
2
... et il est plus facile de voler le design en utilisant l'ingénierie sociale :)
Eugene Sh.
8
Non. L'erreur flagrante ici est que la simulation ne serait pas suffisante. Même si l'on vous donnait un modèle de simulation précis , vous ne seriez toujours pas en mesure de trouver un comportement soigneusement caché, car vous ne savez pas comment le déclencher .
Chris Stratton
4
@ChrisStratton Je n'appellerais pas cette erreur flagrante . Il est raisonnable de supposer que la conception était basée sur des simplifications physiquement habituelles, par exemple que vous ne placez pas deux traces de métallisation si proches l'une de l'autre qu'elles se couplent suffisamment par induction pour changer l'état d'une porte MOSFET. Ce n'est qu'une erreur si a) vos simplifications ne correspondent pas au modèle physique de ce que le concepteur a utilisé ou b) le concepteur cache intentionnellement quelque chose en brisant intentionnellement les exigences de ces simplifications de manière non évidente.
Marcus Müller
7
@ChrisStratton ah, désolé, ok, je pense que maintenant je comprends votre point. Vous dites que même les modèles numériques / comportementaux cadencés d'un CPU sont suffisamment complexes pour cacher les cas où la compréhension / les hypothèses du programmeur ne s'appliquent tout simplement pas. C'est vrai. On aurait pu documenter les effets menant à SPECTRE dans des détails atroces, et la plupart des gens n'auraient jamais pensé à mettre en cache pour avoir des effets secondaires liés aux flux de données ou de programmes. Effectivement!
Marcus Müller
3
Merci :) Votre argument ramène tout le sujet de la vérification formelle de l'exactitude des ISA ("est-ce que cette ISA garantit réellement qu'un CPU conforme n'accorde pas les privilèges RING 0 au code non privilégié?")) Et de la vérification formelle des HDL / RTL par rapport à ces spécifications ISA (j'aime particulièrement ce projet de vérification RISC-V CPU Core .)
Marcus Müller
5

Il est extrêmement difficile de prouver que le processeur ne fait pas quelque chose de sournois. L'exemple classique est une machine à voter. S'il contient un seul morceau qui prend une copie de votre vote et le transmet plus tard à un dictateur, cela pourrait être la vie ou la mort pour vous à certains endroits. Et prouver qu'il n'y en a pas un seul parmi les milliards est plutôt difficile.

Vous pourriez penser à isoler la puce physiquement, il est donc pratique de voir qu'il n'y a pas de connexion incorrecte. Et mettre une autre puce, ou plus d'une puce en série (provenant de différentes sources) dans sa connexion réseau qui garantit qu'elle ne se connecte qu'au bon endroit. Ensuite, éteignez-le puis rallumez-le une fois qu'il a rendu votre vote. Et en espérant qu'il n'y ait pas de bits non volatiles là-dedans. Ou des connexions sans fil sournoises. Mais lui feriez-vous confiance?

emrys57
la source
5

La transmission de données à la NSA nécessitera un accès réseau, il sera donc assez facile de repérer une telle porte dérobée en exécutant un système d'exploitation avec les services réseau désactivés et en vérifiant les interfaces réseau pour le trafic. Pour un système d'exploitation open source, il est même possible de fonctionner avec une prise en charge complète du réseau et une connexion non autorisée par leur IP de destination qui ne correspondra à aucune adresse à laquelle le système d'exploitation pourrait légitimement accéder.

Une porte dérobée basée sur RNG sans transmission de données aura une utilité très limitée. À moins que le processeur RNG ne soit la seule source d'entropie, les chances qu'une telle porte dérobée fournisse un avantage à l'attaquant tout en n'étant pas évident en même temps sont pratiquement nulles . À moins que vous n'insistiez sur le fait que la théière de Russel est là malgré qu'il n'y ait pas de bonne raison d'exister, vous devriez pouvoir appliquer le même argument aux portes dérobées RNG matérielles.

Dmitry Grigoryev
la source
5
Vous supposez donc que l'adversaire a le temps, l'argent et les compétences nécessaires pour créer et cacher un cheval de Troie matériel, mais la première chose qu'ils font est telnet www.nsa.gov? Cela semble être un point de vue très naïf.
Elliot Alderson
1
Si la NSA avait caché une vulnérabilité, alors oui, ils espéreraient que les gens utilisent rdrandou rdseedcomme Intel l'a suggéré: comme la seule source d'entropie pour une graine PRNG. Linux (le noyau) a choisi de ne pas le faire pour /dev/random, mais glibc / libstdc ++ 's actuel std::random_device ne sert à rien de rdrandsi elle est disponible lors de l' exécution au lieu d'ouvrir /dev/random. Participez à un appel de bibliothèque standard avec Godbolt
Peter Cordes
@ElliotAlderson Quel est alors votre point de vue? Comment quelqu'un peut-il voler des données précieuses sans jamais les transmettre quelque part?
Dmitry Grigoryev
@PeterCordes std::random_devicen'est pas un RNG cryptographiquement fort. La norme C ++ vous permet de l'implémenter avec un PRNG, renvoyant efficacement la même séquence à chaque fois , il est donc évident que personne ne devrait l'utiliser pour le chiffrement.
Dmitry Grigoryev
Oh oui, j'ai oublié qu'il n'y a aucune garantie que ce soit bon, xD. Il est bon sur de nombreuses implémentations, mais MinGW est l'exception exceptionnelle à l'intention de conception qu'il vous donne des nombres aléatoires de bonne qualité comme le permet la plate-forme, ce qui va à l'encontre de l'objectif principal de la bibliothèque. (Ce qui, comme vous le dites, n'est pas de la cryptographie, mais l'ensemencement des PRNG à d'autres fins) ( Pourquoi est-ce que j'obtiens la même séquence pour chaque exécution avec std :: random_device avec mingw gcc4.8.1? ). Ce serait acceptable sur une plateforme sans entropie (appareil embarqué minimal), mais pas sur Windows x86!
Peter Cordes