Dieselgate, una questione di software (chiuso)

di a cura di Carlo Piana - 25 settembre 2015

Non si parla d’altro in questi giorni. Per chi è tornato da un mese di meditazione di clausura in Tibet, VolksWagen ha ammesso di aver truccato propri motori diesel per far finta di rispettare le severe norme anti-inquinamento Usa e superare fraudolentemente i test di omologazione. Ne parlo su queste colonne perché il tema è strettamente collegato con il diritto applicato alle nuove tecnologie, in particolare al software.

 

SOFTWARE NEL MOTORE?

Un motore endotermico è una macchina tutto sommato semplice. Entra una miscela aria-carburante, viene compressa, avviene un’espansione che trasforma per combustione l’energia chimica potenziale in energia cinetica, i gas combusti vengono espulsi. Le innovazioni nel motore a ciclo diesel sono state tutto sommato contenute da un secolo a oggi (se si escludono le soluzioni ibride).

Il motore diesel è estremamente inquinante per alcune frazioni di emissioni. In questi anni si è preteso che le emissioni di anidride carbonica e particolato (oltre ad altri inquinanti) venissero ridotte drasticamente, e questo è stato fatto anche migliorando la qualità dei carburanti e l’efficienza in tal senso dei motori diesel. Il tutto fondamentalmente con tre elementi: la marmitta catalitica, il filtro antiparticolato e l’iniezione elettronica. Il sistema, in sé estremamente semplice, è diventato estremamente complicato, perché i tre sistemi devono per forza lavorare assieme.

Tenere assieme il puzzle perché tutto funzioni bene è piuttosto difficile. Occorre raffinare le mappature del motore perché in tutte le condizioni esso funzioni come sperato, senza sacrificare troppo i consumi e le prestazioni. Per forza di cose non si punta però a creare il motore “più perfetto possibile”, ma quello che risponde meglio ai test. Se i test sono fatti bene, rispecchiando un modello sufficientemente realistico di un uso medio, le due cose tendono ad avvicinarsi.

La complessità e la necessità di adattarsi in modo sempre più “granulare” alle varie condizioni, operando secondo modelli sempre più raffinati, fa sì che occorra usare componenti software per adattare, con una frequenza molto elevata, il comportamento del motore ai modelli teorici. La stessa cosa avviene anche con i dispositivi di frenata assistita e anti-bloccaggio. Avviene anche per i dispositivi assistiti di parcheggio e anti-collisione. Insomma, il software in parte guida la nostra auto.

 

SOFTWARE SEGRETO, NON ISPEZIONABILE. QUI INIZIA IL PROBLEMA

Il software che viene montato a bordo delle auto è dunque molto intelligente. Forse anche troppo. Come detto, si cerca più di adattarsi ai test, che avvicinarsi a realizzare il motore ideale. Come fanno molti studenti universitari, la tentazione è elevata di passare dallo studiare per conoscere la materia a studiare solo in funzione dei test, e poi a studiare direttamente i test invece della materia. Siccome i parametri in ingresso sono molti, è stato relativamente facile programmare il software per accertare di essere in una particolare condizione di utilizzo: “sono in presenza di un test in laboratorio”. Da quanto si sa, in quella condizione il software è stato addestrato a modificare i parametri di utilizzo per rispettare i parametri, anche quando tali parametri non erano nemmeno avvicinati in condizioni di utilizzo reale. Un po’ come avere un farmaco che riduce l’ematocrito di un atleta di fondo solo quando viene introdotto un ago in vena e lo rialza quando l’ago viene tolto.

A questo punto uno si domanda: ma come speravano di farla franca, non c’è nessuno che sa leggere il software e capire che le istruzioni sono fatte per barare? Ovviamente sì. Peccato che sia, in larga parte, vietato.

Il software è protetto non solo dal copyright (non può essere copiato, modificato, eseguito senza il permesso del titolare), ma da alcune disposizioni che ne tutelano il segreto. Infatti, il codice oggetto (anche detto codice binario) non può essere decompilato se non in presenza di alcune stringenti condizioni, e solo per conseguire l’interoperabilità (in Italia, il riferimento normativo è l’art. 64-quater Legge sul diritto d’autore, che implementa l’art. 6 della Direttiva software).

Inoltre, è proibito detenere, produrre, distribuire, offrire servizi che abbiano come unico scopo quello di rimuovere le protezioni del software apposte dal titolare dei diritti (in Italia, art. 171-bis Lda). Per cui, se anche ho in teoria il diritto di modificare il software per correggere gli errori, in presenza di un dispositivo di protezione che non mi consente di installare la versione corretta senza aggirare o corrompere la protezione che me lo impedisce, del mio diritto me ne faccio ben poco. È sufficiente che l’hardware pretenda che il software venga “firmato” con una chiave segreta, rifiutandosi di eseguirlo altrimenti.  Questo principio è stato battezzato “TiVoization” (vedi per esempio definizione su Wikipedia).

Tale attività non è però vietata a organi ispettivi per finalità di accertamento di frodi. Peccato che non sia nei loro compiti effettuarlo. E comunque non vi sono norme (ancora) che impongano ai produttori di auto di rendere disponibile alle autorità il codice sorgente e il “toolchain” (cioè tutta la catena di componenti necessaria a ricreare un eseguibile funzionante). Senza codice sorgente e toolchain, rimane solo la decompilazione, che è procedimento molto inefficiente e difficile, soprattutto nei sistemi “embedded”. Tali controlli e la relativa messa a disposizione delle informazioni sono imposti invece – a quanto mi viene riferito – in campo aeronautico e in parte in quello farmaceutico.

