top of page

La victoria de University of Idaho en seguridad de chips coloca a la IA en ambos lados de la lucha

hace 1 hora
14 min de lectura

Investigadores de seguridad de chips de University of Idaho obtuvieron el primer lugar en una competencia de 2026 en la que la IA generativa actuó como defensora y atacante. El estudiante de grado Lloyd Alcorn y el profesor asistente Zain Ul Abideen desarrollaron un flujo de trabajo que ocultaba información sensible del diseño de chips mientras evaluaba qué podía reconstruir un adversario asistido por IA.

Esa combinación crea la verdadera tensión. La IA puede ayudar a los ingenieros a proteger la propiedad intelectual dentro de un diseño, pero la misma clase de tecnología puede ayudar a un atacante a interpretar los archivos protegidos. Por tanto, una defensa no puede tener éxito simplemente haciendo que un circuito sea difícil de leer para una persona.

El proyecto ganó el GenAI-Guided Hardware IP Redaction and Red-Teaming Challenge en la 63.ª Design Automation Conference, conocida como DAC. El resultado no establece un estándar de seguridad listo para producción. Sí muestra cómo la seguridad del diseño de chips con IA se está convirtiendo en un problema de medición adversarial, en lugar de un acto puntual de ocultar información.

University of Idaho triunfa en seguridad de chips en DAC

El proyecto ganador trató el diseño de chips protegido como algo que debe seguir siendo funcional mientras resiste activamente la reconstrucción.

Alcorn, estudiante de último año de ingeniería eléctrica, trabajó con Abideen durante una competencia remota que se desarrolló de junio a julio de 2026. Los premios se entregaron durante DAC, una importante conferencia sobre diseño de chips y automatización del diseño electrónico.

University of Idaho indicó que la conferencia reúne a más de 5.000 investigadores, ingenieros, profesionales de la industria y estudiantes. Alcorn compitió junto a participantes tanto del ámbito académico como de la industria, pese a participar como estudiante de grado.

Su tarea involucraba IP de hardware: la lógica reutilizable, las arquitecturas, las constantes y las estructuras de control que aportan a un chip parte de su comportamiento distintivo. Esta propiedad suele aparecer en código de nivel de transferencia entre registros, o RTL, que describe cómo la lógica digital procesa y transfiere datos.

Alcorn y Abideen crearon un sistema de seguridad que ofuscaba información crítica sobre la funcionalidad y la propiedad intelectual de un chip. La ofuscación cambia la apariencia de un diseño ante un observador, preservando al mismo tiempo su comportamiento previsto.

Ese segundo requisito es importante. Un esquema de protección que interfiere con la simulación, la integración, la temporización o el rendimiento computacional tiene poco valor práctico. El equipo debía ocultar información valiosa sin sacrificar el funcionamiento del diseño.

Según el relato de la universidad sobre el proyecto ganador, Alcorn adaptó y probó repetidamente el flujo de trabajo de protección. Verificó que los diseños protegidos siguieran funcionando correctamente y midió los efectos sobre el consumo energético y la temporización.

Después realizó una evaluación adversarial asistida por IA. Esa evaluación examinó qué información podría seguir infiriendo un atacante a partir del diseño modificado, en vez de asumir que el código transformado era automáticamente seguro.

La competencia formalizó ese conflicto mediante equipos azules y rojos. Los equipos azules ocultaban detalles sensibles, mientras que los equipos rojos utilizaban IA generativa para intentar la reconstrucción, la ingeniería inversa y la auditoría.

Los organizadores describieron varios objetivos de protección. Estos incluían nombres de módulos, jerarquía de circuitos, comportamiento de máquinas de estados finitos, constantes propietarias, estructuras criptográficas y lógica de control sensible. Un equipo rojo podía entonces usar IA para inferir las funciones o relaciones originales.

Por eso el premio es más relevante que un galardón convencional de diseño estudiantil. El equipo no se limitó a pedir a un sistema de IA que generara un circuito. Trabajó en la frontera más difícil entre utilidad y secreto, y luego expuso la defensa a un atacante inteligente.

