Quando lo scorso 9 novembre Intel ha reso pubblica l’esistenza di tre nuove falle di sicurezza che affliggono una lunga lista dei suoi processori, la notizia è passata pressoché sotto silenzio. L’eco dell’annuncio fatto sul sito ufficiale di Santa Clara non si è spinto oltre l’esiguo perimetro informativo delimitato da portali tech e di cybersicurezza. Eppure, le falle scoperte dai ricercatori di Sentinel One e Positive Technologies per conto di Intel non sono da prendere sottogamba. Al contrario, secondo il sistema di classificazione gestito da Mitre Corporation noto come “Common Vulnerabilities and Exposures”, o, più semplicemente, CVE – un database pubblico nato alla fine degli anni ‘90 per tenere traccia dei bug del software, estesosi poi progressivamente anche alle vulnerabilità hardware – il loro impatto è da considerarsi di tipo alto: su una scala da uno a dieci, alla falla meno seria viene attribuito un valore di 7,1, mentre le due più gravi arrivano fino ad 8,2.

Un malintenzionato determinato a sfruttarle – per poterlo fare è però necessario avere accesso fisico alla macchina che monta il processore difettoso – può condurre una “Escalation of Privileges” (EoP), ovvero un attacco attraverso cui garantirsi in maniera illecita i privilegi di amministratore di un sistema e prenderne il controllo. E con ‘sistema’ non si intendono solo server e portatili – per esempio un laptop rubato da cui estrarre le chiavi di cifratura in modo da avere accesso alle informazioni che esso custodisce – ma anche un’automobile: infatti, una delle CPU (acronimo di Central Processing Unit, un altro modo di dire processore) affette dalle falle di sicurezza in questione è stata progettata appositamente per il settore automotive ed è il cervello di diversi modelli di autovetture attualmente in circolazione.

L’insicurezza hardware è un tema che resta trascurato, e non perché non sia rilevante, anzi. È semmai un elemento integrante dell’infrastruttura tecnologica usata quotidianamente da miliardi di persone. Ma come dice il filosofo francese Benjamin Constant, ci si abitua alle infrastrutture tecniche e alle loro caratteristiche (insicurezza inclusa), così come ci si abitua alle leggi naturali della fisica.

Una, cento, mille falle

Quando si parla di insicurezza hardware si fa spesso riferimento solo alle falle più note al grande pubblico: Rowhammer, Meltdown e Spectre. Queste vulnerabilità interessano differenti componenti dei computer – Rowhammer la memoria RAM, Meltdown e Spectre il processore – ma hanno tutte origine in dei difetti di progettazione che permettono ad un attaccante di usare in modo improprio le normali funzionalità di un chip e provocare così dei problemi di sicurezza inaspettati.

Parlare di queste tre falle al singolare sarebbe un errore. La comunità di sicurezza informatica ha continuato a studiarle anche dopo che la loro esistenza era stata resa pubblica e per ognuna ha individuato numerose varianti. Quelle di Spectre sono venute a galla con cadenza quasi mensile nei due anni successivi alla sua scoperta e l’ultima ad essere stata resa nota risale al maggio del 2021. Nel 2019 invece, un gruppo di ricercatori ha annunciato di aver messo a punto un nuovo attacco alla memoria RAM (ribattezzato “RamBleed”) basato su Rowhammer, nonostante fossero passati più di cinque anni da quando un gruppo di ricercatori della Carnegie Mellon ne aveva annunciato l’esistenza al mondo.

Memorie, processori, ma anche periferiche

Esistono poi attacchi che utilizzano in maniera combinata Rowhammer e Spectre: SpecHammer permette di eludere qualsiasi forma di contromisura fino ad oggi elaborata per mitigare l’impatto di queste due falle, mentre Spoiler utilizza i difetti presenti nei processori Intel per rendere più semplici gli attacchi alla RAM. Basta così? Magari, perché purtroppo non sono solo i transistor di cui sono fatti i processori ed i banchi di memoria ad essere inaffidabili. Alla lista vanno aggiunti anche Bluetooth, USB, interfacce Thunderbolt, wireless, chip di sicurezza: praticamente qualsiasi altra periferica di cui sono fatti i nostri computer – e quindi i nostri telefoni, elettrodomestici, orologi, consolle da gioco, contatori del gas, sistemi di controllo industriali e veicoli di trasporto, aeroplani inclusi – è nota per essere o essere stata affetta da una vulnerabilità più o meno grave.

