BIJLAGE I

FORMAAT EN VERTROUWENSBEHEER

Algemene datastructuur, coderingsmechanismen en transportcoderingsmechanisme in een machineleesbaar optisch formaat (hierna “QR” genoemd)

1. Inleiding

De technische specificaties in deze bijlage omvatten een algemene datastructuur en coderingsmechanismen voor het digitale EU-covidcertificaat (hierna “DCC” genoemd). Zij hebben ook betrekking op een transportcoderingsmechanisme in een machineleesbaar optisch formaat (“QR”), dat op het scherm van een mobiel apparaat kan worden weergegeven of dat kan worden afgedrukt. De containerindelingen van het elektronisch gezondheidscertificaat zijn in deze specificaties generiek, maar worden in dit verband gebruikt om de DCC te dragen.

2. Terminologie

Voor de toepassing van deze bijlage staat “afgevers” voor organisaties die deze specificaties gebruiken voor de afgifte van gezondheidscertificaten en “verificateurs” voor organisaties die gezondheidscertificaten als bewijs van de gezondheidsstatus aanvaarden. “Deelnemers” zijn afgevers en verificateurs. Sommige aspecten van deze bijlage moeten worden gecoördineerd tussen de deelnemers, zoals het beheer van een naamruimte en de verdeling van cryptografische sleutels. Aangenomen wordt dat een partij, hierna “secretariaat” genoemd, deze taken uitvoert.

3. Containerindeling van het elektronisch gezondheidscertificaat

De containerindeling van het elektronisch gezondheidscertificaat (Electronic Health Certificate Container Format, hierna “HCERT” genoemd) is ontworpen als een uniform en gestandaardiseerd vehikel voor gezondheidscertificaten van verschillende afgevers (“afgevers”). Het doel van deze specificaties is de wijze waarop deze gezondheidscertificaten worden weergegeven, gecodeerd en ondertekend te harmoniseren en daardoor de interoperabiliteit te bevorderen.

Om een door eender welke afgever afgegeven DCC te kunnen lezen en interpreteren, is er een gemeenschappelijke datastructuur nodig en moet er overeenstemming zijn over de betekenis van elk dataveld van de payload. Met het oog op die interoperabiliteit wordt een gemeenschappelijke gecoördineerde datastructuur gedefinieerd aan de hand van een “JSON”-schema dat het kader van het DCC vormt.

3.1. Structuur van de payload

De payload is gestructureerd en gecodeerd als een CBOR met een digitale COSE-handtekening. Dit staat algemeen bekend als een “CBOR Web Token” (CWT) en wordt gedefinieerd in RFC 8392 (1). De payload, zoals gedefinieerd in de volgende onderdelen, wordt getransporteerd in een hcert-claim.

De integriteit en authenticiteit van de herkomst van de payloaddata moeten door de verificateur kunnen worden geverifieerd. Om dit mechanisme mogelijk te maken, moet de afgever het CWT ondertekenen met behulp van een asymmetrische methode voor elektronische handtekeningen zoals gedefinieerd in de COSE-specificering (RFC 8152 (2)).

3.2. CWT-claims

3.2.1. Overzicht van de CWT-structuur

Beschermde header

— Algoritme Handtekening (alg, label 1)

— Sleutelidentificatiecode (kid, label 4)

Payload

— Afgever (iss, claim key 1, facultatief, ISO 3166-1 alpha-2 van afgever)

— Afgegeven op (iat, claim key 6)

— Vervaltijd (exp, claim key 4)

— Gezondheidscertificaat (hcert, claim key -260)

— Digitaal EU-covidcertificaat v1 (eu_DCC_v1, claim key 1)

Handtekening

3.2.2. Algoritme van de handtekening

De parameter “Algoritme Handtekening” (alg) geeft aan welk algoritme wordt gebruikt voor het aanmaken van de handtekening. Het moet voldoen aan of verder gaan dan de huidige, hieronder samengevatte SOG-IS-richtsnoeren.