Por qué la redacción de IP de hardware se está volviendo más difícil

La redacción de IP de hardware ahora debe resistir máquinas capaces de razonar sobre código, estructura, patrones de nomenclatura y comportamiento de circuitos.

La redacción tradicional suele basarse en eliminar comentarios descriptivos, renombrar señales u ocultar bloques de diseño seleccionados. Esas medidas pueden dificultar una inspección casual, pero no necesariamente eliminan las relaciones integradas en un circuito funcional.

Un módulo con nombres anónimos sigue teniendo entradas, salidas, comportamiento temporal y conexiones. Una máquina de estados sigue transitando por patrones. Un componente criptográfico puede conservar constantes o flujos de datos reconocibles después de que desaparezcan sus etiquetas.

La IA generativa cambia la economía de examinar esas pistas. Puede resumir RTL desconocido, proponer funciones probables de los módulos, comparar estructuras repetidas y generar hipótesis sobre lógica ausente. Un atacante sigue necesitando conocimientos técnicos, pero la IA puede reducir el coste de explorar muchas posibilidades.

La misma capacidad ayuda a los defensores. Un ingeniero de seguridad puede utilizar un flujo de trabajo asistido por IA para identificar nombres reveladores, localizar conos lógicos sensibles, proponer transformaciones y revisar si esos cambios preservan el comportamiento previsto.

Un cono lógico es el conjunto de elementos de circuito que influye en una salida concreta. Si una salida crítica para la seguridad puede rastrearse hasta puertas o constantes reconocibles, ocultar únicamente las etiquetas puede ofrecer una protección débil.

El enfoque del equipo de University of Idaho refleja este doble uso. La IA respaldó el flujo de trabajo defensivo y luego ayudó a examinar el resultado desde una perspectiva adversarial. La herramienta no era intrínsecamente protectora ni intrínsecamente hostil.

Esta dinámica ya aparece en la agenda de investigación de la automatización del diseño electrónico. La agenda de investigación sobre seguridad de DAC para 2026 incluye explícitamente ataques y defensas de hardware basados en IA, ingeniería inversa, ofuscación de hardware y automatización del diseño que preserve la seguridad.

La conferencia también solicitó trabajos sobre modelos fundacionales para EDA, verificación agéntica, automatización del diseño físico y puntos de referencia para evaluar sistemas de IA. EDA se refiere al software utilizado para diseñar, simular, verificar y preparar sistemas electrónicos para su fabricación.

Estos avances hacen que la seguridad del diseño de chips con IA sea un objetivo móvil. Una transformación que derrota a un modelo o estrategia de prompts podría filtrar información a un modelo más potente, a un agente especializado o a un flujo de trabajo que combine IA con análisis formal.

La amenaza también va más allá del robo de código fuente. Un diseño reconstruido podría revelar algoritmos propietarios, comprobaciones de seguridad, estructuras criptográficas o decisiones de implementación. Esa información puede facilitar la falsificación, la clonación, el descubrimiento de vulnerabilidades o modificaciones maliciosas.

NIST describe la cadena de suministro de semiconductores como una red que abarca propiedad intelectual, diseño, fabricación, pruebas, empaquetado y distribución. Su programa de seguridad de hardware considera la piratería de IP, la ingeniería inversa y los troyanos de hardware como cuestiones relacionadas con el diseño orientado a la confianza.

Un troyano de hardware es lógica maliciosa añadida a un circuito para alterar su comportamiento, filtrar información o crear acceso oculto. A diferencia de una vulnerabilidad de software común, puede pasar a formar parte del dispositivo físico.

La redacción por sí sola no puede detener todos esos riesgos. Sin embargo, la competencia aborda una etapa temprana importante: limitar lo que revelan los artefactos de diseño cuando deben circular entre equipos, herramientas, proveedores o instalaciones.

Este requisito es difícil porque la producción de semiconductores está distribuida. Un diseño puede atravesar múltiples fronteras organizativas y técnicas antes de que un componente terminado llegue a un producto.

