ANEXA I

FORMATUL ȘI GESTIONAREA CADRULUI DE ÎNCREDERE

Structura datelor generice, mecanismele de codare și mecanismul de codare pentru transport într-un format optic care poate fi citit automat (denumit în continuare „QR”)

1. Introducere

Specificațiile tehnice stabilite în prezenta anexă conțin o structură a datelor generice și mecanisme de codare pentru certificatul digital al UE privind COVID („DCC”). Acestea specifică, de asemenea, un mecanism de codare pentru transport într-un format optic care poate fi citit automat („QR”) și care poate fi afișat pe ecranul unui dispozitiv mobil sau imprimat. Formatele container ale certificatului de sănătate electronic aferente specificațiilor menționate sunt generice, dar, în acest context, sunt utilizate pentru a purta DCC.

2. Terminologie

În sensul prezentei anexe, „emitenți” înseamnă organismele care utilizează aceste specificații pentru emiterea certificatelor de sănătate și „verificatori” înseamnă organismele care acceptă certificatele de sănătate ca dovadă a stării de sănătate. „Participanți” înseamnă emitenții și verificatorii. Unele aspecte prevăzute în prezenta anexă, cum ar fi gestionarea unui spațiu de nume și distribuirea cheilor de criptare, trebuie să facă obiectul coordonării între participanți. Se presupune că una dintre părți, denumită în continuare „secretariatul”, îndeplinește aceste sarcini.

3. Formatul container al certificatului de sănătate electronic

Formatul container al certificatului de sănătate electronic (Electronic Health Certificate Container Format – HCERT) este conceput pentru a asigura un vehicul uniform și standardizat pentru certificatele de sănătate eliberate de diferiți emitenți („emitenții”). Obiectivul prezentelor specificații este de a armoniza modul în care certificatele de sănătate sunt reprezentate, codate și semnate, cu scopul de a facilita interoperabilitatea.

Capacitatea de a citi și interpreta un DCC, indiferent care este emitentul său, necesită o structură de date comună și ajungerea la un acord cu privire la semnificația fiecărui câmp de date al sarcinii utile. Pentru a facilita o astfel de interoperabilitate, se definește o structură de date comună coordonată, prin utilizarea unei scheme JSON (JavaScript Object Notation – notarea obiectelor în JavaScript), care constituie cadrul DCC.

3.1. Structura sarcinii utile

Sarcina utilă este structurată și codată sub formă de CBOR (Concise Binary Object Representation – reprezentarea concisă a obiectelor binare), cu o semnătură digitală în formatul COSE (CBOR Object Signing and Encryption – semnarea și criptarea de obiecte utilizând CBOR). Aceasta este cunoscută sub denumirea de „token web CBOR” (CWT) și este definită în RFC 8392 (1). Sarcina utilă, astfel cum este definită în secțiunile următoare, este transportată într-o revendicare hcert.

Integritatea și autenticitatea originii datelor privind sarcina utilă trebuie să poată fi verificate de verificator. Pentru a furniza acest mecanism, emitentul trebuie să semneze CWT utilizând un sistem asimetric de semnătură electronică, astfel cum este definit în specificația privind COSE (RFC 8152 (2)).

3.2. Revendicări CWT

3.2.1. Prezentare generală a structurii CWT

Antet protejat

— Algoritmul de semnătură (alg, eticheta 1)

— Identificatorul cheii (kid, eticheta 4)

Sarcină utilă

— Emitentul (iss, cheia de revendicare 1, opțional, ISO 3166-1 alpha-2 al emitentului)

— Emis la (iat, cheia de revendicare 6)

— Momentul expirării (exp, cheia de revendicare 4)

— Certificatul de sănătate (hcert, cheia de revendicare -260)

— Certificatul digital al UE privind COVID v1 (eu_DCC_v1, cheia de revendicare 1)

Semnătură

3.2.2. Algoritmul de semnătură