Er worden een primair en een secundair algoritme bepaald. Het secundaire algoritme mag alleen worden gebruikt als het primaire algoritme niet aanvaardbaar is binnen de aan de afgever opgelegde regels en voorschriften.

Om de beveiliging van het systeem te waarborgen, moeten alle implementaties het secundaire algoritme omvatten. Om deze reden moeten zowel het primaire als het secundaire algoritme worden toegepast.

De door SOG-IS vastgestelde niveaus voor de primaire en secundaire algoritmen zijn:

— Primair algoritme: Het primaire algoritme is een elliptische krommealgoritme voor digitale handtekening (ECDSA), zoals gedefinieerd in (ISO/IEC 14888—3:2006) deel 2.3, waarbij gebruik wordt gemaakt van de P-256-parameters zoals gedefinieerd in aanhangsel D (D.1.2.3) bij (FIPS PUB 186-4) in combinatie met het SHA-256-hash-algoritme zoals gedefinieerd in (ISO/IEC 10118—3:2004) functie 4.

Dit komt overeen met COSE-algoritmeparameter ES256.

— Secundair algoritme: Het secundaire algoritme is RSASSA-PSS zoals gedefinieerd in (RFC 8230 (3)) met een modulus van 2048 bits in combinatie met het SHA-256-hash-algoritme zoals gedefinieerd in (ISO/IEC 10118—3:2004) functie 4.

Dit komt overeen met COSE-algoritmeparameter PS256.

3.2.3. Sleutelidentificatiecode

De claim “sleutelidentificatiecode” (kid) vermeldt in welk documentondertekenaarscertificaat (“Document Signer Certificate” of “DSC”) de publieke sleutel zit die de verificateur moet gebruiken om de juistheid van de digitale handtekening te controleren. Het beheer van publiekesleutelcertificaten, met inbegrip van eisen inzake DSC’s, wordt beschreven in bijlage IV.

De claim “sleutelidentificatiecode” (kid) wordt door verificateurs gebruikt om de juiste publieke sleutel te selecteren uit een lijst van sleutels met betrekking tot de afgever die wordt vermeld in de claim afgever (iss). Verschillende sleutels kunnen om administratieve redenen en bij het uitvoeren van sleutelrollovers parallel worden gebruikt door een afgever. De sleutelidentificatiecode is geen beveiligingskritiek veld. Om die reden kan het, indien nodig, ook in een onbeschermde header worden geplaatst. Verificateurs moeten beide opties aanvaarden. Indien beide opties voorhanden zijn, moet de sleutelidentificatiecode in de beschermde header worden gebruikt.

Door de verkorting van de identificatiecode (omdat de ruimte beperkt is) is er een kleine maar niet onbestaande kans dat de algemene lijst van DSC’s die door een verificateur worden aanvaard, DSC’s met dubbele kid’s bevat. Daarom moet een verificateur alle DSC’s met die kid controleren.

3.2.4. Afgever

De claim “afgever” (iss) is een tekenreekswaarde die eventueel de ISO 3166-1 alpha-2-landcode kan bevatten van de entiteit die het gezondheidscertificaat afgeeft. Deze claim kan door een verificateur worden gebruikt om te bepalen welke reeks DSC’s moet worden gebruikt voor verificatie. De claim Key 1 wordt gebruikt om deze claim te identificeren.

3.2.5. Vervaltijd

De claim “vervaltijd” (exp) bevat een tijdstempel in het NumericDate-formaat in gehele getallen (zoals gespecificeerd in RFC 8392 (4), deel 2), waarin wordt aangegeven tot wanneer deze specifieke handtekening voor de payload als geldig wordt beschouwd, waarna een verificateur de payload moet afwijzen omdat deze verlopen is. De parameter “vervaltijd” heeft tot doel de geldigheidstermijn van het gezondheidscertificaat te beperken. De claim Key 4 wordt gebruikt om deze claim te identificeren.

De vervaltijd mag niet langer zijn dan de geldigheidstermijn van het DSC.

3.2.6. Afgegeven op

