Asegurar un chip ya no es una cuestión de verificación final o de una certificación que se adjunta al producto antes de lanzarlo, sino un proceso que se extiende desde el diseño hasta el despliegue y la supervisión. Esta es la principal conclusión de un debate cerrado organizado por Semiconductor Engineering durante la conferencia Design Automation Conference, en el que participaron expertos de Arteris, Cadence, Keysight EDA, Rambus, Siemens EDA, Synaptics y Synopsys. Este artículo se basa en fragmentos de ese debate, moderado por Ann Mutschler.
La superficie de ataque se amplía con la expansión de la inteligencia artificial, los chiplets, los sistemas definidos por software, las FPGAs y los sistemas conectados. Por tanto, el riesgo no se limita a un defecto físico en el circuito o a un ataque contra el propio chip; puede comenzar en la red, en el software integrado o en una capa programable, y después explotar una vulnerabilidad para acceder al sistema o interrumpirlo.
De la certificación al uso real
Yathiendra Vunnam, de Cadence, señaló que muchos clientes adoptan una defensa multicapa, utilizando mecanismos como IPsec y MACsec en distintas capas del modelo OSI para satisfacer las necesidades de rendimiento y computación. Sin embargo, también explicó que algunas empresas se centran en la certificación porque les ayuda a vender el producto y después reducen el conjunto de protecciones necesarias para lograr un diseño más pequeño, menos costoso y reutilizable.
El problema, según Scott Best, de Rambus, es que disponer de una tecnología de protección no demuestra que se haya aplicado correctamente. Un cliente puede solicitar protección contra ataques de canal lateral, ataques de inyección de fallos o tecnología PUF, y después tratar estos elementos como casillas completadas en una lista de requisitos, sin aclarar cómo se integran y utilizan dentro del sistema final. Lo mismo se aplica al cumplimiento de marcos como CRA e ISO 26262 o a la obtención de CSIP Level 3 de Keysight o de un competidor.
Esto no significa que las certificaciones o las normas carezcan de valor, sino que por sí solas no ofrecen pruebas suficientes de que el producto sea seguro en condiciones reales de funcionamiento. La brecha en la que se centraron los participantes es la diferencia entre que exista un mecanismo de seguridad sobre el papel y que pueda funcionar cuando se integra con el resto del hardware, el software y las redes.
La visibilidad comienza con la lista de componentes
Alexander Petr, de Keysight EDA, afirmó que los sistemas modernos se construyen en niveles superpuestos: un chip, después un encapsulado, una placa, un sistema y, finalmente, un ecosistema conectado que incluye centros de datos y redes extensas. A medida que más funciones pasan al software integrado, saber qué entra en el producto se convierte en una condición para hacer seguimiento de los riesgos.
Esto incluye crear una lista de software para los componentes de hardware, o lo que Petr describió como la importancia de una Software Bill of Materials for hardware, además del seguimiento de vulnerabilidades y la supervisión después del despliegue. La dificultad aumenta con el software de código abierto, ya que señaló los intentos de actores maliciosos de infiltrarse en comunidades de código abierto e inyectar puertas traseras. Además, descubrir una vulnerabilidad zero-day no basta; primero hay que saber si el sistema utiliza el componente afectado y después si la empresa puede corregirlo o crear una defensa adecuada.
La arquitectura de chiplets añade otro desafío. La posibilidad de ensamblar unidades de distintas fuentes puede reducir los costes, porque no necesariamente cada bloque necesita utilizar los nodos más avanzados, pero plantea una pregunta práctica: ¿cómo verifica el diseñador la seguridad de cada chiplet y cómo garantiza que la unidad menos segura no ponga en riesgo todo el sistema?
La regulación aumenta la conciencia, pero no garantiza el comportamiento
Los participantes coincidieron en que las regulaciones, entre ellas la Ley Europea de Resiliencia Cibernética CRA, han elevado el nivel de conciencia y han impulsado a algunas empresas a invertir en raíces de confianza y protección integrada. Chris Giles, de Siemens EDA, afirmó que la existencia de la ley no es suficiente, porque será necesario hacerla cumplir para convertir los requisitos en una inversión continua. Los participantes señalaron que la fecha relacionada con los semiconductores es el 11 de septiembre de 2026, aunque siguen existiendo dudas sobre qué se exigirá revelar y cómo se aplicará en la práctica.
Mohit Arora, de Synaptics, también señaló que las sanciones pueden alcanzar el 4 % de los ingresos anuales, mientras que Reed Hinkel, de Synopsys, consideró que este tipo de presión ha empezado a impulsar a empresas que se mostraban indecisas a colocar una raíz de confianza importante en el chip o a adoptar iniciativas del Open Compute Project como Caliptra. Sin embargo, el debate mostró que el efecto de las regulaciones sobre el comportamiento aún no se ha resuelto; Giles afirmó que la CRA está muy presente en las conversaciones, pero que no está seguro de que haya cambiado las prácticas, mientras que Petr señaló que no se habían impuesto multas hasta el momento del debate.
¿Qué cambia en la práctica?
La transformación necesaria no consiste únicamente en comprar herramientas o propiedad intelectual de seguridad adicional, sino en distribuir la responsabilidad entre los equipos de diseño, software, gestión de producto y operaciones. Cuanto mayor sea el valor del servicio que ofrece el producto, mayor será el coste del fallo de seguridad y de la responsabilidad asociada. Por ello, Hinkel consideró que las promesas de servicios de alto valor deben ir acompañadas de una capacidad real para cumplir los acuerdos de nivel de servicio y responder a las vulnerabilidades.
Los incentivos comerciales y militares también aparecen en el debate. Los productos que gozan de la confianza de los usuarios pueden justificar una mayor inversión en seguridad, mientras que las necesidades del Departamento de Defensa de Estados Unidos y de sus proveedores, entre ellos Boeing y Airbus, tal como se mencionó en el debate, impulsan parte de la inversión en este ámbito. Pero esto no elimina las limitaciones: la seguridad compite siempre con el coste y la fecha de lanzamiento, y la certificación puede seguir siendo más fácil de medir que la calidad del despliegue y la supervisión.
En cuanto a la criptografía poscuántica, Hinkel explicó que el desafío no se limita al hardware o al firmware, sino que también se extiende a los aceleradores de clave pública PKA, construidos históricamente sobre capas acumuladas difíciles de actualizar y ampliar. Según el debate, los productos necesitan admitir los nuevos algoritmos en un plazo de tres años, mientras que la retirada de los algoritmos antiguos se vincula a un horizonte de cinco años. Esto indica que la preparación para la criptografía poscuántica exige reorganizar la arquitectura, no simplemente añadir un algoritmo a un diseño existente.
La lectura más importante para el lector técnico es que la seguridad demostrable debe abarcar qué hay dentro del producto, cómo se ha integrado y cómo se supervisará después de la venta. La certificación sigue siendo un punto de verificación dentro de este proceso, no un sustituto. Los detalles de la aplicación de las regulaciones, los límites de la divulgación de vulnerabilidades y la capacidad de las empresas para corregir productos ya extendidos en el mercado siguen siendo preguntas abiertas que la fuente no resolvió.