Fuzzing para validar la seguridad de SoC. Innovación en verificación

Fuzzing es la verificación del software, lo que la aleatorización es la verificación del hardware. ¿Puede un enfoque de fuzzing mejorar las pruebas de seguridad del hardware? Paul Cunningham (GM, Verification at Cadence), Raúl Camposano (Silicon Catalyst, emprendedor, ex CTO de Synopsys) y yo continuamos nuestra serie sobre ideas de investigación. Como siempre, los comentarios son bienvenidos.

La innovación

La elección de este mes es HyperFuzzing para la validación de seguridad de SoC. Los autores presentaron este artículo en ICCAD 2020. Son del IIT Kanpur.

Este es un enfoque intrigante para el fuzzing, adaptado específicamente al diseño moderno de SoC. Se basa en hiperpropiedad comprobación de simulaciones dinámicas. Estas hiperpropiedades razonan sobre los comportamientos conjuntos de rastros, un enfoque muy adecuado para el control de seguridad. Los autores ofrecen como ejemplos verificaciones de flujo de información (los datos privilegiados no pueden filtrarse de A a B, por ejemplo) y verificaciones de no interferencia (las acciones adversas no deben interferir con el flujo de cálculos). Luego, la seguridad se verifica comparando paquetes de trazas de simulación con y sin manipulación.

La manipulación en este enfoque puede modelar diferentes tipos de vulnerabilidades a fuentes no confiables. Al aleatorizar las instrucciones del firmware, escriba las instrucciones de un componente en el NoC o se inviertan los bits en una memoria. Los autores también proponen varias métricas de cobertura novedosas. Estos están diseñados para guiar las iteraciones hacia la manipulación en los casos más influenciados por ejecuciones de manipulación anteriores.

Su caso de prueba es un SoC pequeño pero representativo (detalles en GitHub) ejecutando pruebas de firmware contra bloques criptográficos, comprobando la no interferencia y otras vulnerabilidades. También ejecutan un arranque seguro con comprobaciones de bloques de datos. Encontraron múltiples violaciones de seguridad en los bloques criptográficos, excepto donde el bloque incluye protección ECC.

Punto de vista de pablo

La verificación de seguridad es un tema tan importante, y hay mucho trabajo en curso aquí tanto en la academia como en la industria. Este documento reúne muy bien la cobertura basada en mutaciones aleatorias con "hiperpropiedades" sobre conjuntos de trazas de simulación para crear una solución innovadora que sea escalable y eficaz para demostrar fallas de seguridad.

Algunas propiedades de seguridad se pueden definir formalmente solo sobre un conjunto de trazas de simulación. Por ejemplo, "no interferencia" significa que un atacante no puede interferir con ciertos cálculos protegidos en un diseño. Para demostrar la interferencia, debe comparar dos rastros, idénticos en el estímulo de entrada, excepto por la presencia de algunas acciones del atacante en un rastro. Si algún cálculo protegido en el rastro atacado difiere de los del rastro dorado, entonces ha habido interferencia.

Los autores crean su propio lenguaje especial para las afirmaciones sobre múltiples rastros y lo utilizan para formular propiedades de seguridad para la no interferencia y la confidencialidad. Construyen un flujo personalizado para manipular simulaciones aleatoriamente y verificar sus propiedades de seguridad entre simulaciones manipuladas y no manipuladas. Su algoritmo de manipulación aleatoria también tiene una elegante heurística de aprendizaje basada en cobertura para guiarlo a encontrar fallas de seguridad de manera más eficiente.

La idea de afirmaciones sobre múltiples simulaciones es muy poderosa. Me pregunto si sería posible extender limpiamente SystemVerilog para admitir este tipo de afirmaciones. Esto podría abrir la puerta a algunas atractivas extensiones nativas de simulación comercial y herramientas formales. Otra posibilidad podría ser extender el nuevo Estándar de Estímulo Portátil (PSS) para incluir afirmaciones que abarquen múltiples pruebas generadas.

Este documento es una lectura fácil y agradable, aunque deseo más detalles sobre los resultados. Los autores afirman que su solución encuentra agujeros de seguridad en su caso de prueba de SoC de código abierto, pero no hay detalles sobre cuáles son estos agujeros o cómo su enfoque se compara con otros enfoques en la literatura que podrían aplicarse para encontrar los mismos agujeros.

La mirada de Raúl

Voy a ver esto primero desde un ángulo de madurez tecnológica. Me gusta la idea en general, un enfoque muy interesante para calificar por seguridad en un diseño. Dicho esto, cada diseño requiere que los diseñadores proporcionen pruebas de semillas, manipulaciones y especificaciones de seguridad en un lenguaje de afirmación novedoso. Para mí, esto limita el enfoque firmemente al dominio académico por ahora. Excelente para disertaciones y trabajos, aún no se acerca a algo que podría dar el salto a la aplicación comercial.

Me pondré mi sombrero de inversor para el segundo desafío. La seguridad es un tema importante, no hay duda. Pero fuera de algunos dominios que ya conocemos: aeroespacial, defensa, sistemas de pago y procesadores / servidores, por ejemplo. Todavía no es un problema existencial para la mayoría de fabricantes de equipos originales y fabricantes de componentes. Están dispuestos a marcar una casilla si se espera en general. Pero solo si el impacto en el costo o el tiempo de comercialización es pequeño. Porque sus clientes generalmente no pagarán más por la seguridad. Lo que hace que la seguridad de la mayoría de los mercados siga dependiendo de la IP llave en mano, como las raíces de confianza del hardware y las aplicaciones fáciles de usar. Las soluciones empaquetadas de una de estas formas se podrán invertir, de lo contrario no tanto.

Mi vista

Paul y Raúl cubrieron la mayor parte de lo que podría haber sugerido. Me gusta la idea de Paul de extender SVA, al menos para fomentar la experimentación con hiperpropiedades. Esto debe abrir una nueva clase de pruebas interesantes, lo que eventualmente conducirá a nuevos métodos de verificación agrupados.

Comparte esta publicación a través de: Fuente: https://semiwiki.com/eda/299391-fuzzing-to-validate-soc-security-innovation-in-verification/