Rendere pubblico senza perdere la firma

Un passaporto digitale del prodotto non mostra a tutti le stesse informazioni. Un’acquirente vede i dati pubblici. Un’officina di riparazione o un’azienda di ricondizionamento vede di più. Un’autorità di vigilanza sul mercato vede tutto. Questo è chiaro, e le norme europee lo stabiliscono ormai espressamente.

La domanda interessante è più sottile: se a qualcuno vengono rivelati campi protetti oltre ai dati pubblici, può dimostrare che proprio quei campi sono autentici? Oppure deve fidarsi che la piattaforma li abbia selezionati correttamente e trasmessi senza modifiche?

Per la maggior parte delle piattaforme, la risposta onesta è: fiducia. Abbiamo costruito la nostra in modo tale che la risposta sia «prova» - non solo per i campi pubblici, ma per ogni campo che viene aggiunto solo al momento della divulgazione. Perché questa differenza è importante e perché abbiamo scelto la strada più complessa.

La regola di accesso è la stessa per tutti

Lanorma EN 18239, la norma europea sui diritti di accesso, la sicurezza e la riservatezza nel DPP, richiede il controllo degli accessi per ogni singolo elemento di dati: per ogni campo esiste una regola che stabilisce chi può visualizzarlo. Si tratta del requisito corretto, e non è difficile da soddisfare. Abbiamo analizzato quale sia lo status effettivo di queste norme nella sezione norme armonizzate.

Il metodo più comune per farlo è il filtraggio lato server. Il server sa chi sta effettuando la richiesta, verifica cosa quella persona è autorizzata a vedere e restituisce esattamente quella porzione di dati. Controllo degli accessi: fatto. La norma non richiede altro.

C’è però un problema di cui la norma non si occupa: la sezione arriva senza firma. Il lettore riceve una visualizzazione creata appositamente per lui e deve fidarsi che il server abbia selezionato il contenuto in modo onesto e non abbia modificato nulla durante il trasferimento. Per una scheda informativa pubblica va bene. Per un valore su cui un gestore basa il prezzo di una batteria usata, però, è una fiducia eccessiva.

Dove una singola firma raggiunge i propri limiti

La soluzione più ovvia è firmare i dati. Per le due estremità della scala, una firma ordinaria funziona bene: firmare la vista pubblica, firmare il set di dati completo, ed entrambi vengono verificati rispetto a una chiave pubblica, senza che un server si frapponga. Come funziona nel dettaglio è spiegato in Firme e certificati nel DPP.

Il problema si presenta nel mezzo. Una firma sull’intero documento copre esattamente un insieme di campi, ovvero quelli presenti al momento della firma. Se si rende visibile a un lettore autorizzato un campo protetto in più, tale campo si trova al di fuori dell’insieme firmato e gli viene trasmesso senza copertura. Se invece si firma fin dall’inizio l’intero set di dati, la firma copre sì tutto, ma in tal caso si dovrebbe mostrare tutto a tutti.

I livelli intermedi cadono quindi fuori dal quadro: l’officina di riparazione, l’assicuratore, l’azienda di riciclaggio. Se si volesse firmare in anticipo ogni possibile combinazione di «chi vede cosa», occorrerebbe un documento firmato a sé stante per ogni combinazione, e il numero delle combinazioni aumenterebbe esponenzialmente con ogni ulteriore gruppo di accesso. Nessuno lo fa. Si ricade quindi sul filtro del server non firmato, e il livello intermedio si basa nuovamente sulla fiducia.

Firmare ogni campo singolarmente

Esiste una soluzione migliore, ed è su questa che costruiamo la piattaforma. Invece di firmare il documento finito come un unico blocco, l’emittente specifica ogni campo singolarmente in un unico ciclo di firma (per gli esperti di standard: l’attestato W3C ecdsa-sd-2023 per la divulgazione selettiva).

Ogni vista parte dal nucleo pubblico

