¿Es realmente imposible saber qué está haciendo una CPU? [cerrado]

24

Los programadores de computadoras a menudo recitan el mantra de que las instrucciones x86 son totalmente opacas: Intel nos dice que están haciendo algo, pero no hay esperanza de que alguien pueda verificar lo que está sucediendo, por lo que si la NSA les dice que bloqueen sus RNG, entonces no podemos realmente hacer algo al respecto.

Bueno, creo que los programadores de computadoras no pueden hacer nada al respecto. Pero, ¿cómo lo atacaría un ingeniero eléctrico? ¿Existen técnicas que un ingeniero eléctrico podría usar para verificar que un circuito realmente realiza las operaciones descritas en su especificación y no otras operaciones?

cpu reverse-engineering usuario14717
fuente
55
Tendría que hacer algo como radiografiar el dado y analizar todo para ver qué está haciendo realmente. Básicamente, realice una ingeniería inversa del chip y tenga en cuenta la función de cada circuito. Totalmente poco práctico.
DKNguyen
77
Ningún circuito eléctrico funciona con una especificación exacta debido al ruido y la ligera posibilidad de que algún día haya una falla que sea "lo suficientemente grande".
Andy alias
55
Información divertida: Esto está vagamente relacionado con el demonio de Laplace .
Harry Svensson
66
Va a ser más fácil robar documentos internos de la base de datos de contenido de Intel de lo que sería hacer ingeniería inversa, incluso una CPU moderna y compleja de Intel.
bosque
14
@Harper su actitud no es constructiva, y su afirmación de que una puerta trasera no se puede ocultar en el hardware no es cierta.
pjc50

Respuestas:

14

El mejor artículo que he leído sobre el tema es "Troyanos de hardware de nivel dopante sigiloso" (Becker et al) de 2014.

Dado que el circuito modificado parece legítimo en todas las capas de cableado (incluido todo el metal y el polisilicio), nuestra familia de troyanos es resistente a la mayoría de las técnicas de detección, incluida la inspección óptica de grano fino y la verificación de "chips de oro". Demostramos la efectividad de nuestro enfoque. insertando troyanos en dos diseños, un postprocesamiento digital derivado del diseño RNG criptográficamente seguro de Intel utilizado en los procesadores Ivy Bridge y una implementación SBox resistente a canales laterales, y explorando su detectabilidad y sus efectos en la seguridad.

El documento describe cómo se realiza el cambio, cómo es extremadamente difícil de detectar al inspeccionar el silicio, las técnicas para ocultarlo de la prueba de producción y cómo se puede hacer para reducir la seguridad de un RNG criptográfico de hardware o para filtrar información clave a través de un canal lateral de riel de potencia de una implementación de AES.

Los canales laterales son un campo emergente de interés. Intel ha estado plagado de problemas relacionados con la ejecución especulativa que filtra información de la memoria que ni siquiera estaba siendo utilizada por el programa. ¿Podría haber sido un defecto de diseño deliberado? Es casi imposible saberlo.

pjc50
fuente
¿No requeriría un canal lateral algún tipo de transmisor para enviar la información a la NSA? De lo contrario, seguramente notaría a alguien midiendo la corriente del riel de alimentación en mi computadora portátil mientras estoy trabajando en ella.
Dmitry Grigoryev
24

¿Existen técnicas que un ingeniero eléctrico podría usar para verificar que un circuito realmente realiza las operaciones descritas en su especificación y no otras operaciones?

En teoría, sí, creo que esto es posible. Sin embargo, para una CPU compleja tomará mucho tiempo y dinero. Además, si no conoce y comprende completamente el diseño, no podrá juzgar si alguna actividad es "legítima" o no.

Una CPU es "solo" un circuito digital complejo que consta de muchas celdas lógicas.

Es posible realizar ingeniería inversa del chip y reconstruir el diseño observando las conexiones metálicas. Puede haber muchas de estas capas de conexión, como hasta 8 capas o más.