La silenziosa crescita delle falle hardware

Come sostenuto dalla sociologa Zeynep Tufecki, la nostra debolezza digitale è radicata in una rete interconnessa caratterizzata da vulnerabilità combinate. All’origine di questo stato di insicurezza permanente ci sono una pluralità di concause di tipo tecnico, sociale e storico che tendono spesso ad alimentarsi l’una con l’altra, rafforzandosi a vicenda. L’hardware ovviamente non è rimasto immune da questa dinamica. 

Andrea Barisani è capo del settore hardware security di una nota società di sicurezza e ricercatore di fama internazionale. Nel 2007 è stato il primo hacker a dimostrare come utilizzare il trasmettitore radio FM di un’automobile per manometterne il sistema di navigazione satellitare in maniera remota. Dopo aver passato quasi 20 anni a smontare e rompere ogni tipo di hardware a sua disposizione per capirne il funzionamento, il ricercatore ritiene che interpretare la sicurezza in senso assoluto sia fuorviante. “Ogni periodo storico”, commenta a Guerre di Rete Barisani, “è caratterizzato dall’emersione dei cosiddetti low hanging fruits”, ovvero da problematiche talmente evidenti e gravi da richiamare il grosso dell’interesse della comunità di sicurezza. “Quando ho cominciato a fare il ricercatore c’era da risolvere un problema su scala molto grande, ovvero la mancanza di librerie crittografiche adeguatamente integrate nei protocolli della rete Internet. L’attenzione era tutta concentrata sul software, mentre l’hardware veniva visto come un ambito esoterico, non particolarmente rilevante e, tutto sommato, trascurabile”.

Risultato: messe in ombra dai bug del software, le falle hardware sono così potute crescere silenziosamente e a dismisura, tanto da diventare una delle caratteristiche predominanti dei nostri ecosistemi digitali. Si tratta di un fenomeno che, tra l’altro, sembrerebbe sbagliato coniugare al passato. Secondo un report pubblicato lo scorso ottobre dal NIST (il National Institute of Standards and Technologies) l’accresciuto livello di guardia creatosi intorno a software e applicazioni ha spinto gli attaccanti a spostare progressivamente la loro attenzione verso l’hardware.

L’attenzione alle prestazioni e non alla sicurezza

Secondo il professor Paolo Prinetto e il ricercatore Gianluca Roascio, questo disastroso stato di cose nasce da lontano. Le sue origini sono molteplici e si possono rintracciare sia in una certa miopia del settore privato, sia sui banchi delle aule universitarie, dove a lungo sono mancati adeguati percorsi di formazione in fatto di cybersicurezza. Prinetto è docente di Computer Engineering al Politecnico di Torino. Dal 2018 riveste il ruolo di direttore del Laboratorio Nazionale di Cybersicurezza del CINI (Consorzio Universitario Nazionale per l’Informatica) e vanta un esteso curriculum di ricerca in fatto di insicurezza hardware. “Per molto tempo”, commenta Prinetto a Guerre di Rete, “le aziende hanno visto la sicurezza solo come un overhead”, ovvero come un costo aggiuntivo, un investimento che non veniva fatto perché non ne erano chiari i benefici. “In passato”, racconta il docente, “nessuno era disposto a sacrificare una quota dei propri guadagni, o a rimandare il lancio di un prodotto – magari con il rischio di perdere terreno sui propri concorrenti – solo per mitigare dei rischi che sembravano ipotetici”.

Fino al 2018 gli sforzi dei produttori di CPU sono stati quasi esclusivamente tesi a migliorare le prestazioni dei loro dispositivi. E l’accademia, in qualche modo, sembrava essersi adeguata a questo trend. “Pochissimi colleghi insegnavano a scrivere codice o a progettare hardware in maniera sicura”, prosegue Prinetto, “e le cose ancora oggi non sembrano cambiare”. Tutto è concentrato sull’ottimizzazione delle prestazioni e la sicurezza, invece che essere applicata sin dalle primissime fasi di design, diventa una specie di appendice, un fastidio che si affronta a posteriori.