De claim “afgegeven op” (iat) bevat een tijdstempel in het NumericDate-formaat in gehele getallen (zoals gespecificeerd in RFC 8392 (5), deel 2), met vermelding van het tijdstip waarop het gezondheidscertificaat is aangemaakt.

De datum in het veld “afgegeven op” mag niet vallen vóór de geldigheidstermijn van het DSC.

Verificateurs kunnen aanvullende beleidslijnen toepassen om de geldigheid van het gezondheidscertificaat te beperken op basis van het tijdstip van afgifte. De claim Key 6 wordt gebruikt om deze claim te identificeren.

3.2.7. Claim “gezondheidscertificaat”

De claim “gezondheidscertificaat” (hcert) is een JSON-object (RFC 7159 (6)) dat de informatie over de gezondheidsstatus omvat. Er kunnen verschillende soorten gezondheidscertificaten bestaan onder dezelfde claim, waarvan de DCC er één is.

De JSON is uitsluitend bedoeld voor schematische doeleinden. Het weergaveformaat is CBOR, zoals gedefinieerd in (RFC 7049 (7)). Applicatieontwikkelaars mogen in feite nooit het JSON-formaat decoderen of coderen naar en van het JSON-formaat, maar moeten de structuur in het geheugen gebruiken.

De te gebruiken Claim Key voor identificatie van deze claim is -260.

De strings in het JSON-object moeten worden genormaliseerd volgens Normalization Form Canonical Composition (NFC) zoals gedefinieerd in de Unicode-norm. Decodeertoepassingen moeten in deze opzichten echter ruim en robuust zijn, en de aanvaarding van elke redelijke omzetting wordt nadrukkelijk aangemoedigd. Indien tijdens het decoderen, of in latere vergelijkingsfuncties, niet-genormaliseerde data worden gevonden, moeten de implementaties zich gedragen alsof de input genormaliseerd is naar NFC.

4. Serialisatie en creatie van de DCC-payload

Als serialisatiepatroon wordt het volgende schema gebruikt:

Het proces begint met het extraheren van data, bijvoorbeeld uit een opslagplaats voor gezondheidsdata (of een externe gegevensbron), waarbij de geëxtraheerde data worden gestructureerd volgens de gedefinieerde DCC-schema’s. In dit proces kunnen de omzetting naar het gedefinieerde dataformaat en de transformatie met het oog op menselijke leesbaarheid plaatsvinden voordat de serialisatie naar CBOR begint. De acroniemen van de claims worden in elk geval vóór serialisatie en na deserialisatie toegewezen aan de weergavenamen.

Facultatieve nationale data-inhoud is niet toegestaan in certificaten die zijn afgegeven op grond van Verordening (EU) 2021/953 (8). De data-inhoud is beperkt tot de gedefinieerde data-elementen in de minimale dataset zoals gespecificeerd in de bijlage bij Verordening (EU) 2021/953.

5. Transportcodering

5.1. Raw

Voor arbitraire data-interfaces mogen de HCERT-container en de payloads ervan ongewijzigd worden overgedragen, met gebruikmaking van elk mogelijk onderliggend, veilig en betrouwbaar 8-bit-datatransport. Deze interfaces kunnen NFC (Near Field Communication), bluetooth of overdracht via een toepassingslaagprotocol omvatten, bijvoorbeeld de overdracht van een HCERT van de afgever naar het mobiele apparaat van de houder.

Als de overdracht van de HCERT van de afgever naar de houder gebaseerd is op een interface voor uitsluitend weergave (bijvoorbeeld sms, e-mail), is de transportcodering Raw uiteraard niet van toepassing.

5.2. Barcode

5.2.1. Compressie van de payload (CWT)

Om de grootte te verminderen en de snelheid en betrouwbaarheid van het leesproces van de HCERT te verbeteren, wordt de CWT gecomprimeerd met behulp van ZLIB (RFC 1950 (9)) en het Deflate-compressiemechanisme in het formaat zoals gedefinieerd in RFC 1951 (10).

5.2.2. QR-2D-barcode

