Thread by @nipafx

Yesterday evening, we spent about two hours digging through the German #Corona app and I'm thoroughly impressed. This is a modern project, developed out there as free software (APL 2.0) on GitHub, and it has stellar documentation.

github.com/corona-warn-app

Let's have a look! 1/🧵

Android and iOS apps use Google's/Apple's Exposure Notification Framework (ENF; google.com/covid19/exposu…, apple.com/covid19/contac…). Android app is written in Kotlin, iOS app in Swift. (Can't tell you much more because I'm clueless about mobile.)

2/22

Backend services:

* Java 11, Maven, Sonar, Jenkins
* Open Shift, Kubernetes, Docker
* Postgres, H2, Liquibase
* Spring Boot, Lombok, Protobuf, Guava
* JUnit 4, Hamcrest, Mockito

3/22

I just skimmed the code for a few minutes. Overall looked very solid - some details I noticed:

* methods a bit on the longer side
* conservative use of `var`
* much imperative use of `Optional`
* preference for unchecked exceptions
* two-space indentation 🤢

4/22

Let's see how the app works ("heavily inspired" by DP-3T, github.com/DP-3T/documents). High-level summary:

* users share non-personally-id'able keys via Bluetooth
* if a user gets sick, they upload their keys to a server
* users download keys and compare to their recording

5/22

Important terms (github.com/corona-warn-ap…):

GUID: one per tested user

Temporary Exposure Key (TEK): one per user per day

Diagnosis Key: TEKs where COVID-positive user was/is infectious

Rolling Proximity Identifier (RPI): derivative of TEK that is shared over Bluetooth

6/22

On to the moving parts (outstanding docs on that:
github.com/corona-warn-ap…). There's the app plus four backend services:

* corona-warn-app server
* verification server
* test result server
* portal server

Let's discuss each.

7/22

Corona-Warn-App (on your 📱):

* generates TEK every 24h
* generates RPI from TEK every 15m
* shares RPI over Bluetooth
* records observed RPIs

(Unlike in the summary, app doesn't share keys but the derived RPIs.)

Most is done by ENF. I'll explain use case flow later.

8/22

Corona-Warn-App Server:

* manages diagnosis keys (i.e. "infected" TEKs)
* lets users upload their diagnosis keys (with TAN; more on that later)
* lets users download all known diagnosis keys (for risk assessment)
* can't identify users and doesn't know their test results

9/22

Verification Server:

* lets users poll for their test results
* if positive, gives them a TAN (later)
* knows hashed user GUID
* doesn't know TEKs or diagnosis keys
* doesn't store test results (but can access via Test Result Server)

10/22

Test Result Server:

* lets labs upload test results
* stores test results
* lets Verification Server check test results
* knows hashed user GUID
* doesn't know TEKs or diagnosis keys

11/22 (half way!)

Portal Server:

* web interface for health authorities
* lets them generate teleTANs (later) for COVID-positive users
* uses Verification Server for that
* doesn't know anything

12/22

Now we know the moving parts, let's see them in action.

First, the proximity recording:

* app generates and shares your RPIs
* app records received RPIs

13/22

Next, risk assessment:

* app regularly downloads Diagnosis Keys from Corona-Warn-App Server
* recreates associated, "infected" RPIs
* compares "infected" RPIs to recorded RPIs
* assesses personal risk of infection

As mentioned, much is done by Google's/Apple's ENF.

14/22

A user gets tested for Corona:

* doctor applies Corona test and sends it to lab
* user and lab get QR code with GUID
* user uses GUID to register for result polling with Verification Server

15/22

If the test is positive:

* lab uploads positivity and hashed GUID to Test Result Server
* lab also informs doctor and health authority
* user gets test result by polling Verification Server (remember: connects to Test Result Server)

16/22

When user receives positive result:

* Verification Server (VS) returned TAN with positive test result
* app prompts user to upload TAN and Diagnosis Keys to Corona-Warn-App Server (CWAS)
* if they do, CWAS checks TAN with VS
* if it passes, CWAS accepts Diagnosis Keys

17/22

When user didn't register with GUID for polling:

* health authority (HA) contacts Portal Server for teleTAN (no personal information shared)
* Verification Server stores teleTAN
* HA gives teleTAN to user
* by entering teleTAN, user can upload Diagnosis Keys

18/22

Notes on TAN/teleTAN:

* they exist to prevent intentional spamming of false positive Diagnosis Keys for the lulz
* registration with TAN lets user see test results very soon
* teleTAN is backup to give users a chance to upload if they didn't use QR code

19/22

Whether registered via QR code or teleTAN, the user now uploaded their Diagnosis Keys (the keys for the days they were deemed infectious) to the CWA server, which will share it with other users. They then use them to see whether they've been in contact.

20/22

Notes on privacy:

* system identifies user by GUID
* users infer proximity from TEKs/RPIs, which aren't personally identifiable
* proximity data only on user devices
* system knows no names, addresses, etc
* connection of name, etc to GUID is only known to doctor and lab

21/22

There's much more in the docs, e.g. about attenuation buckets, risk score calculation, upload schedules, polling intervals, etc. You should really check it out!

* project on GitHub: github.com/corona-warn-app
* overarching documentation: github.com/corona-warn-ap…

22/22 fin

I made a few mistakes on privacy:

* I ignored IP addresses, which the backend can of course access
* GUIDs, test results and TEKs & RPIs (on user phones) are personally identifiable data

Discussions on that:

https://twitter.com/Rainer_Rehak/status/1271045227478953985

https://twitter.com/privacyDE/status/1271117530762018822

Summary: A malicious actor with access to the backend data (e.g. SAP, Telekom, German state) and a way to resolve IPs to actual people (e.g. Google, ISPs) can learn who uses the app and who is infected (German state already knows that, though).