“Questo approccio”, commenta Gianluca Roascio, dottorando presso il Politecnico di Torino, “pur essendo tutt’altro che ideale, può forse avere una qualche efficacia quando parliamo di software”. Infatti, quando un bug viene individuato nel codice di un programma le patch vengono solitamente rilasciate nel giro di giorni, a volte di ore: a quel punto l’utente le scarica, le installa ed il problema è risolto. “Ma con l’hardware”, spiega Roascio, “è tutto un altro paio di maniche”. 

Una volta che processori e banchi di memoria difettosi vengono messi in commercio, rimangono in circolazione con le loro vulnerabilità fino a quando l’industria non sviluppa delle mitigazioni o produce dell’hardware nuovo. I tempi sono infinitamente più lenti. Se si è fortunati è possibile che la casa produttrice rilasci degli aggiornamenti del firmware (ovvero di piccole porzioni di codice che gestiscono l’hardware a basso livello) per tamponare la vulnerabilità. Ma anche quando questo avviene è necessario fare i conti con una dinamica nota come frammentazione dell’ecosistema caratterizzata da una tempistica molto dilatata.

Tradotto: Intel può anche rilasciare in maniera tempestiva un nuovo firmware per mitigare una vulnerabilità recentemente scoperta in uno dei suoi processori, ma possono passare settimane o mesi prima che i produttori di portatili e schede madri lo rendano disponibile al pubblico. Nel frattempo, l’utente rimane senza protezioni ed esposto al rischio che un criminale possa sfruttare questa falle per attaccarlo. E questo rimane il quadro più roseo: molto spesso le case produttrici di CPU non traggono alcun vantaggio dal rilasciare delle patch per l’hardware (soprattutto se molto vecchio) e preferiscono spingere i consumatori ad acquistarne di nuovo.

La variabile supply chain

C’è poi la famigerata questione della supply chain, ovvero della filiera produttiva che fornisce ai grandi manufacturer (TSMC, Intel, AMD, IBM, Qualcomm, NVIDIA) le componenti con cui vengono costruiti i loro dispositivi. E questa è una questione tanto di geopolitica quanto di economia politica.
All’inizio degli anni 2000 le case produttrici di hardware decidono di sostituire il modello di produzione verticale integrato che avevano adottato fino a quel momento – dove le fasi di progettazione, realizzazione ed assemblaggio erano interamente gestite dalla singola azienda in prima persona – con uno orizzontale e distribuito, appaltando la fase di realizzazione a una miriade di aziende esterne, la maggior parte delle quali situate in un unico paese: la Cina.

Come scrivono Prinetto e Roascio in un paper recente in cui viene delineata una tassonomia delle vulnerabilità hardware e degli attacchi che queste rendono possibili, questa trasformazione del modello di produzione ha generato diffuse preoccupazioni in relazione a possibili rischi di pirateria, contraffazione e manomissione dell’hardware. Ma anche in questo caso il concetto di sicurezza non è né assoluto, né prettamente tecnico ma nasce sullo sfondo di una trasformazione del contesto storico su cui si è incistata l’economia neo-liberista globale.

“Si tratta di una situazione paradossale”, commenta ancora Barisani “perché ogni produttore è in controllo del suo dispositivo, ma non dei singoli componenti di cui questo è fatto”. E ad oggi, aggiunge, per un attore abbastanza determinato e dotato di sufficienti risorse le opportunità per colpire la supply chain sono molteplici. “Allo stato attuale delle cose non esiste una metodologia efficace per verificare se si è finiti nel mirino di un attacco di questo genere: i modi che ci sono non sono affidabili, non sono economici, non scalano verso l’altro”.

La convergenza tra hardware e software

Il sostanziale oblio in cui la sicurezza del silicio ha versato per anni ha fatto sì che i problemi crescessero silenziosamente e a dismisura. E quando nel 2014, con la scoperta di Rowhammer, è venuta meno l’erronea convinzione per cui l’hardware potesse essere oggetto di un guasto ma non di un attacco, è scattato il cosiddetto weaponizing: hacker e ricercatori hanno cominciato a fare a gara tra di loro per sfruttare queste inedite classi di vulnerabilità e immaginare nuovi attacchi basati sulle stesse.

Secondo Matt Spencer, professore associato presso il Centre for Interdisciplinary Methodologies della University of Warwick (UK) e studioso delle dinamiche tecniche e sociali alla base dell’insicurezza hardware, Rowhammer rappresenta però uno spartiacque storico anche per un altro motivo. “Pur trattandosi di un attacco che va a colpire l’hardware, Rowhammer viene indotto attraverso dei meccanismi di tipo software”, commenta Spencer a Guerre di Rete. “Questo significa che, a differenza di quanto avveniva in passato, l’hardware può, almeno in teoria, essere attaccato in maniera remota e su scala globale, senza che sia più necessario avere accesso fisico al target”.

