eu-digital-green-certificates / dgc-overview Goto Github PK

In the guidelines on the certificate governance (section 4.1.1), it is stated that Elliptic Curve "SHOULD BE" used. It is stated that RSA-PSS "SHOULD NOT" be used. At the moment, our PKI does not support either algorithm. We do support RSA-PKCS#1. Can we use RSA-PKCS#1 for the DSC-certificate? It is not explicitely stated for the DSC-certificate. For the other certificates (upload, TLS, DSCA) it is stated that you can use RSA-PKCS#1. Is it also allowed for the DSC-certificate?

Can the DSC-certificate contain an extended key usage "1.3.6.1.5.5.7.3.2" (clientAuth)?

I am trying to figure out if there is a way for third party apps & services to validate the QR codes?

Hello everyone,

if I have found a security risk, which I think would be best addressed at the specification/requirements-level, whom should I contact and how?

I should note, that I'm not part of any development team currently implementing the specification, so I don't have any internal contacts.

Thank you!

Regards,

Jan

The TLS client cert does not need SubjectAlt/CN a RSN with the FQDN or IP.

As it is used client side.

Is there an offical database to download offical public keys from EU states? Or how is it possible to get the public keys?

I'm trying to decode the certificates in Elm (compiles to JavaScript in the browser). I can read the data fine, but don't know where to look for

• instructions to check the signing of the data, although I can probably work that out;
• the public keys themselves.

any pointers?

GitHub provides this service for free for open source repos

• https://docs.github.com/en/code-security/code-scanning/automatically-scanning-your-code-for-vulnerabilities-and-errors

Tasks

• Check if we have it enabled
• Enable it if it is not
• Share the reports with EC

The document should stress the surveillance risks if OCSP endpoints are used (and in the same vein stress that CRLs should be applied centrally).

Certificate validation for airlines and non-EU countries

My company represents some non-EU countries that need to be able to validate digital health certificates from many countries, including EU countries. I am happy to see that your code is available on GitHub, but I don't see how the architecture allows for non-EU countries or other 3rd parties to validate EU certificates. Can someone please share some information on this?

From what I understand, we would need access to the trust list. Can this be obtained without a trusted gateway node, outside of the "circle of trust" ? Such countries have no requirement to issue certificates, just to validate them, so need to be able to read the trust list, without being able to upload certificates.

Hope to hear back!

Morten Jorgensen
Travizory Border Security

I want to setup a reverse proxy https for DGCG to make DGC_GATEWAY_CONNECTOR TLS

My local DGCG run on: http://localhost:8080/trustList
How to build DGC_GATEWAY_CONNECTOR_ENDPOINT=https://dgc-gateway.example.com

I tried my best with nginx or envoy but still cannot config success.

Is there anyone can help me with?
Hope & wait

Rgds,

We use a private PKI (not publicly trusted) to supply the certificates.

For example, our TLS-certificate will be not be self-signed, but will be signed by our own Issuing Certificate Authority (part of our private PKI).

The certificate of this Issuing Certificate Authority is signed by our Root Certificate Authority (part of our private PKI).
The certificate of this Root Certificate Authority is self-signed. Is this supported?

Do we give you the entire trust chain when supplying the certificates?

https://github.com/ehn-digital-green-development/hcert-spec/issues
There are multiple issues that have been open prev. in the hcert-spec repository regarding open topics for validation guides etc.

Your Issue

I would like to ask whether there's some kind of certificate revocation list that's exchanged in the EU gateway alongside with the list of Public Keys.

And if it's not the case (which is what I've read in a discussion in the repo of the italian verifier app) I would like to ask the reasoning behind this, as it seems like a pretty important feature.

Are there privacy concerns maybe?

I am currently looking at all the certificates that we need to generate as based on the guide within this repo.
Let us start with the CSCA using a Self Signed Root CA which we could create ourselves.
I am having trouble to fill in all the gaps of how exactly the Root CA must be created, the NBcsca, etc...

Example of what i'm doing:

Generate the private key of the root CA:
openssl genrsa -out rootCAKey.pem 4096

Generate the private key of the root CA:
openssl req -x509 -sha256 -new -nodes -key rootCAKey.pem -days 3650 -out rootCACert.pem -subj "/C=XX/ST=State/L=City/O=My Organization/OU=My Department/CN=My Root CA"