Cada frontera crea un conflicto. Los socios necesitan suficiente información para realizar simulación, verificación, integración, fabricación o pruebas. El propietario de la IP quiere revelar no más de lo que esas tareas requieren.

La redacción de IP de hardware intenta gestionar ese conflicto. La IA generativa acelera a ambos lados, por lo que la protección ahora necesita pruebas adversariales repetibles, en lugar de confianza basada en la oscuridad.

El verdadero concurso fue entre utilidad y secreto

El problema decisivo no es si un diseño puede ocultarse, sino si puede seguir siendo útil después de eliminar sus rasgos más reveladores.

Un defensor podría, en teoría, hacer imposible la reconstrucción reteniendo el diseño completo. Ese enfoque también impide que colaboradores legítimos lo simulen, prueben o integren.

La protección práctica debe preservar un nivel acordado de utilidad. Un artefacto redactado podría necesitar compilarse, superar pruebas funcionales, exponer interfaces definidas y cumplir restricciones de temporización. Cada capacidad que se conserva también puede revelar información adicional.

Esto crea una disyuntiva similar a la anonimización de datos. Eliminar identificadores evidentes no garantiza la privacidad cuando las relaciones entre los campos restantes pueden revelar la información ausente.

La estructura del circuito puede ser igualmente informativa. Las entradas, las salidas, las operaciones repetidas, los patrones de búsqueda y las transiciones de estado pueden identificar un componente incluso cuando sus nombres y comentarios originales han desaparecido.

Un método de ofuscación puede añadir transformaciones o comportamiento codificado para hacer que el diseño sea más difícil de interpretar. Sin embargo, esos cambios pueden aumentar el consumo energético, alargar rutas críticas de temporización, incrementar el área o complicar la verificación.

El equipo de University of Idaho midió el consumo y la temporización porque la seguridad no puede evaluarse de forma aislada. Una defensa que impone una penalización de implementación inaceptable tendrá dificultades para superar una revisión de diseño comercial.

DARPA identificó el mismo obstáculo subyacente en su programa de automatización de silicio seguro. La agencia señaló que la seguridad a nivel de chip suele enfrentar barreras económicas y compromisos técnicos, mientras que los cambios tardíos de diseño son excepcionalmente difíciles.

Su respuesta fue un flujo de diseño automatizado capaz de evaluar alternativas arquitectónicas frente a objetivos de seguridad e implementación. Este planteamiento coincide estrechamente con el problema expuesto por el desafío de DAC, aunque los programas son independientes.

La automatización importa porque el diseño de chips ya implica un enorme espacio de búsqueda. Los ingenieros equilibran funcionalidad, rendimiento, consumo, área, fiabilidad, esfuerzo de verificación, restricciones de fabricación y calendarios de entrega.

La seguridad añade otro objetivo, pero no puede simplemente imponerse sobre todos los demás requisitos. Un diseño protegido todavía debe convertirse en un producto funcional.

La IA puede ayudar a explorar transformaciones candidatas con mayor rapidez. También puede ayudar a un adversario a buscar patrones que sobrevivieron a esas transformaciones. El concurso resultante es iterativo, no estático.

Un equipo azul modifica el diseño. Un equipo rojo busca significado conservado. El equipo azul ajusta entonces la transformación, vuelve a verificar la funcionalidad y mide cualquier nuevo coste.

Ese ciclo se asemeja a las pruebas modernas de seguridad de software, en las que los defensores analizan continuamente el código y los atacantes buscan continuamente formas de eludir las protecciones. El hardware introduce una restricción más dura porque los errores pueden persistir después de la fabricación.

A menudo se puede desplegar un parche de software después del lanzamiento. Un diseño de chip defectuoso puede requerir una sustitución costosa, una nueva ejecución de fabricación o controles compensatorios en otras partes del sistema.

Esto hace que la evaluación pre-silicio sea especialmente valiosa. Pre-silicio se refiere al trabajo realizado antes de que un diseño se convierta en un chip fabricado. Las pruebas asistidas por IA pueden examinar los artefactos de diseño mientras los ingenieros aún pueden revisarlos.

