ALLEGATO I

FORMATO E GESTIONE DELLA FIDUCIA

Struttura dei dati generici, meccanismi di codifica e meccanismo di codifica di trasporto in un formato ottico leggibile meccanicamente (di seguito «Q R»)

1. Introduzione

Le specifiche tecniche di cui al presente allegato contengono una struttura dei dati generici e meccanismi di codifica per il certificato COVID digitale dell’UE (Digital COVID Certificate — «DCC»). Specificano inoltre un meccanismo di codifica di trasporto in un formato ottico leggibile meccanicamente («QR») che possa essere visualizzato sullo schermo di un dispositivo mobile o stampato. I formati contenitore dei certificati sanitari elettronici delle presenti specifiche sono generici, ma in questo contesto sono utilizzati per trasportare il DCC.

2. Terminologia

Ai fini del presente allegato, per «emittenti» si intendono le organizzazioni che utilizzano le presenti specifiche per rilasciare i certificati sanitari e per «verificatori» si intendono le organizzazioni che accettano i certificati sanitari come prova dello stato sanitario. Per «partecipanti» si intendono gli emittenti e i verificatori. Alcuni aspetti indicati nel presente allegato devono essere coordinati tra i partecipanti, come la gestione di uno spazio dei nomi e la distribuzione delle chiavi crittografiche. Si presume che una parte, in appresso denominata «segretariato», svolga tali compiti.

3. Formato contenitore dei certificati sanitari elettronici

Il formato contenitore dei certificati sanitari elettronici (Electronic Health Certificate Container Format — «HCERT») è concepito per fornire un veicolo uniforme e standardizzato per i certificati sanitari dei diversi emittenti («emittenti»). L’obiettivo delle presenti specifiche è armonizzare il modo in cui tali certificati sanitari sono rappresentati, codificati e firmati allo scopo di agevolare l’interoperabilità.

La capacità di leggere e interpretare un DCC rilasciato da qualsiasi emittente richiede una struttura comune dei dati e un accordo sul significato di ciascun campo di dati del carico utile. Per agevolare tale interoperabilità, è definita una struttura comune coordinata dei dati mediante l’uso di uno schema «JSON» che costituisce il quadro del DCC.

3.1. Struttura del carico utile

Il carico utile è strutturato e codificato come CBOR con firma digitale COSE. Questo è comunemente noto come «CBOR Web Token» (CWT) ed è definito in RFC 8392 (1). Il carico utile, quale definito nelle sezioni che seguono, è trasportato in una richiesta hcert.

L’integrità e l’autenticità dell’origine dei dati del carico utile devono essere verificabili dal verificatore. Per fornire questo meccanismo, l’emittente deve firmare il CWT utilizzando uno schema di firma elettronica asimmetrica quale definito nella specifica COSE (RFC 8152 (2)).

3.2. Richieste CWT

3.2.1. Panoramica della struttura CWT

Intestazione protetta

— Algoritmo di firma (alg, etichetta 1)

— Identificativo della chiave (kid, etichetta 4)

Carico utile

— Emittente (iss, chiave di richiesta 1, facoltativo, ISO 3166-1 alpha-2 dell’emittente)

— Momento del rilascio (iat, chiave di richiesta 6)

— Termine di scadenza (exp, chiave di richiesta 4)

— Certificato sanitario (hcert, chiave di richiesta -260)

— Certificato COVID digitale dell’UE v1 (eu_DCC_v1, chiave di richiesta 1)

Firma

3.2.2. Algoritmo di firma

Il parametro dell’algoritmo di firma (alg) indica l’algoritmo utilizzato per creare la firma. Deve rispettare o superare gli attuali orientamenti del SOGIS sintetizzati nei paragrafi seguenti.

Sono definiti un algoritmo primario e un algoritmo secondario. L’algoritmo secondario dovrebbe essere utilizzato solo se l’algoritmo primario non è accettabile nell’ambito delle norme e dei regolamenti imposti all’emittente.

Al fine di garantire la sicurezza del sistema, tutte le implementazioni devono incorporare l’algoritmo secondario. Per questo motivo, sia l’algoritmo primario che quello secondario devono essere implementati.

I livelli stabiliti dal SOGIS per gli algoritmi primari e secondari sono i seguenti.