Necesitará expertos en el campo para reconocer las celdas lógicas y luego tal vez algún software pueda descubrir cómo están todos conectados para que pueda reconstruir la lista de redes.

Una vez que tenga la lista de redes, "conocerá" el diseño. ¡Eso no significa que ahora también sepa cómo funciona!

Podría ser que una determinada función active 2 secciones del diseño mientras cree que una debería ser suficiente, por lo que sospecha que está ocurriendo alguna actividad sospechosa. Sin embargo, el diseño hace algún truco inteligente que no conoce para acelerar las operaciones.

Sin conocer y comprender el diseño, cualquier conclusión que extraiga podría estar equivocada. Solo los ingenieros que diseñaron la CPU tienen toda la información de diseño y tienen la mejor oportunidad de ser capaces de descubrir o adivinar qué sucede realmente o qué debería ocurrir en una CPU.

Bimpelrekkie
fuente
77
Solo los ingenieros que diseñaron la CPU saben todo lo que sucede : soy un ingeniero que trabaja en esta industria y me permite evaluar esta afirmación como muy optimista :)
Eugene Sh.
18
No, los diseñadores de CPU no sabrían todo lo que sucede: el diseño a ese nivel depende de las herramientas de síntesis, y esas podrían inyectar un comportamiento más allá de eso en el diseño HDL. Para tomar un ejemplo no nefasto, muchas herramientas FPGA le permitirán compilar en un analizador lógico.
Chris Stratton
99
La ingeniería inversa de un chip con "miles de millones de transistores" presentaría un desafío. spectrum.ieee.org/semiconductors/processors/…
Pico de voltaje
44
@Wilson Debido a que los circuitos complejos (incluidas las CPU) contendrán muchos diseños patentados (y secretos, marca registrada / patentados incluso) que no se ponen a disposición del público en general porque las empresas que poseen esos diseños quieren beneficiarse (ganar dinero) de ellos. El 6502 es un diseño antiguo , ya no tiene ninguna información de diseño valiosa, así que sí, está completamente abierto y disponible para todos.
Bimpelrekkie
3
@Bimpelrekkie: Si están patentados, por definición no son secretos. Ese es el punto de una patente. Cambias un secreto por un monopolio temporal.
MSalters
9

Bueno, creo que los programadores de computadoras no pueden hacer nada al respecto. Pero, ¿cómo lo atacaría un ingeniero eléctrico?

No hay buenas maneras de encontrar puertas traseras, una forma de encontrar una puerta trasera de hardware sería probar combinaciones o instrucciones no documentadas. Aquí hay una buena charla de alguien que realmente hace esto y realiza auditorías en hardware x86 . Esto se puede hacer sin romper el chip. Un problema con Intel (no estoy seguro acerca de otros chips) es que en realidad tiene un procesador con Linux ejecutándose, por lo que también hay software ejecutándose en algunos procesadores, y supuestamente no tiene acceso a eso.

¿Existen técnicas que un ingeniero eléctrico podría usar para verificar que un circuito realmente realiza las operaciones descritas en su especificación y no otras operaciones?

Hay formas de probar el uso del hardware para probar la funcionalidad. Dado que x86 tiene una parte no documentada de su conjunto de instrucciones, sería inusual introducir puertas traseras en las instrucciones normales porque introduciría la posibilidad de errores (como si tuviera una puerta trasera en una instrucción add o mult), por lo que es el primer lugar para buscar estaría en las instrucciones indocumentadas.

Si necesita probar la funcionalidad de las instrucciones regulares, puede observar el tiempo que lleva ejecutar las instrucciones, observe la cantidad de energía que se necesita para ejecutar las instrucciones para ver si hay diferencias con respecto a lo que esperaría.