Por tanto, el resultado de Idaho respalda un mecanismo, no una respuesta universal. Utilizar IA para asistir en la protección, preservar la utilidad del diseño, medir los costes de implementación y atacar el resultado antes de confiar en él.

Ese mecanismo puede mejorar la disciplina de ingeniería incluso cuando el modelo produce sugerencias imperfectas. Obliga al equipo a definir qué debe seguir siendo utilizable, qué debe permanecer secreto y qué evidencias constituyen una defensa exitosa.

La seguridad del diseño de chips con IA necesita mejores evidencias

Un primer puesto demuestra éxito competitivo, pero todavía no prueba que el flujo de trabajo pueda proteger la propiedad intelectual comercial de semiconductores.

El informe público de la University of Idaho no ofrece un documento técnico detallado, una suite de benchmarks, un inventario de modelos, un desglose de puntuaciones ni un modelo de amenazas completo. Tampoco publica los diseños protegidos ni los intentos de reconstrucción exitosos.

Estas omisiones son comprensibles en una breve noticia universitaria. Aun así, limitan las conclusiones que los ingenieros externos pueden extraer del resultado.

Una evaluación significativa debe definir el acceso del atacante. ¿El equipo rojo recibió RTL, una netlist sintetizada, resultados de simulación, documentación de interfaces o solo artefactos seleccionados? Los distintos niveles de acceso generan riesgos de reconstrucción muy diferentes.

La configuración del modelo también importa. Un modelo de lenguaje generalista, un modelo centrado en código y un agente EDA conectado a herramientas de análisis pueden producir resultados distintos.

Los prompts y la iteración también pueden afectar el rendimiento. Un atacante con una sola consulta no representa a otro que puede ejecutar numerosos agentes, compilar diseños candidatos, examinar fallos y refinar hipótesis.

Las métricas de evaluación siguen siendo otro problema sin resolver. Una defensa podría impedir la reconstrucción exacta del código fuente y, aun así, filtrar el propósito del componente, el algoritmo, las constantes o el perímetro de seguridad.

A la inversa, un sistema de IA podría generar explicaciones plausibles pero técnicamente incorrectas. Una reconstrucción aparente no equivale a una recuperación verificada.

Por tanto, un benchmark sólido necesita varias capas de medición. Debe evaluar equivalencia funcional, similitud estructural, inferencia semántica, recuperación de secretos y el coste impuesto al diseño protegido.

También debe comprobar si la defensa se transfiere entre familias de circuitos no vistas. Un método ajustado a un benchmark puede rendir bien en competición y fallar ante arquitecturas diferentes.

NIST ha destacado esta brecha de medición. Su programa de hardware reclama conjuntos de datos de referencia y métricas que puedan respaldar las pruebas, la atestación, la certificación y la verificación de componentes semiconductores.

El informe del taller sobre estándares de 2026 de la agencia también identificó la verificación y validación escalables como una prioridad. Entre los enfoques recomendados se incluyeron el análisis asistido por IA, los métodos formales, el fuzzing, las pruebas estandarizadas y la evaluación de resiliencia.

Esa combinación es importante. La IA no debería convertirse en el único juez de si la IA protegió con éxito un diseño.

Los métodos formales emplean razonamiento matemático para verificar propiedades de un sistema. La simulación ejecuta escenarios seleccionados, mientras que la verificación formal puede examinar clases más amplias de comportamiento posible bajo supuestos definidos.

El flujo de trabajo más creíble para la seguridad del diseño de chips con IA combinaría exploración asistida por modelos con comprobaciones deterministas. El modelo puede proponer transformaciones o ataques, mientras las herramientas convencionales verifican las propiedades de función, temporización, potencia y seguridad.

La reproducibilidad es igual de importante. Los investigadores necesitan registros de las versiones de los modelos, prompts, llamadas a herramientas, artefactos intermedios y resultados de validación. De lo contrario, un resultado ganador puede ser difícil de comparar o repetir.

