BILAG I

FORMAT OG TILLIDSFORVALTNING

Generisk datastruktur, kodningsmekanismer og transportkodningsmekanisme i et maskinlæsbart, optisk format (»QR«)

1. Indledning

De tekniske specifikationer, der er fastsat i dette bilag, omfatter en generisk datastruktur og kodningsmekanismer for EU's digitale covidcertifikat (»DCC«). De fastsætter ligeledes en transportkodningsmekanisme i et maskinlæsbart, optisk format (»QR«), som kan vises på mobile enheders skærme eller udskrives. De i disse specifikationer fastsatte containerformater for de elektroniske sundhedscertifikater er generiske, men bruges i denne sammenhæng til at opbevare DCC'et.

2. Terminologi

I dette bilag forstås der ved »udstedere« organisationer, der anvender disse specifikationer ved udstedelse af sundhedscertifikater, og ved »kontrollører« organisationer, der accepterer disse certifikater som dokumentation for helbredstilstand. Ved »deltagere« forstås udstedere og kontrollører. Visse aspekter af dette bilag skal koordineres mellem deltagerne, såsom forvaltningen af et navneområde og distributionen af krypteringsnøgler. Det antages, at en part, som i det følgende benævnes »sekretariatet«, varetager disse opgaver.

3. Containerformat for det elektroniske sundhedscertifikat

Containerformatet for det elektroniske sundhedscertifikat (Electronic Health Certificate Container Format (»HCERT«)) er udformet, så sundhedscertifikater fra forskellige udstedere er ensartede og standardiserede. Målet med disse specifikationer er at harmonisere måden, hvorpå disse sundhedscertifikater gengives, kodes og signeres, med henblik på at fremme interoperabiliteten.

Evnen til at læse og fortolke et DCC fra en given udsteder kræver en fælles datastruktur og aftale om betydningen af hvert datafelt i nyttedataene. For at fremme denne interoperabilitet bliver der defineret en fælles koordineret datastruktur ved hjælp af et »JSON«-skema, der udgør rammen for DCC'et.

3.1. Nyttedataenes struktur

Nyttedataene er struktureret og kodet som en CBOR med en digital COSE-signatur. Dette er alment kendt som en »CBOR Web Token« (CWT) og er defineret i RFC 8392 (1). Nyttedataene som defineret i de følgende afsnit transporteres via et hcert-krav (claim).

Integriteten og ægtheden af nyttedataenes oprindelse skal kunne efterprøves af kontrollørerne. For at stille denne mekanisme til rådighed skal udstederen signere CWT'en ved hjælp af et asymmetrisk elektronisk signatursystem som defineret i COSE-specifikation (RFC 8152 (2)).

3.2. CWT-krav

3.2.1. Overblik over CWT-struktur

Beskyttet header

— Signaturalgoritme (alg, mærkat 1)

— Nøgleidentifikator (kid, mærkat 4)

Nyttedata

— Udsteder (iss, kravnøgle 1, valgfri, udstederens ISO 3166-1 alpha-2)

— Udstedt den (iat, kravnøgle 6)

— Udløbstidspunkt (exp, kravnøgle 4)

— Sundhedscertifikat (hcert, kravnøgle -260)

— EU's digitale covidcertifikat v1 (eu_DCC_v1, kravnøgle 1)

Signatur

3.2.2. Signaturalgoritme

Parameteret signaturalgoritme (alg) angiver, hvilken algoritme der bruges til at oprette signaturen. Det skal opfylde eller overgå de nuværende SOG-IS-retningslinjer som sammenfattet nedenfor.

Der defineres en primær og en sekundær algoritme. Den sekundære algoritme bør kun bruges, hvis den primære algoritme ikke kan godkendes i henhold til de regler og forskrifter, som er pålagt udstederen.

For at sikre systemets sikkerhed vil alle implementeringer skulle medtage den sekundære algoritme. Af den årsag skal både den primære og den sekundære algoritme implementeres.

SOG-IS-værdierne for den primære og den sekundære algoritme er:

— Primær algoritme: Den primære algoritme er digital signaturalgoritme med elliptisk kurve (ECDSA) som defineret i (ISO/IEC 14888–3:2006) afsnit 2.3, der bruger P–256-parametre som defineret i tillæg D (D.1.2.3) til (FIPS PUB 186–4) i kombination med hashalgoritmen SHA–256 som defineret i (ISO/IEC 10118–3:2004) funktion 4.