Parametrul algoritmului de semnătură (alg) indică algoritmul care a fost utilizat pentru crearea semnăturii. Acesta trebuie să respecte sau chiar să depășească orientările actuale ale SOG-IS (Senior Officials Group Information Systems Security – Grupul înalților funcționari pentru securitatea sistemelor informatice), astfel cum sunt rezumate în paragrafele următoare.

Se definesc un algoritm primar și unul secundar. Algoritmul secundar ar trebui utilizat numai în cazul în care algoritmul primar nu este acceptabil conform normelor și reglementărilor impuse emitentului.

Pentru a asigura securitatea sistemului, ar trebui ca toate punerile în aplicare să includă algoritmul secundar. Din acest motiv, trebuie aplicat atât algoritmul primar, cât și cel secundar.

Nivelurile stabilite de SOG-IS pentru algoritmul primar și pentru cel secundar sunt următoarele:

— Algoritmul primar: algoritmul primar este algoritmul de semnătură digitală bazat pe curbe eliptice (Elliptic Curve Digital Signature Algorithm – ECDSA), astfel cum este definit în secțiunea 2.3 din (ISO/IEC 14888-3: 2006), utilizând parametrii P-256 definiți în apendicele D (D.1.2.3) la (FIPS PUB 186-4), în combinație cu algoritmul de distribuire (hash) SHA-256, astfel cum este definit în funcția 4 din (ISO/IEC 10118-3: 2004).

Acesta corespunde parametrului ES256 al algoritmului COSE.

— Algoritmul secundar: algoritmul secundar este RSASSA-PSS, astfel cum este definit în (RFC 8230 (3)), cu un modul de 2048 biți, în combinație cu algoritmul de distribuire (hash) SHA-256, astfel cum este definit în funcția 4 din (ISO/IEC 10118-3: 2004).

Acesta corespunde algoritmului COSE, parametrul PS256.

3.2.3. Identificatorul cheii

Revendicarea privind identificatorul cheii (kid) indică certificatul de semnatar de documente (DSC) care conține cheia publică pe care verificatorul trebuie să o utilizeze atunci când verifică dacă semnătura digitală este corectă. Guvernanța certificatelor de cheie publică, inclusiv cerințele pentru DSC-uri, este descrisă în anexa IV.

Revendicarea privind identificatorul cheii (kid) este utilizată de verificatori pentru selectarea cheii publice corecte dintr-o listă de chei aferente emitentului indicat în revendicarea privind emitentul (iss). Un emitent poate utiliza în paralel mai multe chei, din motive administrative și atunci când efectuează reînnoirea cheilor. Identificatorul cheii nu este un câmp critic din punctul de vedere al securității. Din acest motiv, el poate fi plasat și într-un antet neprotejat, dacă este necesar. Verificatorii trebuie să accepte ambele opțiuni. În cazul în care sunt prezente ambele opțiuni, trebuie utilizat identificatorul cheii din antetul protejat.

Din cauza scurtării identificatorului (din motive de limitare a dimensiunii), există o șansă redusă, dar nu egală cu zero, ca lista globală a DSC-urilor (Document Signer Certificates – certificate ale semnatarilor de documente) acceptate de un verificator să conțină DSC-uri cu același kid. Din acest motiv, verificatorul trebuie să verifice toate DSC-urile cukid-ul respectiv.

3.2.4. Emitent

Revendicarea privind emitentul (iss) este o valoare de tip șir care poate conține codul de țară ISO 3166-1 alpha-2 al entității care eliberează certificatul de sănătate. Această revendicare poate fi utilizată de un verificator pentru a identifica setul de DSC-uri care urmează să fie utilizate pentru verificare. Pentru a identifica această revendicare se utilizează cheia de revendicare 1.

3.2.5. Momentul expirării

Revendicarea privind momentul expirării (exp) trebuie să conțină o marcă temporală în formatul de tip număr întreg NumericDate (astfel cum se specifică în RFC 8392 (4), secțiunea 2), care indică perioada de valabilitate a acestei semnături specifice asupra sarcinii utile, după încheierea căreia verificatorul trebuie să respingă sarcina utilă ca fiind expirată. Scopul parametrului de expirare este de a impune o limită la perioada de valabilitate a certificatului de sănătate. Pentru a identifica această revendicare se utilizează cheia de revendicare 4.

