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

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?

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.

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.

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.

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.

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?

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.