Dette svarer til COSE-algoritmeparameter ES256.

— Sekundær algoritme: Den sekundære algoritme er RSASSA-PSS som defineret i (RFC 8230 (3)) med modulo på 2048 bits i kombination med hashalgoritmen SHA–256 som defineret i (ISO/IEC 10118–3:2004) funktion 4.

Dette svarer til COSE-algoritmeparameter PS256.

3.2.3. Nøgleidentifikator

Kravet »nøgleidentifikator« (Key Identifier) (kid) angiver det dokumentsigneringscertifikat (Document Signer Certificate (DSC)), der indeholder den offentlige nøgle, som kontrolløren skal bruge til at kontrollere den digitale signaturs rigtighed med. Administration af offentlige nøglecertifikater, herunder kravene til DSC'er, er beskrevet i bilag IV.

Kravet »nøgleidentifikator« (kid) bruges af kontrollørerne til at vælge den korrekte offentlige nøgle fra en liste over nøgler vedrørende udstederen angivet i kravet udsteder (iss). En udsteder kan af administrative årsager og ved nøgleovergange anvende flere forskellige nøgler parallelt. Nøgleidentifikatoren er ikke et sikkerhedskritisk felt. Af den årsag kan den også placeres i en ubeskyttet header, hvis det er nødvendigt. Kontrollørerne skal acceptere begge løsninger. Hvis begge løsninger forefindes, bruges nøgleidentifikatoren i den beskyttede header.

Pga. forkortelsen af identifikatoren (af årsager relateret til begrænsning af størrelsen) kan det ikke udelukkes, at den generelle liste over DSC'er, som en kontrollør godkender, kan indeholde dobbelte forekomster af enkelte kid-krav. Af den årsag skal en kontrollør kontrollere alle DSC'er med denne kid.

3.2.4. Udsteder

Kravet »udsteder« (iss) er en strengværdi, der eventuelt kan indeholde ISO 3166-1 alpha-2-landekoden for den enhed, som udsteder sundhedscertifikatet. Dette krav kan bruges af en kontrollør til at identificere, hvilke DSC-sæt der skal bruges til kontrol. Kravnøgle 1 bruges til at identificere dette krav.

3.2.5. Udløbstidspunkt

Kravet »udløbstidspunkt« (exp) skal indeholde et tidsstempel i NumericDate-heltalsformat (som specificeret i RFC 8392 (4), afsnit 2), som angiver et tidspunkt indtil hvilket den pågældende signatur for nyttedataene skal betragtes som gyldig, og efter hvilket en kontrollør skal afvise nyttedataene som udløbet. Formålet med parameteret udløbstidspunkt er at sætte en grænse for sundhedscertifikatets gyldighedsperiode. Kravnøgle 4 bruges til at identificere dette krav.

Udløbstidspunktet må ikke være senere end udløbet af DSC'ens gyldighedsperiode.

3.2.6. Udstedt den

Kravet »udstedt den« (iat) skal indeholde et tidsstempel i NumericDate-heltalsformat (som specificeret i RFC 8392 (5), afsnit 2) og angive det tidspunkt, hvor sundhedscertifikatet blev oprettet.

Tidspunktet i feltet »udstedt den« må ikke ligge før udløbet af DSC'ens gyldighedsperiode.

Kontrollører kan anvende yderligere foranstaltninger med det formål at begrænse gyldigheden af sundhedscertifikatet baseret på tidspunktet for udstedelse. Kravnøgle 6 bruges til at identificere dette krav.

3.2.7. Kravet sundhedscertifikat

Kravet »sundhedscertifikat« (hcert) er et JSON-objekt (RFC 7159 (6)) indeholdende oplysninger om sundhedsstatus. Der kan findes mange forskellige typer af sundhedscertifikater under samme krav, hvor DCC'et er et af dem.

JSON anvendes udelukkende til skemaformål. Gengivelsesformatet er CBOR som defineret i (RFC 7049 (7)). Applikationsudviklere må faktisk hverken afkode eller kode til og fra JSON-formatet, men skal bruge strukturen i hukommelsen.

Den kravnøgle, der skal bruges til at identificere dette krav, er -260.