Il fatto che hardware e software possano essere combinati tra loro per finalità di tipo offensivo sta portando la comunità di security a maturare una crescente consapevolezza sul fatto che un approccio olistico verso questo tipo di problematiche sia sempre più urgente. “Hardware e software non possono più essere considerate come categorie concettuali tra loro separate”, aggiunge Spencer. “La maggior parte dell’hardware include del software di un qualche tipo, magari integrato nella stessa scheda madre, oppure progettato per interfacciarsi a livello superiore di sistema. Allo stesso modo, tutto il software dipende dall’hardware”.
Anche Barisani insiste su questo concetto parlando esplicitamente di convergenza tra hardware e software. “La sicurezza comincia nel silicio. Metaforicamente parlando, l’hardware è la culla in cui il software può girare in maniera sicura. Una falla nell’hardware può andare a minare qualsiasi modello di sicurezza implementato nel software”.

Questo discorso vale anche al contrario? “Certo. Il software ha molto potere sul modo in cui l’hardware lavora e può interferire con il suo corretto funzionamento. Per questo motivo quando cerco di capire se un dispositivo è affetto da delle falle lo guardo come se fosse un tutt’uno”. Se hardware e software sono due lati della stessa medaglia, allora la comprensione del modo in cui interagiscono reciprocamente non può più essere ignorata: la cybersicurezza è una scienza che deve evolvere seguendo necessariamente una traiettoria interdisciplinare. “Questi due ambiti ad un certo punto non avranno più neppure un confine tra loro”, chiosa il ricercatore.

E la convergenza tra safety e security

Atomi e bit si mescolano tra di loro. Fisica e scienza dei computer diventano un’unica disciplina. Hardware e software convergono in un unico oggetto. Ma anche, sostiene ancora Paolo Prinetto, security e safety (quest’ultima traducibile in italiano come “la sicurezza delle persone e dell’ambiente”) devono cominciare a muoversi all’unisono. Secondo il docente torinese, Rowhammer ha messo in chiaro che sicurezza e affidabilità devono essere entrambe debitamente tenute in conto nella progettazione hardware, senza prediligere l’una a discapito dell’altra. “La vulnerabilità alla base di Rowhammer non nasce dal nulla. Si tratta di un problema notissimo a chi si occupa di sviluppo di metodologie di collaudo per memorie RAM”.

Le tecniche utilizzate per condurre attacchi di tipo Rowhammer, spiega Prinetto, sono le medesime che da anni vengono utilizzate in fase di collaudo della RAM per identificare eventuali guasti che le affliggono ed evitare che sul mercato siano immessi dispositivi difettosi. “Solo che”, sottolinea Prinetto, “con Rowhammer queste medesime tecniche, ideate per finalità di safety, possono essere cooptate per indurre un malfunzionamento del sistema sfruttabile con finalità di security”. 

Di contro però, anche le falle di sicurezza possono essere sfruttate per compromettere l’affidabilità di un dispositivo. “Io e il mio team siamo spesso chiamati a testare la sicurezza di treni o aeroplani”, racconta Barisani. Un aereo è sempre progettato seguendo criteri che garantiscano sicurezza (intesa come safety) e affidabilità. Per esempio, il numero dei suoi motori è ridondante perché in caso di guasti gli altri continuino a funzionare. “Noi come ricercatori di sicurezza informatica ovviamente non mettiamo bocca su scelte di questo tipo. Quello che però facciamo è andare a capire se delle falle di sicurezza, per esempio nei sistemi direttamente o indirettamente connessi digitalmente, possono essere sfruttate da un criminale per andare a causare dei problemi di affidabilità, magari interagendo negativamente con sistemi critici alla safety del velivolo, specialmente se in quota”.

Ecco perché security e safety devono andare a braccetto. Perché ci sono circostanze in cui il venir meno di una delle due significa anche il fallimento dell’altra. E il fallimento quando stai volando a 10000 metri d’altezza non è un’opzione.

Inerzia infrastrutturale