Ogni vista inizia quindi con gli stessi campi pubblici. Ciò che un lettore vede oltre a questi viene aggiunto campo per campo, e ciascuno di questi campi riconduce comunque alla chiave pubblica dell’emittente - offline, senza necessità di una nuova firma e senza dover riporre fiducia nell’ente che ha compilato la vista. I campi per i quali non sussiste alcun diritto semplicemente mancano. Non sono oscurati, ma non ci sono affatto, e nulla trapela su di essi.

Un esempio pratico: l’officina di riparazione

Un esempio pratico illustra come ciò si traduca concretamente. Un’officina di riparazione ha dichiarato un interesse legittimo per una batteria, uno dei livelli di accesso espressamente previsti dal regolamento sulle batterie. Il suo sistema di officina si autentica presso la nostra interfaccia con la propria chiave API e recupera il pass.

La risposta è lo stesso pass pubblico che vede anche l’acquirente, arricchito di un solo campo: le istruzioni di smontaggio, che vengono rivelate solo ai lettori autorizzati. Nessun secondo documento, nessuna versione speciale, lo stesso pass con un campo in più.

Prima che l’azienda si affidi a questo campo, il suo software verifica la corrispondenza tra la documentazione fornita e la chiave pubblica dell’emittente. Se la verifica ha esito positivo, anche per quanto riguarda il campo aggiuntivo, sa con certezza che queste istruzioni provengono esattamente dal produttore e che né noi né nessun altro lungo il percorso le ha modificate. Se la verifica non va a buon fine, ne è altrettanto certo e mette da parte l’intera visualizzazione.

Il nostro contributo in questo senso è volutamente minimo. Garantire che riceva esattamente i campi a cui ha diritto rimane compito del nostro controllo degli accessi; ogni filtro del server svolge esattamente questa funzione. La novità sta nel passo successivo: è lui stesso a verificare, senza chiederci nulla, se ciò che riceve è autentico.

Perché «intatto» è il punto cruciale

Immaginiamo un notaio che non autentichi la lettera nel suo insieme, ma ogni paragrafo singolarmente. La lettera pubblica viene consegnata a tutti. Chi ha diritto a di più riceve i paragrafi aggiuntivi, e ciascuno di essi continua a recare il sigillo dello stesso notaio.

Vale la pena dedicare un’altra frase al motivo per cui in questo contesto è fondamentale che il sigillo sia «intatto ». Un sigillo intatto non garantisce che il contenuto sia vero. Significa: questo è esattamente ciò che ha scritto l’emittente e da allora nessuno ha modificato nemmeno un segno. In questo modo, chiunque abbia semplicemente trasmesso il documento - il server di cache, la rete, l’archivio, noi - viene escluso dalla questione della fiducia. Chi vi ha consegnato il passaporto non ha più alcuna importanza.

E un sigillo è binario. Regge o non regge, non esiste un sigillo «mezzo rotto». Se si rompe, non saprete quale frase è stata modificata, ma solo che non potete più fidarvi dell’intero documento. Ecco perché non è una differenza graduale se i campi aggiuntivi vi arrivano con il loro sigillo o senza: senza sigillo non sono documentati in modo leggermente meno sicuro, non sono affatto documentati.

Entrambe le modalità di visualizzazione

Chiunque può verificarlo di persona. La Transpareo Time Machine è la nostra app open source per la visualizzazione dei passaporti di prodotto: essa sfoglia la cronologia delle versioni di un pass e, nel farlo, ricalcola ogni firma nel browser dell’utente senza interrogare un nostro server. Al suo interno sono disponibili pubblicamente due pass di esempio. Il pass di una maglietta presenta una firma sull’intero documento, mentre quello di una batteria presenta la divulgazione campo per campo.

Entrambe sono specifiche aperte del W3C: eddsa-jcs-2022 per la firma sull’intero documento, ecdsa-sd-2023 per la divulgazione campo per campo. Chiunque lo desideri può implementarle. L’impegno richiesto è il motivo per cui molti non lo faranno: la firma sull’intero documento è decisamente più economica da realizzare e gestire, e chi fornisce solo dati pubblici se la cava così.

