📊 Diagram: Corona Warn App (CWA)

🔗 Link to Original Paper/Article

View Full Main Source

📝 Short Description

This diagram illustrates the complex data flow of the Corona-Warn-App (CWA), as stated in their documentation. The architecture is divided into three main components: Corona-Warn-App, Verification Server and Corona-Warn-App Server. The first one runs on the user's mobile phone. This component is responsible for scanning nearby users' keys via Bluetooth Low Energy (BLE), interacting with the Exposure Notification Framework, and communicating with the Data Donation Server. The second one verifies test results received from the Test Result Server. The last one receives diagnosis keys from the CWA and analytics data from the Data Donation Server. It stores this data and, via the Content Delivery Network (CDN), makes it available to other users, allowing them to determine whether they have been in contact with someone who tested positive.

🔤 Abbreviations

• TEK: Temporary Exposure Key
• RPI: Rolling Proximity Identifier
• AEM: Associated Encrypted Metadata
• TAN: Transaction Authorization Number
• RAT: Rapid Antigen Test
• EDUS: Event-Driven User Survey Service
• PPA: Privacy-Preserving Analytics
• OTC: Open Telekom Cloud
• BLE: Bluetooth Low Energy

📖 Extensive Description (if possible)

The diagram can be divided into different sections. The first one, in the upper-right part of the diagram, is related to the CWA Data Donation Server Interface, in which depending on the users mobile phone OS a certain data flow is followed. For example in the case of an Android OS, the Google Service node generates an attestation_token which flows to the Google Attestation API. From this node the attestation_token is forwarded to the Send Attestation Token node which sends the token to the Send PPA and Send OTP for EDUS, which are the two framewroks for collecting data. In addition to the attestation_token these nodes also receive salt from the Generate Salt node (and forwarded by Send Salt node) which is added to the token for security reasons. In the case of Apples OS the main idea is simmilar but with other nodes and functions. From the PPA and EDUS nodes the ppa data and the respective EDUS tokens finally flow to the CWA Data Donation Server Interface. From this point on, again depending on the OS, there is some verification/checking of the sent tokens, but most importantly the connection to the Corona Warn App Server. This connection is done through the Analytic Data Storage which receives the analytic_data from the CWA Data Donation Server Interface and forwards it to the Generate Statistics node, which itself forwards this data to the C__Corona Warn App Server__.

The central (including left) part of the diagram focuses on the main data flows for the main tasks of CWA belonging to the test results functionality, creating/receiving the different identifiers for the user regarding their status. Here the most important nodes are the Test Result Server, which is responsible for receiving and transmitting the results from the Laboratory Information System and forwarding them to the Verification Server. This server receives the pcr test results, RAT test results which can be directly uploaded by the user and the TAN identifier and forwards them to the Corona Warn App (the test results) and the Health Authority Portal (the teleTAN) and the Upload Keys (normal TAN) nodes. The Corona Warn App is mainly responsible for sending th ekeys which reflect the users state, evaluating the risk of the user given his/her encounter with other (possibly infected) users.

Finally the right-most side of the diagram shows the process of the distribution of the keys generated by the user thorugh the Exposure Notification Framework, which is the joint API/framework by Google and Apple that all national apps are built on. This node is responsible for: Receiving the RPIs via the BLE Interface and sending the identifier through the Send Bluetooth Payload. Logging the foreign RPIs, their storage in Foreign RPIs Storage node and their later comparison in the Compare Keys node to create a risk summary for the user.

A further and deeper understanding of the different components can be studied in their documentation (link above).

🏷️ Label description