Ogni infrastruttura è caratterizzata da un certo livello di inerzia. Una volta che il suo sviluppo viene indirizzato su un determinato binario è difficile che possa cambiare strada. Più passa il tempo, più diventa difficile invertirne la direzione di corsa: curvare la traiettoria di un sistema tecnico – tanto più se sedimentato in società complesse come le nostre – è un processo costoso, difficile, in alcuni casi impossibile. E in ogni caso, estremamente lungo. 
L’hardware non fa eccezione. Gli errori indotti nei banchi di memoria attraverso Rowhammer sono principalmente dovuti al fatto che le RAM vengono costruite con condensatori sempre più miniaturizzati e addensati l’uno accanto all’altro. Questo design è il risultato di anni di ricerche finalizzate a soddisfare le esigenze del mercato – i chip sono più piccoli, hanno una maggiore capacità di memoria e costano di meno. Introdurre di punto in bianco delle modifiche che contemplino anche la sicurezza degli utenti non è facile.

Alcune proposte di soluzione

Le prime soluzioni implementate su larga scala dall’industria – come il Target Row Refresh (TRR), una tecnologia proprietaria che avrebbe dovuto individuare e bloccare sul nascere l’esecuzione di un attacco basato su Rowhammer – si sono dimostrate insufficienti di fronte alla creatività dei ricercatori di sicurezza che hanno inventato dei tool automatizzati chiamati in gergo tecnico fuzzer (vedi 1 e 2) in grado di eluderle con facilità. Lo stesso dicasi per le funzioni di memoria predittiva alla base di Spectre e Meltdown: ogni CPU messa sul mercato dal 1995 incorpora questo tipo di funzione e, allo stato attuale, l’unica via possibile sembra essere quella di riprogettare da zero l’architettura dei processori.

Ma anche intraprendere questo percorso, estremamente impervio e faticoso, non è affatto garanzia di successo. Il ciclo di vita di un chip può variare dai 5 ai 20 anni: per quanto un team di ingegneri possa essere preparato e scrupoloso è impensabile che sia in grado di prevedere l’emersione di ogni possibile minaccia in un arco temporale così esteso. D’altra parte, dice Spencer, “solo in casi eccezionali la sicurezza viene implementata in maniera esauriente già dalle fasi di design o sviluppo. Nella maggior parte dei casi sarà comunque necessario fare tesoro dell’esperienza maturata sul campo”. Il teorico è dell’avviso che, “piuttosto che immaginare i computer come sistemi normalmente sicuri che vengono spinti all’insicurezza dalle forze di mercato, avrebbe più senso pensare ai computer come sistemi che sono normalmente insicuri”. Dal suo punto di vista, un auditing di sicurezza condotto da degli ingegneri dovrebbe essenzialmente essere in grado di rispondere a questa domanda: “Ora che abbiamo creato qualcosa che fa quello che dovrebbe fare, possiamo dimostrare che fa solo quello che dovrebbe fare?”

Far parlare le due tribù: coder e ingegneri hardware

Inoltre, la consapevolezza della necessità di dover adottare un approccio olistico per contenere le minacce derivanti dall’effetto combinato di falle hardware e falle software richiederà ancora tempo per tradursi in fatti concreti. Gli ostacoli su questo versante, spiega Barisani, sono diversi. Primo, coder software e ingegneri hardware hanno fatto parte per decenni di tribù che parlavano lingue differenti: nel migliore dei casi faticano a capirsi gli uni con gli altri e si ignorano cordialmente; nel peggiore sono invece in aperto conflitto tra loro.
“Quando appartieni ad uno di questi due mondi solitamente tendi a non essere un grande conoscitore dell’altro. E questo è un grosso limite perché spesso le falle di sicurezza nascono proprio da una interazione scorretta tra hardware e software”. Ostacolo numero due. “Avremmo bisogno di stabilire un unico modo pragmatico a cui ispirarci per costruire hardware e software in maniera sicura. E invece per motivi di posizionamento di mercato ognuno prova a reinventarsi la ruota”.