Momentul expirării nu trebuie să depășească perioada de valabilitate a DSC.

3.2.6. Emis la

Revendicarea „emis la” (iat) trebuie să conțină o marcă temporală în formatul de tip număr întreg NumericDate (astfel cum se specifică în RFC 8392 (5), secțiunea 2), indicând momentul în care a fost creat certificatul de sănătate.

Câmpul „emis la” nu trebuie să conțină o dată anterioară perioadei de valabilitate a DSC.

Verificatorii pot să aplice și alte politici cu scopul de a limita valabilitatea certificatului de sănătate în funcție de momentul emiterii. Pentru a identifica această revendicare se utilizează cheia de revendicare 6.

3.2.7. Revendicarea privind certificatul de sănătate

Revendicarea privind certificatul de sănătate (hcert) este un obiect JSON (RFC 7159 (6)) care conține informații privind starea de sănătate. În cadrul aceleiași revendicări pot exista mai multe tipuri de certificate de sănătate, printre care și DCC.

Formatul JSON este utilizat exclusiv pentru scheme. Formatul de reprezentare este CBOR, astfel cum este definit în (RFC 7049 (7)). Este posibil ca, în realitate, dezvoltatorii de aplicații să nu decodeze sau să codeze niciodată în și din format JSON, ci să utilizeze în schimb structura integrată în memorie.

Pentru a identifica această revendicare se utilizează cheia de revendicare -260.

Șirurile din obiectul JSON ar trebui normalizate în conformitate cu forma de normalizare NFC (Normalization Form Canonical Composition - forma de normalizare cu compunere canonică) definită în standardul Unicode. Cu toate acestea, aplicațiile de decodare ar trebui să fie permisive și robuste în aceste privințe, iar acceptarea oricărui tip de conversie rezonabilă este puternic încurajată. În cazul în care, în timpul decodării sau în funcțiile de comparare ulterioară, se descoperă date nenormalizate, punerile în aplicare ar trebui să se comporte ca și cum datele de intrare ar fi normalizate pentru NFC.

4. Serializarea și crearea sarcinii utile a DCC

Ca model de serializare, se utilizează următoarea schemă:

Procesul începe cu extragerea de date, de exemplu, dintr-un registru de date privind sănătatea (sau dintr-o sursă de date externă), structurând datele extrase în conformitate cu schemele DCC definite. În acest proces, conversia în formatul de date definit și transformarea pentru a permite lizibilitatea umană pot avea loc înainte de începerea serializării în format CBOR. Acronimele revendicărilor trebuie puse în corespondență, în fiecare caz, cu denumirile de afișare înainte de serializare și după deserializare.

Conținutul opțional de date naționale nu este permis în certificatele eliberate în conformitate cu Regulamentul (UE) nr. 2021/953 (8). Conținutul datelor se limitează la elementele de date definite în setul minim de date specificat în anexa la Regulamentul 2021/953.

5. Codările pentru transport

5.1. Forma brută

Pentru interfețele de date arbitrare, formatul container al certificatului HCERT și sarcinile sale utile pot fi transferate ca atare, utilizând orice tip de transport de date subiacent sigur și fiabil cu 8 biți. Interfețele respective pot include comunicarea în câmp apropiat (Near-Field Communication – NFC), Bluetooth sau transfer prin intermediul unui protocol privind nivelul de aplicație, de exemplu transferul unui certificat HCERT de la emitent către dispozitivul mobil al unui titular.

În cazul în care transferul certificatului HCERT de la emitent către titular se bazează pe o interfață exclusiv de prezentare (de exemplu, SMS sau e-mail), codarea pentru transport brută nu este, în mod evident, aplicabilă.

5.2. Codul de bare

5.2.1. Compresia sarcinii utile (CWT)

