La vittoria dell'University of Idaho nella sicurezza dei chip mette l'AI da entrambe le parti della sfida
I ricercatori dell'University of Idaho specializzati nella sicurezza dei chip hanno conquistato il primo posto in una competizione del 2026 in cui l'AI generativa ha operato sia come difensore sia come attaccante. Lo studente universitario Lloyd Alcorn e l'assistente professore Zain Ul Abideen hanno realizzato un flusso di lavoro che nascondeva informazioni sensibili sulla progettazione dei chip, verificando al contempo cosa un avversario assistito dall'AI potesse ricostruire.
Questa combinazione crea la vera tensione. L'AI può aiutare gli ingegneri a proteggere la proprietà intellettuale all'interno di un progetto, ma la stessa classe di tecnologia può aiutare un attaccante a interpretare i file protetti. Una difesa, quindi, non può riuscire semplicemente rendendo un circuito difficile da leggere per una persona.
Il progetto ha vinto la GenAI-Guided Hardware IP Redaction and Red-Teaming Challenge alla 63ª Design Automation Conference, nota come DAC. Il risultato non definisce uno standard di sicurezza pronto per la produzione. Mostra però come la sicurezza nella progettazione AI dei chip stia diventando un problema di misurazione avversariale, anziché un'azione isolata per nascondere informazioni.
La sicurezza dei chip dell'University of Idaho vince al DAC
Il progetto vincitore ha trattato il design protetto di un chip come qualcosa che deve restare funzionale mentre resiste attivamente alla ricostruzione.
Alcorn, studente senior di ingegneria elettrica, ha lavorato con Abideen durante una competizione da remoto svoltasi da giugno a luglio 2026. I premi sono stati consegnati durante DAC, un'importante conferenza dedicata alla progettazione di chip e all'automazione della progettazione elettronica.
L'University of Idaho ha dichiarato che la conferenza riunisce oltre 5.000 ricercatori, ingegneri, professionisti del settore e studenti. Alcorn ha gareggiato con partecipanti provenienti sia dal mondo accademico sia dall'industria, pur partecipando come studente universitario.
Il loro compito riguardava l'IP hardware: la logica riutilizzabile, le architetture, le costanti e le strutture di controllo che conferiscono a un chip parte del suo comportamento distintivo. Questa proprietà compare spesso nel codice a livello di trasferimento tra registri, o RTL, che descrive come la logica digitale elabori e trasferisca dati.
Alcorn e Abideen hanno creato un sistema di sicurezza che offuscava informazioni critiche sulla funzionalità e sulla proprietà intellettuale di un chip. L'offuscamento modifica il modo in cui un progetto appare a un osservatore, preservandone il comportamento previsto.
Questo secondo requisito è importante. Uno schema di protezione che compromette simulazione, integrazione, temporizzazione o prestazioni di calcolo ha scarso valore pratico. Il team doveva nascondere informazioni preziose senza sacrificare il funzionamento del progetto.
Secondo il resoconto dell'università sul progetto vincitore, Alcorn ha ripetutamente adattato e testato il flusso di lavoro di protezione. Ha verificato che i progetti protetti continuassero a funzionare correttamente e ha misurato gli effetti su potenza e temporizzazione.
Ha quindi condotto una valutazione avversariale assistita dall'AI. Tale valutazione ha esaminato quali informazioni un attaccante potesse ancora dedurre dal progetto modificato, invece di presumere che il codice trasformato fosse automaticamente sicuro.
La competizione ha formalizzato questo conflitto attraverso team blu e rossi. I team blu hanno nascosto dettagli sensibili, mentre i team rossi hanno usato l'AI generativa per tentare ricostruzione, reverse engineering e auditing.
Gli organizzatori hanno descritto diversi obiettivi di protezione. Tra questi figuravano nomi dei moduli, gerarchia dei circuiti, comportamento delle macchine a stati finiti, costanti proprietarie, strutture crittografiche e logica di controllo sensibile. Un team rosso poteva quindi usare l'AI per dedurre ruoli o relazioni originali.
Ecco perché il riconoscimento è più significativo di un tradizionale premio studentesco per la progettazione. Il team non si è limitato a chiedere a un sistema AI di generare un circuito. Ha lavorato sul confine più difficile tra utilizzabilità e segretezza, esponendo poi la difesa a un attaccante intelligente.
Perché la redazione dell'IP hardware sta diventando più difficile
La redazione dell'IP hardware ora deve resistere a macchine in grado di ragionare su codice, struttura, schemi di denominazione e comportamento dei circuiti.
La redazione tradizionale si basa spesso sulla rimozione di commenti descrittivi, sulla ridenominazione dei segnali o sull'occultamento di blocchi progettuali selezionati. Queste misure possono ostacolare un'ispezione superficiale, ma non eliminano necessariamente le relazioni incorporate in un circuito funzionante.
Un modulo con nomi anonimi ha comunque ingressi, uscite, comportamento temporale e connessioni. Una macchina a stati continua a seguire determinati schemi. Un componente crittografico può mantenere costanti o flussi di dati riconoscibili dopo la scomparsa delle sue etichette.
L'AI generativa modifica l'economia dell'esame di questi indizi. Può riassumere RTL poco familiare, proporre probabili ruoli dei moduli, confrontare strutture ripetute e generare ipotesi sulla logica mancante. Un attaccante necessita comunque di conoscenze tecniche, ma l'AI può ridurre il costo dell'esplorazione di molte possibilità.
La stessa capacità aiuta i difensori. Un ingegnere della sicurezza può utilizzare un flusso di lavoro assistito dall'AI per identificare nomi rivelatori, individuare coni logici sensibili, proporre trasformazioni e verificare se tali modifiche preservino il comportamento previsto.
Un cono logico è l'insieme degli elementi circuitali che influenzano una particolare uscita. Se un'uscita critica per la sicurezza può essere ricondotta a porte o costanti riconoscibili, nascondere le sole etichette può offrire una protezione debole.
L'approccio del team dell'University of Idaho riflette questo duplice utilizzo. L'AI ha supportato il flusso di lavoro difensivo, quindi ha contribuito a sondarne il risultato da una prospettiva avversariale. Lo strumento non era né intrinsecamente protettivo né intrinsecamente ostile.
Questa dinamica sta già emergendo nell'agenda di ricerca dell'automazione della progettazione elettronica. L'agenda di ricerca sulla sicurezza del DAC per il 2026 include esplicitamente attacchi e difese hardware basati sull'AI, reverse engineering, offuscamento hardware e automazione della progettazione che preserva la sicurezza.
La conferenza ha inoltre sollecitato lavori su modelli fondazionali per l'EDA, verifica agentica, automazione della progettazione fisica e benchmark per valutare i sistemi AI. EDA si riferisce al software usato per progettare, simulare, verificare e preparare sistemi elettronici alla produzione.
Questi sviluppi rendono la sicurezza nella progettazione AI dei chip un bersaglio mobile. Una trasformazione che sconfigge un modello o una strategia di prompt potrebbe divulgare informazioni a un modello più potente, a un agente specializzato o a un flusso di lavoro che combina AI e analisi formale.
La minaccia è inoltre più ampia del furto di codice sorgente. Un progetto ricostruito potrebbe rivelare algoritmi proprietari, controlli di sicurezza, strutture crittografiche o decisioni di implementazione. Tali informazioni possono favorire contraffazione, clonazione, scoperta di vulnerabilità o modifiche dannose.
NIST descrive la catena di fornitura dei semiconduttori come una rete che comprende proprietà intellettuale, progettazione, produzione, test, confezionamento e distribuzione. Il suo programma di sicurezza hardware considera la pirateria dell'IP, il reverse engineering e i Trojan hardware come aspetti correlati della progettazione orientata alla fiducia.
Un Trojan hardware è logica dannosa aggiunta a un circuito per modificarne il comportamento, far trapelare informazioni o creare accessi nascosti. A differenza di una normale vulnerabilità software, può diventare parte del dispositivo fisico.
La sola redazione non può fermare ogni rischio di questo tipo. Tuttavia, la competizione affronta una fase iniziale importante: limitare ciò che gli artefatti di progettazione rivelano quando devono passare tra team, strumenti, fornitori o impianti.
Questo requisito è difficile perché la produzione di semiconduttori è distribuita. Un progetto può attraversare molteplici confini organizzativi e tecnici prima che un componente finito raggiunga un prodotto.
Ogni confine crea un conflitto. I partner necessitano di informazioni sufficienti per eseguire simulazione, verifica, integrazione, produzione o test. Il proprietario dell'IP desidera divulgare solo ciò che tali attività richiedono.
La redazione dell'IP hardware cerca di gestire questo conflitto. L'AI generativa rende entrambe le parti più veloci, quindi la protezione ora richiede test avversariali ripetibili anziché fiducia basata sull'oscurità.
La vera sfida era l'utilizzabilità contro la segretezza
Il problema decisivo non è se un progetto possa essere nascosto, ma se possa restare utile dopo la rimozione delle sue caratteristiche più rivelatrici.
Un difensore potrebbe teoricamente rendere impossibile la ricostruzione trattenendo l'intero progetto. Tale approccio impedisce però anche ai collaboratori legittimi di simularlo, testarlo o integrarlo.
La protezione pratica deve preservare un livello concordato di utilità. Un artefatto redatto potrebbe dover compilare, superare test funzionali, esporre interfacce definite e rispettare vincoli di temporizzazione. Ogni capacità mantenuta può inoltre rivelare informazioni aggiuntive.
Questo crea un compromesso simile all'anonimizzazione dei dati. Rimuovere identificatori evidenti non garantisce la privacy quando le relazioni tra i campi rimanenti possono rivelare le informazioni mancanti.
La struttura dei circuiti può essere altrettanto informativa. Ingressi, uscite, operazioni ripetute, schemi di lookup e transizioni di stato possono identificare un componente anche quando i nomi e i commenti originali sono scomparsi.
Un metodo di offuscamento può aggiungere trasformazioni o comportamenti basati su chiavi per rendere il progetto più difficile da interpretare. Tuttavia, tali modifiche possono aumentare il consumo energetico, estendere i percorsi temporali critici, incrementare l'area o complicare la verifica.
Il team dell'University of Idaho ha misurato potenza e temporizzazione perché la sicurezza non può essere valutata isolatamente. Una difesa che impone una penalità di implementazione inaccettabile avrà difficoltà a superare una revisione commerciale del progetto.
DARPA ha identificato lo stesso ostacolo di fondo nel suo programma di automazione del silicio sicuro. L'agenzia ha osservato che la sicurezza a livello di chip incontra spesso ostacoli economici e compromessi tecnici, mentre le modifiche tardive al progetto sono eccezionalmente difficili.
La sua risposta è stata un flusso di progettazione automatizzato capace di valutare alternative architetturali rispetto a obiettivi di sicurezza e implementazione. Questa impostazione corrisponde strettamente al problema messo in luce dalla sfida DAC, anche se i programmi sono distinti.
L'automazione è importante perché la progettazione dei chip comporta già uno spazio di ricerca enorme. Gli ingegneri bilanciano funzionalità, prestazioni, potenza, area, affidabilità, sforzo di verifica, vincoli produttivi e calendari di consegna.
La sicurezza aggiunge un altro obiettivo, ma non può semplicemente prevalere su ogni altro requisito. Un progetto protetto deve comunque diventare un prodotto funzionante.
L'AI può aiutare a esplorare più rapidamente le trasformazioni candidate. Può anche aiutare un avversario a cercare schemi sopravvissuti a tali trasformazioni. La sfida risultante è iterativa, non statica.
Un team blu modifica il progetto. Un team rosso cerca il significato mantenuto. Il team blu adegua quindi la trasformazione, verifica di nuovo la funzionalità e misura gli eventuali nuovi costi.
Questo ciclo ricorda i moderni test di sicurezza software, in cui i difensori analizzano continuamente il codice e gli attaccanti cercano continuamente aggiramenti. L'hardware introduce un vincolo più severo perché gli errori possono persistere dopo la fabbricazione.
Spesso una patch software può essere distribuita dopo il rilascio. Un progetto di chip difettoso può richiedere una sostituzione costosa, una nuova produzione o controlli compensativi in altre parti del sistema.
Ciò rende particolarmente preziosa la valutazione pre-silicio. Pre-silicio si riferisce al lavoro svolto prima che un progetto diventi un chip prodotto. I test assistiti dall'AI possono esaminare gli artefatti di progettazione mentre gli ingegneri possono ancora modificarli.
Il risultato ottenuto dall'Idaho supporta quindi un meccanismo, non una risposta universale. Usare l'AI per assistere la protezione, preservare l'utilità del progetto, misurare i costi di implementazione e attaccare l'output prima di fidarsene.
Quel meccanismo può migliorare la disciplina ingegneristica anche quando il modello produce suggerimenti imperfetti. Costringe il team a definire ciò che deve restare utilizzabile, ciò che deve restare riservato e quali prove costituiscono una difesa efficace.
La sicurezza nella progettazione di chip con IA richiede prove migliori
Un primo posto dimostra il successo in una competizione, ma non prova ancora che il flusso di lavoro possa proteggere la proprietà intellettuale commerciale dei semiconduttori.
Il rapporto pubblico dell'Università dell'Idaho non fornisce un articolo tecnico dettagliato, una suite di benchmark, un inventario dei modelli, una ripartizione dei punteggi o un modello completo delle minacce. Non pubblica nemmeno i progetti protetti né i tentativi di ricostruzione riusciti.
Queste omissioni sono comprensibili in un breve articolo di cronaca universitaria. Tuttavia, limitano ciò che gli ingegneri esterni possono dedurre dal risultato.
Una valutazione significativa deve definire l'accesso dell'attaccante. Il red team ha ricevuto RTL, una netlist sintetizzata, output di simulazione, documentazione delle interfacce o solo artefatti selezionati? Livelli di accesso diversi creano rischi di ricostruzione molto diversi.
Anche la configurazione del modello conta. Un modello linguistico generalista, un modello focalizzato sul codice e un agente EDA connesso a strumenti di analisi possono produrre risultati differenti.
Anche prompt e iterazione possono influire sulle prestazioni. Un attaccante con una sola query non rappresenta un attaccante in grado di eseguire molti agenti, compilare progetti candidati, analizzare gli errori e affinare le ipotesi.
Le metriche di valutazione restano un'altra questione irrisolta. Una difesa potrebbe impedire la ricostruzione esatta del codice sorgente continuando però a divulgare lo scopo del componente, l'algoritmo, le costanti o il confine di sicurezza.
Al contrario, un sistema di IA potrebbe generare spiegazioni plausibili ma tecnicamente errate. Una ricostruzione apparente non equivale a un recupero verificato.
Un benchmark solido necessita quindi di più livelli di misurazione. Dovrebbe testare l'equivalenza funzionale, la somiglianza strutturale, l'inferenza semantica, il recupero dei segreti e il costo imposto al progetto protetto.
Dovrebbe inoltre verificare se la difesa si trasferisce a famiglie di circuiti non viste. Un metodo ottimizzato per un benchmark può funzionare bene in una competizione ma fallire su architetture differenti.
Il NIST ha sottolineato questa lacuna di misurazione. Il suo programma sull'hardware richiede dataset di riferimento e metriche in grado di supportare test, attestazione, certificazione e verifica dei componenti a semiconduttore.
Il rapporto del workshop sugli standard dell'agenzia del 2026 ha inoltre identificato la verifica e la validazione scalabili come priorità. Gli approcci raccomandati includevano analisi assistita dall'IA, metodi formali, fuzzing, test standardizzati e valutazione della resilienza.
Questa combinazione è importante. L'IA non dovrebbe diventare l'unico giudice della propria capacità di proteggere con successo un progetto.
I metodi formali usano il ragionamento matematico per verificare proprietà di un sistema. La simulazione esegue scenari selezionati, mentre la verifica formale può esaminare classi più ampie di comportamenti possibili in base ad assunzioni definite.
Il flusso di lavoro più credibile per la sicurezza nella progettazione di chip con IA combinerebbe l'esplorazione assistita dal modello con controlli deterministici. Il modello può proporre trasformazioni o attacchi, mentre gli strumenti convenzionali verificano funzione, temporizzazione, potenza e proprietà di sicurezza.
Anche la riproducibilità è altrettanto importante. I ricercatori hanno bisogno di registrazioni delle versioni dei modelli, dei prompt, delle chiamate agli strumenti, degli artefatti intermedi e dei risultati di validazione. Altrimenti, un risultato vincente può essere difficile da confrontare o ripetere.
I servizi di IA pongono anche proprie questioni di riservatezza. Caricare RTL proprietario su un modello esterno potrebbe esporre proprio le informazioni che un flusso di protezione è destinato a tutelare.
Un'implementazione in produzione richiederebbe controlli chiari su conservazione dei dati, accesso ai modelli, log, isolamento e proprietà degli artefatti generati. I modelli locali o controllati dall'organizzazione possono ridurre parte dell'esposizione, ma non eliminano il rischio tecnico.
Esiste anche un problema di contaminazione dei benchmark. Se esempi pubblici di circuiti compaiono nei dati di addestramento del modello, un sistema potrebbe richiamare schemi familiari anziché dedurli da un progetto realmente protetto.
I ricercatori devono distinguere la memorizzazione dalla ricostruzione. Circuiti di valutazione privati, divulgazione controllata e benchmark successivi all'addestramento possono aiutare, anche se rendono più difficile la replica aperta.
Il premio dimostra quindi che l'approccio merita uno studio più approfondito. Non dimostra che l'IA generativa abbia risolto la protezione della proprietà intellettuale hardware.
I produttori di chip affrontano un nuovo ciclo di attacco e difesa
La pressione ricade su ogni organizzazione che condivide artefatti di progettazione oltre un team interno strettamente controllato.
Questo gruppo include aziende di chip, fornitori di IP riutilizzabile, fonderie, provider EDA cloud, appaltatori per la verifica, specialisti del packaging e partner di ricerca. Include anche i clienti che integrano core concessi in licenza in sistemi più ampi.
La fonte della pressione non è un singolo concorrente. È la crescente capacità degli attaccanti di combinare il ragionamento dell'IA con strumenti consolidati di reverse engineering e analisi.
I modelli generativi possono abbassare la barriera all'esame di descrizioni hardware non familiari. Possono tradurre la sintassi, spiegare il comportamento probabile, proporre test e generare script per toolchain esistenti.
Gli ingegneri specializzati restano fondamentali. Il comportamento dell'hardware dipende da temporizzazione, sintesi, effetti fisici e dettagli di implementazione che un output in linguaggio naturale può rappresentare in modo errato.
Tuttavia, gli attaccanti non hanno bisogno di un'automazione completa per ottenere un vantaggio. Una modesta riduzione del tempo di analisi può rendere economicamente attraenti più bersagli.
I difensori subiranno pressioni per testare gli artefatti protetti rispetto alle capacità in evoluzione dei modelli prima di condividerli. Dovranno inoltre documentare quali informazioni richiede effettivamente ciascun destinatario.
Questo avvicina il controllo degli accessi al progetto stesso. Invece di considerare ogni partner approvato autorizzato allo stesso artefatto, le aziende possono adattare la divulgazione a un compito specifico.
Il progetto dell'Università dell'Idaho offre una dimostrazione concisa di questo approccio. Conservare ciò che richiede un flusso di lavoro legittimo, oscurare le informazioni sensibili e mettere alla prova il risultato dalla prospettiva di un attaccante.
L'industria EDA più ampia si sta già muovendo verso sistemi più autonomi. La discussione del DAC su uno stack EDA nativo per l'IA sostiene che infrastruttura, integrazione e fiducia siano diventati ostacoli centrali all'adozione in produzione.
La sicurezza è parte di questo problema di fiducia. Un agente in grado di ispezionare repository, eseguire strumenti, modificare RTL e interpretare risultati di verifica dispone di capacità maggiori rispetto a un chatbot isolato.
Una maggiore capacità aiuta i team di ingegneria ad automatizzare lavori difficili. Aumenta anche le conseguenze di un accesso eccessivo, di ragionamenti errati, di istruzioni compromesse o di log protetti in modo inadeguato.
Le organizzazioni che progettano chip avranno quindi bisogno di controlli progettati per gli agenti, non solo per gli utenti umani. Tali controlli includono autorizzazioni ristrette, spazi di lavoro isolati, esecuzione riproducibile degli strumenti e gate di revisione prima che modifiche sensibili entrino in un progetto.
È qui che il modello della competizione diventa utile oltre l'ambito educativo. I red e blue team offrono un modo strutturato per mettere in luce le assunzioni prima che lo faccia un avversario.
L'approccio può anche rafforzare la formazione sui semiconduttori. Gli studenti che apprendono solo l'ottimizzazione della progettazione potrebbero non cogliere come artefatti apparentemente innocui rivelino informazioni proprietarie o sensibili per la sicurezza.
Abideen ha affermato che la competizione ha combinato IA generativa, strumenti di progettazione di chip e analisi di sicurezza avversariale in un modo raramente disponibile agli studenti universitari. Questa combinazione è importante perché i futuri ingegneri erediteranno sia sistemi automatizzati di progettazione sia minacce assistite dall'IA.
L'Università dell'Idaho dispone di una base più ampia nella sicurezza hardware a sostegno del progetto. La ricerca di Abideen copre la progettazione affidabile di circuiti integrati, EDA orientato alla sicurezza, difese contro il reverse engineering, offuscamento dei circuiti e progettazione di chip assistita dall'IA.
Tuttavia, la lezione più utile non è istituzionale. È operativa: i team dovrebbero presumere che gli artefatti di progettazione leggibili saranno sottoposti a un'analisi automatizzata sempre più capace.
Questa assunzione cambia l'onere della prova. Una difesa non dovrebbe essere considerata adeguata perché gli ingegneri non riescono a comprenderla immediatamente. Dovrebbe resistere ad attacchi definiti, validazione misurabile e test ripetuti con nuovi strumenti.
Tre segnali mostreranno se la vittoria conta davvero
Il prossimo test è stabilire se questo risultato in competizione si tradurrà in prove riproducibili, benchmark più solidi e adozione oltre un progetto universitario.
Il primo segnale è una pubblicazione tecnica. Un articolo, un benchmark, un repository o un rapporto dettagliato sulla competizione chiarirebbero il modello delle minacce, gli artefatti protetti, i modelli, il sistema di punteggio e l'overhead di implementazione.
Se tale materiale mostrasse una protezione coerente su vari progetti non visti, rafforzerebbe la tesi a favore della redazione della proprietà intellettuale hardware assistita dall'IA. Se il risultato dipendesse da un singolo benchmark ristretto, l'affermazione più ampia si indebolirebbe.
Il secondo segnale è la prestazione di red team indipendenti. Altri ricercatori dovrebbero testare la stessa protezione rispetto a modelli diversi, architetture di agenti e strumenti EDA convenzionali.
Una difesa che resiste solo agli attacchi previsti dai suoi stessi progettisti offre garanzie limitate. Una difesa che resiste a team indipendenti preservando al contempo la funzione fornisce prove più significative.
Il terzo segnale è l'integrazione in un flusso di lavoro di progettazione ripetibile. Occorre osservare strumenti che collegano redazione, simulazione, controlli formali, analisi della temporizzazione, misurazione della potenza e valutazione avversariale.
L'integrazione dimostrerebbe che la sicurezza nella progettazione di chip con IA può operare entro vincoli ingegneristici reali. Una dimostrazione isolata che richiede un'ampia regolazione manuale resterebbe una ricerca utile, ma non ancora un metodo di produzione scalabile.
Questi segnali contano più del premio stesso. Le competizioni premiano i progressi secondo regole definite, mentre la sicurezza dei semiconduttori in produzione deve affrontare progetti sconosciuti, attaccanti in evoluzione, controlli di riservatezza ed errori costosi.
La vittoria dell'Università dell'Idaho nella sicurezza dei chip segna comunque un cambiamento importante. Colloca l'IA su entrambi i lati dello stesso confine progettuale e misura la difesa attraverso un attacco attivo.
Per gli sviluppatori e i team di sicurezza, la domanda pratica ora è concreta: quali artefatti di progettazione può condividere in sicurezza la vostra organizzazione, e come testereste ciò che un avversario assistito dall'IA può dedurne? Seguite i benchmark emergenti, richiedete una validazione riproducibile e considerate l'accesso ai modelli come parte del modello delle minacce hardware. Le organizzazioni che risponderanno a queste domande prima della distribuzione saranno meglio preparate a un ciclo di attacco e difesa già iniziato.