Pico de voltaje
fuente
3
No estaría de acuerdo, no es imposible que alguien haga esto, pero es poco probable. Supongamos que retrasó una instrucción regular como una instrucción de agregar, y si ejecutó una instrucción adicional, digamos que abrió una puerta trasera. Luego, un cliente desarrolla un programa que tiene exactamente esa combinación, lo investigan, encuentran la puerta de atrás y todos se enojan y lo demandan. Es mucho más seguro poner una puerta trasera en las instrucciones no documentadas (o en la computadora Linux integrada en la CPU)
Voltaje pico
44
IME ejecuta Minix que no es Linux y es mucho más pequeño y simple. Linux se inspiró en la existencia de Minix y originalmente usó su sistema de archivos y se anunció en su grupo de noticias, pero eran bastante diferentes en ese momento y lo son extremadamente ahora.
Chris Stratton
55
@ user14717: la posibilidad desagradable sería una secuencia de activación en un ejecutable nativo encarcelado, algo así como un cliente nativo. Pero no hay razón para que tenga que ser código y no datos .
Chris Stratton
55
@ laptop2d Los errores en los que las CPU no hacen lo que dice la documentación teórica del conjunto de instrucciones todo el tiempo ; nadie es demandado, por lo general: lea la sección de erratas en la actualización de documentos de Intel 7th gen Core i7 family doc, por ejemplo. El uso de una instrucción no documentada sonaría de inmediato la alarma de cualquier investigador de malware. El uso de una combinación inusual de ADD rítmicos con los MOV correctos entre registros es menos probable que active una alarma.
Marcus Müller
66
@ laptop2d Me sorprendió la declaración "Linux integrado en la CPU". Así que hice un poco de investigación, supongo que hablas sobre el motor Intel ME. Bueno, no se ejecuta en la CPU en sí, sino en el chipset del puente norte. Parece que ha habido mucha información errónea al respecto, consulte itsfoss.com/fact-intel-minix-case
tenue
6

La única forma sería eliminar el chip capa por capa y registrar cada transistor con un microscopio electrónico, y luego ingresarlo en algún tipo de programa de simulación y luego verlo funcionar.

Este es esencialmente el problema de la caja negra en el que intenta reconstruir las partes internas de las entradas y salidas de medición. Una vez que la complejidad de los elementos internos, o el número de E / S, va más allá de lo trivial, hay una explosión combinatoria donde el número de posibles estados internos se vuelve astronómico. Donde se arrojan números como Googol .

Dirk Bruere
fuente
2
... y es más fácil robar el diseño usando ingeniería social :)
Eugene Sh.
8
No. El error evidente aquí es que la simulación no sería suficiente. Incluso si le dieran un modelo de simulación preciso , aún no podría encontrar un comportamiento cuidadosamente oculto, porque no tiene idea de cómo activarlo .
Chris Stratton
44
@ChrisStratton No llamaría a ese error evidente . Es razonable suponer que el diseño se basó en hacer simplificaciones que son físicamente habituales, por ejemplo, que no se colocan dos trazas de metalización tan juntas que se acoplan inductivamente para cambiar el estado de una puerta MOSFET. Eso es solo un error si a) sus simplificaciones no coinciden con el modelo físico de lo que el diseñador usó ob) el diseñador oculta algo intencionalmente al romper intencionalmente los requisitos para estas simplificaciones de maneras no obvias.
Marcus Müller
77
@ ChrisStratton ah, lo siento, está bien, creo que ahora entiendo tu punto. Usted dice que incluso los modelos con reloj digital / de comportamiento de una CPU son lo suficientemente complejos como para ocultar casos en los que la comprensión / suposiciones del programador simplemente no se aplican. Es verdad. Uno podría haber documentado los efectos que conducen a SPECTER en detalles insoportables, y la mayoría de la gente nunca hubiera pensado en almacenar en caché para tener efectos secundarios relevantes para el flujo de datos o programas. ¡En efecto!
Marcus Müller
3
Gracias :) Su argumento trae de vuelta a la vista todo el tema de la verificación formal de la corrección de las ISA ("¿esta ISA realmente garantiza que una CPU compatible no otorga privilegios RING 0 al código no privilegiado?") Y de la verificación formal de HDL / RTL contra tales especificaciones ISA (me gusta especialmente este proyecto de verificación del núcleo de CPU RISC-V )
Marcus Müller
5

