URL Scheme in QR Code

[mrlnc]

Current Implementation

QR Codes on Muster OEGD and Muster 10C currently encode the test GUID like this:
https://localhost/?3D6D08-3567F3F2-4DCF-43A3-8737-4CD1F87D6FDA

Scanning the QR code with the smartphone's camera app does not work; the smartphone attempts to open the URL in a browser:

Suggested Enhancement

Add a custom URL scheme corona-warn-app:// to the apps. QR codes should include the URL scheme, open CWA and directly add the test.
corona-warn-app://?3D6D08-3567F3F2-4DCF-43A3-8737-4CD1F87D6FDA

That also removes any ambiguity if the test GUID is supposed to be scanned by CWA or any other application. For backwards compatibility, CWA's QR scanner can accept the old URLs.

Possibly, the QR code could also contain a website link like https://coronawarn.app?test-guid=123. The website then opens the app if the app is present, or show installs instructions if the app is not yet installed.

Expected Benefits

Frictionless QR code scanning with the system's camera.

Related

URL Scheme for app provisioning removed:
corona-warn-app/cwa-app-ios#199

QR Code validation:
corona-warn-app/cwa-app-ios#1386

---

Internal Tracking ID: EXPOSUREAPP-5774

[thomasaugsten]

Because of security reason we are not allowed to use urls or url schemas in the qr codes because if the app is not installed the url schema requests are logged by Apple or the used url can be logged via proxy or on the webserver

[mrlnc]

Scanning QR codes with the system's camera is a standard procedure that many people know. When people choose to scan the code with a third-party application, there's nothing the CWA can do to prevent leakage. But it could make things easier for people who already have the CWA installed.

Having a link to the CWA's web server should not be an issue by itself; there could be a subdomain without logging.

[daimpi]

@mrlnc
iiuc the threat model here is not a malicious QR app but rather a malicious web proxy and/or OS logging of web requests. Dunno how problematic/likely this is though 🤷.

[wienand]

How could a malicious web proxy log contents of https requests? And if, would that not extend to all traffic from the app? OS logging of QR code deferrals to Safari, I dunno. And even if, it would just convey that a test with a certain GUID is scanned and the result for the GUID is only available for two weeks. After that periods the GUID just tells you that there most likely was a test for someone related to the smartphone user.

…

On Fri, Oct 23, 2020 at 7:02 PM Daniel Frey ***@***.***> wrote: @mrlnc <https://github.com/mrlnc> iiuc the threat model here is not a malicious QR app but rather a malicious web proxy and/or OS logging of web requests. Dunno how problematic/likely this is though 🤷. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#224 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA2EU6LIALWSTWEBLKZ4JO3SMGZLPANCNFSM4S3BM2NQ> .

[daimpi]

How could a malicious web proxy log contents of https requests? And if, would that not extend to all traffic from the app?

I'm not sure but isn't all the info of a QR code contained in the link it queries? And can't a proxy server just grab that link and have all the info, even when it's a https address?

And if, would that not extend to all traffic from the app?

When it comes to the app communicating with the server: I don't think so, this communication is all encrypted and iirc CWA is even broadcasting decoy messages such that you cannot even learn whether a person entered their test from traffic analysis.

OS logging of QR code deferrals to Safari, I dunno.

I'm also not sure… I mean on some level you anyway have to trust Google/Apple not to do something fishy b/c they're providing you with the Exposure Notification Framework (ENF) so they could do all kinds of things on that level if they want… not sure what to think of that or if this is even the threat model they have in mind tbh 🤷

[wienand]

How could a malicious web proxy log contents of https requests? And if, would that not extend to all traffic from the app?

I'm not sure but isn't all the info of a QR code contained in the link it queries? And can't a proxy server just grab that link and have all the info, even when it's a https address?

And if, would that not extend to all traffic from the app?

When it comes to the app communicating with the server: I don't think so, this communication is all encrypted and iirc CWA is even broadcasting decoy messages such that you cannot even learn whether a person entered their test from traffic analysis.

Everything except the IP address and maybe host name via SNI (or also detectable by DNS monitoring) is encrypted (also everything after the host name in an URL). If a proxy want to decrypt that stuff it has to possess a root certificate trusted by the user in order to issue a certificate for the host name on the fly (this is used in corporate environment in oder to finde encrypted command&control traffic or malicious downloads).