— Algoritmo primario: l’algoritmo primario è l’algoritmo di firma digitale su curva ellittica (Elliptic Curve Digital Signature Algorithm — ECDSA) quale definito nella sezione 2.3 (ISO/IEC 14888–3:2006) utilizzando i parametri P–256 definiti nell’appendice D (D.1.2.3) di (FIPS PUB 186-4) in combinazione con l’algoritmo hash SHA–256 quale definito nella funzione 4 (ISO/IEC 10118–3:2004).

Questo corrisponde al parametro dell’algoritmo COSE ES256.

— Algoritmo secondario: l’algoritmo secondario è RSASSA-PSS quale definito in (RFC 8230 (3)) con un modulo di 2048 bit in combinazione con l’algoritmo hash SHA–256 quale definito nella funzione 4 (ISO/IEC 10118–3:2004).

Questo corrisponde al parametro dell’algoritmo COSE PS256.

3.2.3. Identificativo della chiave

La richiesta Identificativo della chiave (kid) indica il certificato di firma digitale (Document Signer Certificate — DSC) contenente la chiave pubblica che il verificatore deve utilizzare per controllare la correttezza della firma digitale. Nell’allegato IV è descritta la governance dei certificati a chiave pubblica, compresi i requisiti per i DSC.

La richiesta Identificativo della chiave (kid) è utilizzata dai verificatori per selezionare la chiave pubblica corretta da un elenco di chiavi relative all’emittente indicato nella richiesta Emittente (iss). Un emittente può utilizzare diverse chiavi in parallelo per motivi amministrativi e quando effettua i rinnovi delle chiavi. L’identificativo della chiave non è un campo critico per la sicurezza. Per questo motivo, se necessario, può anche essere collocato in un’intestazione non protetta. I verificatori devono accettare entrambe le opzioni. Se entrambe le opzioni sono presenti, deve essere utilizzato l’identificativo della chiave nell’intestazione protetta.

A causa dell’accorciamento dell’identificativo (per motivi di limitazione delle dimensioni) vi è una probabilità molto bassa, ma non inesistente, che l’elenco generale dei DSC accettati da un verificatore possa contenere DSC con kid doppi. Per questo motivo il verificatore deve controllare tutti i DSC con tale kid.

3.2.4. Emittente

La richiesta Emittente (iss) è un valore di stringa che può facoltativamente riportare il codice paese ISO 3166-1 alpha-2 del soggetto che ha rilasciato il certificato sanitario. Tale richiesta può essere utilizzata da un verificatore per individuare la serie di DSC da utilizzare per la verifica. La chiave di richiesta 1 è utilizzata per identificare questa richiesta.

3.2.5. Termine di scadenza

La richiesta Termine di scadenza (exp) deve contenere una marcatura temporale nel formato NumericDate intero (come specificato in RFC 8392 (4), sezione 2) che indichi per quanto tempo quella particolare firma sul carico utile è considerata valida e decorso il quale il verificatore deve rifiutare il carico utile come scaduto. Il parametro del termine di scadenza ha lo scopo di imporre un limite al periodo di validità del certificato sanitario. La chiave di richiesta 4 è utilizzata per identificare questa richiesta.

Il termine di scadenza non deve cadere oltre il periodo di validità del DSC.

3.2.6. Momento del rilascio

La richiesta Momento del rilascio (iat) deve contenere una marcatura temporale nel formato NumericDate intero (come specificato in RFC 8392 (5), sezione 2) indicante il momento in cui è stato creato il certificato sanitario.

Il campo Momento del rilascio non deve indicare una data anteriore al periodo di validità del DSC.

I verificatori possono applicare policy aggiuntive allo scopo di limitare la validità del certificato sanitario in base al momento del rilascio. La chiave di richiesta 6 è utilizzata per identificare questa richiesta.

3.2.7. Richiesta Certificato sanitario

La richiesta Certificato sanitario (hcert) è un oggetto JSON (RFC 7159 (6)) contenente le informazioni sullo stato sanitario. Nell’ambito della stessa richiesta possono esistere diversi tipi di certificato sanitario, tra cui il DCC.

Il formato JSON serve esclusivamente per finalità di schema. Il formato di rappresentazione è CBOR, come definito in (RFC 7049 (7)). Gli sviluppatori di applicazioni non possono in realtà mai decodificare o codificare da e verso il formato JSON, bensì utilizzano la struttura in-memory.

La chiave di richiesta da utilizzare per identificare questa richiesta è -260.