Certo, spiega l’hacker, l’idea di stabilire uno standard per fare le cose in sicurezza si scontra anche con altri significativi ostacoli, principalmente di tipo culturale. “Un’azienda solitamente privilegia un linguaggio di programmazione rispetto ad un altro: i suoi dipendenti lo adottano per crearsi un profilo professionale e, quando lo fanno, di solito non si muovono più da quell’ambito specifico”.
A questo si deve aggiungere che esistono numerosi linguaggi di programmazione: solitamente uno sviluppatore tende a privilegiarne uno a discapito dell’altro perché lo trova più affine alla sua lingua madre, al suo modo di pensare o al suo percorso educativo. Insomma, dal momento che nella stessa tribù dei coder si parlano una miriade di linguaggi differenti, stabilire un singolo insieme di procedure a cui chiunque possa far riferimento non sembra essere un obiettivo realizzabile. E, per certi versi, neppure desiderabile. Si rischierebbe di dar vita ad un processo necessariamente non inclusivo, che taglierebbe fuori dalla comunità di sicurezza moltissime persone, solo in virtù del loro background culturale.

“E in ogni caso”, aggiunge Barisani, “adottare un singolo linguaggio di programmazione non sarebbe comunque garanzia di uniformità: persone che parlano lingue diverse ma usano lo stesso linguaggio tendono comunque a programmare in maniera diversa perché pensano in modo diverso”.

Un progetto di sicurezza by design: Morello

Qualcuno però il lungo sentiero della sicurezza olistica lo ha già intrapreso. E, seppur tra mille ostacoli e difficoltà, qualche risultato comincia a vederlo. Digital Security By Design (DSbD) è un progetto nato nel 2019 che coinvolge il governo britannico, numerosi atenei d’oltre Manica e diversi stakeholders del settore privato (ARM, Microsoft e Google su tutti). L’idea alla base di DSbD – finanziato con la bellezza di 187 milioni di sterline, di cui 70 pubblici ed il restante coperto dai partner privati dell’iniziativa – è quella di andare ad alimentare un circolo di collaborazione virtuosa tra questi differenti attori con l’obiettivo di sviluppare tecnologie sperimentali che contemplino la sicurezza fin dalle primissime fasi di progettazione

Dopo tre anni di lavoro, lo scorso 20 gennaio DSbD ha presentato al pubblico una board sperimentale chiamata Morello dotata di particolari proprietà di protezione e compartimentazione della memoria. In estrema sintesi, l’idea alla base del design di Morello è quella di prevenire il maggior numero di attacchi possibili attraverso un set di istruzioni sicure direttamente incorporate nel silicio dei suoi chip. In secondo luogo, questo computer è stato progettato per far sì che se anche un attaccante dovesse essere in grado di trovare una breccia nel sistema, la sua libertà di muoversi all’interno di esso, e quindi di fare danni, sarebbe molto ridotta. Fatto importante, Morello non è solo hardware ma anche software: i suoi sviluppatori hanno creato un ambiente operativo (derivato da FreeBSD) la cui finalità è quella di agire di concerto con chip e transistor per massimizzarne le capacità di sicurezza.

Attenzione, ora come ora il valore di Morello non è di tipo commerciale, non stiamo parlando di un prodotto finito. I suoi creatori lo hanno concepito come un prototipo che è stato solo ora messo a disposizione di numerosi settori strategici dell’industria britannica (aerospazio, finanza, difesa, salute, energia ed educazione) per sottoporlo ad una verifica formale e per ampliarne il range degli usi possibili. Morello però è una piattaforma di testing in senso più lato. Gli ingegneri che lo hanno costruito sono infatti affiancati da un vasto team di sociologi, antropologi, criminologi, giuristi, economisti ed esperti di narratologia raccolti sotto la sigla DiscribeHub.

Ian Slesinger, di professione geografo critico alla Royal Holloway University di Londra, fa parte di questa folta ciurma di scienziati sociali e spiega a Guerre di Rete come il loro lavoro “sia quello di studiare quali sono i fattori sociali che potrebbero favorire o intralciare l’impiego di una tecnologia come Morello”. I loro campi di intervento sono principalmente quattro: “adozione”, ovvero l’identificazione degli elementi che possono facilitare o bloccare la diffusione di tecnologie sicure su larga scala; “regolamentazione”, ovvero il ruolo che deve svolgere la politica per favorire la produzione e l’implementazione di prodotti come Morello a livello sociale; “readiness”, per capire quale potrebbe essere l’inclinazione degli sviluppatori software a lavorare quotidianamente con una tecnologia sicura by design; e infine un’ultima area genericamente definita come “across contexts”, interessata a valutare quale potrebbe essere l’impatto dei prototipi di DSbD e come questi sarebbero percepiti in una pluralità di differenti contesti culturali.
Inoltre, spiega Slesinger, il ruolo di DSbD è quello di creare uno storytelling, una narrativa intorno a prototipi come Morello. “Spiegare il valore di questa tecnologia all’uomo della strada è un compito davvero ingrato. Ma il punto è che se nessuno si prende la briga di farlo”, dice il geografo, “Morello resterà una scatola nera, un oggetto misterioso che nessuno avrà interesse ad utilizzare. E, se così fosse, le sue proprietà di sicurezza, per quanto straordinarie, non sarebbero di alcun valore”.