Pentru a reduce dimensiunea și a îmbunătăți viteza și fiabilitatea procesului de citire a certificatelor HCERT, CWT trebuie comprimat utilizând formatul ZLIB (RFC 1950 (9)) și mecanismul de compresie Deflate, în formatul definit în RFC 1951 (10).

5.2.2. Codul de bare QR 2D

Pentru a gestiona mai bine echipamentele tradiționale concepute să funcționeze pe sarcini utile ASCII (American Standard Code for Information Interchange – Codul standard american pentru schimbul de informații), CWT comprimat este codificat ca ASCII cu ajutorul schemei de codare Base45, înainte de a fi codat într-un cod de bare 2D.

Pentru generarea de coduri de bare 2D trebuie utilizat formatul QR, astfel cum este definit în (ISO/IEC 18004:2015). Se recomandă o rată de corecție a erorilor egală cu „Q” (de aproximativ 25 %). Deoarece se utilizează Base45, codul QR trebuie să utilizeze codarea alfanumerică (modul 2, indicat de simbolurile 0010).

Pentru ca verificatorii să poată detecta tipul de date codate și să selecteze schema corespunzătoare de decodare și prelucrare, datele codate cu ajutorul schemei de codare Base45 (în conformitate cu prezenta specificație) trebuie să fie precedate de identificatorul de context sub formă de șir „HC1:”. Versiunile viitoare ale prezentei specificații de natură să afecteze compatibilitatea inversă vor defini un nou identificator de context, iar caracterul care urmează după literele „HC” trebuie selectat din setul de caractere [1-9A-Z]. Ordinea incrementelor este definită în această ordine, și anume mai întâi [1-9] și apoi [A-Z].

Se recomandă ca, în cadrul mediului de prezentare, codul optic să aibă o diagonală cuprinsă între 35 mm și 60 mm, pentru a permite utilizarea de cititoare cu elemente optice fixe pentru care mediul de prezentare trebuie amplasat pe suprafața cititorului.

În cazul în care codul optic este imprimat pe hârtie cu ajutorul unei imprimante cu rezoluție mică (< 300 dpi), trebuie să se acorde atenție reprezentării cu precizie a fiecărui simbol (punct) al codului QR, astfel încât acesta să aibă formă pătrată. Scalarea neproporțională va face ca unele rânduri sau coloane din QR să aibă simboluri dreptunghiulare, ceea ce, în multe cazuri, va afecta lizibilitatea.

6. Formatul listelor de încredere (lista CSCA și lista DSC)

Fiecare stat membru trebuie să furnizeze o listă cuprinzând una sau mai multe autorități naționale de certificare pentru semnătură (CSCA) și o listă a tuturor certificatelor de semnatar de documente (DSC) în termen de valabilitate, și să asigure actualizarea acestor liste.

6.1. CSCA/DSC simplificate

Începând cu versiunea curentă a specificațiilor, statele membre nu trebuie să pornească de la prezumția că informațiile din lista certificatelor revocate (CRL) sunt utilizate sau că perioada de utilizare a cheii private este verificată de către entitățile care asigură punerea în aplicare.

În schimb, mecanismul principal de verificare a perioadei de valabilitate este prezența certificatului pe cea mai recentă versiune a respectivei liste de certificate.

6.2. Documentul de călătorie electronic cu citire optică (eMRTD) și certificatul de cheie publică PKI ale Organizației Aviației Civile Internaționale (OACI) și centrele de încredere

Statele membre pot utiliza o CSCA separată, dar pot, de asemenea, să transmită certificatele eMRTD emise de CSCA existentă și/sau DSC-urile deja existente și pot alege chiar să achiziționeze certificate de la centre de încredere (comerciale) și să le transmită. Cu toate acestea, orice DSC trebuie să fie întotdeauna semnat de CSCA prezentată de statul membru respectiv.

7. Considerente de securitate

Atunci când proiectează o schemă care utilizează această specificație, statele membre trebuie să identifice, să analizeze și să monitorizeze anumite aspecte legate de securitate.