Le stringhe dell’oggetto JSON dovrebbero essere normalizzate secondo la Normalization Form Canonical Composition (NFC) definita nello standard Unicode. Le applicazioni di decodifica dovrebbero tuttavia essere permissive e solide in relazione a questi aspetti ed è fortemente incoraggiata l’accettazione di qualsiasi tipo di conversione ragionevole. Se durante la decodifica o nelle successive funzioni di confronto si riscontrano dati non normalizzati, le implementazioni dovrebbero comportarsi come se l’immissione fosse normalizzata NFC.

4. Serializzazione e creazione del carico utile DCC

Come modello di serializzazione si utilizza lo schema seguente:

Il processo inizia con l’estrazione dei dati, ad esempio da un archivio di dati sanitari (o da qualche fonte di dati esterna), e con la strutturazione dei dati estratti secondo gli schemi DCC definiti. In questo processo, la conversione nel formato di dati definito e la trasformazione per la leggibilità da parte dell’uomo possono aver luogo prima dell’inizio della serializzazione CBOR. Gli acronimi delle richieste sono in ogni caso mappati ai nomi visualizzati prima della serializzazione e dopo la deserializzazione.

Non sono consentiti contenuti di dati nazionali facoltativi nei certificati rilasciati a norma del regolamento (UE) 2021/953 (8). Il contenuto di dati è limitato agli elementi di dati definiti nella serie minima di dati specificata nell’allegato del regolamento (UE) 2021/953.

5. Codifiche di trasporto

5.1. Codifica grezza

Per le interfacce di dati arbitrari, il contenitore HCERT e i suoi carichi utili possono essere trasferiti tal quali, utilizzando qualsiasi trasporto di dati sottostante sicuro e affidabile a 8 bit. Queste interfacce possono comprendere la comunicazione di prossimità (Near-Field Communication — NFC), il Bluetooth o il trasferimento attraverso un protocollo di livello applicazione, ad esempio il trasferimento di un HCERT dall’emittente al dispositivo mobile del titolare.

Se il trasferimento dell’HCERT dall’emittente al titolare si basa su un’interfaccia di sola presentazione (ad esempio SMS, e-mail), la codifica di trasporto grezza non è ovviamente applicabile.

5.2. Codice a barre

5.2.1. Compressione del carico utile (CWT)

Per ridurre le dimensioni e migliorare la velocità e l’affidabilità nel processo di lettura dell’HCERT, il CWT è compresso utilizzando ZLIB (RFC 1950 (9)) e il meccanismo di compressione Deflate nel formato definito in RFC 1951 (10).

5.2.2. Codice a barre 2D QR

Ai fini di una migliore gestione delle apparecchiature preesistenti progettate per funzionare sui carichi utili ASCII, il CWT compresso è codificato come ASCII utilizzando Base45 prima di essere codificato in un codice a barre 2D.

Il formato QR quale definito nella norma (ISO/IEC 18004:2015) è utilizzato per la generazione di codici a barre 2D. Si raccomanda un tasso di correzione degli errori di «Q» (circa il 25 %). Poiché si utilizza Base45, il codice QR deve utilizzare la codifica alfanumerica (modalità 2, indicata dai simboli 0010).

Affinché i verificatori siano in grado di rilevare il tipo di dati codificati e di selezionare il sistema adeguato di decodifica e trattamento, i dati codificati Base45 (secondo la presente specifica) hanno come prefisso la stringa dell’identificativo di contesto «HC1:». Le versioni future della presente specifica che incidono sulla retrocompatibilità definiranno un nuovo identificativo di contesto, mentre il carattere che segue «HC» sarà tratto dalla serie di caratteri [1-9 A-Z]. L’ordine degli incrementi è definito in tale ordine, ossia prima [1-9] e successivamente [A-Z].

Si raccomanda di rendere il codice ottico sul supporto di presentazione con dimensioni della diagonale comprese tra 35 mm e 60 mm per i lettori con ottica fissa in cui i supporti di presentazione devono essere collocati sulla superficie del lettore.

Se il codice ottico è stampato su carta con stampanti a bassa risoluzione (< 300 dpi), si deve prestare attenzione a rappresentare ciascun simbolo (punto) del codice QR esattamente quadrato. Se il ridimensionamento non sarà proporzionale, alcune righe o colonne del codice QR avranno simboli rettangolari, il che in molti casi ostacolerà la leggibilità.

6. Formato dell’elenco di fiducia (elenco di CSCA e DSC)

Ciascuno Stato membro è tenuto a fornire un elenco di una o più autorità nazionali di certificazione (Country Signing Certificate Authority — CSCA) e un elenco di tutti i certificati di firma digitale (DSC) validi e a mantenere tali elenchi aggiornati.