Create a NBcsca

openssl req -x509 -newkey rsa:4096 -keyout key_nbcsca.pem -out cert_nbcsca.pem -days 1460 -nodes -subj "/C=XX/ST=State/L=City/O=My Organization/OU=My Department/CN=XX DGC CSCA 1"

Export public key to Java Keystore
keytool -importcert -alias dgci_nbcsca -file cert_nbcsca.pem -keystore nbcsca.jks -storepass somesecurekeystorepassword

I think I'm missing passwords in these steps above, which think is the problem...

As per the issuance service applciation.yaml specification:

issuance:
  dgciPrefix: dgci:V1:DE
  keyStoreFile: certs/test.jks
  keyStorePassword: dgca
  certAlias: edgc_dev_ec
  privateKeyPassword: dgca
  countryCode: DE

I need a keyStorePassword which is specified above as somesecurekeystorepassword, however, i'm missing the privateKeyPassword

A full list of openssl commands to depict exact steps would be most helpful, better yet, a bash/sh script to accompany it would really help people get over the bumps and complexities on creating the certificates with the right specifications from the start, leading to a much smoother rollout for Europe.

Insufficient requirements on NB-TLS client certificate key usage

Section 4.5 of certificate-governance.md is insufficient. The current text says:

Beware that self-signed certificates should also contain the key usage Certificate signing (keyCertSign), so that OpenSSL can verify the (self) signature of the certificate.

As we learned during the dry-run, this is not a SHOULD, but a MUST. Or has this changed to just be a recommendation?

In case this is a MUST, then I would also recommend to lift this into the table above

Note: that the requirement is really in error as there is no support for the requirement of keyCertSign in any of the open standards of PKI, but if this key usage is required any way due to how current tools work, then it should be made mor clear.

An example that highlights the contradiction is the following requirement from RFC 5280:

The keyCertSign bit is asserted when the subject public key is used for verifying signatures on public key certificates. If the keyCertSign bit is asserted, then the cA bit in the basic constraints extension (Section 4.2.1.9) MUST also be asserted

That is: A certificate with keyCertSign set, MUST be a CA, which is not true for the TLS client. But I'm really not trying to change this requirement at this point, just making sure it is is clearly stated. Some comment on this contradiction may however be in place.

Hello,

we would like to integrate the validation into our gastro software so that our staff does not need to use their personal smartphones with the "CovPassCheck" app.

Are there publicly available trust stores or is there a publicly available URI where one can obtain the public key to a given kid from a given issuer or something like a JWKS?

Being forced by government regulations to grant access to indoor venues only for tested or vaccinated people, we would prefer an easy way to check the official digital vaccination certificates of the guests.

Kind regards,
Alex

Most commercial CAs will not be able to issue KUFs that are this strict. Cut them some slack.

Your Issue

There's an article in the ZDF (https://www.zdf.de/nachrichten/politik/corona-digitale-impfausweise-100.html german) which talks about "massive security flaws" in the digital green pass. I think all the flaws criticised there, except the possibility of getting hacked, are also in the paper pass. I thought there should be a clarification, cause this implicates, that the digital certificate is so much worse than the paper pass. (Sorry didn't found a better way to contact an official.)

https://ec.europa.eu/health/sites/health/files/ehealth/docs/digital-green-certificates_dt-specifications_en.pdf

I think the published scheme has some problems:

1. The lack of a "version" field to accommodate future changes to this schema. If more than one version of the DGC is in circulation, validation applications cannot distinguish between them without a version field. This field is present in more recent versions: https://github.com/ehn-digital-green-development/ehn-dgc-schema/blob/main/DGC.schema.json
2. The datasets for disease-agent-targeted, vaccine-prophylaxis, vaccine-medicinal-product, test-manf, etc are hard-coded in the schema and don't accommodate for the future update of this values to add new vaccines or tests. I think this datasets must be maintained outside of the schema.

This issue is based around the closed issue #7, even though it is closed it is not solved.

The TAN second-factor is quite redundant. It would only make sense if the DGC standard only allows for digital certificates; paper versions of the QR code would not be allowed.

However, currently a bad actor can use a DGC, the only thing stopping them from getting past health checkpoints is the mismatched ID details on the passport or any other type of ID being used. I understand the TAN is being used to stop people from having multiple digital copies of a DGC but I'm not sure how that would help user's protect their DGC; it just makes the digital on-boarding less user friendly. If we are to make digital certificates secure we must have another process in place to generate the certificates.

