Emerge da un’analisi tecnica del green pass che – a differenza di quanto dice la norma italiana – non è possibile effettivamente revocarlo in caso di positività covid del detentore. Pasticcio all’italiana, come scrivono alcuni giornali? La faccenda è un po’ più complicata di così.
Il green pass è senza database centrale
Alla base, bisogna sapere alcuni punti:
- data la vastità del territorio su cui si applicano le disposizioni;
- e per validissime ragioni di protezione dei dati personali,
- si è scelto che il sistema di verifica dei certificati verdi digitale, “green pass”, debba funzionare senza un database centrale e in modo completamente scollegato dalla rete.
Questo è il punto fondamentale. Questo requisito implica quasi tutte le scelte tecniche in merito alla struttura del certificato, alla sua implementazione sia lato “utente” che lato “infrastruttura”.
La Commissione Europea ha ritenuto che questo fosse un punto fondamentale, e tale requisito ha condizionato, nel bene e nel male, lo sviluppo e i limiti dello strumento.
Il sistema di firma digitale
L’assenza di uno o più database ha imposto un meccanismo di firma digitale basato su crittografia asimmetrica a chiave pubblica per verificare l’autenticità dei singoli certificati.
Il certificato all’atto dell’emissione, viene pertanto firmato digitalmente con la chiave segreta dell’emittente; ciascuno stato gestisce una o più chiavi private con le quali autentica l’emissione del certificato.
All’atto di verifica, il verificatore può, utilizzando la chiave pubblica dell’emittente, verificare la corrispondenza della firma e del contenuto del certificato
Basandosi sull’algoritmo RSA[4], la validità e la robustezza del sistema è, in sé, fuori di dubbio.
Il meccanismo di revoca
Siccome con tale sistema una volta emesso un certificato non è più possibile annullarlo, è di solito previsto un meccanismo di revoca. L’autorità emittente pubblica una lista di certificati (o di firme) che sono da considerarsi invalidati. Tali liste sono chiamate Certificate Revocation List (CRL) e il sistema nel suo complesso funziona come per i passaporti della “vita reale”: una volta emessi, possono solo essere annullati tramite una lista distribuita a tutti gli uffici, lista che elenca i numeri di passaporto non più validi.
La revoca può avvenire sia sui singoli certificati, sia sulle chiavi pubbliche degli enti emittenti, qualora per esempio una chiave di firma sia stata utilizzata fraudolentemente o sia stata violata.
All’interno il certificato riporta una serie di dati personali e sanitari: oltre al nome, cognome, data di nascita, nazionalità del titolare, sono riportati alcuni blocchi di dati aggiuntivi, diversi a seconda che il certificato sia rilasciato per vaccinazione, guarigione o tampone. Nel primo caso, tipo di vaccino, numero di dose e numero totale di dosi previste, data di vaccinazione; nel secondo, data di avvenuta guarigione; nel terzo, data e tipo di tampone.
In coda al certificato è assegnato un ID univoco del singolo certificato e la durata del certificato.
Tutti questi dati sono riportati in chiaro sul modello PDF scaricabile in Italia dal sito del ministero della salute, ma sono anche codificati, in chiaro, nel famigerato QR-Code.
Il QR Code può essere validato attraverso l’applicazione per dispositivi mobili “VerificaC19” del ministero della salute, le cui specifiche sono definite dalle linee guida della rete eHealth e i cui sorgenti sono liberamente scaricabili da GitHub[5].
L’appropriatezza del green pass all’italiana
Il cosiddetto “Green Pass” è la declinazione italiana del “Digital Green Pass” europeo, strumento nato per permettere lo spostamento delle persone tra i diversi stati europei i quali applicano regole sanitarie diverse a seconda dello stato di salute, di vaccinazione o dei risultati dei tamponi diagnostici.
Quando facciamo valutazioni sull’appropriatezza dello strumento sia tecnico che normativo, è necessario tenere a mente principalmente questo: esso è uno strumento europeo che è nato per una ragione di mobilità e che deve venire incontro a situazioni normative diverse. Lo strumento si innesta nella più grande rete sanitaria europea denominata eHealth.
Pertanto le principali fonti tecnico normative sono: il regolamento europeo di istituzione del DGC (regolamento EU 2021/953)[1], le linee guida eHealth per l’implementazione dei certificati (“Technical Specifications for Digital Green Certificates”, attualmente alla versione 1.0.5 del 21 aprile 2021)[2] e per la parte specificatamente italiana, il d.l. 52/2021, attuato con Dpcm 17.6.2021[3].
Presunti dubbi sulla privacy
Molti hanno sollevato un sopracciglio nell’apprendere che tutti questi dati sono visualizzabili in chiaro, sebbene la app ufficiale, seguendo le linee guida eHealth, eviti la loro visualizzazione. Alcuni si sono spinti a definire tale questione “Security by Obscurity[6]”, forse dimenticando per un attimo di guardare alla “big picture”, ossia al contesto generale in cui è applicato tale strumento. In questo caso non è la “security” ad essere minacciata, la non-confidenzialità del dato è, come vedremo, un requisito per il funzionamento del sistema.
Alcuni si sono spinti fino a proporre un pass di tipo “si/no”, che a parte le informazioni personali necessarie alla verifica dell’identità del portatore, non esponesse alcun altro dato (essendo di per sé l’esistenza del certificato già una informazione di natura positiva al fine del permesso).
La cosa funzionerebbe se in tutto il territorio vi fossero regole comuni riguardo la durata della validità del certificato nei vari casi (vaccinazione, negatività al tampone), e se tali regole non fossero passibili di revisioni future, magari alla luce di nuove evidenze scientifiche o empiriche.
Ma la commissione ha ritenuto di sacrificare questa piccola fettina di privacy per la flessibilità dello strumento, permettendo dunque di poter applicare regole diverse in territori diversi e in tempi diversi.
E, diversamente da quanto ipotizzato da alcuni, la crittografia sarebbe stata completamente inutile, sia essa simmetrica o asimmetrica, in quanto le chiavi di decrittazione devono essere liberamente disponibili.
I veri nodi della privacy e la CRL (revoca certificati)
Esistono invece alcuni “reali” nodi relativi alla privacy. E uno[7] di questi, ahimè, è assai importante e solleva un problema di cui il legislatore pare non aver tenuto conto.
Il problema nasce dal regolamento europeo che prevede espressamente una Certificate Revocation List (CRL) per le firme e per i singoli certificati. Il considerando (19) recita: “Per motivi medici e di salute pubblica e in caso di certificati rilasciati o ottenuti fraudolentemente, è opportuno che gli Stati membri possano stilare e scambiare con altri Stati membri, ai fini del presente regolamento, elenchi di revoca dei certificati per casi limitati, in particolare per revocare i certificati rilasciati erroneamente, come conseguenza di una frode o a seguito della sospensione di una partita di vaccino anti COVID-19 risultata difettosa.”
Il DPCM recepisce questo punto: L’allegato B[8] sezione 2 recita infatti: “Le certificazioni verdi Covid-19 possono essere revocate mediante l’inserimento del codice univoco della certificazione verde all’interno di liste di revoca. (…) La lista di revoca è oggetto di scambio con gli altri Stati membri, tramite le modalità sotto descritte…”
Ma c’è un problema. Il regolamento eHealth al punto 6.1 recita: “It is anticipated that health certificates can not be reliably revoked once issued, especially not if this specification would be used on a global scale. Publishing of recovation information containing identifiers may also create privacy concerns, as this information is per definition Personally Identifiable Information (PII). For these reasons, this specification requires the Issuer of HCERTs to limit the validity period of the signature by specifying a signature expiry time. This requires the holder of a health certificate to renew it at periodic intervals.”
Ovvero: siccome l’identificativo del Certificato è unico, e il certificato è nominativo, l’identificativo diventa esso stesso un PII, ossia un’informazione atta a identificare una persona, ergo, non è possibile pubblicarla in liste di consultazione come una CRL.
La situazione in VerificaC19
Attualmente le CRL non sono implementate nel sistema DGC italiano né a livello di app, né a livello di infrastruttura.
A livello di infrastruttura infatti non sono presenti nel Gateway alcuna API o servizio in grado di scambiare o fornire liste di revoca; è possibile infatti verificare sia che il client al DGC Gateway[9] ha solo servizi per l’interscambio delle trust list, ossia delle chiavi pubbliche dei certificatori; sia che il DGC Verifier Service[10], ossia il servizio che fornisce dati alla app, espone soltanto degli endpoint per lo scambio delle regole e delle trust list.
A livello di app, analogamente, il client[11] accede soltanto ai tre stessi endpoint.
Evidentemente, non essendoci un canale per scaricare la lista di revoca, non c’è la possibilità di confrontarla con il certificato in fase di verifica. E infatti tale controllo manca.
E’ dunque evidente che sebbene la normativa italiana imponga la revoca dei certificati in certe situazioni, essa non sia al momento attuabile.
Conclusioni
Il pasticcio è piuttosto grande.
- Da una parte, l’Europa e l’Italia suggeriscono, come naturale, l’implementazione di certificati di revoca.
- Dall’altra, le linee guida e la protezione dei dati personali imporrebbero di evitare il loro uso; il buon senso fa pensare ancora che la revoca per positività sia una forzatura, lo stato di vaccinazione avvenuta o di guarigione non viene cancellato dalla reinfezione.
Del resto il nostro legislatore si è bloccato in un angolo emettendo dei certificati di durata lunghissima che pertanto non possono essere in alcun modo revocati, neppure con la “scappatoia” indicata dalle linee guida.
La ratio di questa scelta è palese, in quanto l’uso del DGC italiano è prettamente interno mentre, invece, in origine il DGC è stato pensato per gli spostamenti tra stati. L’uso interno impone un rinnovo frequente degli eventuali certificati in scadenza, cosa che caricherebbe sia le infrastrutture sia gli utenti stessi che spesso si affidano a terzi (farmacie, MMG) per la stampa del certificato.
E dunque? Salvo pressioni dall’Europa, avrebbe senso tenere il sistema così com’è. L’eventualità di revoca dei singoli certificati è bassa se si elimina la necessità di revocarlo a seguito di infezione, che forse ha poco senso; in caso di “lotti difettosi” paventato nel documento della Commissione, sarebbe sufficiente revocare i codici dei lotti stessi. Mentre in caso di falsificazione, si dovrà revocare la chiave pubblica ed emettere nuovi certificati per quelli validi ma invalidati.
Noi intanto restiamo con l’amarezza di appurare ancora che chi decide come si fanno le cose non si pone il problema di come poi implementarle.
Note
[1] https://eur-lex.europa.eu/legal-content/IT/TXT/PDF/?uri=CELEX:32021R0953&from=IT
[2] https://ec.europa.eu/health/sites/default/files/ehealth/docs/digital-green-certificates_v1_en.pdf
[3] https://www.gazzettaufficiale.it/atto/serie_generale/caricaDettaglioAtto/originario?atto.dataPubblicazioneGazzetta=2021-06-17&atto.codiceRedazionale=21A03739&elenco30giorni=false
[4] https://it.wikipedia.org/wiki/RSA_(crittografia)
[5] https://github.com/ministero-salute
[6] https://it.wikipedia.org/wiki/Sicurezza_tramite_segretezza
[7] Non è l’unico nodo da sbrogliare. La maggior parte deriva dalla peculiarità delle regole italiane, per le quali, per esempio, in caso di vaccinazione parziale il DGC diviene valido solo trascorsi un certo numero di giorni dalla data di prima inoculazione. Questo dato di per sé comportando un diverso trattamento, implica la possibilità di dedurre un dato sanitario. La valutazione in termini di privacy di questo caso è tutta da studiare.
[8] https://www.governo.it/sites/governo.it/files/Green_Pass_all_B.pdf
[9] https://github.com/ministero-salute/it-dgc-gateway-client
[10] https://github.com/ministero-salute/it-dgc-verifier-service
[11] https://github.com/ministero-salute/it-dgc-verificaC19-android/blob/develop/app/src/main/java/it/ministerodellasalute/verificaC19/data/remote/ApiService.kt
