search

corona-warn-app / cwa-documentation

Project overview, general documentation, and white papers. The CWA development ends on May 31, 2023. You still can warn other users until April 30, 2023. More information:
https://coronawarn.app/en/faq/#ramp_down
Apache License 2.0
3.28k stars 344 forks source link

[SOLVED] Version 2.4 announcement blog post - RAT/PCR-DCC "Encryption" #647

Closed vaubaehn closed 1 year ago

vaubaehn commented 3 years ago

I'm asking here, because I don't know yet, whether there is an issue in the blog post or not regarding technical description of transmitting, signing and decoding a RAT/PCR-DCC from test lab to "RKI" and to CWA. And because it's quite technical, it may fit here best for now.

Where to find the issue

https://www.coronawarn.app/en/blog/2021-06-24-cwa-version-2-4/

Please note: To create the test certificate, the data is encrypted end-to-end and transmitted from the lab or the rapid test site to the Corona-Warn-App. For this purpose, the encrypted data is transmitted to the Robert Koch-Institut (RKI) in order to digitally sign it and thus confirm the certificate’s validity. The RKI cannot decrypt the data, which will be deleted after the certificate has been delivered.

https://www.coronawarn.app/de/blog/2021-06-24-cwa-version-2-4/

Wichtig: Zur Erstellung des Testzertifikats werden die Daten Ende-zu-Ende verschlüsselt und vom Labor, beziehungsweise der Schnellteststelle an die Corona-Warn-App übermittelt. Dafür werden die verschlüsselten Daten an das Robert Koch-Institut (RKI) übermittelt, um sie digital zu signieren und so die Gültigkeit des Zertifikats zu bestätigen. Die Daten können vom RKI nicht entschlüsselt werden und werden nach Zustellung des Zertifikats gelöscht.

Describe the issue

As far as I understand data structure, encoding, signing and transmission of DCCs, above descriptions are not correct. I assume the RAT/PCR-DCCs have following COSE structure:

(Taken from here: https://pycose.readthedocs.io/en/latest/cose/messages/sign1message.html)

As far as I know, CWA does not make use of any Document Signer Certificates (DSCs) or any other forms of certificates for cryptography yet, thus the payload of the DCC will need to be in plain text for displaying contents in CWA. It is encoded (and can be decoded), but it is not encrypted (hence will not be decrypted). This means, the "RKI" is always able to "read" the contents of the DCC while it is processing the signing and then transmitting it to CWA. But for sure the data will be immediately erased after signing and transmitting to CWA, no doubt. The test lab could encrypt the data before sending them to "RKI" for signing - in that case the test lab may have obtained a certificate for encryption from "RKI". But I assume that "end-to-end encryption" in the text above refers to the https transfer between these two endpoints? Encrypting the data then would be a second encryption layer, that is probably unnecessary, as "RKI" sends an unencrpted DCC to CWA?

If my assumptions are correct, should the blog post be corrected/made more precise then?

I think, @thomasaugsten or @mlenkeit could help here...

Thank you very much in advance, and have a nice week-end!

vaubaehn commented 3 years ago

After pressing "submit", it just comes to my mind: Are the DCCs actually encrypted - with the birthdate?

thomasaugsten commented 3 years ago

The content of DCC is encrypted. The device will create and private and public for each DCC request. In case of a negative result the user device will upload the public key to the test lab. The test lab will encrypt the DCC and the user can decrypt the DCC with the private key. On the transport nobody can decrypt the DCC. The birthday is necessary to have unique identifier in the test id of an pcr test

vaubaehn commented 3 years ago

@thomasaugsten Thank you very much - that's amazing. That was completely out of my sight when peeking to the code. Have a nice time!

vaubaehn commented 3 years ago

But still: won't RKI need to sign the unencrypted DCC to be compliant with the ehn-schema? If "RKI" signed an encrypted DCC, the signature would get invalid for veryfing the "regular" (unencrypted) DCC object?

thomasaugsten commented 3 years ago

RKI is signing the hash not the complete certificate

vaubaehn commented 3 years ago

@thomasaugsten Thanks again!

RKI is signing the hash not the complete certificate

That was also how I understood it earlier. In this case, the blog post is a bit misleading in this special detail:

Dafür werden die verschlüsselten Daten an das Robert Koch-Institut (RKI) übermittelt, um sie digital zu signieren

I will think about, whether that sentence may be improved and continue in website repo accordingly.

@dsarkar @heinezen Could be nice to leave this issue here open for a while for information purposes, but please close anytime you feel it's suitable.

Ein-Tim commented 2 years ago

@vaubaehn I think the time has come to close this issue. 🥲

MikeMcC399 commented 1 year ago

@vaubaehn already wrote:

Could be nice to leave this issue here open for a while for information purposes, but please close anytime you feel it's suitable.

So I suggest to close the issue now.