La percezione pubblica di una tecnologia di sicurezza è dunque a sua volta una proprietà di sicurezza. Certo “affrontare questi temi con un pubblico vasto è sempre molto difficile, perché il significato della parola sicurezza è mutevole, influenzato da costanti trasformazioni sociali e intorno a cui non esiste un chiaro consenso”. Slesinger e i suoi colleghi provano a definire che cosa questo tipo di tecnologie debba effettivamente mettere in sicurezza, quali sono gli usi pratici che se ne possono fare nel mondo reale e chi ne potrebbe trarre vantaggio. 

Sicurezza olistica

Indipendentemente da quello che sarà il suo esito, DSbD è un’iniziativa interessante per il modo in cui è stata organizzata. Parafrasando Clemenceau si potrebbe dire che chi l’ha ideata sembra avere ben chiaro che la sicurezza è una faccenda troppo importante per essere lasciata agli hacker. O, se preferite, che gli hacker non devono essere lasciati da soli ad occuparsi di sicurezza. E lo stesso dicasi per i big player tech, indipendentemente da quanto mastodontico possa essere il loro fatturato annuale. Se l’insicurezza è un fenomeno complesso e sfaccettato – situato, come abbiamo visto, all’incrocio di una molteplicità di cortocircuiti storici, fattori culturali, fallimenti di mercato, assenza di adeguati percorsi di formazione universitaria, scarsa percezione del problema ed incapacità di declinarlo a livello pubblico – allora deve essere affrontato di conseguenza.

La convergenza tra hardware e software, safety e security è già molto, ma non basta. Oltre a mobilitare differenti competenze tecniche, è necessario democratizzare il più possibile la sicurezza, coinvolgendo nel suo processo di definizione differenti settori sociali e forme di sapere.
Morello è un esperimento che sembra andare in questa direzione. È una piattaforma di sviluppo per nuove tecnologie di sicurezza ma anche un banco di prova dove elaborare metodologie alternative per affinare l’interazione tra coder ed ingegneri. I poli universitari coinvolti (e sono molti) ricevono una pioggia di finanziamenti per realizzare un progetto ambizioso che permette loro di attrarre giovani talenti. Computer science e scienze sociali si trovano a confrontarsi e a mettere reciprocamente alla prova il loro modo di interpretare e affrontare l’instabilità delle reti.

L’industria nazionale britannica testa prodotti nuovi ed avanzatissimi integrandoli nella propria infrastruttura produttiva prima ancora che questi siano completati, trovandosi così nella posizione di poter suggerire delle modifiche da apportare quando queste non sono ancora troppo costose o inattuabili. Gli altri stakeholder privati non hanno che da guadagnare da questa golosa opportunità: nessuna compagnia, dice Slesinger, si lancerebbe mai per conto suo in un’impresa di questo tipo. Costruire da zero dell’hardware sicuro è un processo lungo – i semi di Morello sono stati gettati nel 2010, quando Cambridge ha cominciato a lavorare con SRI International, al set di istruzioni per processori CHERI – e che non garantisce alcun ritorno economico nel breve, e neppure nel medio periodo. E in ogni caso i rischi sarebbero elevatissimi: in caso di mancata adozione del prodotto finale le perdite sul piano economico sarebbero tremende.

“Per come la vedo io”, conclude Slesinger facendo ricorso ad un vocabolario tipico delle scienze sociali, “Morello rappresenta un nuovo approccio al problema della sicurezza perché è stato concepito come un boundary object” ovvero un oggetto di confine. Che significa? “Significa che ognuno dei soggetti coinvolti nel progetto guarda la board da una prospettiva differente e le attribuisce un valore diverso. Lavorare fianco a fianco aiuta le nostre differenti comunità a creare una comprensione di più ampio respiro attorno al tema della sicurezza e a creare delle intersezioni tra mondi che altrimenti sarebbero separati e difficilmente interagirebbero tra di loro”