Om ervoor te zorgen dat beter kan worden gewerkt met oude apparatuur die is ontworpen voor ASCII-payloads, wordt de gecomprimeerde CWT gecodeerd als ASCII met gebruikmaking van Base45 alvorens te worden gecodeerd in een 2D-barcode.

Voor het genereren van de 2D-barcode wordt het QR-formaat gebruikt zoals gedefinieerd in (ISO/IEC 18004:2015). Een foutcorrectiepercentage van “Q” (ongeveer 25 %) wordt aanbevolen. Omdat gebruik wordt gemaakt van Base45, moet voor de QR-code alfanumerieke codering worden gebruikt (modus 2, aangegeven door de symbolen 0010).

Om verificateurs in staat te stellen het soort gecodeerde data te detecteren en het juiste decoderings- en verwerkingsschema te kiezen, moeten de met Base45 gecodeerde data (volgens deze specificatie) worden voorafgegaan door de Context-Identifier-string “HC1:”. Bij toekomstige versies van deze specificatie die gevolgen hebben voor de compatibiliteit met oudere systemen, moet een nieuwe context-ID worden gedefinieerd, waarbij “HC” moet worden gevolgd door een teken uit de tekenset [1-9A-Z]. Deze tekens moeten in die volgorde worden bepaald, d.w.z. eerst [1-9] en vervolgens [A-Z].

Er wordt aanbevolen de optische code op het presentatiemedium weer te geven met een diagonaal tussen 35 mm en 60 mm, om het gebruik ervan te vergemakkelijken met lezers met vaste optische onderdelen indien het presentatiemedium op het oppervlak van de lezer moet worden geplaatst.

Indien de optische code op papier wordt gedrukt met behulp van printers met lage resolutie (< 300 dpi), moet erop worden gelet dat elk symbool (punt) van de QR-code precies vierkant worden weergegeven. Niet-proportionele schaalverkleining zal in sommige rijen of kolommen van de QR-code tot rechthoekige symbolen leiden, wat de leesbaarheid in veel gevallen zal bemoeilijken.

6. Formaat van vertrouwenslijsten (CSCA- en DSC-lijst)

Elke lidstaat moet een lijst van een of meer Country Signing Certificate Authorities (CSCA’s) en een lijst van alle geldige Document Signer Certificates (DSC’s) verstrekken en deze lijsten actueel houden.

6.1. Vereenvoudigde CSCA/DSC

Vanaf deze versie van de specificaties gaan de lidstaten er niet vanuit dat informatie uit de lijst van ingetrokken certificaten (Certificate Revocation List — CRL) is gebruikt of dat de gebruiksperiode van de persoonlijke sleutel door de uitvoerders is gecontroleerd.

Het primaire geldigheidsmechanisme is daarentegen de aanwezigheid van het certificaat op de meest recente versie van die certificaatlijst.

6.2. eMRTD-PKI van de ICAO en trustcentra

De lidstaten kunnen een afzonderlijke CSCA gebruiken, maar kunnen ook hun bestaande CSCA-certificaten en/of DSC’s voor eMRTD indienen, en kunnen er zelfs voor kiezen deze in te kopen bij (commerciële) trustcentra en die vervolgens in te dienen. Een DSC moet echter altijd worden ondertekend door de CSCA die door die lidstaat is aangewezen.

7. Beveiligingsoverwegingen

Bij het ontwerpen van een regeling aan de hand van deze specificatie bepalen, analyseren en monitoren de lidstaten bepaalde beveiligingsaspecten.

Ten minste met de volgende aspecten moet rekening worden gehouden:

7.1. Geldigheidstermijn HCERT-handtekening

De uitgever van HCERT’s moet de geldigheidsduur van de handtekening beperken door een termijn voor het verstrijken van de handtekening te specificeren. Dit houdt in dat de houder van een gezondheidscertificaat het periodiek moet vernieuwen.