Il fatto che Time Machine supporti entrambe le procedure è intenzionale e rimarrà tale. Non appartiene a nessuna piattaforma. Un verificatore che accettasse solo il metodo più costoso sarebbe uno strumento utile solo a noi e a nessun altro.

A chi vengono divulgati i campi protetti

Vale la pena chiedersi a chi, oltre ai dati pubblici, venga effettivamente divulgato qualcosa. Non all’acquirente occasionale, che riceve il pass pubblico. Sono il trattatore che valuta il valore di un pacco batterie usato, l’assicuratore che quantifica un rischio, il riciclatore che separa le sostanze chimiche, l’autorità che istruisce un caso. Questi sono i destinatari le cui decisioni dipendono dal denaro o dalla sicurezza.

E sono proprio questi i campi che, nell’approccio tradizionale, rimangono scoperti. Chi avrebbe più motivi per volere una certificazione crittografica, non la ottiene proprio per quei campi su cui si basa la propria decisione.

Riteniamo che un marchio di certificazione debba avere lo stesso significato per tutti. «Verificato da Transpareo» ha lo stesso significato nella vista estesa di un’officina di riparazione e nel passaporto pubblico di un’acquirente: ogni settore mostrato proviene dall’emittente e da allora non è stato alterato. Un sigillo che copre solo i campi pubblici è un sigillo incompleto.

Più di quanto richieda la norma

Lo diciamo chiaramente: nulla di tutto ciò è obbligatorio. La norma EN 18239 richiede che l’accesso sia controllato, e un filtro lato server lo fa in modo impeccabile. Anche rendere i campi esposti verificabili crittograficamente è qualcosa che facciamo in più, non un requisito che la normativa ci impone.

Proprio per questo vale la pena metterlo per iscritto. Il senso stesso di un pass firmata è che nessuno debba fidarsi della piattaforma. Escludere il livello intermedio come eccezione ripristina proprio quella fiducia che la firma avrebbe dovuto eliminare.

Lo stesso principio fa sì che un campo venga ignorato

Definire ogni singolo campo comporta una seconda caratteristica, che la normativa europea richiede effettivamente. Il Regolamento generale sulla protezione dei dati conferisce alle persone il diritto di far cancellare i propri dati personali. Un record di dati firmato come un unico blocco non può soddisfare tale requisito senza distruggere la propria firma.

Poiché qui ogni campo è indipendente, è possibile rimuovere un singolo campo, mentre tutto il resto rimane verificabile. Se per errore dei dati personali finiscono in un passaporto, vengono eliminati in modo pulito e il passaporto rimane valido: nessuna riemissione, nessuna storia compromessa. I campi normativi che la legge impone di conservare rimangono intatti; ciò che è cancellabile può essere eliminato su richiesta, anche a distanza di anni.

Ciononostante, rimane un passaporto del tutto normale

Nulla di tutto ciò rende il passaporto un oggetto speciale, apribile solo dai nostri strumenti. Rimane una credenziale verificabile in JSON-LD, il formato verso cui converge il mondo degli standard web, e lo stesso formato utilizzato dal Protocollo di trasparenza delle Nazioni Unite e dal resto dell’ecosistema W3C.

Il pass che un’acquirente scansiona nel browser è quindi lo stesso oggetto che un partner della data room può leggere, e qualsiasi verificatore conforme agli standard può controllarlo, non solo i nostri. La sicurezza aggiuntiva non costa nulla al lettore e non vincola nessuno a noi.

Perché è tecnicamente difficile

Innanzitutto, per evitare fraintendimenti: non siamo stati noi a inventare questa procedura. ecdsa-sd-2023 è una specifica pubblica del W3C, la crittografia alla base non è opera nostra e chiunque voglia implementarla può documentarsi in merito. La difficoltà non sta nell’avere l’idea. La difficoltà sta nel realizzarla in modo tale che un pass sia ancora valido tra dieci anni. È qui che sta il lavoro, e su questo si può dire qualcosa di utile.

La differenza sembra piccola, ma cambia le basi: una firma ordinaria effettua i calcoli sui byte di un documento. La divulgazione selettiva opera sulle sue affermazioni. Prima della firma, il passaporto viene convertito in un formato standardizzato, in cui ogni informazione è presente come frase a sé stante. Solo così è possibile omettere una frase senza compromettere le altre.