Mentre ci sono altri soggetti che avrebbero le capacità e l’interesse a effettuare questi controlli in modo indipendente, ovvero enti autonomi di ricerca, associazioni di consumatori, privati cittadini hacker. Ma non lo possono fare perché se lo facessero si troverebbero subito una causa molto dispendiosa con i produttori. È successo in passato, piuttosto famoso il caso di Oyster Card (vedi l’ottimo articolo di Bruce Schneier). Con anche la minaccia di un’azione penale. Un rischio troppo elevato.

Mancando la seria possibilità di essere sottoposti a sanzioni a seguito di verifiche di routine e mancando la pressione dei “controinteressati”, il gioco è sbilanciato verso l’elusione delle regole.

 

LA SOLUZIONE È IL CONTROLLO DIFFUSO

Nel caso di VolksWagen l’inghippo non proviene da un whistleblower, non proviene da un controllo più zelante del solito, proviene proprio da un ente autonomo incaricato di vagliare alcuni sospetti iniziali. I tecnici dell’ente non hanno potuto osservare il codice e testarlo. Hanno creato un marchingegno che ripropone ciò che i test dovrebbero simulare, ma con un veicolo in marcia effettiva. Hanno fatto sull’auto quello che si chiama “studio osservazionale”. Anche nel software ciò è permesso senza limite a chi ha il diritto di utilizzare la copia osservata (art. 64-ter Lda), ottenendo informazioni che possono consentire addirittura di creare un “clone funzionale” del software osservato (vedi il caso Sas Institute v. World Programming Software, caso C-406/10). E hanno scoperto che nel mondo reale i risultati erano talmente difformi da far sospettare che non fosse un caso, ma un risultato voluto. Hanno perciò scoperto “dal di fuori” quale fosse il vero funzionamento del software.

L’accertamento compiuto è macchinoso, e ovviamente adatto a misurare difformità grossolane tra il comportamento atteso e il comportamento osservato. Ovviamente non è una soluzione per difformità più microscopiche, ma non meno importanti, come per esempio una vulnerabilità che consenta – come è stato recentemente dimostrato – di intervenire direttamente dall’esterno (via wireless, addirittura) su parametri del motore, dei freni, dell’acceleratore, dello sterzo e, con alcuni modelli di auto, uccidere potenzialmente qualcuno. Queste vulnerabilità sono scopribili, con molta perizia, solo osservando come il software è stato realizzato, e ciò sarebbe possibile solo con la disponibilità del codice sorgente.

Non solo: per avere una “pressione” dall’esterno è necessario che chiunque possa verificare che il codice sorgente così come configurato dal produttore e il software installato siano identici: occorre perciò poter ricreare una copia identica del software installato ricostruendo l’identico percorso seguito dal produttore. Il che è nient’altro come il metodo scientifico opera.

 

LA SOLUZIONE È “OPEN SOURCE”

Il passo logico conclusivo è che il software a cui ci affidiamo per la salute e la sicurezza dovrebbe essere open source; a tutti dovrebbe essere dato il permesso di studiarlo e verificare che fa quello che dice, installandolo al posto di quello ufficiale. E ciò vale per tutto, non solo per le auto: dai dispositivi di voto agli apparati elettromedicali, a tutto ciò che va sotto il nome “Internet of Things”.

L’obiezione contraria è fallace e drammaticamente smentita dai fatti. Si dice (Epa per prima) se si consentisse ciò, tutto sarebbe insicuro, la gente si metterebbe a modificare il software della macchina per farla andare più veloce e consumare di più. Come se ciò non fosse già possibile in altro modo… E il fatto di ritenere che la sicurezza si abbia solo con il segreto è un principio totalmente smentito da ogni teoria scientifica sulla sicurezza. Anzi, è vero il contrario: la sicurezza si ha solo se le insicurezze possono essere testate da molti, e non solo dai maleintenzionati.

Resta il legittimo interesse a che sostanziali investimenti non vengano messi a disposizione di altri “free rider”: progettare e gestire una centralina da competizione è uno dei costi maggiori per un team di motoGP, per esempio. Ma sono casi tutto sommato limite e le eccezioni possono essere gestite meglio di un sistema destinato a essere abusato per l’inefficienza dei giochi che le regole creano.

 

Carlo Piana

@carlopiana

 

- - - - - - -

Articolo sotto licenza Creative Commons Attribuzione – Condividi allo stesso modo 4.0


1 Commenti :

Inviato da Marco Ciampa il 27 settembre 2015 alle 13:19

Al solito Carlo si dimostra brillante nell'ennesimo "il re è nudo", scoprendo con l'esempio di questo ennesimo caso, come il software chiuso sia una vera anomalia di cui tutti dovremo renderci conto per la nostra sicurezza.

Commento

Captcha

A CURA DI CARLO PIANA

/media/5648275/piana.png
DIRITTO NUOVE TECNOLOGIE
Account twitter Account LinkedIn Feed RSS

Rubrica in collaborazione con Simone Aliprandi e Alberto Pianon di Array Avvocato esperto di diritto delle nuove tecnologie, si occupa di tutela del software, informatica nei servizi pubblici, antitrust, marchi e nomi a dominio e molto altro.

Noto per l'impegno per il software libero e le libertà digitali, è editor della International Free and Open Source Software Law Review. Nel 2008 ha fondato Array, network di legali specializzati in ICT law - http://arraylaw.eu

Impresa
Se le leggi offrono poca ospitalità alla sharing economy: i problemi sollevati da AirBnB
30 novembre 2016

Grane legali per Facebook. Quando i social media diventano veicolo di contenuti illeciti
17 novembre 2016

"Secondary ticketing” o bagarinaggio 2.0?
3 novembre 2016

ARCHIVIO