Los servicios de IA también plantean sus propias cuestiones de confidencialidad. Cargar RTL propietario en un modelo externo podría exponer precisamente la información que un flujo de trabajo de protección pretende resguardar.

Una implementación en producción necesitaría controles claros sobre retención de datos, acceso a modelos, registros, aislamiento y propiedad de los artefactos generados. Los modelos locales o controlados por la organización pueden reducir parte de la exposición, pero no eliminan el riesgo técnico.

También existe un problema de contaminación de benchmarks. Si ejemplos de circuitos públicos aparecen en los datos de entrenamiento del modelo, un sistema podría recordar patrones conocidos en lugar de inferirlos a partir de un diseño realmente protegido.

Los investigadores deben distinguir la memorización de la reconstrucción. Los circuitos de evaluación privados, la divulgación controlada y los benchmarks posteriores al entrenamiento pueden ayudar, aunque dificultan la replicación abierta.

Por tanto, el premio demuestra que el enfoque merece un estudio más profundo. No demuestra que la IA generativa haya resuelto la protección de propiedad intelectual de hardware.

Los fabricantes de chips afrontan un nuevo ciclo de ataque y defensa

La presión recae sobre toda organización que comparta artefactos de diseño más allá de un equipo interno estrictamente controlado.

Ese grupo incluye empresas de chips, proveedores de IP reutilizable, fundiciones, proveedores de EDA en la nube, contratistas de verificación, especialistas en empaquetado y socios de investigación. También incluye a clientes que integran núcleos bajo licencia en sistemas más grandes.

La fuente de presión no es un único competidor. Es la creciente capacidad de los atacantes para combinar el razonamiento de IA con herramientas consolidadas de ingeniería inversa y análisis.

Los modelos generativos pueden reducir la barrera para examinar descripciones de hardware desconocidas. Pueden traducir sintaxis, explicar comportamientos probables, proponer pruebas y generar scripts para cadenas de herramientas existentes.

Los ingenieros especializados siguen siendo importantes. El comportamiento del hardware depende de la temporización, la síntesis, los efectos físicos y los detalles de implementación que una salida en lenguaje natural puede representar erróneamente.

Sin embargo, los atacantes no necesitan automatización total para obtener ventaja. Una reducción modesta del tiempo de análisis puede hacer que más objetivos resulten económicamente atractivos.

Los defensores afrontarán presión para probar los artefactos protegidos frente a capacidades de modelos en evolución antes de compartirlos. También deberán documentar qué información necesita realmente cada destinatario.

Esto acerca el control de acceso al propio diseño. En lugar de tratar a cada socio aprobado como si tuviera derecho al mismo artefacto, las empresas pueden adaptar la divulgación a una tarea concreta.

El proyecto de la University of Idaho ofrece una demostración compacta de este enfoque. Preservar lo que requiere un flujo de trabajo legítimo, ocultar la información sensible y cuestionar el resultado desde la perspectiva de un atacante.

La industria EDA en general ya avanza hacia sistemas más autónomos. El debate de DAC sobre una pila de EDA nativa de IA sostiene que la infraestructura, la integración y la confianza se han convertido en obstáculos centrales para la adopción en producción.

La seguridad forma parte de ese problema de confianza. Un agente que puede inspeccionar repositorios, ejecutar herramientas, modificar RTL e interpretar resultados de verificación tiene más capacidad que un chatbot aislado.

Una mayor capacidad ayuda a los equipos de ingeniería a automatizar tareas difíciles. También incrementa las consecuencias de un acceso excesivo, un razonamiento incorrecto, instrucciones comprometidas o registros mal protegidos.

Por ello, las organizaciones de chips necesitarán controles diseñados para agentes, no solo para usuarios humanos. Esos controles incluyen permisos limitados, espacios de trabajo aislados, ejecución reproducible de herramientas y controles de revisión antes de que cambios sensibles entren en un diseño.

Aquí es donde el modelo de competición se vuelve útil más allá de la educación. Los equipos rojos y azules proporcionan una forma estructurada de exponer supuestos antes de que lo haga un adversario.