The app itself also uses https requests but never transfer the GUID in clear writing but only a hash. But afaik the hash is fixed and can therefore from an attacker point of view equally be used to the result.

As for logging of QR codes deferrals from the camera app to the browser: This also happens with the localhost prefix. If this is an attack vector, the QR-code should not encode an url at all.

[daimpi]

@wienand

Everything except the IP address and maybe host name via SNI (or also detectable by DNS monitoring) is encrypted (also everything after the host name in an URL).

Thanks for the information, I didn't know that 🙂

As for logging of QR codes deferrals from the camera app to the browser: This also happens with the localhost prefix. If this is an attack vector, the QR-code should not encode an url at all.

I also didn't know that, thanks 🙂.

Taking those together I really don't understand which threat model they possibly could be trying to mitigate here 🤷

[mrlnc]

Scanning within CWA can still remain the default way for most people, and the most secure. An URL scheme / universal link could reduce friction for users who scan the code using the system camera.

Just for reference:

• iOS docs on URL Scheme like corona-warn-app://<GUID>: Defining a Custom URL Scheme for Your App
• iOS documentation for universal links like https://www.coronawarn.app?guid=<GUID>: Allowing Apps and Websites to Link to Your Content
• Android docs: Handling Android App Links

[thomasaugsten]

The issue is still with URL Scheme that Apple can see the GUID and with universal link the owner/admin/hoster of the website can see the GUID

[mrlnc]

I do understand that the additional transfer is unnecessary from a technical point of view. I'm still wondering however if the overall risk is any different when using a universal link -- after all, CWA is the owner and the QR-Code could point to a host that sits somewhere next to your API endpoints… secure.coronawarn.app (or testresult.coronawarn.app )

Anyway, I did want to point out a potential usability issue here and I'm not aware of all the security implications when using iOS/Android app links.

[mrlnc]

@dsarkar what input specifically?

[mrlnc]

to clarify: I am not suggesting to give the main webserver https://coronawarn.app access to the GUID.

Instead, a separate instance (e.g., on testresult.coronawarn.app) serves a static information page ("download CWA to access test results. scan the QR-code using the CWA."). no GUID logging; same policies apply like for the API-endpoint where the GUID goes anyway.

• if CWA is installed, the universal link is opened by the app immediately and the website is never accessed
• if CWA is not installed, the user can read the information and install CWA.
  the default still is to scan the QR-code directly using the app.

[dsarkar]

@mrlnc, will bring this up internally. Thanks for contributing.

[MikeMcC399]

It seems the security concern is that if the QR code does not contain the prefix https://localhost/? and if it is scanned by a QR reader app instead of the CWA app, then the GUID would be transmitted in plain text over the Internet where it could be recorded and misused. For instance, somebody else could then register the test, preventing the person being tested from receiving the test result via CWA. Or the other person could find out the result of the test, which would breach health-data privacy.

Strangely, this point is not covered at all in the CWA Datenschutzfolgenabschätzungsdokument. It just discusses hashing the GUID before transmission takes place.

[daimpi]

@MikeMcC399

It seems the security concern is that if the QR code does not contain the prefix localhost? and if it is scanned by a QR reader app instead of the CWA app, then the GUID would be transmitted in plain text over the Internet where it could be recorded and misused.

This was also my first thought but this doesn't seem to be an actual problem as @wienand explained above:

Everything except the IP address and maybe host name via SNI (or also detectable by DNS monitoring) is encrypted (also everything after the host name in an URL).

[MikeMcC399]

@daimpi
Thanks for pointing out my incorrect interpretation of https request encryption!

Does anybody know how many software application packages are in production use, printing Corona Test QR codes? I suspect there are many, so that any change to the GUID code formatting affects not just the CWA app, but also lots of different software houses. From what I understand, the Kassenärztliche Bundesvereinigung are the ones setting the standard for what gets printed on the Corona test forms (10C / OEGD).

[Ein-Tim]

At least the arguments reg. security should be obsolete now since rapid antigen test results have a custom URL scheme so that the QR-Code can be scanned with the native camera app or any QR-Code scanner. Some testing sites even offer to import the test result via a link (s.coronawarn.app).
The same goes for event-registration QR-Codes (e.coronawarn.app).

I don't see a reason why this wouldn't be possible for PCR QR-Codes too. As also already said by @mrlnc, the in-app QR-Code scanner could also continue to scan the localhost QR-Codes for backwards compatibility.

This seems feasible for me, or am I missing something?