6.1. CSCA/DSC semplificati

A partire da questa versione delle specifiche, gli Stati membri non presumono che siano utilizzate informazioni relative all’elenco dei certificati revocati (Certificate Revocation List — CRL) o che il periodo di utilizzo della chiave privata sia verificato dagli attuatori.

Il meccanismo di validità principale è invece la presenza del certificato nella versione più recente dell’elenco dei certificati.

6.2. Infrastruttura a chiave pubblica eMRTD conforme ICAO e centri protezione

Gli Stati membri possono ricorrere a una CSCA distinta, ma possono anche presentare i loro certificati CSCA e/o DSC eMRTD esistenti; inoltre possono anche scegliere di procurarseli presso centri protezione (commerciali) e di presentare questi ultimi. Tuttavia qualsiasi DSC deve sempre essere firmato dalla CSCA presentata da tale Stato membro.

7. Considerazioni in materia di sicurezza

Nel progettare uno schema basato su questa specifica, gli Stati membri individuano, analizzano e monitorano taluni aspetti legati alla sicurezza.

Dovrebbero essere presi in considerazione almeno gli aspetti seguenti.

7.1. Periodo di validità della firma HCERT

L’emittente degli HCERT è tenuto a limitare il periodo di validità della firma specificando un termine di scadenza. Ciò impone al titolare di un certificato sanitario di rinnovarlo periodicamente.

Il periodo di validità accettabile può essere determinato da vincoli pratici. Ad esempio, un viaggiatore potrebbe non avere la possibilità di rinnovare il certificato sanitario durante un viaggio all’estero. Tuttavia può anche accadere che un emittente stia valutando la possibilità di una qualche forma di compromissione della sicurezza che gli impone di ritirare un DSC (invalidando tutti i certificati sanitari rilasciati utilizzando tale chiave ancora entro il loro periodo di validità). Le conseguenze di un tale evento possono essere limitate effettuando una regolare rotazione delle chiavi emittente e richiedendo il rinnovo di tutti i certificati sanitari a intervalli ragionevoli.

7.2. Gestione delle chiavi

Questa specifica si basa in larga misura su solidi meccanismi crittografici che garantiscono l’integrità dei dati e l’autenticazione dell’origine dei dati. È pertanto necessario mantenere la riservatezza delle chiavi private.

La riservatezza delle chiavi crittografiche può essere compromessa in vari modi, ad esempio:

— il processo di generazione delle chiavi può essere viziato, con conseguente debolezza delle chiavi;

— le chiavi possono essere rivelate per errore umano;

— le chiavi possono essere rubate da soggetti esterni o interni;

— le chiavi possono essere calcolate mediante crittoanalisi.

Al fine di mitigare i rischi che l’algoritmo di firma sia debole e consenta di compromettere le chiavi private mediante crittoanalisi, questa specifica raccomanda a tutti i partecipanti di implementare un algoritmo di firma secondario di riserva, basato su parametri diversi o su un problema matematico diverso da quello primario.

Per quanto riguarda i rischi menzionati relativi agli ambienti operativi degli emittenti, sono attuate misure di mitigazione per garantire un controllo efficace, in modo da generare, memorizzare e utilizzare le chiavi private nei moduli di sicurezza hardware (Hardware Security Model — HSM). L’uso di HSM per la firma dei certificati sanitari è fortemente incoraggiato.

Indipendentemente dal fatto che un emittente decida di utilizzare gli HSM o no, è opportuno stabilire un calendario dei rinnovi delle chiavi la cui frequenza sia proporzionata all’esposizione delle chiavi a reti esterne, altri sistemi e personale. Un calendario dei rinnovi ben scelto limita inoltre i rischi associati ai certificati sanitari rilasciati erroneamente, consentendo all’emittente di revocare tali certificati in lotti, ritirando una chiave, se necessario.

7.3. Convalida dei dati immessi

Queste specifiche possono essere utilizzate in modo da implicare il ricevimento di dati da fonti non fidate in sistemi che possono essere di natura critica. Per ridurre al minimo i rischi associati a questo vettore di attacco, tutti i campi di immissione devono essere debitamente convalidati in termini di tipi di dati, lunghezze e contenuto. Prima di qualsiasi trattamento del contenuto dell’HCERT è verificata anche la firma dell’emittente. Tuttavia la convalida della firma dell’emittente implica innanzitutto l’analisi dell’intestazione protetta dell’emittente, nella quale un potenziale aggressore potrebbe tentare di iniettare informazioni accuratamente preparate per compromettere la sicurezza del sistema.