De aanvaardbare geldigheidsduur kan worden bepaald op basis van praktische beperkingen. Een reiziger heeft bijvoorbeeld niet de mogelijkheid om het gezondheidscertificaat tijdens een buitenlandse reis te verlengen. Het is echter ook mogelijk dat een afgever het mogelijk acht dat de beveiliging op een of andere manier is gecompromitteerd, waardoor de afgever een DSC moet intrekken (waardoor alle gezondheidscertificaten die zijn afgegeven met gebruikmaking van de sleutel die nog binnen de geldigheidsperiode valt, ongeldig worden verklaard). De gevolgen van een dergelijke gebeurtenis kunnen worden beperkt door de sleutels van de afgever regelmatig te vernieuwen en met redelijke intervallen de vernieuwing van alle gezondheidscertificaten te eisen.

7.2. Sleutelbeheer

Deze specificatie is sterk afhankelijk van sterke cryptografische mechanismen om de integriteit van data en de authenticatie van de oorsprong van de data te beveiligen. Daarom is het noodzakelijk de vertrouwelijkheid van de persoonlijke sleutels te waarborgen.

De vertrouwelijkheid van cryptografische sleutels kan op verschillende manieren in het gedrang komen. Enkele voorbeelden:

— Het proces waarbij de sleutel wordt aangemaakt, kan gebreken vertonen, wat leidt tot zwakke sleutels.

— De sleutels kunnen worden onthuld door menselijke fouten.

— De sleutels kunnen worden gestolen door externe of interne daders.

— De sleutels kunnen worden berekend aan de hand van cryptoanalyse.

Om het risico op een zwak ondertekeningsalgoritme te beperken, waardoor de persoonlijke sleutels kunnen worden gecompromitteerd door cryptoanalyse, wordt met deze specificatie aanbevolen dat alle deelnemers voor noodgevallen een secundair ondertekeningsalgoritme toepassen op basis van andere parameters of een ander wiskundig probleem dan het primaire.

Wat de vermelde risico’s in verband met de besturingsomgevingen van de afgevers betreft, moeten risicobeperkende maatregelen worden genomen om een doeltreffende controle te waarborgen, zodat de persoonlijke sleutels worden gegenereerd, opgeslagen en gebruikt in HSM’s (Hardware Security Modules). Het gebruik van HSM’s voor het ondertekenen van gezondheidscertificaten wordt nadrukkelijk aangemoedigd.

Ongeacht of een afgever besluit HSM’s te gebruiken of niet, moet een schema voor sleutelrollovers worden vastgesteld waarbij de frequentie van de sleutelrollovers in verhouding staat tot de blootstelling van de sleutels aan externe netwerken, andere systemen en personeel. Een goed gekozen rolloverschema beperkt ook de risico’s in verband met ten onrechte afgegeven gezondheidscertificaten, waardoor een afgever dergelijke gezondheidscertificaten in batches kan intrekken door zo nodig een sleutel in te trekken.

7.3. Validatie van inputdata

Deze specificaties kunnen worden gebruikt op een manier die inhoudt dat data van onbetrouwbare bronnen worden ontvangen in systemen die van missiekritische aard kunnen zijn. Om de risico’s in verband met deze aanvalsvector tot een minimum te beperken, moeten alle inputvelden naar behoren worden gevalideerd op basis van datatypes, -lengtes en -inhoud. De handtekening van de afgever wordt ook geverifieerd voordat de inhoud van het HCERT wordt verwerkt. De validatie van de handtekening van de afgever houdt echter in dat eerst de beschermde header van de afgever wordt geparseerd, waarbij een potentiële aanvaller kan proberen zorgvuldig gefabriceerde informatie in te voeren die bedoeld is om de beveiliging van het systeem in gevaar te brengen.

8. Vertrouwensbeheer

Om de HCERT-handtekening te verifiëren, is een publieke sleutel nodig. De lidstaten maken deze publieke sleutels bekend. Uiteindelijk moet elke verificateur beschikken over een lijst van alle publieke sleutels die hij bereid is te vertrouwen (aangezien de publieke sleutel geen deel uitmaakt van het HCERT).