Strenge i JSON-objektet bør normaliseres efter Normalization Form Canonical Composition (NFC), som er defineret i Unicode-standarden. Imidlertid bør afkodningsapplikationer i den henseende være rummelige og robuste, og der tilskyndes stærkt til understøttelse af enhver rimelig typekonvertering. Hvis der i forbindelse med afkodning eller i efterfølgende sammenligningsfunktioner findes ikkenormaliserede data, bør implementeringerne behandle inputtet, som om det var normaliseret til NFC.

4. Serialisering og oprettelse af DCC'ets nyttedata

Som serialiseringsmønster anvendes følgende skema:

Processen starter med udtræk af data fra f.eks. et sundhedsdataregister (eller en ekstern datakilde) og strukturering af de udtrukne data ifølge de definerede DCC-skemaer. I denne proces kan konvertering til det definerede dataformat og omdannelse til for mennesker læsbare oplysninger, finde sted, før serialiseringen til CBOR starter. Kravenes akronymer skal i hvert tilfælde kobles til de viste navne før serialisering og efter deserialisering.

Valgfrit nationalt dataindhold er ikke tilladt i de certifikater, som udstedes i henhold til forordning (EU) 2021/953 (8). Dataindholdet er begrænset til de definerede dataelementer i det minimumsdatasæt, der er fastsat i bilaget i forordning 2021/953.

5. Transportkodning

5.1. Rådata

Hvad angår arbitrære datagrænseflader kan HCERT og dets nyttedata overføres, som de er, ved hjælp af enhver form for underliggende 8 bit sikker og pålidelig datatransport. Disse grænseflader kan omfatte Near Field Communication (NFC), bluetooth eller overførsel via en programlagsprotokol, f.eks. overførsel af et HCERT fra udstederen til en indehavers mobile enhed.

Hvis overførslen af HCERT fra udstederen til indehaveren er baseret på en grænseflade, som kun bruges til præsentation (f.eks. SMS eller e-mail), finder transportkodning af rådata naturligvis ikke anvendelse.

5.2. Stregkode

5.2.1. Komprimering af nyttedata (CWT)

For at mindske størrelsen af HCERT og øge hastigheden og pålideligheden i forbindelse med læseprocessen skal CWT komprimeres ved hjælp af ZLIB (RFC 1950 (9)) og Deflate-komprimeringsmekanismen i det format, som er defineret i RFC 1951 (10).

5.2.2. QR 2D-stregkode

For bedre at kunne håndtere eksisterende udstyr, der er udformet til at fungere med ASCII-nyttedata, er den komprimerede CWT kodet som ASCII ved hjælp af Base45, før den kodes til en 2D-stregkode.

QR-formatet som defineret i (ISO/IEC 18004:2015) skal anvendes til generering af 2D-stregkoden. Der anbefales en fejlkorrektionsprocent (»Q«) på ca. 25 %. Fordi der anvendes Base45, skal QR-koden bruge alfanumerisk kode (tilstand 2, angivet med symbolerne 0010).

For at kontrollørerne skal kunne genkende den type data, der er kodet, og vælge det rigtige afkodnings- og behandlingsskema, skal Base45-kodede data (i henhold til nærværende specifikation) have den foranstillede kontekstidentifikationsstreng »HC1:«. Fremtidige versioner af denne specifikation, som påvirker bagudkompatibiliteten, skal definere en ny kontekstidentifikator, mens tegnet, som følger efter »HC«, skal tages fra tegnsættet [1-9A-Z]. Rækkefølgen er fastsat herefter, dvs. først [1-9] og dernæst [A-Z].

Det anbefales, at den optiske kode gengives på fremstillingsmediet med en diagonal størrelse på mellem 35 mm og 60 mm for at kunne bruges i aflæsningsapparater med fastmonteret optik, hvor mediet skal placeres på apparatets overflade.

Hvis den optiske kode printes på papir af printere med lav opløsning (< 300 dpi), skal der sørges for, at hvert symbol (prik) i QR-koden er helt firkantet. Ikkeforholdsmæssig skalering vil resultere i, at visse rækker eller kolonner i QR-koden har rektangulære symboler, hvilket i mange tilfælde vil gå ud over læsbarheden.

6. Tillidslisteformat (CSCA- og DSC-lister)

Hver medlemsstat skal udarbejde en liste over en eller flere nationalt signerende certificeringscentre (Country Signing Certification Authorities (CSCA)), og en liste over alle gyldige dokumentsigneringscertifikater (Document Signer Certificates (DSC)) og holde disse lister ajourført.

6.1. Forenklet CSCA/DSC

