3 way handshake
Closed this issue · 7 comments
What you don't want is that an authorized healthcare provider gives out a paper to an infected citizen and the citizen does not use the paper. Now somebody else can report bogus information. What if the citizen gives a generated code to the healthcare provider as 1 part of the transaction? Now that citizen can report using the paper and his/her generated code. Only when the 2 come together in the backend the information is validated.
The reason for thinking this way is that I read about concerns with "cry wolf" actions, abused beacons etc. Somehow we need to close that loop, preserving privacy of course.
I'm not sure how likely that scenario is. To abuse this an attacker will need to 1) identify multiple people who have been positively tested and 2) get a hold of the paper. That does not feel like a very likely thing to happen.
Keep in mind that the Apple/Google proposal works with three 16-byte (128 bits) keys.
- A device specific tracing key (tk) that never leaves the device.
- A daily tracing key (dtk), which is derived from a combination of tk and a day-number (details are in the specification documents).
- A rolling proximity identifier (RPI) which is derived from dtk and is then sent out over bluetooth.
The tracing works by submitting one dtk to the backend-server for each day a patient's infection is active.
However: Their standard allows for generation of all relevant dtk's in a single instant, because the app can simply generate all relevant dtk's in an instant by adding or substracting from the day-number.
This means that we can work with short-lived tokens that can be distributed by showing them on a monitor of a healtcare provider in the form of a string and/or QR-code.
This way we will always have an authenticated account of a healthcare provider active when keys are submitted to the backend, and we can simply receive all relevant keys for any required date-time interval in a single POST-request at a single point in time.
This means that the transaction of uploading keys has to take place at the healthcare provider, without the possibility of cleaning up like in the DP3T proposal.
This means that the transaction of uploading keys has to take place at the healthcare provider, without the possibility of cleaning up like in the DP3T proposal.
It's also possible to provide the user with an inactive authentication code, but the healthcare provider has to generate those.
However, we should be careful, because a piece of paper with an inactive authentication code (or the printer that it comes out of) could potentially become a fomite. This means that we might make things worse by slipping pieces of paper around.
This is why I think it would be better, to show a QR-code or a number on a screen. The QR-code can be scanned without contact if the patient is present and a string of numbers can be provided by phone (or even a text-message) by the healthcare provider without the need for physical contact. Both only need to be valid for a very short amount of time.
Also the DP-3T does not specify that a user should be able to retract day-keys after they have been submitted. This might even be undesirable from a public health-perspective.
But we do need something to "remove" keys after the fact, because users will make mistakes that have to be corrected.
If the apps process the data in a decentralized way, than the only way to "delete" keys, is by publishing them as "retracted", which is something we could easily do.
But first of all, lets think about which protocol we will be implementing. We can choose between PEPP-PT, DP-3T and the Apple/Google protocol announced here: https://www.apple.com/newsroom/2020/04/apple-and-google-partner-on-covid-19-contact-tracing-technology/
I expect that a system which uses OS components and has support from both major OS-vendors will probably give superior results. It also appears to be very similar, but better thought-out than DP-3T. Especially with regard to the privacy protections and cryptography used.
Also read this summary https://twitter.com/benadida/status/1249067484679794688 which was retweeted by @ahupowerdns on his twitter account.
I think I might have solved this as well with #11.
Let me know if there are any further comments.
Indeed