Maybe we should only allow generation of paper certificates based on information the user should have. This could be a flow like the following:

1. User scans QR code (with the DGCI)
2. QR code takes the user to a webpage/app(via deeplink) which asks them to give the TAN code.
   • If the user goes through the app the typical app flow applies with the keypair generation.
   • If the user goes through the webpage then the browser makes it's own keypair(acts as an ephemeral key) which it uses to make the transaction. This allows the API calls to be consistent in the webpage and app versions as well as allowing the webpage session the ability to create a derived DGC(we will call this dDGC from now on).
3. Upon verifying the TAN code with the DGCI the DGC is given to the user to print or store on their device.
   • This DGC should be used to generate dDGCs which will be used for presentation to the validation apps. This works because the DGC will have the holders public key enclosed. On validation of the dDGC the validator will check to make sure the signature of the dDGC is valid and the dDGC hasn't expired.
   • The webpage will generate a dDGC for the user to print, this dDGC will have a long time expiry.

Considerations of this approach:

• Since the TAN was used in the webpage version it can not be used again to make the digital version of the DGC.
• The user has accepted that it is their responsibility to take care of the paper version of their dDGC if that is the solution they have opted for.
• If the user opted for the App flow they are able to recover the DGC using key recovery flows of the app they used.
• This allows for non official versions of the wallet to be used allowing the community the ability to create their own apps that would be just as secure as the official apps since there are now technical constraints.

The presentation of dDGCs will still be QR codes adding another signature and expiry on top will not be heavy. I understand this is quite different to the current flow but this is the only way we can make sure the certificates are more secure and uses the technology we have better. We should not allow our mobile devices to be just a glorified storage medium with a screen. We need to leverage their real time capabilities to provide a more secure presentation interface, hence the usage of dDGCs.

Your Issue

This organisation contains a Fork of the JSON Schema repository from the eHealth network, pointing to an outdated draft version of the schema.

This fork should be updated to the version 1.0.0, so that member states have a common view on the current implementation baseline.

Hey everyone,

first of all thanks for this awesome work in such a short time.

To verify all the different codes we need access to a global trust list.
Of course only to access the public keys.

We found one list for Austria, but this list looks more like a test list.
But using this list we are able to verify code for Austria but cant verify other countries.

Maybe I did get something wrong or why is the trust list not public accessible.
The public keys are no sensitive information.

https://dgc.a-sit.at/ehn/cert/listv2
https://dgc.a-sit.at/ehn/cert/sigv2
https://dgc.a-sit.at/ehn/

relevant issues:
ehn-dcc-development/hcert-kotlin#28
eu-digital-green-certificates/dgc-participating-countries#10

thanks and best regards
Julian

Hi all, not sure where to put this question.
I just wanted to bring this thread to your attention. Maybe this would be a better place to address some of it's questions therein.

corona-warn-app/cwa-documentation#615

Your Issue

The current HC1-scheme doesn't support documenting a vaccination process using two different vaccines, and those who are vaccinated using a single dose vaccine as their primary vaccination and a single jab of a two dose vaccine for their booster can't differentiate if their Health Certificate is a "fully vaccination" using the two dose vaccine or a "single dose + booster (a single jab of a two dose) vaccination".

I am myself vaccinated using the COVID-19 Vaccine Janssen, and had a single jab of Spikevax in november, and my EUDCC is portrayed as a 2/2 Spikevax, the same as a fully vaccination using Spikevax.

According to this article, the EU will introduce a 9 month validity for the "fully vaccinated" and require a booster vaccine for continued travel using the EUDCC beyond the 9 month validity period, and this can have some travel complications in the case presented above.

My suggestion is to introduce a standard of how the boosters should be portrayed in the scenario above, and I think of two solutions:

• Always display the original vaccine, and not the booster vaccine, in the EUDCC (if 2/2 COVID-19 Vaccine Janssen, it must be implicitted seen as a booster)
• Always show booster health certificates as a minimum of three doses, regardless of the practical number

Regarding section 5.1, 5.2 in the Guidelines on Technical Specifications for DGCs, Volume 4, European DGC Applications, v1.3

