Hardware Trojan: un problema de seguridad difícil de ‘parchear’ – Parte 2/2
Aquí tienes la siguiente parte sobre Hardware Trojan, esta vez me centraré en información algo más práctica que en la primera parte. En ese otro artículo mostré una introducción para definir este fenómeno y también el calado que podría llegar a tener si no se le da la importancia que merece.
En cambio, en este otra parte podrás comprender la naturaleza de este tipo de modificaciones y cómo se pueden realizar, así como la parte del proceso de producción se insertan…
Si puedo, me gustaría crear otra serie de artículos sobre las vulnerabilidades de hardware, que no hay que confundirlas con esta otra práctica. En esa serie analizaré este otro problema de seguridad, los tipos de ataques, la forma de actuar de algunas vulnerabilidades conocidas, y más…
Cómo se crean los Hardware Trojan
Durante la fabricación, los circuitos integrados son susceptibles de intervenciones maliciosas en la fondry para alterar el diseño, como aplicando un dopante diferente para un inversor. Eso haría que el inversor siempre generase VDD. Si se tratase de un circuito para cifrado que genera números aleatorios (RNG), ese cambio podría comprometer el nivel de entropía de CI (véase este ejemplo en el RNG del Intel Ivy Bridge).
Por cierto, en la parte 1 comenté que estos cambios no solo se pueden realizar para crear funciones ocultas, también para que los sistemas fallen, como una especie de denegación de servicio física. Algunos investigadores han demostrado que se pueden alterar las concentraciones de dopantes para reducir la vida útil de un circuito mediante efectos de portadores calientes y NBTI.
Hace unos meses, unos investigadores encontraron instrucciones no documentadas en los microprocesadores de Intel. Estas instrucciones podían habilitar la modificación del microcódigo, lo que es un riesgo potencial.
Si te interesa el tema, puedes probar el programa sandsifter con el que poder localizar instrucciones erróneas o no documentadas de tu CPU x86. Más información aquí.
Los cambios también se pueden introducir durante la fase de diseño del CI, en el modelo RTL, o en la netlist en la post-síntesis. Esto es algo que preocupa especialmente a los integradores de soluciones IP.
Además, no es necesario la complicidad de toda una empresa. Por ejemplo, si un gobierno quisiera insertar este tipo de troyano de hardware, tan solo bastaría con introducir dentro de la compañía diseñadora a un miembro, algo que con su capacidad de influencia le resultaría fácil.
Ese único empleado podría realizar las modificaciones maliciosas en el código RTL, pudiendo permanecer ocultas a pruebas posteriores, optimizaciones de potencia, área y rendimiento. Es decir, pasarían a la fase de producción sin que nadie se percatase de ello.
Es habitual introducir ciertas puertas traseras o funciones ocultas durante el desarrollo del IP con fines de depuración. Por lo general, son eliminadas antes de la producción, por lo que resultarían inocuas. Pero si no se hace, podrían ser explotadas. Estos descuidos no son extraños. Por ejemplo, se han detectado puertas traseras en algunos productos como el FPGA Microsemi ProASIC3. Como se puede comprobar en el documento, los investigadores pudieron extraer claves y códigos de acceso que podrían usarse para realizar ingeniería inversa del IP e incluso reprogramar el FPGA.
Analizar de forma minuciosa y detallada de cada IP puede no ser una opción si la licencia no lo permite. E incluso si lo permitiese, los recursos necesarios podrían tener un coste prohibitivo, más aún en los complejos SoCs que se emplean actualmente, o en ciertos ASICs avanzados, como una CPU, GPU, etc.
Algunos troyanos de hardware se pueden implementar en menos de 200 puertas lógicas. Esto resulta relativamente reducido cuando se compara con el resto del circuito original, que tiene cientos de miles o millones en algunos casos. Por tanto, podría pasar desapercibidas fácilmente, y no suponer un incremento del área considerable (más aún en procesos de fabricación con un nodo más actual).
También veo un serio problema en las técnicas empleadas actualmente, ya que existen muchas herramientas de software que automatizan ciertas partes del diseño, además del uso de bibliotecas de celdas estándar para el diseño de los circuitos. Esto hace que se necesite de menor implicación humana, lo que hace más difícil la detección de este tipo de modificaciones. Ya ni siquiera se suelen hacer manualmente diseños para el critical path…
Las pruebas habituales a las que se someten podrían, en teoría, detectar algunas funciones no documentadas. Pero en la práctica, este tipo de pruebas parten de la idea de que los circuitos analizados se comporten como se espera, por lo que podrían pasar por alto este tipo de agujeros de seguridad.
Además de los problemas para su detección, se puede deducir que, cuando existe una cadena desagregada en la que intervienen varias empresas (diseñadores de IP, licenciatarios que usan esos diseños IP, y fábricas), cada una en países diferentes, introducir un Hardware Trojan es relativamente fácil en algún eslabón de la cadena.
Como se aprecia en la imagen, solo la etapa donde se definen las especificaciones y la arquitectura, así como las etapas finales post-empaquetado, son las únicas seguras en las que no se puede introducir un troyano de hardware. El resto, en amarillo o rojo, son susceptibles de cambios maliciosos.
El riesgo aumenta especialmente en las etapas más tardías, por ello que se muestren en rojo en ese diagrama (modificación de la máscara para la fabricación de un circuito diferente al layout original), aunque también implica mayor riesgo, ya que podría terminar con un producto disfuncional, consumo excesivo o diafonía (crosstalk).
Por otro lado, mientras más avanza la cadena de diseño y fabricación, más caro y limitados serán los cambios. Por ejemplo, durante la etapa de creación de máscaras para la fabricación de un circuito, las alteraciones pueden ser menos importantes, como modificaciones en el doping, en el tamaño de las intercionexiones para producir fallos de fiabilidad, etc. Además, una sola máscara puede costar más de 80.000€, y es posible que una modificación implique alterar varias de estas máscaras, por lo que cambios tardíos no resultan baratos… Sin embargo, dado el impacto que pueda tener el ataque podrían merecer la pena.
Más información:
- ECE Florida – Documento sobre Hardware Trojan
- IEEE XPlore – Detección de troyanos en chips de cifrado para redes wireless fabricados por TSMC
- ResearchGate – Estudio sobre la amenaza de Hardware Trojan y Defensa
¿Existen contramedidas realmente buenas?
Aunque algunas vulnerabilidades ocurren de forma natural y no son intencionadas, y dependen en parte de las limitaciones de la simulación y emulación del hardware durante su fase de desarrollo. Estas limitaciones son principalmente de tiempo y de capacidad computacional. No es posible probar todas las posibles combinaciones y secuencias de vectores de entrada para detectarlas a tiempo.
En cambio, un Hardware Trojan es intencionado, pero igualmente puede resultar muy complejo de encontrar, o directamente imposible, como ya cité en la primera parte del artículo. Por tanto, no existe garantía de que se puedan detectar, mucho menos por las métricas de verificación tradicionales, convirtiéndose en un problema muy serio, como cité en la parte uno.
La industria de los semiconductores se enfrenta a un gran desafío. Ya está tratando de desarrollar algunas soluciones interesantes para identificar ciertos problemas de seguridad de manera sistemática y eficiente. Algunas de ellas podrían tener aplicación también en el campo de los troyanos de hardware, especialmente en los diseños IP.
OneSpin Solutions es una de las empresas de vanguardia para desarrollar soluciones para medir y garantizar la confiabilidad de hardware.
Todas las soluciones aportadas, desde que en 2000 EE.UU. intentará impulsar las inversiones para paliar estos problemas, han sido inútiles para poder frenar este problema. La mejor solución es confiar fielmente en el diseñador y el fabricante del hardware. De ahí que sea tan importante que Europa pueda tener capacidad de desarrollar y producir su propio hardware. No hay mucho más que hacer.
Quien controle las foundries tendrá media batalla ganada. La otra media se gana desde las oficinas de diseño…
Además, arquitecturas abiertas como RISC-V, así como hardware abierto (frente a los núcleos IP), también podrían ayudar a facilitar las cosas. Aunque no serían garantía de éxito, al igual que el código abierto tampoco lo ha sido a nivel de software… Siempre será susceptible de tener funciones ocultas, aunque serán más evidentes, y se permitirá que se puedan solucionar por parte de terceros, sin necesidad de intervención de una corporación.
Otras propuestas que también están cobrando importancia son las de combinar la detección y la reparación (BlueChip), como una investigación de Matthew Hicks y sus compañeros de la Universidad de Illinois y la de Pensilvania. Para ello, se emplean comprobaciones en tiempo de diseño para evitar ataques durante elt iempo de ejecución. Cualquier lógica que no haya pasado por las pruebas de verificación del diseñador original, serán etiquetadas y eliminadas, siendo sustituidas por un manejador de excepciones.
Otro enfoque interesante fue desarrollado por Adam Waksman y Simha Sethumadhavan de la Universidad de Columbia. En él se asumía que no se puede confiar en IPs de terceros, por lo que se debían codificar sus entradas para dificultar que los troyanos de hardware enterrados en el silicio obtengan información necesaria para desarrollar su función. En cambio, esta técnica no funcionaría para disparadores de troyano analógicos, donde se emplean sensores PVT del chip para que entre en marcha el estado malicioso al usarse un voltaje alto combinado con una baja temperatura.
