CH: testdata contains live, validating certificates

[knoepfchendruecker]

Affected Country: CH

Issue Description

Out of curiosity, I checked dgc-specs on certain details and scanned various QR codes from different countries, using the iOS release versions of both "CovPass Check" (Germany) and "CovidCheck.lu" (Luxembourg), installed on iPhone via Apple's (German) App Store.

Most tested QR codes did "fail" validation using those live/release/production apps, which is what I'd expect from test data, and CovidCheck.lu also presented more metadata. However, I also noticed a number of scanned QR-codes from the swiss testdata set ( https://github.com/eu-digital-green-certificates/dgc-testdata/tree/main/CH/ ) do perfectly validate with a green checkmark. The swiss QR codes 1,3,4,6,7,8,10,12,13 and 15 scanned by both apps do give a green checkmark and specify various identities of two female and two male first names (Martina Studer and Giulia Rosse born in 1964, Hans Muster and Hans Tester born in 1950). The only odd thing about some of those certs is the reference to "2 out of 2 vaccinations" for the one-shot Janssen vaccine - which an app is unlikely to notice.

I'm perfectly aware the full validation process in live requires checking the certificate's full name and DOB with official photo id (e.g. passport or ID card), so if everyone is following the rules, this is not a security risk. However, the general public is being warned across Europe not to share their QR codes on social media, as imposters might just copy those codes and hope on venue owners skipping the mandatory photo ID check, relying on "first name matches the person's sex and the DOB does look somewhat reasonable"). So publishing official and validating QR codes with reasonable metadata as part of the test data repository is possibly not intended. As the QR codes of other countries don't pass the validation apps, this is a CH-specific issue, but possibly requires broader clarification.

I tried searching for a policy on what kind of testdata should be used or how testdata should be generated, but couldn't find any. I tried finding a policy on security-related aspects of testdata or how to report possibly security-related issues, but couldn't find any as well.

Proposed Solution

Short-term (member state issue): ask Switzerland to revoke their test certificates, to prevent illegitimate use of their test certs. I've checked dozens of other QR codes from cdg-testdata, they don't validate with production apps and so revoking those certs shouldn't cause much harm, as nobody should rely on the validity.

Long-term (general issue): specify a policy, naming the intended use of test-data and how to properly create and use test data. A specific section in this policy should address security concerns - how to prevent test certificates from being misused in production.

Some simple ideas:

• The test data is expected to serve as a "reference" of production certificate samples. The data itself is a production sample, the signature has been revoked or metadata is unambiguously fake/sample data.
• certs are being used for QA tests, and any production-issued test certs are being revoked no later than 2 weeks after QA tests have passed.
• Today, about any country is using their own specimen names, which does make it harder for human validators from other countries to spot those names. Specifying a common policy on test metadata for all countries might help a human to spot test certificates. For example, specify a specific name and DOB to use for all kinds of test certificates ("Fake Sample", born no more than 3 years before the cert has been issued) might be an idea to start.
• require dedicated test CAs for signing test certificates and provide a separate keystore of such CAs for testing purposes.

[daniel-eder]

@SchulzeStTSI can you look at this and evaluate?

[krlnokrl]

I haved scanned the dgc-testdata json files against the production trustedList kids. Multiple countries are using their production keys to sign the fictitious testdata.

Affected countries: CH, ES

Affected keys: 2 Production valid test-certificates: 18

VALID:dgc-testdata/CH/2DCode/raw/1.json VALID:dgc-testdata/CH/2DCode/raw/7.json VALID:dgc-testdata/CH/2DCode/raw/10.json VALID:dgc-testdata/CH/2DCode/raw/14.json VALID:dgc-testdata/CH/2DCode/raw/3.json VALID:dgc-testdata/CH/2DCode/raw/15.json VALID:dgc-testdata/CH/2DCode/raw/2.json VALID:dgc-testdata/CH/2DCode/raw/12.json VALID:dgc-testdata/CH/2DCode/raw/9.json VALID:dgc-testdata/CH/2DCode/raw/4.json VALID:dgc-testdata/CH/2DCode/raw/6.json VALID:dgc-testdata/CH/2DCode/raw/8.json VALID:dgc-testdata/CH/2DCode/raw/13.json VALID:dgc-testdata/CH/2DCode/raw/11.json VALID:dgc-testdata/CH/2DCode/raw/5.json VALID:dgc-testdata/ES/2DCode/raw/203.json VALID:dgc-testdata/ES/2DCode/raw/202.json VALID:dgc-testdata/ES/2DCode/raw/201.json

There could be more misuse of the keys.

In the case of Spain, the signed dgc is not present in png format.