Per anni abbiamo raccontato la sicurezza come un problema di codice, configurazioni e patch. Oggi non basta più. Le moderne microarchitetture, spinte da speculazione, parallelismo, eterogeneità e ottimizzazioni dipendenti dai dati, possono compromettere la riservatezza anche quando il software è corretto.
Il dibattito è stato rinfocolato dalle ricerche di Caroline Trippel, Assistant Professor a Stanford e guida dell’High Assurance Computer Architectures Lab, che nel suo nuovo paper “Specification and Formal Verification of Hardware–Software Contracts for High-Assurance Computer Architectures” (IEEE ComputingEdge, marzo 2026) propone di trattare i contratti hardware-software come il nuovo perimetro della fiducia digitale: non più una promessa vaga tra ISA (Instruction Set Architectures) e implementazione, ma una specifica formale di ciò che l’hardware può fare, di ciò che può far trapelare e di come verificarlo davvero.
Più che un contributo accademico, il suo framework è già leggibile come una roadmap strategica per l’industria del silicio.
Il chip non è più innocente con l’attenuarsi della Legge di Moore
Il prossimo incidente grave di sicurezza hardware non nascerà necessariamente da una backdoor hollywoodiana o da un bug spettacolare.
Più probabilmente nascerà da qualcosa di molto più banale e molto più pericoloso: unafiducia eccessiva in un processore che fa “la cosa giusta” dal punto di vista funzionale, ma agendo nel modo sbagliato dal punto di vista della riservatezza.
È qui che si colloca il vero salto di maturità del dibattito: capire che un microprocessore può eseguire correttamente un programma e, nello stesso tempo, tradirlo lateralmente.
È il punto su cui insiste l’articolo di Trippel, là dove osserva che la crescente complessità dei design hardware e dei deployment moderni sta esponendo i limiti delle specifiche e dei flussi di verifica attuali.
La tesi è scomoda, ma difficilmente contestabile.
Con l’attenuarsi dei benefici lineari della Legge di Moore, l’industria ha cercato performance attraverso parallelismo, specializzazione hardware, eterogeneità hardware-software e ottimizzazioni data-dependent.
Nel frattempo, gli scenari d’uso sono diventati più critici: multitenancy, hyperscale, automotive, sanità, infrastrutture, servizi di sicurezza.
Trippel, nel suo lavoro, colloca il tema dentro un quadro di assurance requirements stringenti, cioè correttezza, sicurezza e affidabilità insieme. Non è solo una questione di ingegneria elegante: è una ridefinizione del concetto stesso di piattaforma affidabile.
La fiducia malriposta nell’hardware
Per un CISO di un produttore hardware, o per chi ha in carico la product security di piattaforme avanzate, questa erosione della fiducia nel silicio ha ricadute molto concrete.
Significa costi di remediation più tardivi e più costosi, firmware update che inseguono leak emersi tardi, frizioni con i team crypto, maggiore complessità nelle assurance review dei clienti enterprise, esposizione reputazionale nei mercati regolati, e un tema sempre più sensibile nelle catene di fornitura: saper spiegare non solo che cosa fa il chip, ma anche che cosa non farà ai dati sensibili.
In questo senso, la fiducia malriposta nell’hardware diventa un rischio economico prima ancora che tecnico. L’inferenza regolatoria è chiara: in un contesto come quello del Cyber Resilience Act (CRA), che impone requisiti di cyber security lungo il ciclo di vita di prodotti hardware e software, la capacità di dimostrare scelte progettuali robuste e verificabili si avvicina sempre di più a una forma di due diligence tecnica.
Le ISA tradizionali falliscono: correttezza non è più sinonimo di riservatezza
Per decenni, l’Instruction Set Architecture è stata il contratto implicito che ha tenuto insieme l’ecosistema: il software definiva il “cosa”, l’hardware si prendeva in carico il “come”.
È stato un patto industrialmente vincente. Oggi, però, quel patto mostra le crepe.
Trippel lo formula in modo netto: il primo problema è lo specification challenge, cioè il fatto che le ISA tradizionali non siano abbastanza ricche da catturare tutti i modi in cui una microarchitettura può compromettere l’assurance del software.
In altre parole, il software continua a ragionare con astrazioni ordinate; il silicio decide in tempo reale, specula, riordina, condivide risorse, ottimizza e lascia tracce. L’esempio più chiaro viene dai Memory Consistency Models (MCM).
La storia dell’architettura insegna che, quando la complessità cresce, il contratto hardware-software va esplicitato, non lasciato nel sottinteso.
A partire dagli anni Ottanta e poi con l’era multicore, le ISA sono state estese con modelli di consistenza per permettere un ragionamento formale sui programmi concorrenti.
La zona grigia diventa disciplina rigorosa
Litmus test, formalizzazioni e strumenti automatici hanno trasformato quella che era una zona grigia in una disciplina rigorosa.
Oggi, però, la sfida si amplia ancora: nei sistemi eterogenei, i mismatch tra modelli di memoria tra cluster differenti rendono difficile persino definire quale debba essere il comportamento complessivo del sistema, e il paper richiama sia i compound consistency models sia l’approccio modulare di MemGlue come esempi di questa evoluzione.
Ma la vera frattura è emersa con Spectre e con l’intera famiglia degli attacchi da transient execution.
Qui il problema non è che il processore sbagli il risultato finale; il problema è che, durante un percorso speculativo poi annullato, può avere già toccato cache, predictor, porte di memoria o altre risorse in modo osservabile.
Il risultato architetturale resta corretto; la riservatezza, no. È per questo che la frase “l’esecuzione è corretta” non basta più a descrivere la sicurezza di una piattaforma.
In altri termini: il software guarda ancora il risultato; l’attaccante osserva il tragitto.
Il fallimento delle ISA in una riga
Una CPU può restituire il risultato giusto e avere comunque già perso il segreto lungo il percorso.
È qui che la correttezza cessa di coincidere con la sicurezza.
Dai modelli di memoria ai modelli di leakage: dove nasce il nuovo contratto
Il passaggio più importante del lavoro di Trippel è forse questo: trattare la sicurezza side-channel come un problema di specifica formale, non come una collezione di contromisure scollegate.
Se i Memory Consistency Models (MCM) hanno definito i contratti della concorrenza, i nuovi Leakage Containment Models (LCM) fanno lo stesso per la perdita di informazione.
L’idea è potente perché sposta il dibattito dal “come tamponare” al “come specificare ciò che l’hardware è autorizzato a esporre”.
Nel suo articolo, Trippel descrive gli LCM come contratti assiomatici costruiti estendendo direttamente i modelli assiomatici di memoria. È una scelta elegante sul piano teorico e molto pragmatica su quello industriale: si riusa un vocabolario già noto per entrare nel territorio del leakage.
Una tassonomia di base chiara
Un attacco side-channel coinvolge un transmitter, cioè un’operazione che modula una risorsa hardware in modo dipendente dagli operandi; un channel, cioè la risorsa stessa; e un receiver, che osserva indirettamente la modulazione, per esempio attraverso tempo di esecuzione o contesa.
Cache, branch predictor, functional units e memory ports sono tutti candidati naturali.
La forza del framework di Trippel è che non si…
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
Aldo Ceccarelli
Source link