Probar que la CPU no está haciendo algo astuto es extraordinariamente difícil. El ejemplo clásico es una máquina de votación. Si tiene un solo elemento que toma una copia de su voto y luego se lo escapa a algún dictador, podría ser vida o muerte para usted en algunos lugares. Y demostrar que no hay un solo tipo de ese tipo entre los miles de millones es bastante difícil.

Puede pensar en aislar el chip físicamente, por lo que es práctico ver que no hay conexiones de cables inadecuadas. Y poniendo otro chip, o más de un chip en serie (de diferentes fuentes) en su conexión de red que garantiza que solo se conecta al lugar correcto. Luego enciéndalo después de que haya emitido su voto. Y esperando que no haya trozos no volátiles allí. O furtivas conexiones inalámbricas. ¿Pero confiarías en tu vida?

emrys57
fuente
5

La transmisión de cualquier información a la NSA requerirá acceso a la red, por lo que será bastante fácil detectar dicha puerta trasera ejecutando un sistema operativo con servicios de red deshabilitados y verificando el tráfico en las interfaces de red. Para un sistema operativo de código abierto, incluso es posible ejecutarlo con soporte de red completo y detectar conexiones falsas por su IP de destino, que no coincidirá con ninguna dirección a la que el sistema operativo pueda acceder legítimamente.

Una puerta trasera basada en RNG sin transmisión de datos tendrá una utilidad muy limitada. A menos que el CPU RNG sea la única fuente de entropía, las posibilidades de que dicha puerta trasera proporcione alguna ventaja al atacante sin ser obvia al mismo tiempo son prácticamente nulas . A menos que insista en que la tetera de Russel está ahí afuera a pesar de no tener una buena razón para existir, debería poder aplicar el mismo argumento a las puertas traseras RNG de hardware.

Dmitry Grigoryev
fuente
55
Entonces, ¿asume que el adversario tiene el tiempo, el dinero y la habilidad para crear y ocultar un troyano de hardware, pero lo primero que hace es telnet www.nsa.gov? Esto parece un punto de vista muy ingenuo.
Elliot Alderson
1
Si la NSA hubiera ocultado una vulnerabilidad, entonces sí estarían esperando que la gente usara rdrando rdseedcomo Intel sugirió: como la única fuente de entropía para una semilla PRNG. Linux (el kernel) decidió no hacer eso /dev/random, pero la corriente de glibc / libstdc ++ std::random_device sí se usa solo rdrandsi está disponible en tiempo de ejecución en lugar de abrirse /dev/random. Ingrese a la llamada estándar de la biblioteca con Godbolt
Peter Cordes
@ElliotAlderson ¿Cuál es tu punto de vista entonces? ¿Cómo puede alguien robar datos valiosos sin transmitirlos alguna vez?
Dmitry Grigoryev
@PeterCordes std::random_deviceno es un RNG criptográficamente fuerte. El estándar C ++ le permite implementarlo con un PRNG, devolviendo efectivamente la misma secuencia cada vez , por lo que es bastante obvio que nadie debería usarlo para el cifrado.
Dmitry Grigoryev
Ah, claro, olvidé que no hay garantía de que sea bueno, xD. Que es bueno en muchas implementaciones, pero MinGW es la excepción sobresaliente a la intención del diseño que se le da como números aleatorios de buena calidad como la plataforma es capaz de derrotar el propósito principal de la biblioteca. (Lo que como dices no es criptografía, sino sembrar PRNG para otros fines). ( ¿Por qué obtengo la misma secuencia para cada ejecución con std :: random_device con mingw gcc4.8.1? ). ¡Eso sería aceptable en una plataforma sin entropía (dispositivo embebido mínimo), pero no en Windows x86!
Peter Cordes