Fra og med denne version af specifikationerne kan medlemsstaterne ikke længere gå ud fra, at der anvendes oplysninger om lister over tilbagekaldte certifikater (CRL), eller at anvendelsesperioden for private nøgler kontrolleres af implementatorerne.

I stedet kontrolleres gyldigheden primært ved en validering af, at certifikatet svarer til den seneste version på certifikatlisten.

6.2. ICAO eMRTD PKI og tillidscentre

Medlemsstater kan bruge særskilte CSCA, men kan også fremsende deres eksisterende eMRTD CSCA-certifikater og/eller DSC'er og endog vælge at skaffe dem fra (kommercielle) tillidscentre og fremsende disse. Ethvert DSC skal dog altid være signeret af det CSCA, som figurerer på den pågældende medlemsstats liste.

7. Sikkerhedshensyn

Når de udarbejder en ordning, hvor de bruger nærværende specifikation, skal medlemsstaterne identificere, analysere og føre tilsyn med visse sikkerhedsaspekter.

Der bør som minimum tages højde for følgende aspekter:

7.1. Gyldighedsperiode for HCERT-signatur

Udstederen af HCERT skal begrænse gyldigheden af signaturen ved at fastsætte et tidspunkt, hvor gyldigheden udløber. Dermed pålægges indehaveren af et sundhedscertifikat at forny dette med periodiske intervaller.

Den acceptable gyldighedsperiode kan afhænge af praktiske omstændigheder. F.eks. har en rejsende ikke mulighed for at forny sit sundhedscertifikat på en oversøisk rejse. Det kan dog også hænde, at en udsteder mener, at der kan være tale om et sikkerhedsbrist, hvilket kræver, at udstederen trækker et DSC tilbage (og således gør alle de sundhedscertifikater, som er udstedt ved hjælp af denne nøgle, ugyldige, selv om gyldighedsperioden ellers ikke er udløbet). Konsekvenserne af en sådan hændelse kan begrænses ved regelmæssigt at udskifte udstedernes nøgler og kræve fornyelse af alle sundhedscertifikater med et rimeligt interval.

7.2. Nøgleforvaltning

Denne specifikation beror i høj grad på stærke krypteringsmekanismer, der skal sikre dataintegritet og autentificering af dataenes oprindelse. Det er derfor nødvendigt at opretholde de private nøglers fortrolighed.

Fortroligheden vedrørende krypteringsnøgler kan kompromitteres på en række forskellige måder, bl.a.:

— Genereringen af nøgler kan være mangelfuld og resultere i svage nøgler.

— Nøglerne kan blive udsat for menneskelige fejl.

— Nøglerne kan blive stjålet af eksterne eller interne gerningsmænd.

— Nøglerne kan blive regnet ud ved hjælp af kryptoanalyse.

For at afbøde risikoen for, at signeringsalgoritmen er for svag, og at private nøgler derfor kan kompromitteres ved kryptoanalyse, anbefales det i denne specifikation alle deltagere at implementere en sekundær signeringsalgoritme, der kan bruges som reserve, og som er baseret på andre parametre eller et andet matematisk problem end den primære.