I am unsure, if I understand the DGC installation process in the Wallet App correctly, especially the planned use of a TAN via SMS (or on paper) to move a test result from an e-mail (or paper) into the app.

I assume the following:

• the QR code shown in the Wallet is the same as on the printed version (its just the DGC)
• it is always necessary to check if the ID of the person presenting the DGC matches the DGC, and of course the signature
• there is maybe some protection against just presenting a screenshot, like a moving counter or so on the wallet screen
• on the other hand, localized versions of the wallet may have different appearances
• it is possible to build an app not doing the TAN/DGCI check on DGC installation, that still looks like the wallet and presents DGCs
• it is even possible (but probably illegal) to use a rogue verifier app at an venue that just records DGC, with or without actually verifying the signature

So, the protection offered by the TAN requirement is somewhat limited, as the data to display is already transmitted to the user and only the installation in the app is a bit more difficult.

I think it is useful to only allow one installation of the DGC in the official wallet app by registering the installation's public key with the backend and only allow registration for a limited time after issuing the certificate as planned. The wallet app should inform the user that the DGC can only be installed in one wallet before registering the DGCI with the backend.

This would help against the "normal" DGC reuse attempts, like forwarding a test result email to a friend, or trying to scan the QR code from the wallet of another person.

But I don't understand the benefit of a second factor in this situation. Maybe I have missed something important?

Hello!

Where we can find a list of the production Urls of the different national DGC Servers (public key Apis) for testing purpose?
We are developing a Windows C# WPF green pass checker application, and we just found the Sweden Url (https://dgcg.covidbevis.se/tp/trust-list)?

Thanks a lot.

Hello,

I'd be interested in knowing, if data encoded within the QR code is not only signed using a digital signature, but also encrypted?
Or in other words: Is it possible for a 3rd party app to read the data in these QR codes?
And as a followup-question: Is it possible for a 3rd party app to use the EU certificate gateway to retrieve the public certificates required for verification of the dig. signature?

Thank you and best regards,

I have been asked by one of my customers to write a custom DCC verification service. Here are TONS of information, but the "verification guide" is empty (https://github.com/eu-digital-green-certificates/dgc-overview/blob/main/guides/validation-guide.md).

It's also not clear how to obtain access to the test gateway (and later acceptance and production). I created an issue here: eu-digital-green-certificates/dgc-participating-countries#13 (comment)

For any information I would be very grateful!

Your Issue

ios 15.1 is already out, in this update apple is accepting covid vaccination cards natively but only if it is in the SMART Health Card format.
https://support.apple.com/en-us/HT212752
https://smarthealth.cards/

This will make the vaccine card holder experience much nicer, because they will be in a centralized place.

I kindly suggest to implement this.

Thanks.

How to use DGC's service to validate/decode a QR code containing recovery or vaccination?

I came across https://www.npmjs.com/package/covid-certificate-parser with which we will be able to decode/parse a QR code with recovery/vaccination information offline.

What I am unable to understand is, how can I make use of DGC API/Service to validate/decode a QR code and check the authenticity of the QR code.

Is it possible? Does DGC provide some public APIs where a private company can connect to validate the authenticity of the QR code?

Hi,
I would like to test dgca-issuance-service component, after build and run, i got error message bellow

what i can do to perform test?

From this document,

https://ec.europa.eu/health/sites/default/files/ehealth/docs/digital-green-value-sets_en.pdf

Type of the Test

Result of the test

Q1) On Result of the test, Can we assume, Not detected is negative and Detected positive ?

Q2) On Type of the Test, Can we get the more information of Test ? like name, type of test for common people understandable ?

DPIA for any Member State deployment

• Have been unable to find an exemplary DPIA for any national member state deployment. Can anybody help?

The Dockerfiles for verfiier/businessrule components use the adoptopenjdk image (specifically adoptopenjdk:11-jre-hotspot) which seems to be unmaintained since 01/08/2021

This image is officially deprecated in favor of the eclipse-temurin image, and will receive no further updates after 2021-08-01 (Aug 01, 2021). Please adjust your usage accordingly.

They recommend το switch over το eclipse-temurin

If its possible we would like to have common wallet/verifier apps for different member states to have one registration with Google/Apple. Usually it takes a lot of time to register app and it might be easier to have one app with localisation for different countries/languages.