Anbindung an CWA mit Verwendung von DCCs
- Vorbereitung
- Anbindung an CWA mit Verwendung von DCCs
- Backend-Integration
- Weitere Links
- Anhang
- Implementierungshinweise
- Glossar
Sie können zusätzlich zu jedem personalisierten negativen Schnelltestnachweis in der CWA ein Digital COVID Certificate (DCC) erstellen. Damit wird ein negativer Testnachweis 48 Stunden EU-weit gültig und mit Verifizierungs-Apps überprüfbar.
- Schreiben Sie uns per E-Mail an, falls Sie die bestehende Anbindung um DCCs erweitern wollen.
- Falls Sie bereits ein Clientzertifikat für den Zugang zum Test-Ergebnis-Server erhalten haben, können Sie dieses für den DCC-Server benutzen.
- Sobald die Anbindung Ihrerseits implementiert und in der WRU-Umgebung getestet ist, vereinbaren Sie einen Abnahmetermin mit uns.
- Nach dem Abnahmetest wird Ihr Zugang zum DCC-Server in der Produktionsumgebung freigeschaltet.
Der Schematischer Ablauf für Erstellung von DCC setzt sich aus den folgenden Schritten zusammen:
- Aktivierung von DCC im QR-Code
- Testergebnis liegt vor:
- Testergebnis wird am CWA-Backend (Quicktest-Result-Proxy) gesetzt (1) Upload des Testergebnisses
- Periodische Abfragen am DCC-Server für Public-Keys (5) Ermittlung von Public Keys für vorhandene Testergebnisse
- Nach Erhalt von Public-Keys zu gegebenen Test-IDs wird das DCC-Payload erstellt, dabei auch verschlüsselt und mit Hash versehen (6) DCC Daten Generierung
- Request aus Test-ID / DCC Payload / DEK / DCC-Payload-Hash zu jedem Test an den DCC-Server senden (7) Upload der DCC Komponenten
- Erhalt eines signierten DCC-COSE-Obekts (ohne DCC-Payload) zum Test per Response (9)
Nachfolgend sind Beispielimplementierungen aufgeführt, welche aus der Community stammen und somit keinen Anspruch an Vollständigkeit und korrekte Implementierung stellen. Sie dienen lediglich als Orientierung. Beispielimplementierung in:
Der Abruf aktuell gültiger EU RATs ist hier dokumentiert: Nutzung des-RAT List Distribution-Services
Hier ist eine schematische Übersicht zu den zu erstellenden Datenobjekten und der Kommunikation mit den Schnittstellen zur Erstellung von DCCs zu finden: DCC_Data_Model_and_Communications.pdf.
Die aktuelle Open-API-Beschreibung des Test-Result-Servers finden Sie separat in der Datei quicktest-openapi-dcc.json
Ein Nutzer der CWA kann DCC innerhalb der App aktivieren. Danach erstellt die jeweilige CWA-Instanz einen Public-Key, mit dem DCC-Daten im Backend des Teststellenbetreibers verschlüsselt werden.
Das Attribut dgc signalisiert der CWA, dass Ihr Backend DCCs erstellen kann. Das Attribut ist nicht für Speicherung der Einwilligung zur Verarbeitung der persönlichen Daten gedacht.
Das Attribut dgc ist Boolean. Der Wert true bedeutet, dass ein DCC erstellt werden kann. Der Wert false oder kein Attribut dgc bedeutet, dass DCC nicht erstellt werden kann.
Es kommt zusätzlich in das JSON-Objekt, wird allerdings nicht bei der Berechnung des Hash-Werts benutzt:
{
"fn": "Erika",
"ln": "Mustermann",
"dob": "1990-12-23",
"timestamp": 1622541600,
"testid": "internalid01",
"salt": "759F8FF3554F0E1BBF6EFF8DE298D9E9",
"dgc": true,
"hash": "a5df5308a159909e9f1e436e7fc9748d12bd8a251278b3c4a7f99b71da2bd9e8"
}
Für die Erzeugung des SHA256-Hashwerts nutzen Sie eine Zeichenkette, die nach dem folgenden Muster aufgebaut ist (hier gibt es keine Veränderungen zur ursprünglichen Anleitung):
[dob]#[fn]#[ln]#[timestamp]#[testid]#[salt]
Oder für das obige JSON-Objekt:
1990-12-23#Erika#Mustermann#1622541600#internalid01#759F8FF3554F0E1BBF6EFF8DE298D9E9
Daraus ergibt sich der SHA256-Hash-Wert:
a5df5308a159909e9f1e436e7fc9748d12bd8a251278b3c4a7f99b71da2bd9e8
Dieser wird ins JSON-Objekt eingetragen.
Das Testergebnis für den Test wird an den Test-Result-Server per POST-Aufruf übermittelt.
[Base-URL des Test-Result-Servers]/api/v1/quicktest/results
(Bitte beachten Sie die Hinweise zur Base-URL)
Bitte beachten Sie bei allen Codierungen (JSON, HCERT, etc.) auf die korrekte Schreibweise der Attribute (Case Sensitivity). Fehler darin werden nicht explizit abgefangen und Übertragungen ggf. nur verworfen und nicht verarbeitet.
| Attribut | Beschreibung |
|---|---|
| id | SHA256-Hashwert aus dem JSON-Objekt des QR-Codes |
| result | Testergebnis: Wertebereich 6 bis 8* |
| sc | Sample collected / Zeitpunkt der Probenentnahme als Zeitstempel** |
| labId | Point-of-Care-ID, maximale Länge 64 Zeichen*** |
*DCCs sollen nicht für ungültige Testergebnisse erstellt werden.
**der Parameter sc ist optional
***Die Point-of-Care-ID können Sie selbst generieren. Diese ID können Sie in der Konfiguration Ihrer Software speichern und neben dem Zugriff auf Test-Result-Server bei der Erstellung von DCC-Payloads verwenden. Das Attribut labId ist außerhalb des Arrays mit den Testergebnissen. Bitte beachten: wählen Sie eine möglichst zufällige Point-of-Care-ID, da diese an Ihr Zertifikat zur Authentifizierung gebunden wird. Versuchen Sie eine Point-of-Care-ID zu verwenden, die bereits ein anderer Partner genutzt hat, so schlägt der Upload fehl. Sie können mit diesem Aufruf prüfen, ob Ihnen eine konkrete LabID zugewiesen ist: link Weiterhin sind pro Partner/Zertifikat maximal 10.000 unterschiedliche LabIDs erlaubt. Sollten Sie versuchen eine größere Anzahl zu nutzen, so liefert das Backend einen 403 Fehler.
Beispiel:
{
"testResults":
[
{
"id": "a5df5308a159909e9f1e436e7fc9748d12bd8a251278b3c4a7f99b71da2bd9e8",
"result": 6
}
],
"labId": "mylab01234"
}
oder mit Datum und Uhrzeit des Tests:
{
"testResults":
[
{
"id": "a5df5308a159909e9f1e436e7fc9748d12bd8a251278b3c4a7f99b71da2bd9e8",
"sc": 1622541600,
"result": 6
}
],
"labId": "mylab01234"
}
Für die Ausführung der kryptografischen Operationen für DCC ermitteln Sie zu jeder Test-ID (CWA-Hash) einen Public-Key sowie eine DCCI indem Sie in Ihrer Software einen periodischen Prozess laufen lassen. Dieser Prozess setzt ein GET-Request am DCC-Server (CWA-Backend) im 10 Sekundentakt. Der Endpunkt lautet:
[Base-URL des DCC-Servers]/version/v1/publicKey/search/{labId}
(Bitte beachten Sie die Hinweise zur Base-URL)
In der URL des Requests ersetzen die den Platzhalter durch Ihre gewählte labid (Point-of-Care-ID). Die labid wird an ihr Zertifikat gebunden. Dies bedeutet, dass Sie eine neue labid verwenden müssen, wenn Sie ein neues Zertifikat ausgestellt bekommen.
Der DCC-Server liefert als Response alle zu dem Zeitpunkt bekannte Public-Keys sowie DCCIs zurück in der Form:
[
{
"testId": "4fd1f6f41b510fc…",
"dcci": "URN:UVCI:V1:DE:DMN3L94E7PBDYYLAPNNSS5T218",
"publicKey": "MIIBojANBgkqhkiG9w0BAQEFAAOCAY8AMIIBigKC…"
}
]
| Attribut | Beschreibung |
|---|---|
| testId | SHA256-Hashwert der id aus dem Testergebnis (SHA256-Hashwert aus dem JSON-Objekt des QR-Codes)* |
| dcci | DCCI des Schnelltests |
| publicKey | 3072-bit RSA, base64-kodiert |
* Aufgrund von Sicherheitsanforderungen zur Weitergabe von Test-IDs (SHA256-Hashwert aus dem JSON-Objekt des QR-Codes) sind wir verpflichtet, von dieser ID noch einen SHA256-Hashwert zu berechnen. Dieser Hash-vom-Hash-berechneter Wert wird für die Zuordnung der Tests zu Public-Key benutzt.
Beispiel:
Für den Test aus dem Bespiel in diesem Dokument nutzen Sie folgende Test-ID, um das Testergebnis zu setzen:
a5df5308a159909e9f1e436e7fc9748d12bd8a251278b3c4a7f99b71da2bd9e8
Sobald Sie das Testergebnis an das Backend übermittelt haben, speichern Sie zu dem Test den Hash-Wert, der von der Test-ID abgebildet ist:
4fd1f6f41b510fc06dc86eaeb90a5b8d0a384580eca1992cb1b4dbbcfbf2c329
Anhand von diesem Wert erkennen Sie den passenden Public-Key vom DCC-Server.
Die Daten aus der Response zusammen mit den Personendaten / Schnelltestdaten sowie der Daten zu Ihren Schnellteststellen bilden die Basis für Erstellung von DCC-Payloads. DCCI wird im JSON-Objekt des DCC-Payloads eingetragen.
Im nächsten Schritt sollen die erhaltenen Daten anhand des Public-Keys kryptografisch verarbeitet und vom National Issuer (IBM) signiert werden. Damit kommen Sie zu fertigen DCCs.
Die Point-of-Care-ID können Sie frei wählen. Wir empfehlen ein menschenlesbares Präfix, gefolgt von einer hexadezimalen ID, z.B. noq9f86d081884c7d65…822cd15d6c15b0f00a08. Sie können in der ID nur Buchstaben und Zahlen verwenden. Maximale Länge der Point-of-Care-ID beträgt 64 Zeichen. Jeder Partner kann mehrere Point-of-Care-IDs verwenden.
Zu beachten ist, dass das Polling nach DCC-Requests mit der korrekten Point-of-Care-ID durchgeführt wird.
Zu einem Schnelltest erstellen Sie zuerst ein JSON-Objekt, Das JSON-Schema zum DCC finden Sie unter https://github.com/ehn-dcc-development/ehn-dcc-schema und https://ec.europa.eu/health/sites/default/files/ehealth/docs/covid-certificate_json_specification_en.pdf
{
"t": [
{
"ci": "URN:UVCI:V1:DE:DMN3L94E7PBDYYLAPNNSS5T218",
"co": "DE",
"is": "Robert Koch-Institut",
"tg": "840539006",
"tt": "LP217198-3",
"sc": "2021-06-01T12:00:00Z",
"tr": "260415000",
"tc": "FTA TestZentrum",
"ma": "1468"
}
],
"dob": "1990-12-23",
"nam": {
"fn": "Mustermann",
"fnt": "MUSTERMANN",
"gn": "Erika",
"gnt": "ERIKA"
},
"ver": "1.3.0"
}
| Attribut | Wert / Beispiel | |
|---|---|---|
| fn | Family name / Nachname | Mustermann |
| gn | Given name / Vorname | Erika |
| fnt | Nachname, maschinenlesbare Form* | MUSTERMANN |
| gnt | Vorname, maschinenlesbare Form | ERIKA |
| dob | Geburtsdatum | 1990-12-23 |
| ci | DCCI** | URN:UVCI:V1:DE:DMN3L94E7PBDYYLAPNNSS5T218 |
| sc | Zeitpunkt der Probenentnahme | 2021-06-01T12:00:00Z |
| tr | Testergebnis | 260415000 (für negativ) 260373001 (für positiv) |
| tc | Teststelle | FTA TestZentrum |
| ma | Test Identifier*** | 1468 |
| Konstante Werte | ||
| is | Aussteller des Zertifikats | Robert Koch-Institut |
| ver | Version | 1.3.0 |
| co | Das Land der Zertifikatausstellers | DE |
| tg | Erkrankung, COVID-19 | 840539006 |
| tt | Typ des Tests, Antigentest | LP217198-3 |
* Namen in maschinenlesbarer Form entsprechen der von der ICAO herausgegebenen Spezifikation Doc 9303 part 3. https://www.icao.int/publications/Documents/9303_p3_cons_en.pdf
** DCCI erhalten Sie zusammen mit dem Public-Key beim Polling (siehe Abschnitt Ermittlung von Public-Keys für vorhandene Testergebnisse)
*** Muss alle 24h auf aktuell zugelassene Tests geprüft werden. Eine Liste mit Tests, die in der EU zugelassen sind ist hier zu finden: https://ec.europa.eu/health/sites/default/files/preparedness_response/docs/covid-19_rat_common-list_en.pdf
Persönliche Daten in einem DCC können nur im Zeichensatz „Lateinische Zeichen im Unicode“ vorkommen. Eine formale Definition finden sie unter: http://xoev.de/latinchars/1_1/latinchars.pdf
Für eine Transformation des Namens eines Probanden empfehlen wir den im Anhang ICAO conversion beschriebenen Algorithmus.
Die im vorigen Kapitel genannte Struktur muss in einen HCERT Container eingebettet werden. Dieser ist ein CBOR-Objekt und hat die folgenden Attribute.
| HCERT Attribut | Wert / Beipsiel | |
|---|---|---|
| 1 | Land des Zertifikats | DE |
| 4 | Ablaufdatum als Zeitstempel | 1622714400, Zeitpunkt der Probenentnahme + 2 Tage * |
| 6 | Ausstellungsdatum des Zertifikats als Zeitstempel | 1622541600 |
| -260 | Oberelement für Health Certificate | |
| 1 | Child-Element von Health Certificate, EU Digital Green Certificate (DCC) |
* Beachten Sie bitte, dass die Gültigkeit des Zertifikats 48 Stunden nach der Probenentnahme endet. Die Ausstellungszeit des Zertifikats darf nicht für die Berechnung des Ablaufdatums benutzt werden.
Dieser HCERT-Container bildet den DCC-Payload:
{
1: "DE",
4: 1622714400,
6: 1622541600,
-260: {
1: {
"t": [
{
"ci": "URN:UVCI:V1:DE:DMN3L94E7PBDYYLAPNNSS5T218",
"co": "DE",
"is": "Robert Koch-Institut",
"tg": "840539006",
"tt": "FTA Test Type",
"sc": "2021-06-01T12:00:00Z",
"tr": "260415000",
"tc": "FTA TestZentrum",
"ma": "1468"
}
],
"dob": "1990-12-23",
"nam":
{
"fn": "Mustermann",
"fnt": "MUSTERMANN",
"gn": "Erika",
"gnt": "ERIKA"
},
"ver": "1.3.0"
}
}
}
JSON wird hier nur zur Darstellung der Daten verwendet. Es handelt sich um keine gültigen JSON Objekte. Beim Codieren in CBOR muss zwingend darauf geachtet werden, dass es sich bei den Keys (1,4,6,-260) nicht um Strings handelt. Zu Debugging-Zwecken empfiehlt sich http://cbor.me/
[
"Signature1",
h'a10126',
h'',
h'>>HIER CBOR PAYLOAD HEX EINFÜGEN<<'
]
CBOR Array aus dieser Struktur erzeugen. Die ersten drei Werte dürfen nicht geändert werden. An der vierten Stelle muss das CBOR Objekt des DCC-Payloads als Byte-String eingefügt werden. (DCC-Payload JSON_Struktur z.B. auf cbor.me einfügen und Byte-String ohne Kommentare entnehmen)
Aus diesem CBOR Objekt (mit eingefügtem DCC-Payload als CBOR) muss der sha256 Hash berechnet werden. --> DCC-Hash(in hexadezimaler Codierung)
- Erzeugung eines 32 Byte Schlüssels zur AES-Verschlüsselung (kryptografisch sicher mit entsprechender krypto-Bibliothek)
- Verschlüsselung des CBOR vom DCC-Payload mittels AES256 (AES/CBC/PKCS5Padding; IV={0,...,0}) --> encryptedDcc
- 32 Byte Schlüssel mittels public Key aus Schritt "Ermittlung von Public-Keys für vorhandene Testergebnisse" RSA verschlüsseln (RSA/ECB/OAEPWithSHA-256AndMGF1Padding) --> dataEncryptionKey
- Diese beiden erhaltenen Werte jeweils Base64 Kodieren
Verschlüsselte CBOR (encryptedDcc), DEK (dataEncryptionKey) sowie der DCC-Hash [in hexadezimaler Codierung] werden mit einer POST-Request an den folgenden Endpunkt übermittelt:
[Base-URL des DCC-Servers]/version/v1/test/{testId}/dcc
Pro Schnelltest wird ein Aufruf ausgeführt. Die Request setzt sich aus den folgenden Attributen zusammen:
{
"dccHash": "string", #HexValue
"encryptedDcc": "string", #Base64
"dataEncryptionKey": "string" #Base64
}
Der DCC-Server liefert als Response ein Base64 codiertes COSE Objekt:
{
"partialDcc": " 0oRDoQEmoQRIDEsVUSvpFAFYLGdIZ2d…"
}
Dieser Schritt ist optional:
Das Objekt können Sie für Erstellung von QR-Codes zu DCC benutzen und diesen den Probanden zustellen. Nach Dekodierung des Attributs partialDcc aus der Base64-Form haben Sie ein COSE-Objekt.
[
h'a10126',
{4: h'0C4B15512BE91401'},
h'674867674D596569795A534D33734A49564D4F454C4E7973504939395551714F52526B4C794D7A35764A453D',
h'[Signature drom DCC server]'
]
In dem COSE-Objekt ist an der Stelle des Payloads lediglich ein Platzhalter (Dritte Header-Zeile in dem COSE Array, beginnt in dem Beispiel mit 674867).
Der Wert des Headers muss mit dem Payload aus der Struktur zum Berechnen des Hashes des DCC ersetzt werden. Der Payload ist in der Variable dccData enthalten. Lediglich dieser Wert muss ersetzt werden. Speichern Sie das Ergebnis als byte[] Array (dccCose), mit dem Sie einen QR-Code erstellen können:
DgcGenerator dccGenerator = new DgcGenerator();
byte[] base64DecodedPartialDcc = Base64.decode(dccTestResponse.getPartialDcc());
CBORObject cborPartialDcc = CBORObject.DecodeFromBytes(base64DecodedPartialDcc);
cborPartialDcc.RemoveAt(2);
cborPartialDcc.Insert(2, CBORObject.FromObject(cborStoredDccData.get(2)));
byte[] dccCose = cborPartialDcc.EncodeToBytes();
String dccQrCode = dccGenerator.coseToQrCode(dccCose);
Ein korrekt ausgestelltes Schnelltestzertifikat kann verifiziert werden.
Im Rahmen der Referenzumgebung (WRU) kann eine Verifizierung durch Mitarbeiter beim Abnahmetest durchgeführt werden.
Im Rahmen der Produktivumgebung kann eine Verifizierung mittel der "CovPassCheck-App" durchgeführt werden. Diese ist für Android und iOS unter https://digitaler-impfnachweis-app.de/covpasscheck-app/ und den jeweiligen Store verfügbar.
Testseite für Generierung der DCCs https://github.pathcheck.org/eu.dgc.html
JSON-Schema für DCC-Payload https://github.com/eu-digital-green-certificates/ehn-dgc-schema
Concise Binary Object Representation (CBOR) https://datatracker.ietf.org/doc/html/rfc8949
COSE: CBOR Object Signing and Encryption https://datatracker.ietf.org/doc/html/rfc8152
FAQ für DCC-Payload https://github.com/ehn-digital-green-development/ehn-dgc-schema/wiki/FAQ
DCC Implementierung in C# / .NET https://github.com/ehn-digital-green-development/hcert-dotnet
DCC Implementierung in Java https://github.com/ehn-digital-green-development/hcert-java https://github.com/ehn-digital-green-development/dgc-java
DCC Implementierung in Python https://github.com/ehn-digital-green-development/python-hcert
DCC Implementierung in Kotlin https://github.com/ehn-digital-green-development/hcert-kotlin
DCC Implementierung in Swift https://github.com/ehn-digital-green-development/hcert-swift
Das JSON-Objekt zu dem Schnelltest wird in einen Electronic Health Certificate Container (HCERT) integriert.
Aktuelle Beschreibung des Containers finden Sie unter: https://github.com/ehn-digital-green-development/hcert-spec/blob/main/hcert_spec.md
Bildung eines HCERT-Containers unterstützen wir durch eine Java-Bibliothek. Diese finden Sie unter: https://github.com/eu-digital-green-certificates/dgc-lib/
Die Beispiele in dieser Anleitung sind für die Bibliothek erstellt.
HCERT-Container besteht aus folgenden Komponenten:
- Protected Header (Enthält AlgId: { 1: -7 } )
- Unprotected Header (Enthält KeyId: { 4: h’111111111111’} )
- Payload (DCC)
- DCC-Signatur
Struktur eines DCC-Payloads beinhaltet einen Envelope in folgender Form:
{
1: "DE",
4: 1622541600,
6: 1622714400,
-260: {
1: { [JSON DCC] }
}
}
Die Bibliothek dgc-lib implementiert die für DCC benötigten Schritte, wie HCERT-Container, CBOR, COSE, Hashing und Signatur. Dieses Code-Beispiel zeigt eine Implementierung, die encryptedDcc, dataEncryptionKey sowie den DCC-Hash erzeugt.
// Prepare your public key received into publicKeyString after polling
byte[] publicKeyBytes = Base64.decodeBase64(publicKeyString.getBytes());
KeyFactory keyFactory = KeyFactory.getInstance("RSA");
PublicKey publicKey = keyFactory.generatePublic(new X509EncodedKeySpec(publicKeyBytes));
// Assign your JSON-Object here
String dccJson = "";
// ID for algorithm ECDSA w/ SHA-256
int algId = -7;
// Set the country (Germany)
String countryCode = "DE";
// Calculate certificate creation and validity times
ZonedDateTime now = ZonedDateTime.now();
ZonedDateTime expiration = now.plus(Duration.of(2, ChronoUnit.DAYS));
long issuedAt = now.toInstant().getEpochSecond();
long expirationSec = expiration.toInstant().getEpochSecond();
// Create helper object for DCC initializing
DgcInitData dccInitData = new DgcInitData();
dccInitData.setExpriation(expirationSec);
dccInitData.setIssuedAt(issuedAt);
dccInitData.setIssuerCode(countryCode);
dccInitData.setKeyId(null);
dccInitData.setAlgId(algId);
// Create DCC with JSON object (only JSON, no HCERT-container), initial data and publicKey
DgcCryptedPublisher dgcCryptedPublisher = new DgcCryptedPublisher();
DgcData dccData = dgcCryptedPublisher.createDgc(dccInitData, dccJson, publicKey);
// Get strings for final API call
// dccHash should be set as hex string
// You can use org.bouncycastle.util.encoders.Hex
String dccHash = Hex.toHexString(dgcData.getHash());
String dccEncrypted = Base64.getEncoder().encodeToString(dccData.getdataEncrypted());
String dataEncryptionKey = Base64.getEncoder().encodeToString(dccData.getDek());
// Save dccData for creating QR code after getting response from server
byte[] dccData = dccData.getDccData();
Dies stellt ein nicht vollständiges Beispiel dar, wie eine ICAO Konvertierung durchgeführt werden kann. Zur vollständigen Konformität zur Spezifikation müssen die in [1] genannten Zeichen korrekt konvertiert werden.
0. First name and last name are handled separately (the following steps are done for first name and last name individually)
1. Make sure that the name is in String.Latin format (Latin chars in Unicode) via Regex ^[\u0020-\u0233\u1E02-\u1EF9]+$ (cf. [2], p. 5ff.) -- the charset is actually smaller, but step 7 takes care of that
2. Convert the string to UPPERCASE (cf. [1], p. 18)
3. Replace commas (\u002C), spaces (\u0020), and hyphens (\u002D = -) by '<' (cf. [1], p. 19f.)
4. Replace multiple occurrences of '<' by a single '<' (e.g., 'HANS<<PETER' --> 'HANS<PETER') (cf. [1], p. 18)
5. Replace diacritical characters: (cf. [1], p. 30ff.; [2], p. 5ff.)
\u00C0-\u00C3, \u0100-\u0104, \u01CD, \u01DE, \u01FA, \u1EA0-\u1EB6 --> A
\u00C4, \u00C6, \u01FC --> AE
\u00C5 --> AA
\u1E02 --> B
\u00C7, \u0106-\u010C --> C
\u00D0, \u010E, \u0110, \u1E0A, \u1E10 --> D
\u00C8-\u00CB, \u0112-\u011A, \u018F, \u1EB8-\u1EC6 --> E
\u1E1E --> F
\u011C-\u0122, \u01E4, \u01E6, \u01F4, \u1E20 --> G
\u0124, \u0126, \u021E, \u1E24, \u1E26 --> H
\u00CC-\u00CF, \u0128-\u0131, \u01CF, \u1EC8, \u1ECA --> I
\u0134 --> J
\u0132 --> IJ
\u0136, \u01E8, \u1E30 --> K
\u0139-\u0141 --> L
\u1E40 --> M
\u00D1, \u0143-\u014A, \u1E44 --> N
\u00D2-\u00D5, \u014C-\u0150, \u01A0, \u01D1, \u01EA, \u01EC, \u022A-\u0230, \u1ECC-\u1EDC --> O
\u00D6, \u00D8, \u0152, \u01FE --> OE
\u1E56 --> P
\u0154-\u0158 --> R
\u015A-\u0160, \u0218, \u1E60, \u1E62 --> S
\u00DF, \u1E9E --> SS
\u0162-\u0166, \u021A, \u1E6A --> T
\u00DE --> TH
\u00D9-\u00DB, \u0168-\u0172, \u01AF, \u01D3, \u1EE4-\u1EF0 --> U
\u00DC --> UE
\u0174, \u1E80-\u1E84 --> W
\u1E8C --> X
\u00DD, \u0176, \u0178, \u0232, \u1E8E, \u1EF2-\u1EF8 --> Y
\u0179-\u017D, \u01B7, \u01EE, \u1E90, \u1E92 --> Z
6. Replace arabic numerals 1-9 with roman numerals I-IV if present. Arabic zero is not valid input.
7. Remove all remaining characters that are not A-Z or '<' (cf. [1], p. 20)
Quellen:
[1] ICAO Doc 9303: Machine Readable Travel Documents Part 3: Specifications Common to all MRTDs, Seventh Edition, 2015 https://www.icao.int/publications/Documents/9303_p3_cons_en.pdf
[2] LATEINISCHE ZEICHEN IN UNICODE, Version 1.1.1 vom 27. 01. 2012 https://www.personenstandsrecht.de/SharedDocs/downloads/Webs/PERS/Themen/Vorhaben/Zeichensatz/zeichensatz.pdf?__blob=publicationFile&v=1
Bei der Verwendung von NodeJS kann es notwendig sein folgende Änderung zu übernehmen:
Anstatt
const hash = crypto.createHash("sha256", secret).digest("hex");
muss der Code wie folgt umgeschrieben und die shajs-bibliothek genutzt werden:
const hash = new shajs.sha256().update(secret).digest("hex");
- DGC: Digital Green Certificate
- DCC: Digital COVID Certificate
- CBOR: Concise Binary Object Representation
- COSE: CBOR Object Signing and Encryption
- DCCI: Digital COVID Certificate ID
- DCC-Server: CWA-Backend Die Begriffe DGC und DCC werden in dieser Anleitung synonym verwendet.