EU Digital COVID Certificate Validation Service

About • Development • Documentation • Support • Contribute • Licensing

About

This repository contains the source code of the EU Digital COVID Certificate Validation Service.

The validation service can validate EU Digital Covid Certificates for travel and booking services using business rules from dgca-businessrule-service and certificates from dgca-verifier-service.

The validation has a complex work flow that involves

• dgca-validation-decorator - additional service on travel system
• dgca-booking-demo - travel system mock
• dgca-booking-demo-frontend
• dgca-verifier-app-android - provide dcc

Specification Document

https://ec.europa.eu/health/sites/default/files/ehealth/docs/covid-certificate_traveller-onlinebooking_en.pdf

Note: The document defines in the identity document RFC7517 for x5c, which is a json array instead of a string. The kid is calculated over the first certificate of the chain.

Performed Checkups

The validation service checks the provided DCC for:

• Expiration
• Issuing Date validity
• Cryptographic validity
• FNT/GNT/DOB Matching
• Provided Certificate Type
• Category Checks (not implemented)
• Business Rules

The VS does not perform additional checkups regarding the "category" of the access token, which is depending on the operator of the service to do additional checks or not, if necessary.

Confirmation Token

The confirmation token is a signed JWT which confirms the successful checkup of a DCC associated with a subject. This token can be signed by a self signed certificate which was created especially for this VS instance OR by a CSCA. Which option is chosen depends on the operator. Whatever is chosen, it's recommended to share the VS signer certificate public keys on national lists or to share the Identity Documents URLs of the validation services, for validating confirmation tokens across all service providers in a decentralized manner.

Results

The VS delivers a result OK (all checks passed), NOK (DCC not valid) or CHK (cross check necessary). CHK means in this case to cross check documents and/or request additional RAT or PCR tests, because the VS was not able to check the DCC successfully. Depending on the used additional checks in the VS, controlled by the categories, the CHK value can be used for manual checkups as well.

Public Key Considerations

The public key for the initialization call must be in a PEM format with or without PEM Markers. In the case of Apple iOS the public key must be converted into DER format at first before generating a PEM out of it (https://github.com/eu-digital-green-certificates/dgca-app-core-ios/blob/main/Sources/Services/X509.swift#L39). Otherwise the key is encoded in ASN1 format and not readable by Java's Bouncy Castle.

RSA Keys should have a minimum of 3072 bits according to the RSA recommendation of TLS certificates (https://github.com/eu-digital-green-certificates/dgc-overview/blob/main/guides/certificate-governance.md#requirements-on-tls-upload-and-csca).

Crypto Schemes

Please note: the encryption schemes were selected in this manner, to support a wide range of devices, programming languages and tools. Embedded encryption schemas like ECIES and similar can be provided for the future (e.g. Apple iOS Ecies schemes).

Token

Accesstokens must have a valid audience, iat, kid and exp for the call. The kid is checked against the available public keys, which can be loaded from:

• Fixed Provider (Environment Variable DGC_ACCESSKEYS)
• Identity Document (Environment Variable Decorator URL, dynamically download)
• Custom Key Provider (not implemented yet)

Key Management

The provided keys in the identity document should be held in an HSM or any kind of vault (hashicorp, jks etc.). To increase the security it's recommended to rollover the keys for encryption from time to time or provide multiple ones in the same time.

Encryption Key Selection

To select the right key for encryption, a wallet app should search for "type": "DccEncryptionScheme2021" in the verification Methods to identity available encryption schemas. All found methods can be scanned for the needed schema e.g. RSAOAEPWithSHA256AESGCM. Within the "verificationMethods" can the linked key material be found for encryption. The latest method of this array should be used for encryption.

TLS Certificate Rollover

When the validation service is linked in the validation decorator, the TLS certificate is defined there to allow the connection pinning. Is this certificate changed in the future, the decorators must be informed about this change to insert the certificate in the own identity document under "ValidationServiceKey". To establish the rollover, the new service must be added in the "services" section as well as a new service (e.g. ValidationService-5). It's recommended that the wallet app handles these multiple services grouped by validation service URL (sorted by latest service added) to support the rollover. For instance, are three services configured and all of them roll over in the same time. The document should contain 6 validation service definitions with 3 groups of two items. Each couple of items have the same url. In the wallet app, just the three latest should be shown for selection.

Development

Prerequisites

• Open JDK 11
• Maven
• Docker
• Authenticate to GitHub Packages

Authenticating in to GitHub Packages

As some of the required libraries (and/or versions are pinned/available only from GitHub Packages) you need to authenticate to GitHub Packages. The following steps need to be followed

• Create PAT with scopes:
  • read:packages for downloading packages

GitHub Maven

• Copy/Augment ~/.m2/settings.xml with the contents of settings.xml present in this repository
  • Replace ${app.packages.username} with your github username
  • Replace ${app.packages.password} with the generated PAT

GitHub Docker Registry

• Run docker login docker.pkg.github.com/eu-digital-green-certificates before running further docker commands.
  • Use your GitHub username as username
  • Use the generated PAT as password

Build

Whether you cloned or downloaded the 'zipped' sources you will either find the sources in the chosen checkout-directory or get a zip file with the source code, which you can expand to a folder of your choice.

In either case open a terminal pointing to the directory you put the sources in. The local build process is described afterwards depending on the way you choose.

Build with maven

• Check settings.xml in root folder and copy the servers to your own ~/.m2/settings.xml to connect the GitHub repositories we use in our code. Provide your GitHub username and access token (see GitHub Help) under the variables suggested.
• Run mvn clean package from the project root folder

Run with docker

• Perform maven build as described above
• Run docker-compose up from the project root folder

After all containers have started you will be able to reach the application on your local machine under port 8080.

Documentation

• OpenAPI documentation

Support and feedback

The following channels are available for discussions, feedback, and support requests:

Type	Channel
Issues
Other requests

How to contribute

Contribution and feedback is encouraged and always welcome. For more information about how to contribute, the project structure, as well as additional contribution information, see our Contribution Guidelines. By participating in this project, you agree to abide by its Code of Conduct at all times.

Licensing

Copyright (C) 2021 T-Systems International GmbH and all other contributors

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License.

You may obtain a copy of the License at https://www.apache.org/licenses/LICENSE-2.0.

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the LICENSE for the specific language governing permissions and limitations under the License.