Trebuie luate în considerare cel puțin următoarele aspecte:

7.1. Perioada de valabilitate a semnăturii certificatelor HCERT

Emitentul certificatului HCERT trebuie să limiteze perioada de valabilitate a semnăturii prin specificarea momentului la care expiră semnătura. Prin urmare, titularul unui certificat de sănătate este obligat să îl reînnoiască periodic.

Perioada de valabilitate acceptabilă poate fi determinată de constrângeri practice. De exemplu, este posibil ca un călător să nu aibă posibilitatea de a-și reînnoi certificatul de sănătate în timpul unei călătorii în străinătate. Cu toate acestea, se poate întâmpla, de asemenea, ca un emitent să ia în considerare posibilitatea ca securitatea să fie compromisă, emitentul fiind nevoit să retragă un DSC (invalidând toate certificatele de sănătate eliberate cu ajutorul cheii respective care sunt încă valabile). Consecințele unui astfel de eveniment pot fi limitate prin reînnoirea periodică a cheilor emitenților și prin impunerea reînnoirii tuturor certificatelor de sănătate într-un interval rezonabil.

7.2. Gestionarea cheilor

Prezenta specificație se bazează în mare măsură pe mecanisme criptografice solide, menite să asigure integritatea datelor și autentificarea originii datelor. Prin urmare, este necesar să se mențină confidențialitatea cheilor private.

Confidențialitatea cheilor criptografice poate fi compromisă în mai multe moduri, de exemplu:

— procesul de generare a cheilor poate fi defectuos, având ca rezultat chei slabe;

— cheile pot fi expuse din cauza unei erori umane;

— cheile pot fi furate de infractori externi sau interni.

— cheile pot fi calculate cu ajutorul criptanalizei.

Pentru a atenua riscurile de a se constata că algoritmul de semnare este slab și permite compromiterea cheilor prin criptanaliză, prezenta specificație recomandă ca toți participanții să aplice un algoritm de semnătură secundar, de rezervă, bazat pe parametri diferiți sau pe o problemă matematică diferită față de cea pentru algoritmul primar.

În ceea ce privește riscurile menționate legate de mediile de operare ale emitenților, trebuie puse în aplicare măsuri de atenuare care să asigure un control eficace, astfel încât să se genereze, să se stocheze și să se utilizeze cheile private din modulele de securitate hardware (HSM). Se încurajează puternic utilizarea modulelor HSM pentru semnarea certificatelor de sănătate.

Indiferent dacă un emitent decide să utilizeze sau nu modulele HSM, ar trebui stabilit un calendar de reînnoire a cheilor care să prevadă o frecvență a reînnoirii cheilor proporțională cu expunerea cheilor la rețele externe, la alte sisteme și la personal. Un calendar de reînnoire bine ales limitează, totodată, riscurile asociate certificatelor de sănătate eliberate în mod eronat, prin faptul că îi permite unui emitent să revoce aceste certificate de sănătate pe loturi, prin retragerea unei chei, dacă acest lucru se dovedește necesar.

7.3. Validarea datelor de intrare

Prezentele specificații pot fi utilizate într-un mod care implică primirea de date din surse nefiabile în sisteme care pot fi esențiale pentru îndeplinirea misiunii stabilite. Pentru a reduce la minimum riscurile asociate acestui vector de atac, toate câmpurile de intrare trebuie să fie validate în mod corespunzător, în funcție de tipul, lungimea și conținutul datelor. Înainte de prelucrarea conținutului certificatului HCERT, trebuie verificată, de asemenea, semnătura emitentului. Cu toate acestea, validarea semnăturii emitentului implică analizarea prealabilă a antetului protejat al emitentului, în care un potențial atacator poate încerca să introducă informații atent formulate, concepute pentru a compromite securitatea sistemului.

8. Gestionarea încrederii