El enfoque también puede fortalecer la educación en semiconductores. Los estudiantes que solo aprenden optimización de diseño pueden pasar por alto cómo artefactos aparentemente inocuos revelan información propietaria o sensible para la seguridad.

Abideen afirmó que la competición combinó IA generativa, herramientas de diseño de chips y análisis adversarial de seguridad de una forma rara vez disponible para estudiantes de grado. Esa combinación importa porque los futuros ingenieros heredarán tanto sistemas de diseño automatizado como amenazas asistidas por IA.

La University of Idaho cuenta con una base más amplia de seguridad de hardware detrás del proyecto. La investigación de Abideen abarca el diseño fiable de circuitos integrados, EDA con conciencia de seguridad, defensas contra ingeniería inversa, ofuscación de circuitos y diseño de chips asistido por IA.

Aun así, la lección más útil no es institucional. Es operativa: los equipos deberían asumir que los artefactos de diseño legibles recibirán análisis automatizados cada vez más capaces.

Ese supuesto cambia la carga de la prueba. Una defensa no debería considerarse adecuada porque los ingenieros no puedan descifrarla de inmediato. Debería resistir ataques definidos, validación medible y pruebas repetidas con herramientas nuevas.

Tres señales mostrarán si la victoria importa

La siguiente prueba es si este resultado de competición se convierte en evidencia reproducible, benchmarks más sólidos y adopción más allá de un proyecto universitario.

La primera señal es una publicación técnica. Un documento, benchmark, repositorio o informe detallado de la competición aclararía el modelo de amenazas, los artefactos protegidos, los modelos, el sistema de puntuación y la sobrecarga de implementación.

Si ese material muestra una protección consistente en varios diseños no vistos, reforzaría el argumento a favor de la redacción de propiedad intelectual de hardware asistida por IA. Si el resultado depende de un único benchmark limitado, la afirmación más amplia se debilitaría.

La segunda señal es el rendimiento de equipos rojos independientes. Otros investigadores deberían probar la misma protección frente a modelos diferentes, arquitecturas de agentes y herramientas EDA convencionales.

Una defensa que solo sobrevive a los ataques previstos por sus propios diseñadores ofrece garantías limitadas. Una defensa que resiste a equipos independientes mientras preserva la función aporta evidencias más significativas.

La tercera señal es la integración en un flujo de trabajo de diseño repetible. Hay que observar herramientas que conecten la redacción, la simulación, las comprobaciones formales, el análisis de temporización, la medición de potencia y la evaluación adversarial.

La integración demostraría que la seguridad del diseño de chips con IA puede operar dentro de restricciones reales de ingeniería. Una demostración independiente que requiera un amplio ajuste manual seguiría siendo una investigación útil, pero todavía no un método de producción escalable.

Estas señales importan más que el premio en sí. Las competiciones recompensan el progreso bajo reglas definidas, mientras que la seguridad de semiconductores desplegada debe gestionar diseños desconocidos, atacantes cambiantes, controles de confidencialidad y errores costosos.

La victoria de la University of Idaho en seguridad de chips sigue marcando un cambio importante. Sitúa a la IA a ambos lados del mismo límite de diseño y mide la defensa mediante ataques activos.

Para desarrolladores y equipos de seguridad, la cuestión práctica es ahora concreta: ¿qué artefactos de diseño puede compartir de forma segura su organización y cómo probarían lo que un adversario asistido por IA puede inferir de ellos? Sigan los benchmarks emergentes, exijan validación reproducible y consideren el acceso a modelos como parte del modelo de amenazas de hardware. Las organizaciones que respondan a estas preguntas antes del despliegue estarán mejor preparadas para un ciclo de ataque y defensa que ya ha comenzado.

 
 

Empieza gratis

Un asistente de IA local-first con gestión del conocimiento personal

Para ofrecer una mejor experiencia con la IA,

actualmente remio solo es compatible con Windows 10+ (x64) y M-Chip Macs.

Tu aliado de IA para el trabajo
Haz más con remio

Planifica. Crea. Entrega.
Todo en un solo lugar.

bottom of page