Het systeem bestaat uit (slechts) twee lagen; voor elke lidstaat een of meer landencertificaten waarmee telkens een of meer DSC’s worden ondertekend die dagelijks worden gebruikt.

De certificaten van de lidstaten worden CSCA’s genoemd (Country Signing Certificate Authority) en zijn (doorgaans) zelfondertekend. De lidstaten kunnen er meer dan één hebben (bijvoorbeeld in het geval van regionale decentralisatie). Deze CSCA-certificaten ondertekenen regelmatig de DSC’s (Document Signer Certificates) die worden gebruikt voor het ondertekenen van HCERT’s.

Het “secretariaat” is een functionele rol. Het verzamelt en publiceert de DSC’s van de lidstaten op regelmatige tijdstippen, nadat het deze heeft geverifieerd aan de hand van de lijst van CSCA-certificaten (die met andere middelen zijn overgedragen en geverifieerd).

De daaruit voortvloeiende lijst van DSC’s bevat dan de geaggregeerde reeks aanvaardbare publieke sleutels (en de bijbehorende sleutelidentificatiecodes) die verificateurs kunnen gebruiken om de handtekeningen via de HCERT’s te valideren. Verificateurs moeten deze lijst regelmatig ophalen en actualiseren.

Dergelijke lidstaatspecifieke lijsten kunnen worden omgezet in het door de lidstaat vastgestelde formaat. Het bestandsformaat van deze vertrouwenslijst kan dus variëren: het kan een ondertekend JWKS zijn (JWK-setindeling volgens RFC 7517 (11), deel 5) of een ander formaat dat specifiek is voor de in die lidstaat gebruikte technologie.

Ter wille van de eenvoud kunnen de lidstaten zowel hun bestaande CSCA-certificaten van hun eMRTD-systemen van de ICAO indienen of, zoals aanbevolen door de WHO, een specifiek certificaat voor dit gezondheidsgebied creëren.

8.1. De sleutelidentificatiecode

De sleutelidentificatiecode (“key identifier” of “kid”) wordt berekend bij het samenstellen van de lijst van betrouwbare publieke sleutels van DSC’s en bestaat uit een afgekapte (eerste 8 bytes) SHA-256-vingerafdruk van het DSC die is gecodeerd in het DER-formaat (raw).

Verificateurs hoeven de sleutelidentificatiecode niet te berekenen op basis van het DSC en kunnen de sleutelidentificatiecode in het afgegeven gezondheidscertificaat direct matchen met de sleutelidentificatiecode op de vertrouwenslijst.

8.2. Verschillen met het eMRTD-PKI-vertrouwensmodel van de ICAO

Hoewel er wordt voortgebouwd op beste praktijken van het eMRTD-PKI-vertrouwensmodel van de ICAO, wordt in het belang van de snelheid een aantal vereenvoudigingen aangebracht:

— Een lidstaat kan meerdere CSCA-certificaten indienen.

— De geldigheidstermijn van het DSC (sleutelgebruik) kan eender welke lengte hebben, zolang deze de geldigheidstermijn van het CSCA-certificaat niet overschrijdt, en mag ontbreken.

— Het DSC mag beleidsidentificatiecodes (uitgebreide-sleutelgebruik) bevatten die specifiek zijn voor gezondheidscertificaten.

— De lidstaten kunnen ervoor kiezen gepubliceerde intrekkingen nooit te verifiëren, maar uitsluitend gebruik te maken van de DSC-lijsten die zij dagelijks van het secretariaat ontvangen of zelf samenstellen.

(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) Verordening (EU) 2021/953 van het Europees Parlement en de Raad van 14 juni 2021 betreffende een kader voor de afgifte, verificatie en aanvaarding van interoperabele COVID-19-vaccinatie-, test- en herstelcertificaten (digitaal EU-COVID-certificaat) teneinde het vrije verkeer tijdens de COVID-19-pandemie te faciliteren (PB L 211 van 15.6.2021, blz. 1).

(9) rfc1950 (ietf.org)

(10) rfc1951 (ietf.org)

(11) rfc7517 (ietf.org)