Semnătura certificatului HCERT necesită o cheie publică pentru a fi verificată. Statele membre trebuie să pună la dispoziție aceste chei publice. În ultimă instanță, fiecare verificator trebuie să aibă o listă a tuturor cheilor publice în care este dispus să aibă încredere (având în vedere faptul că o cheie publică nu face parte din certificatul HCERT).

Sistemul este format din (numai) două niveluri: pentru fiecare stat membru, unul sau mai multe certificate la nivel de țară, fiecare dintre acestea servind la semnarea unuia sau a mai multor certificate de semnatar de documente, care sunt utilizate în operațiunile zilnice.

Certificatele statelor membre se numesc certificate ale autorităților naționale de certificare pentru semnătură (CSCA) și sunt (de regulă) certificate autosemnate. Un stat membru poate avea mai multe astfel de certificate (de exemplu, în cazul deconcentrării regionale). Aceste certificate CSCA semnează periodic certificatele de semnatar de documente (DSC) utilizate pentru semnarea certificatelor HCERT.

„Secretariatul” este un rol funcțional. Acesta trebuie să agrege și să publice periodic DSC-urile statelor membre, după ce verifică dacă acestea se regăsesc în lista certificatelor CSCA (care au fost transmise și verificate prin alte mijloace).

Lista de certificate DSC rezultată trebuie să furnizeze apoi setul agregat de chei publice acceptabile (și kid-urile corespunzătoare) pe care verificatorii le pot utiliza pentru a valida semnăturile pentru certificatele HCERT. Verificatorii trebuie să obțină și să actualizeze această listă în mod regulat.

Aceste liste specifice fiecărui stat membru pot fi adaptate în formatul corespunzător situației existente la nivel național. Din acest motiv, formatul fișierului acestei liste de încredere poate varia, de exemplu, poate fi un JWKS semnat (format pentru seturi de chei web JSON conform RFC 7517 (11) secțiunea 5) sau orice alt format specific tehnologiei utilizate în statul membru respectiv.

Pentru a asigura simplitatea, statele membre pot fie să își transmită certificatele CSCA existente din sistemele lor eMRTD conforme cu normele OACI, fie, în conformitate cu recomandările OMS, să creeze un certificat specific pentru acest domeniu al sănătății.

8.1. Identificatorul cheii (kid)

Identificatorul cheii (kid) se calculează atunci când se elaborează lista cheilor publice de încredere pe baza certificatelor DSC și constă într-o amprentă digitală SHA-256 trunchiată (primii 8 byți) a DSC, codificată în format DER (brut).

Verificatorii nu trebuie să calculeze kid-ul pe baza certificatului DSC; ei pot corela direct identificatorul cheii din certificatul de sănătate emis cu kid-ul de pe lista de încredere.

8.2. Diferențe față de modelul de încredere eMRTD PKI al OACI

Deși se bazează pe cele mai bune practici ale modelului de încredere eMRTD PKI al OACI, din motive de rapiditate, în prezenta specificație trebuie efectuate o serie de simplificări:

— Un stat membru poate prezenta mai multe certificate CSCA.

— Perioada de valabilitate a DSC (utilizarea cheii) poate fi stabilită la orice durată, atât timp cât aceasta nu depășește certificatul CSCA, și poate să lipsească.

— DSC poate să conțină identificatori ai politicilor (utilizarea extinsă a cheii) care sunt specifici certificatelor de sănătate.

— Statele membre pot alege să nu efectueze niciodată verificări ale revocărilor publicate și să se bazeze exclusiv pe listele DSC pe care le primesc zilnic de la secretariat sau le compilează ele însele.

(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) Regulamentul (UE) 2021/953 al Parlamentului European și al Consiliului din 14 iunie 2021 privind cadrul pentru eliberarea, verificarea și acceptarea certificatelor interoperabile de vaccinare, testare și vindecare de COVID-19 (certificatul digital al UE privind COVID) pentru a facilita libera circulație pe durata pandemiei de COVID-19, JO L 211, 15.6.2021, p. 1.

(9) rfc1950 (ietf.org)

(10) rfc1951 (ietf.org)

(11) rfc7517 (ietf.org)