Full Report
NCSC technical paper about the privacy and security design of the NHS contact tracing app developed to help slow the spread of coronavirus.
Analysis Summary
# Research: High level privacy and security design for NHS COVID-19 contact tracing app
## Metadata
- **Authors:** Ian Levy (Technical Director)
- **Institution:** National Cyber Security Centre (NCSC) / NHSx
- **Publication:** NCSC Technical Paper
- **Date:** 4 May 2020
## Abstract
This report outlines the technical architecture and privacy-preserving mechanisms of the first iteration of the NHS COVID-19 contact tracing app. It details a "centralized" approach to digital contact tracing, designed to balance individual anonymity with the epidemiological need to understand the spread of the virus. The paper justifies the security controls implemented to prevent deanonymization, spoofing, and data misuse.
## Research Objective
The research addresses how to design a smartphone application that can accurately record proximity between users to assist manual contact tracing efforts, while ensuring:
1. **User Privacy:** Preventing the government or third parties from tracking individuals’ movements or identities.
2. **System Integrity:** Preventing malicious actors from triggering false alerts (trolling) or flooding the health system with fake reports.
3. **Epidemiological Utility:** Providing health authorities with sufficient (anonymized) data to refine risk models and understand transmission patterns.
## Methodology
### Approach
The NCSC utilized a "security-by-design" methodology, conducting a risk assessment of both centralized and decentralized contact tracing models. The approach involved architectural modeling of Bluetooth Low Energy (BLE) handshakes and cryptographic key management.
### Dataset/Environment
The design focuses on the UK population's smartphone ecosystem (iOS and Android). The study examines the interaction between distributed mobile devices and a centralized NHS backend server.
### Tools & Technologies
- **Bluetooth Low Energy (BLE):** For proximity detection.
- **Elliptic Curve Cryptography (ECC):** Specifically ECIES (Elliptic Curve Integrated Encryption Scheme) for secure registration.
- **HMAC (Hash-based Message Authentication Code):** For integrity checks.
- **Daily Installation Keys:** A hierarchical key structure to limit the exposure of data.
## Key Findings
### Primary Results
1. **Privacy through Ephemeral IDs:** The app uses rotating, encrypted identifiers (Broadcast IDs) so that a static identity is never broadcast over the air.
2. **Centralized Risk Calculation:** Unlike the Google/Apple (GAEN) model, the calculation of "who is at risk" happens on a secure server, allowing the NHS to tune the algorithm as clinical understanding of COVID-19 evolves.
3. **Resistance to Replay Attacks:** By including a timestamp in the broadcast payload, the system limits the ability of attackers to record and "replay" a proximity event elsewhere.
### Supporting Evidence
- The architecture uses a **Registration ID** (Linking a device to a push notification token) which is separate from the **Installation Key** used to generate the daily broadcast tokens, creating a layer of separation between identity and activity.
### Novel Contributions
- **Epidemiological Calibration:** The system was designed specifically to allow "risk-scoring" to be updated centrally without requiring an app update, a critical feature during the early phases of a pandemic when transmission parameters (distance/time) were frequently changing.
## Technical Details
The system operates on a multi-tier key structure:
- **Registration:** Upon install, the app generates an Elliptic Curve key pair. The public key is sent to the backend, which returns an encrypted **Installation ID**.
- **Proximity Logging:** Devices exchange **Broadcast IDs** via BLE. These IDs are derived from a daily key and are rotated frequently to prevent "static" tracking by third-party beacons.
- **Upload Trigger:** When a user tests positive, they upload their log of "seen" IDs. The server then identifies which users were in proximity and calculates a risk score based on the received signal strength (RSSI) and duration.
## Practical Implications
### For Security Practitioners
- The paper demonstrates that **centralized models** are not inherently "insecure" but shift the trust boundary to the central authority. It emphasizes the importance of hardware-backed security (Secure Enclave/TEE) for storing long-term keys.
### For Defenders
- Actionable insights include the use of **authorization codes** delivered via SMS/offline channels to prevent fraudulent "positive" status reports, ensuring only those with verified tests can trigger alerts.
### For Researchers
- This work highlights the inherent tension between **data utility for public health** (centralized) and **maximum privacy for the individual** (decentralized), providing a framework for evaluating these trade-offs in future public health crises.
## Limitations
- **Power Management:** The paper acknowledges the difficulty of keeping BLE active in the background on iOS devices without the official Apple/Google framework.
- **Trust Requirements:** The model requires users to trust that the central NHS server will not attempt to correlate IP addresses or push tokens with proximity data.
## Comparison to Prior Work
This design differs from the **DP-3T (Decentralized Privacy-Preserving Proximity Tracing)** model. While DP-3T processes risks on the device, the NHS design centers risk calculation on the backend to allow for "aggregated, anonymous insights" into how the virus spreads—data that is largely lost in fully decentralized models.
## Real-world Applications
- **Public Health Management:** Integration with national testing databases to automate the notification of potentially infected individuals.
- **Privacy Auditing:** The commitment to open-sourcing the code allows for independent verification of the claims made in the design document.
## Future Work
- Migration considerations toward the Google/Apple Exposure Notification (GAEN) framework if background BLE performance issues persist.
- Development of "Self-report" mechanisms that allow users to report symptoms before a formal test result is available.
## References
- NCSC/NHSx Technical Documentation (v0.1)
- [hxtps://www.ncsc.gov.uk/report/nhs-covid-19-app-privacy-security-report]
- [hxtps://github.com/nhsx/covid-19-app-documentation-internals] (Note: Historical reference for source code).