Garantizando la confiabilidad en el diseño de procesadores: mejores prácticas para ICs seguros y fiables

Los circuitos integrados (CI) modernos proporcionan las capacidades computacionales y de control de sistema para procesar enormes cantidades de datos, tomar decisiones críticas de seguridad en tiempo real y proteger datos sensibles. Diseñar un circuito integrado de aplicación específica (ASIC) o un sistema en chip (SoC) de array de puertas programable en campo (FPGA) desde cero sería prohibitivamente costoso y lento. Muchas funciones críticas se implementan usando propiedades intelectuales (IP) de terceros. Los núcleos de procesador, por ejemplo, provienen de organizaciones especializadas y proporcionan una función flexible y programable por software a través de su arquitectura de conjunto de instrucciones (ISA), que define la interfaz entre hardware y software. Las arquitecturas de procesador de código abierto ofrecen una oportunidad para un escrutinio más profundo y una garantía de seguridad rigurosa en sistemas que ya enfrentan un entorno de amenazas fluido. Este artículo describe un enfoque para proporcionar garantía de seguridad de IP y SoCs basado en la ISA open‑source RISC‑V.

Inventada en la Universidad de California y gestionada por la Fundación RISC‑V sin ánimo de lucro, RISC‑V es la primera ISA open‑source en convertirse en una opción industrial genuinamente viable para una amplia gama de aplicaciones.

RISC‑V es una ISA open‑source inventada en la Universidad de California y gestionada por la Fundación RISC‑V, una organización sin ánimo de lucro con más de 300 miembros fundada en 2015. RISC‑V es la primera ISA open‑source en convertirse en una opción industrial genuinamente viable para una amplia gama de aplicaciones. El ecosistema de herramientas, software y experiencia es robusto y crece constantemente. Muchos individuos y organizaciones ya han donado IPs de hardware open‑source que implementan la ISA RISC‑V. El grupo OpenHW, por ejemplo, apunta a hacer realidad la largamente esperada perspectiva de hardware open‑source —particularmente, núcleos de procesador— para chips de alto volumen.

El auge de RISC‑V tiene muchas razones. Construida desde cero con extensibilidad personalizada en mente, RISC‑V permite un nuevo nivel de optimización de hardware para cargas de trabajo específicas. La ley de Moore se está desacelerando, y la personalización es crucial para mantener el nivel de mejoras de rendimiento que los avances tecnológicos en el proceso de fabricación de semiconductores ya no pueden proporcionar. Además, la arquitectura RISC‑V está libre de costes de licencia y regalías, permitiendo a más empresas desarrollar productos innovadores y asequibles. Mucho está ocurriendo en el campo de IoT y dispositivos wearables con capacidades de inteligencia artificial, por ejemplo.

Los integradores de SoC a menudo usan IPs de procesador RISC‑V open‑source o de terceros. Estos diseños y sus toolchains asociados pueden aumentarse con instrucciones personalizadas. Un entorno de verificación de alta calidad entregado con la IP y pruebas adicionales a nivel de sistema pueden proporcionar cierta confianza de que la IP no tiene bugs críticos. Desafortunadamente, para muchas aplicaciones, esto no es suficiente, y hay otros riesgos serios que considerar.

Vulnerabilidades y Troyanos

Tradicionalmente, las vulnerabilidades de seguridad en sistemas electrónicos se han asociado con problemas a nivel de sistema y software. Más recientemente, las IPs de hardware, prominentemente procesadores, también se han convertido en una preocupación central (ver Fig. 1). Las implementaciones de procesador usan microarquitecturas basadas en pipeline y a menudo incluyen características de optimización de rendimiento y energía. La complejidad aumenta el riesgo de pasar por alto no solo bugs funcionales sino también vulnerabilidades de seguridad. Los investigadores de seguridad que descubrieron los ataques Meltdown y Spectre a principios de 2018 demostraron que las características de optimización de rendimiento en procesadores pueden usarse de formas no intencionadas con fines nefarios. Desde entonces, se han descubierto muchas más vulnerabilidades en procesadores tanto de gama alta como baja. Canales laterales y ataques de ejecución transitoria pueden violar enclaves seguros y permitir que aplicaciones maliciosas filtren datos confidenciales o incluso tomen el control del sistema. Y a diferencia del software, los problemas de hardware no se pueden reparar fácilmente con actualizaciones over‑the‑air. Abordar un problema de hardware mediante software a menudo causa degradación severa de rendimiento.