Ciò comporta un problema che una firma a byte non presenta: la stessa forma standardizzata dovrà riemergere esattamente identica tra dieci anni. Non approssimativamente, ma carattere per carattere, altrimenti la prova non sarà più valida. Tre elementi ostacolano questo processo, e tutti e tre sono apparentemente insignificanti.

I numeri perdono il loro tipo. Se si scrive un numero come semplice JSON, lungo il percorso si perde il tipo di numero di cui si trattava. Un valore come 2.0, dopo un passaggio attraverso JSON, ritorna come 2. Per un essere umano è la stessa cosa, ma per la forma standardizzata è una frase diversa, e la verifica fallisce.

Le denominazioni non sono ancora un significato. Affinché si crei la forma standardizzata, ogni nome di campo deve risolversi in un significato univoco. Se ne manca uno, il campo scompare silenziosamente durante la conversione. Rimane quindi nel passaporto, ma la certificazione non lo copre e nessuno se ne accorge.

I significati si trovano solitamente in rete. Questa associazione è contenuta in un vocabolario che la maggior parte degli strumenti ricarica dalla rete durante la verifica. Chi agisce in questo modo fa dipendere la verificabilità del proprio pass dal fatto che un indirizzo esterno risponda ancora tra dieci anni, e per di più senza modifiche.

Come abbiamo risolto il problema

Abbiamo risolto i tre punti alla radice, invece di intercettarli in un secondo momento.

Tipi. Ogni valore viene scritto con il proprio tipo, e la pubblicazione viene interrotta non appena nella forma standardizzata compare anche un solo numero senza tipo. L’errore viene così individuato immediatamente, con il costo di una sola riga, anziché manifestarsi anni dopo come un’inspiegabile violazione della verifica.

Vocabolari. Ogni vocabolario a cui fa riferimento un pass è disponibile localmente presso di noi e non viene mai recuperato dalla rete. Un indirizzo sconosciuto comporta un’interruzione netta durante la firma, non un silenzioso ritorno a un risultato vuoto.

Identificatori. Ogni nodo nel documento porta un identificatore stabile, affinché la forma standardizzata rimanga riproducibile, invece di assegnare nuovi nomi ausiliari ad ogni ciclo.

La parte più delicata risiede nel «Bring Your Own Key». Per ogni emissione è necessaria una chiave aggiuntiva di breve durata, con la quale vengono firmati singolarmente i campi divulgabili. Questa chiave viene generata e scartata dall’emittente stesso. Se fosse in nostro possesso, potremmo inventare singoli campi a posteriori e l’indipendenza della firma dell’espositore sarebbe solo una dichiarazione. Verifichiamo la prova ricevuta confrontandola con la chiave pubblica depositata, prima di considerarla attendibile.

Ogni pass contiene due prove di questo tipo: una dell’emittente e una di Transpareo, ed entrambe vengono derivate in modo indipendente per la visualizzazione da parte di un lettore. Due firme, due autorità indipendenti l’una dall’altra, anche per un singolo campo reso pubblico.

Per noi, questo sforzo è ben ripagato. Non abbiamo aggiunto la verificabilità a posteriori; la piattaforma è stata sviluppata attorno a questo principio fin dalla prima versione. Ogni passaporto viene firmato al momento della pubblicazione e concatenato alla versione precedente. L’archivio decennale immutabile viene creato ed entra in funzione non appena i passaporti vengono registrati presso il Registro DPP dell’UE. Firmare ogni campo anziché l’intero blocco è un’estensione di questo nucleo, non un’aggiunta a qualcosa che non era mai stato concepito a tale scopo.

A che punto siamo

Abbiamo optato per la prova, a beneficio di ogni lettore, perché un sigillo dovrebbe significare una cosa sola, indipendentemente da chi lo osservi. Per chi volesse vederlo in azione: le due demo collegate più in alto si verificano direttamente nel browser, senza interrogare alcun server.