Hvad angår de nævnte risici relateret til udstedernes driftsomgivelser, skal der gennemføres afbødende foranstaltninger, som skal sikre effektiv kontrol, f.eks. generering, lagring og brug af private nøgler i hardwaresikkerhedsmoduler (HSM'er). Der tilskyndes i høj grad til brug af HSM'er til signering af sundhedscertifikater.

Uanset om en udsteder vælger at bruge HSM'er eller ej, bør der lægges en plan for udskiftning af nøgler, hvor hyppigheden af udskiftningen er proportional med, hvor udsatte nøglerne er med hensyn til eksterne netværk, andre systemer og personale. En veltilrettelagt udskiftningsplan begrænser også de risici, der er forbundet med forkert udstedte sundhedscertifikater, fordi udstederen er i stand til at tilbagekalde sådanne sundhedscertifikater i portioner ved om nødvendigt at trække en nøgle tilbage.

7.3. Validering af inputdata

Disse specifikationer kan bruges på en måde, som indebærer modtagelse af data fra upålidelige kilder i systemer af opgavekritisk art. For at minimere den risiko, der er forbundet med denne angrebsvektor, skal alle inputfelter valideres behørigt med hensyn til datatype, længde og indhold. Før en hvilken som helst form for behandling af HCERT-indholdet finder sted, skal udstederens signatur ligeledes kontrolleres. Validering af udstederens signatur indebærer imidlertid, at udstederens beskyttede header fortolkes først, da en eventuel angriber kan forsøge at tilføre nøje udarbejdede oplysninger hertil, hvis formål er at kompromittere systemets sikkerhed.

8. Tillidsforvaltning

Signering af HCERT kræver, at der er en offentlig nøgle at kontrollere. Medlemsstaterne skal stille disse offentlige nøgler til rådighed. I den sidste ende skal den enkelte kontrollør have en liste over alle de offentlige nøgler, vedkommende har tillid til (eftersom den offentlige nøgle ikke er del af HCERT).

Systemet består af (kun) to lag: For hver medlemsstat et eller flere landespecifikke certifikater, som hver signerer et eller flere dokumentsigneringscertifikater, der bruges i de daglige aktiviteter.

Medlemsstaternes certifikater kaldes certifikater fra nationalt signerende certificeringscentre (Country Signing Certificate Authority (CSCA)) og er (typisk) selvsignerede certifikater. Medlemsstaterne kan have mere end et (f.eks. i tilfælde af regional decentralisering). Disse CSCA-certifikater signerer regelmæssigt de dokumentsigneringscertifikater (Document Signer Certificates (DSC)), der bruges til signering af HCERT'er.

»Sekretariatet« er en funktionel rolle. Det skal regelmæssigt aggregere og offentliggøre medlemsstaternes DSC'er efter at have verificeret disse ud fra listen over CSCA-certifikater (som er blevet overbragt og verificeret på anden vis).

Den heraf resulterende liste over DSC'er indeholder således det aggregerede sæt af godkendte offentlige nøgler (og de tilhørende nøgleidentifikatorer), som kontrollører kan bruge til at validere signaturer vedrørende HCERT'er. Kontrollørerne skal regelmæssigt hente og ajourføre denne liste.

Sådanne medlemsstatsspecifikke lister kan tilpasses det format, der passer til de nationale forhold. Filformatet for denne tillidsliste kan variere. Det kan f.eks. være et signeret JWKS (JWK set format i henhold til RFC 7517 (11), afsnit 5) eller ethvert andet format, der er specifikt for den teknologi, som anvendes i den pågældende medlemsstat.

For at sikre enkelthed kan medlemsstaterne både indsende deres eksisterende CSCA-certifikater fra deres ICAO eMRTD-systemer eller — som anbefalet af WHO — oprette et specielt til dette sundhedsområde.

8.1. Nøgleidentifikator (Key Identifier (kid))

Nøgleidentifikatoren (kid) beregnes, når der udarbejdes en liste over pålidelige offentlige nøgler fra DSC'er, og består af et afkortet (første 8 bytes) SHA-256-fingeraftryk fra DSC'et kodet i DER-format (raw).

Kontrollørerne behøver ikke at beregne kid'en på grundlag af DSC'et og kan direkte matche nøgleidentifikatoren i det udstedte sundhedscertifikat med kid'en på den pålidelige liste.

8.2. Forskelle i forhold til ICAO eMRTD PKI-tillidsmodellen

Om end den bygger på bedste praksis i ICAO eMRTD PKI-tillidsmodellen skal der foretages en række forenklinger for at øge hastigheden:

— En medlemsstat kan indsende flere forskellige CSCA-certifikater.

— DSC'ets (nøgleanvendelse) gyldighedsperiode kan fastsættes til en hvilken som helst varighed, der ikke er længere end CSCA-certifikatets gyldighedsperiode, og kan være fraværende.

— DSC'et kan indeholde politikidentifikatorer (udvidet nøgleanvendelse), som er specifikke for sundhedscertifikater.

— Medlemsstaterne kan vælge ikke at foretage kontrol af offentliggjorte tilbagekaldelser og i stedet forlade sig udelukkende på de DSC-lister, de dagligt får fra sekretariatet eller selv indhenter.

(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) Europa-Parlamentets og Rådets forordning (EU) 2021/953 af 14. juni 2021 om en ramme for udstedelse, kontrol og accept af interoperable covid-19-vaccinations-, test- og restitutionscertifikater (EU's digitale covidcertifikat) for at lette fri bevægelighed under covid-19-pandemien (EUT L 211 af 15.6.2021, s. 1).

(9) rfc1950 (ietf.org)

(10) rfc1951 (ietf.org)

(11) rfc7517 (ietf.org)