La arquitectura RISC‑V tiene muchas características que soportan la implementación de sistemas embebidos seguros. La especificación de privilegios define cuatro modos de privilegio (máquina, supervisor, hipervisor y usuario), por ejemplo. Instrucciones personalizadas y extensiones ISA en proceso de ratificación, como la extensión Criptográfica, proporcionan capacidades de seguridad adicionales. Los diseñadores pueden implementar múltiples enclaves seguros para aislar aplicaciones y prevenir filtración de datos sensibles. Sin embargo, características microarquitectónicas a nivel RTL aún pueden resultar en vulnerabilidades de seguridad. Estos riesgos no pueden abordarse completamente a nivel ISA. Un nuevo enfoque en exploración es el uso de una ISA aumentada (aISA) para definir aspectos de la ejecución de instrucciones a nivel microarquitectónico y, por ejemplo, controlar el estado de buffers o registros no visibles a nivel ISA. Bugs funcionales RTL aún podrían comprometer todas estas características de seguridad.

Un riesgo menos probable pero con severidad mucho mayor es la presencia de lógica maliciosa o troyanos de hardware en el núcleo RISC‑V. Un troyano de hardware es una función lógica diseñada deliberadamente para ser sigilosa, que se activa en circunstancias muy raras conocidas solo por el atacante. Una secuencia específica de eventos de datos y control que no ocurriría mientras el sistema opera en sus casos de uso objetivo dispara la lógica del troyano, que a su vez entrega una carga dañina, filtrando un secreto o corrompiendo críticamente el comportamiento del sistema, por ejemplo. Las integraciones SoC usando núcleos RISC‑V open‑source o de terceros ya no pueden ignorar este riesgo.

Asegurar que un procesador haga lo que se supone que debe hacer es difícil, pero asegurar que no haga nada que no se supone que debe hacer es una tarea aún más desafiante que permanece largely unaddressed. Sistemas críticos de seguridad y sistemas donde la protección de la privacidad de datos es primordial, necesitan soluciones eficientes y de alta calidad que aborden el riesgo de vulnerabilidades de seguridad y troyanos.

Garantía de hardware inteligente

Asegurar la confianza y seguridad de IPs RISC‑V requiere soluciones técnicas innovadoras y eficientes que sean complementarias a los enfoques de corrección funcional, dirigidos principalmente a los casos de uso previstos de la IP (ver Fig. 2). Los proveedores de IP son responsables de aplicar procesos de verificación de confianza y seguridad de vanguardia, mientras que los integradores de IP deberían tener acceso a soluciones de garantía independientes que puedan desplegarse rápidamente y sin conocimiento profundo de los detalles de implementación de la IP.

Los métodos formales pueden analizar funciones de hardware exhaustivamente y entregar prueba de que la IP o SoC coincide precisamente con un comportamiento esperado a menudo capturado en aserciones SystemVerilog. La verificación formal de hardware usando model checkers comerciales ha disfrutado adopción amplia en la última década. Típicamente, proveedores de IP e integradores de SoC tienen expertos en verificación formal en sus filas, intentando reducir el riesgo de perder bugs funcionales al mínimo. Si bien ciertas tareas de verificación formal bien definidas pueden automatizarse mediante Apps, en general, se requiere esfuerzo significativo de ingeniería para capturar el comportamiento esperado de la IP en aserciones. Además, no hay garantía de que se hayan escrito suficientes aserciones. Funciones no documentadas o brechas no intencionadas en el conjunto de aserciones podrían llevar a funcionalidad IP no verificada.

La naturaleza open‑source de RISC‑V permite el desarrollo de soluciones de garantía independientes, preempaquetadas. La Solución de Verificación de Integridad RISC‑V de OneSpin, por ejemplo, puede aplicarse a una amplia gama de microarquitecturas. Incluye modelos de la ISA RISC‑V e ISA privilegiada que son extensibles y pueden acomodar instrucciones personalizadas. Un aspecto crucial de esta solución es que se basa en el proceso GapFreeVerification™ de OneSpin, que entrega una prueba rigurosa de que el conjunto de aserciones que modelan la ISA RISC‑V está completo y libre de brechas. Este aspecto es de suma importancia cuando la detección de troyanos de hardware o lógica no documentada es un objetivo crucial. La solución permite a integradores de SoC con experiencia limitada en RISC‑V y la implementación RTL bajo escrutinio ganar confianza en la calidad y confiabilidad de la IP. Los desarrolladores de IP pueden usarla para detectar debilidades de seguridad y bugs funcionales antes del lanzamiento.