• 🗂️ Data Labels:

  • Identifiers:

    • GuidQR: QR for the test results
    • PersonalData: Personal data from the tested patient
    • CWATestId: Test ID from the Corona Warn App
    • RPI: A short-lived identifier derived from the TEK (changes every ~10–20 minutes). These are what phones actually broadcast via Bluetooth.
    • TEK: A secret key generated once per day on your phone. It never leaves your device except when you report a positive test.
    • AEM: Extra information sent together with the RPI over Bluetooth

  • Tokens:

    • RegistrationToken: Registration for the app
    • TAN: A one-time code you get (e.g., via hotline or test result portal) that authorizes your app to upload your TEKs if you tested positive.
    • DiagnosisKeys: These are simply the TEKs from the days you were infectious that you upload
    • TeleTAN: A TAN given verbally by phone (via hotline) when your test result cannot automatically trigger a normal TAN
    • DiagnosisKeyBatch: Batch of Diagnosis Keys
    • AttestationToken: A cryptographic proof issued by the Google/Apple Exposure Notification (GAEN) framework.
    • APIToken: In Corona-Warn-App, this is a temporary token from the CWA server that the app uses to prove it already passed the TAN validation step.
    • OTP: A short-lived code used once in the verification process (e.g., during TAN/TeleTAN exchange). It prevents replay attacks when requesting tokens.
    • DeviceToken: A persistent identifier assigned per device to prevent abuse of the verification system (e.g., requesting too many TANs).
    • Salt: A random value added when hashing data (e.g., during device token creation) to ensure uniqueness and resist pre-computation attacks

  • TestResults:

    • PCRTestResultsPositive: PCR positive test results
    • RATTestResults: Results of the RAT test

  • UserConfigurations:

    • NotificationsOn: User allows to receive notifications from the app
    • AllowUploadKeys: User allows the app to upload its keys
    • AllowPersonalData: user allows the app to use its personal data

  • Encrypted:

    • Metadata: Metadata sent from the app

  • Information:

    • RiskSummary: Summary of potential risk for the user based on the received keys from other users
    • APIsMetadata: Metadata from the APIs
    • EDUS: Token for EDUS (backend-service for collecting data surveys from users)
    • PPA: Same as previous but for PPA (for collecting app usage statistics in a privacy-preserving way)
    • AnalyticData: Analytic data from the users to generate statistics
    • SurveyData: Data from the survey of the users

  • DiagnosisKeys:

    • Local: Diagnosis Keys from within germany
    • Foreign: Diagnosis Keys from other countries (normally within the UE)

• 🏷️ Node Labels:

  • MobileOS:

    • IOS: Apple Operating System
    • Android: Androids Operating System

  • Server:

    • CWApp: Corona Warn App in the users mobile phone
    • CWAppServer: Corona Warn App central servers
    • VerificationServer: Server where the test results are verified
    • DDServer: Diagnosis Data Server
    • AppleServer: Server from Apple for managing their API
    • Androiderver: Server from Android for managing their API
    • TestResultServer: Server for managing the test results coming from the laboratory
    • ForeignCountryServer: Server for the Covid app from a foreign country
    • SurveyBrowser: Browser where the survey takes place
    • SurverySystemEDUS: Survey System for the EDUS
    • GoogleServer: Googles server for the Attestation API

  • Cloud:

    -OTC: Hosting environment in the cloud for the CWApp backend

⚠️ Constraints

• RPI and TEK identifiers may never flow to the CWA or CWA Server for privacy reasons:

  1. RPIs_TEKs: data Identifiers.RPI,Identifiers.TEK neverFlows vertex Server.CWApp,Server.CWAppServer

• Personal data shuld never flow to the CWA (in the mobile phone), Verification server, Test Results Server, DD server and CWA server.

  2. Personal_Data: data Identifiers.PersonalData neverFlows vertex Server.CWApp,Server.VerificationServer,Server.TestResultServer,Server.DDServer,Server.CWAppServer

🚨 Violations

Although no violations were found in the original CWA architecture, we have slightly modified the diagram to produce two alternate versions in which violations are introduced:

• The first diagram, RPIViolation, illustrates a breach in which RPIs (Rolling Proximity Identifiers) flow into the CWA Server. This is a clear violation, as RPIs could potentially be linked back to individuals, undermining the anonymity and privacy principles of the original CWA.

  1. data Identifiers.RPI neverFlows vertex Server.CWAppServer

• The second diagram, PersonalDataViolation, shows a case where personal data from the user's mobile device flows into the CWA (via the Verification Server). This is another violation of the strict privacy guarantees provided by the real CWA.

  2. data Identifiers.PersonalData neverFlows vertex Server.CWApp,Server.VerificationServer,Server.TestResultServer,Server.DDServer,Server.CWAppServer