High level privacy and security design for NHS Covid-19 contact tracing app
ncsc.gov.ukSome high level observations on their design:
They use Bluetooth identifiers that last for 24 hours, which breaks Wifi/Bluetooth MAC rotation and allows 3rd parties to track users.
They require a connection to be established between each pair of devices and need to ping the same device again and again to check you are still in proximity. That's going to be alot of wakeups for each person you come into contact with.
They broadcast a country code in plaintext, so any international deployment would reveal the probable nationality of nearby users.
It requires NCSC / the NHS to hold a master key which they can use to reveal the identifier of any individual using the system. I think that poses a real risk of mission creep, where they start using contact tracing data for criminal investigations etc.
They also make a number of misleading claims about the decentralised solutions being deployed by Estonia, Germany, Switzerland, etc:
Claim 1: Decentralised systems without authenticated diagnosis reports can't manage malicious notifications. This is true, but all the proposed decentralised systems use authenticated diagnosis reports. Interestingly, its totally unclear how they plan to manage "anonymous" unauthenticated reports in their centralised systems. How do you distinguish between a supermarket worker or a nurse visiting homes who came into contact with a lot of people and a relay attack? Surely any centralised post-hoc verification is going to be highly invasive to individual privacy?
Claim 2: Decentralised systems introduce delays in the reporting of symptoms. This just isn't true.
Claim 3: Second Order Contact Tracing isn't possible in a decentralised system. Again, just not true. It is actually easier in a decentralised system than in a centralised one, where it carries much more difficult privacy trade-offs.
Lively comment thread re Register article on this:
Techincal paper is here - https://www.ncsc.gov.uk/files/NHS-app-security-paper%20V0.1....
I think this is a quite reasonable design that also takes into account basic privacy concerns.
I can see the central component can be used to better protect against certain spam-like attacks as mentioned under the section "Notification issues". And also can provide potentially better tracing as mentioned in the section "Centralised vs Decentralised".
For example (from the paper) in a decentralised approach how would you protect against:
The targeted false alerts problem
Assume an attacker wishes to target a particular user and cause them to self-isolate. They can get sufficiently close to the target to create a proximity event that will score as high risk. If the attacker self-decalres symptoms, in the process submitting this contact event, the target will be notified to self-isolate
The mass notification problem
Consider a malicious user, who can collect broadcast identities from around a particular area, such as a hospital, and record them all.
They can register a malicious pseudo-device and generate realistic-looking but entirely fake contact events for all the BroadcastValues it has observed.
> The targeted false alerts problem
You require, for example, a registered healthcare provider to approve the act of marking yourself as symptomatic. Which basically means that you can't mark yourself as symptomatic unless a doctor agrees/diagnoses you, which is a good idea anyway, given the amount of people who are like "my flu in december must have been COVID".
But that would be a quite a different app from what is described here; as far as I can see self-diagnosis is how you use the app.