¿Funciona?

El proceso de garantía de integridad RISC‑V descrito en la sección anterior se ha aplicado exitosamente a múltiples diseños RTL. Edaptive Computing, una empresa que integra soluciones innovadoras para optimizar, asegurar y automatizar sistemas de sistemas y procesos para una variedad de clientes del Departamento de Defensa de EE. UU. y sector comercial, ha aplicado el proceso al RocketCore, por ejemplo. El RocketCore es un núcleo RISC‑V open‑source, probado en silicio, de 64 bits con un sistema de memoria virtual de 39 bits. Tiene un pipeline de cinco etapas, single‑issue, in‑order con finalización out‑of‑order para instrucciones de latencia larga como división. Incluye características avanzadas de predicción de salto y replay de instrucción.

La Solución de Verificación de Integridad RISC‑V se aplicó al diseño con todas las instrucciones, niveles de privilegio, interrupciones y mecanismo de excepción, y se detectaron 8 issues (ver Fig. 3). Información adicional sobre 3 de ellos se reporta a continuación.

Caso esquina en división

Un bug de caso esquina profundo asociado con la finalización out‑of‑order de la instrucción de división. Este issue podría haber causado que un programa de software usando la operación de división calcule resultados incorrectos y lleve a comportamiento erróneo del sistema. El issue aparece solo bajo una combinación de circunstancias raras, y por eso esfuerzos de verificación previos lo habían pasado por alto.

Replay de instrucción ilegal

Este no es un bug de caso esquina. Replayar una instrucción ilegal puede desperdiciar ciclos de procesamiento, pero si esto ocurre solo en situaciones raras, el impacto en rendimiento es negligible. Sin embargo, hay otros aspectos a considerar. El replay de instrucción puede causar peticiones de memoria innecesarias. Estas peticiones pueden tener efectos laterales que podrían aprovecharse en ataques de canal lateral. Como resultado, este comportamiento necesita ser eliminado o claramente entendido y documentado.

Instrucción no documentada

Se detectó una instrucción no estándar, no documentada, llamada CEASE que detiene el núcleo. En efecto, el RocketCore RISC‑V podía hacer algo que no se suponía que debía hacer. Funciones ocultas no documentadas no son aceptables cuando la confianza y seguridad son una preocupación, incluso cuando se relacionan con casos de uso considerados no relevantes para la aplicación final.

El caso de estudio RocketCore se presenta en detalle en el paper GOMACTech 2019 titulado Complete Formal Verification of RISC‑V Processor IPs for Trojan‑Free Trusted ICs. Para obtener una copia, visite onespin.com/resources/white‑papers.

¿Qué sigue?

El proceso de garantía RISC‑V presentado en este artículo detecta escenarios que podrían afectar la seguridad, y descubre sistemáticamente funciones no documentadas y troyanos de hardware que impactan el comportamiento del procesador, sin importar qué tan raros y sigilosos puedan ser. Sin embargo, los canales laterales no se detectan sistemáticamente. La detección exhaustiva de todos los canales laterales potenciales requiere una solución dedicada con tecnología apropiada. Ya hay prototipos que abordan este desafío. Para más información, visite onespin.com/resources/technical‑articles y lea el artículo de EE Times Side‑Channel Attacks on Embedded Processors.

Los núcleos de procesador son IPs cruciales dentro de sistemas embebidos. Sin embargo, un SoC típico integra muchas otras IPs que también podrían contener troyanos de hardware. A diferencia de los núcleos RISC‑V, soluciones de garantía de confianza independientes podrían no estar disponibles. En este caso, sería valioso tener un proceso automatizado de evaluación de confiabilidad de bajo esfuerzo aplicable a cualquier IP. Un proceso que no incluya un modelo confiable de la IP no puede asegurar la ausencia de un troyano. Sin embargo, es posible identificar patrones de código inusuales y sospechosos y firmas de troyano conocidas, y debilidades que podrían explotarse en etapas posteriores de desarrollo con fines nefarios. Un paper sobre este tema titulado An Automated Pre‑Silicon IP Trustworthiness Assessment for Hardware Assurance, autorado por ingenieros de AEROSPACE Corporation y OneSpin, se presentará en la conferencia GOMACTech 2020.