Missing Documentation of Rapid Antigen Test Implementation - Questions regarding security

[vaubaehn]

Missing Documentation of Rapid Antigen Test (RAT) Implementation

Works on implementing Rapid Antigen Tests into CWA have begun: A RAT portal (for testing staff?), the connected RAT server backend have been published on GH, and app coding (at least for Android, didn't look up iOS) has started.

Unfortunately there is no documentation at all about this new feature yet.
When do you plan to publish such a documentation for assessing technical and security implications, similar to the Event Registration (=presence tracing) documentation?

Security Related Questions

For now I have only questions with regard to the data embedded into the generated QR code.
From a short code review, I assume following workflow with associated tech specs (which for sure can be far away from the actually planned implementation):

1. The testee visits the testing location, performs test and provides personal data: First name, last name and date of birth, sex, full address, e-mail, phone number, consent to process the personal data, as can be found here:
   https://github.com/corona-warn-app/cwa-quick-test-frontend/blob/f95b94b1e1e852f29b2c7f9904fdf6a0b7d3258d/src/api.tsx#L75-L89
2. The testing staff registers the test into the RAT portal (cwa-quick-test-frontend), entering testee's personal data (and also the test result?).
3. The test also receives a timestamp, a test ID, a salt, and a hash, a test status, and probably more data.
4. A certain amount of this data is stored on the backend server (I didn't look into the code yet, but at least timestamp, test ID, and a SHA-256 hash of at least parts of the registered data seems to be necessary).
5. A QR code is generated, embedding an URI (for fetching result/verification?) with base64 encoded data, containing timestamp, test ID, hash, testee's name and date of birth, that can later be extracted by CWA, see: https://github.com/corona-warn-app/cwa-app-android/blob/42c0907f68b9a47c290587f0b0e08a4005262638/Corona-Warn-App/src/main/java/de/rki/coronawarnapp/coronatest/qrcode/RapidAntigenQrCodeExtractor.kt#L21-L30
   A current sampe URI can be found here: https://github.com/corona-warn-app/cwa-app-android/blob/feature/6031-extract-data/Corona-Warn-App/src/test/java/de/rki/coronawarnapp/coronatest/qrcode/TestQrCodes.kt
   QR code no. 3's URI is:
   [...]s.coronawarn.app/?v=1#eyJ0aW1lc3RhbXAiOjE2MTg1NjM3ODIsInNhbHQiOiI1QTI3M0REREJCQTFEMkFDQUEzN0ExMDg4NjhGNkIwMjM3NjQzRjhBNjdCQTNENkQ3RUE3RkREQ0M0RDJGMjBEIiwidGVzdElkIjoiMGQ5ZTg0MzItZWI5MS00YzhmLTgyYWYtNWEwMWZiMWI2NzYwIiwiaGFzaCI6IjdiMWMwNjNlODgzMDYzZjhjMzNmZmFhMjU2YWRlZDUwNmFmZDkwN2Y3NDQ2MTQzYjNkYTBmOTM4YTIxOTY3YTkiLCJmbiI6IkFsbWEiLCJsbiI6IkhheWVzIiwiZG9iIjoiMTk2Mi0wMS0wOCJ9
   whereas the payload would decode to
   {"timestamp":1618563782,"
   salt":"5A273DDDBBA1D2ACAA37A108868F6B0237643F8A67BA3D6D7EA7FDDCC4D2F20D",
   "testId":"0d9e8432-eb91-4c8f-82af-5a01fb1b6760",
   "hash":"7b1c063e883063f8c33ffaa256aded506afd907f7446143b3da0f938a21967a9",
   "fn":"Alma",
   "ln":"Hayes",
   "dob":"1962-01-08"}
6. The QR is possibly printed out by the testing staff and registered inside CWA by the testee.
7. CWA receives the test result later.

Questions:

• Is there a plan that the RAT QR code can be used as an entry pass to venues, by presenting it to gate keepers?
• Why is it necessary to store personal data (i.e., firstname, lastname and date of birth) inside the QR code?
• Do you see any risk, that this QR code might unintentionally be exposed to unauthorized persons, for example by posting photographs with the QR code to facebook ("Look, my first rapid test!") or by presenting it to fraudulent fake gate keepers, and personal data could be disclosed?
• Why was an approach different from PCR test chosen, which obviously does not contain directly linkable personal data?
• If the personal data inside the QR code is necessary, why did you not choose an approach, where the embedded personal data is encrypted for the QR code and can later be decrypted by fetching the decryption key via an (authorized) app/personnel?

If it is indeed intended that the QR code in its current implementation could be used as an entry pass, social engeneering attacks might be possible. A fake gate keeper could scan the QRs en masse with an arbitrary scanning app, extract names and birthdates, find people via telephone books, and use the personal data for better social engeneering attacks like Enkeltrick and alike.

If there is no way to skip or to encrypt the personal data embedded in the QR code for the planned implementation, people must be warned, that the QR code contains personal data and must not be presented publicly or to unauthorized persons (which is not trivial, if blinds, analphabetics or people with language barriers are supposed to be included).

[Ein-Tim]

Is there a plan that the RAT QR code can be used as an entry pass to venues, by presenting it to gate keepers?

I think something like this is indeed planned, see corona-warn-app/cwa-app-ios#2422, which implemented the text:

"Auf Wunsch können Sie über die App Ihren persönlichen Infektionsstatus nachweisen (z.B. negativer Schnelltest). Bitte beachten Sie, dass Sie grundsätzlich nicht zum Nachweis Ihres Infektionsstatus per App verpflichtet sind. Sie können Ihren Infektionsstatus im Rahmen der rechtlichen Bestimmungen an Ihrem Aufenthaltsort auch auf andere Weise nachweisen."

Also, there is the PR corona-warn-app/cwa-app-ios#2437 which introduced a counter which counts how long the test result is already available. Also, it includes this text:

"Sie können den hier angezeigten Befund auch als Nachweis für das Vorliegen eines negativen Schnelltest-Ergebnisses verwenden. Informieren Sie sich hierzu bitte auch über die Kriterien für die Anerkennung von Test-Nachweisen in Ihrem Bundesland. [...]"

[Ein-Tim]

Related Issue:

• Rapid test integration - documentation cwa-wishlist#449 - Rapid test integration - documentation

[vaubaehn]

Thanks, @Ein-Tim , you're like a walking library 😁

[vaubaehn]

@dsarkar
Hi Dipankar, I hope you had a nice start into the week!
Do you plan to refer this issue to the people in charge? I think would be good not to loose too much time, as RAT implementation for release 2.1 already started.
This is also related and additionally illustrates my questions/doubts/concerns: corona-warn-app/cwa-wishlist#463
Thank you, and have a nice day!

[Ein-Tim]

To add one thing here:

Please clarify with Apple & Google if there is a problem with the non-anonymity of the RAT integration.
It is planned that the following personal data is needed: first name, last name, date of birth (see also OP).

[vaubaehn]

@heinezen
Hi Christoph, as @dsarkar seems to be off-charge at the moment - could you provide a short feedback if this issue is already under evaluation/consideration in the associated departments?
Sorry for my impatience, but I think the here discussed points have a non-negliable importance for the further implementation of RAT and I don't want CWA to run into any kind of trouble here..
Thanks a lot, V.

[heinezen]

I guess we'll answer here finally, sorry for the delay

Is there a plan that the RAT QR code can be used as an entry pass to venues, by presenting it to gate keepers?

It is intended as a proof, but then it got superseded by the EU-wide implementation via DGC. There have been a lot of changes in the past 2 months, so the idea of how exactly it was intended to be used might have changed.

Why is it necessary to store personal data (i.e., firstname, lastname and date of birth) inside the QR code?
Why was an approach different from PCR test chosen, which obviously does not contain directly linkable personal data?

The personalized RAT result is a proof that you made a negative antigen test (legislation may vary between federal states). Unlike the non-personalized RAT and PCR-test results it is not only used for your own information. The personal information is supposed to be cross-checked by the verifier using your ID card.

Do you see any risk, that this QR code might unintentionally be exposed to unauthorized persons, for example by posting photographs with the QR code to facebook ("Look, my first rapid test!") or by presenting it to fraudulent fake gate keepers, and personal data could be disclosed?

Yes, we have seen quite a few examples of that with different QR code types (vaccination + rapid test) by now. However, all digital proofs are only valid in combination with an ID card (e.g. passport) that must be checked by the verifier. Therefore, even if an adversary can recover a certificate, they cannot use it effectively if all verifiers follow a standard process.

Disclosure of personal data is a problem that we are trying to address. Unfortunately, a lot of people don't think about the consequences of sharing their certificates on social media. I don't think they are fully to blame here because not everyone knows how QR code encoding works or is aware that they are sharing not only their proof, but basically a universal proof with their data on it. With the EU certificates we are trying to mitigate this by including as little information as possible while also spreading some awareness about the secure handling of QR codes.

---

Corona-Warn-App Open Source Team

[heinezen]

If the personal data inside the QR code is necessary, why did you not choose an approach, where the embedded personal data is encrypted for the QR code and can later be decrypted by fetching the decryption key via an (authorized) app/personnel?

From a cryptographic perspective, keeping information confidential with one untrusted party (i.e. the verifier) is not as easy as you think. We have to assume that the verifier is untrusted because the RKI cannot authorize every restaurant owner or event organizer manually, and even if they could, the chance that the key gets leaked increases with every new person involved. Same with an authorized app where you can just extract the key.

[ndegendogo]

Well - unfortunately, the European solution was specified under much time pressure and did not address this well. They could have designed a solution with a trusted verifier instead. Some kind of cryptographic protocol, where the verifier proofs itself trusted towards the wallet, and only then the wallet discloses personal data.
Now with the current spec this kind of extension is indeed hard, if not impossible. As long as we have a requirement of backward-compatibility, a rogue verifier can always claim itself as 'version 1', and will get all data without such an authentication step.

Question: How much are the cwa developers involved (and will be heard!) in this kind of discussion for the European specs?
Do you think there is a chance of improvement, or is it too late?
Would maybe other ways of discussing such topics be more promising, like from the political or legal side (or Datenschutz-Beauftragte or similar)?

[Ein-Tim]

@vaubaehn Please decide how to proceed with this now one year old issue.