8. Gestione della fiducia

La firma dell’HCERT richiede una chiave pubblica da verificare. Gli Stati membri mettono a disposizione tali chiavi pubbliche. In ultima analisi, ogni verificatore deve disporre di un elenco di tutte le chiavi pubbliche di cui intende fidarsi (dato che la chiave pubblica non fa parte dell’HCERT).

Il sistema è costituito (solo) da due livelli; per ciascuno Stato membro, uno o più certificati di livello nazionale che firmano ognuno uno o più certificati di firma digitale utilizzati nelle operazioni quotidiane.

I certificati degli Stati membri sono denominati certificati dell’autorità nazionale di certificazione (CSCA) e sono (di norma) autofirmati. Gli Stati membri possono averne più di una (ad esempio, in caso di decentramento regionale). Questi certificati CSCA firmano regolarmente i certificati di firma digitale (DSC) utilizzati per firmare gli HCERT.

Il «segretariato» svolge un ruolo funzionale. Esso aggrega e pubblica periodicamente i DSC degli Stati membri, dopo averli verificati sulla base dell’elenco dei certificati CSCA (che sono stati trasmessi e verificati con altri mezzi).

L’elenco risultante dei DSC fornisce quindi la serie aggregata di chiavi pubbliche accettabili (e i relativi identificativi) che i verificatori possono utilizzare per convalidare le firme sugli HCERT. I verificatori devono estrarre e aggiornare regolarmente questo elenco.

Tali elenchi specifici degli Stati membri possono essere adattati nel formato per il proprio contesto nazionale. Pertanto il formato di file di questo elenco di fiducia può variare; ad esempio può trattarsi di un formato JWKS firmato (formato JWK Set per RFC 7517 (11), sezione 5) o di qualsiasi altro formato specifico per la tecnologia utilizzata in tale Stato membro.

Al fine di garantire la semplicità, gli Stati membri possono presentare i loro certificati CSCA esistenti generati dai rispettivi sistemi eMRTD conformi ICAO o, come raccomandato dall’OMS, crearne uno specifico per questo settore sanitario.

8.1. Identificativo della chiave (kid)

L’identificativo della chiave (kid) è calcolato quando si costruisce l’elenco delle chiavi pubbliche fidate dei DSC ed è costituito da un’impronta digitale SHA-256 troncata (primi 8 byte) del DSC codificato nel formato (grezzo) DER.

I verificatori non sono tenuti a calcolare l’identificativo della chiave sulla base del DSC e possono far collimare direttamente l’identificativo della chiave nel certificato sanitario rilasciato con quello figurante nell’elenco di fiducia.

8.2. Differenze rispetto al modello di fiducia dell’infrastruttura a chiave pubblica eMRTD conforme ICAO

Nonostante la modellizzazione sulle migliori pratiche del modello di fiducia dell’infrastruttura a chiave pubblica (Public Key Infrastructure — PKI) eMRTD conforme ICAO, è necessario introdurre una serie di semplificazioni nell’interesse della velocità:

— uno Stato membro può presentare più certificati CSCA;

— il periodo di validità del DSC (utilizzo della chiave) può essere fissato a una durata non superiore a quella del certificato CSCA e può essere assente;

— il DSC può contenere identificativi di policy (utilizzo esteso della chiave) specifici dei certificati sanitari;

— gli Stati membri possono scegliere di non effettuare mai alcuna verifica delle revoche pubblicate e di affidarsi esclusivamente agli elenchi di DSC che ricevono quotidianamente dal segretariato o che compilano essi stessi.

(1) rfc8392 (ietf.org).

(2) rfc8152 (ietf.org).

(3) rfc8230 (ietf.org).

(4) rfc8392 (ietf.org).

(5) rfc8392 (ietf.org).

(6) rfc7159 (ietf.org).

(7) rfc7049 (ietf.org).

(8) Regolamento (UE) 2021/953 del Parlamento europeo e del Consiglio, del 14 giugno 2021, su un quadro per il rilascio, la verifica e l’accettazione di certificati interoperabili di vaccinazione, di test e di guarigione in relazione alla COVID-19 (certificato COVID digitale dell’UE) per agevolare la libera circolazione delle persone durante la pandemia di COVID-19 (GU L 211 del 15.6.2021, pag. 1).

(9) rfc1950 (ietf.org).

(10) rfc1951 (ietf.org).

(11) rfc7517 (ietf.org).