Cwa-documentation: Prevent forwarding of TANs/QR-codes to other users

[wuerzebesser]

Regarding E06.04, E06.05 & E06.06:
It is proposed to allow a user to activate the notifications of other users also via a TAN obtained from a call center.
I want to point out the danger of misuse: A positive tested user can obtain this TAN and forward it to another (non-infected) user, who could then trigger false notifications. (Think about people who want to undermine the system by carrying extra smartphones in densely populated city centres, and activating their false notifications with such a TAN code)
Hence, it should be ensured that there is a proven link between the person, smartphone/app and test, e.g. by having the user to scan the QR-code (or acquire a TAN) in attendance of a health official. (Of course, there is still the risk of users carrying not their normal smartphone)

Regarding E06.01:
Of course, it has also to be ensured the the QR-code can't be forwarded to another user. (This can also be achieved by having the user to scan the code in attendance of a health official)

It would in general be good to also see the documentation of the health centre and server-side user stories.

[TomTeeJay]

already topic of closed issue #34

[wuerzebesser]

Thanks for the fast reply.
Yes, the topic is the same, but issue #34 is mainly concerned about how to identify the user.
I'd like to point out more clearly that there is significant potential of misuse even if the user is identified, by allowing her/him to forward the obtained TAN (or QR-code, if photographed) to another user/smartphone.

[MalteJ]

Honestly, we don't have a plan how to prevent that. The TAN has a limited validity. Therefore you have to prepare your attack days before you get a positive test result.

[pitsch]

The tan use case is taken from DP3T. besides the secure infrastructure and logistics needed to provide doctors with valid keys, the positive test requires a registration at the local health office. it should be the only trust provider as well as a needed backend for authentication and verification of test results. using a system like SORMAS and DEMIS. its a severe design flaw of DP3T which leads to false positives and redundancy and unreliablity in the work flow.

a positive test is at the same time a requirement for registration at the local health office. in terms of throughput they are the local trust center to validate positive covid tests, healh authorities use a federated backend software which can be combined with an authentication backend (OAUTH) in combination with SORMAS. no need for QR codes. and providing each and every doctor in Germany with the needed documentation, hotline service, key certificates and key generator software to print out QR codes.

https://www.rki.de/DE/Content/InfAZ/N/Neuartiges_Coronavirus/Massnahmen_Verdachtsfall_Infografik_DINA3.pdf?__blob=publicationFile

https://github.com/hzi-braunschweig/SORMAS-Project

[TomTeeJay]

Apparently development has already begun in private repositories. Tough I urge stakeholders and decision makers to reduce complexity and get rid of any additional functions beside the single-purpose of a Corona-Warning-App.

That being said here, nobody can claim later that he or she has never heard this recommendation.

[s-martin]

Once a TAN has been used it's not valid anymore, so how would you forward it to others?

[wuerzebesser]

Once a TAN has been used it's not valid anymore, so how would you forward it to others?

• The user obtains the TAN (during a phone call with the proposed call center), but the user never enters this TAN into the own smartphone.
• Instead, the user forwards the (unused) TAN to another user.
• Hence, the TAN is only used once, but on the wrong smartphone.

Similar attack vector possible in case you can't restrict that the proposed QR-codes is photographed instead of entered: Again, a user can forward the QR-code without actually using it on the own phone.

Potential scenario:
Imagine an (probably illegal) online marketplace for trading such TANs/QR-codes.
People could buy such codes to trigger warnings (and effectively enforce quarantine measures) to persons around them like e.g. competitors. They just need to bring a smartphone close enough to them in the previous two weeks, and then activate with such a TAN.

It probably won't be possible to eliminate such attack vectors completely without compromising privacy any further. Nevertheless, you need at least to ensure that these codes can't be forwarded too easily. The whole system will loose credibility, if there are public reports of such attacks.

[s-martin]

You could circumvent this with a limited time a TAN is valid. I would assume https://github.com/DP-3T has already discussed this issue, but I haven't checked yet.

[wuerzebesser]

You could circumvent this with a limited time a TAN is valid. I would assume https://github.com/DP-3T has already discussed this issue, but I haven't checked yet.

Yes, you are right: There is already an analysis on this topic.
(DP3T - Upload Authorisation Analysis and Guidelines.pdf)

They identify a potential misuse scenario (esp. S1D) and present three proposals for mitigation.

• The first two proposals/options are still vulnerable to misuse.
• Proposal 3 (Data-bound Authorisation) would prevent this, but doesn't allow authentication via TANs from a call center, and has very clear requirements regarding the QR-code process.

I wonder, why this is not considered in the current user stories / documentation.

[mh-]

If there is a TAN-from-call-center option, that is not linked to a QR-code, how long is such a TAN (needs to be read out during a phone call), and will you really be able to prevent malicious users from brute-forcing such TANs?

[niklas2810]

Preventing brute-force attacks is quite easy (even though I wonder why anyone would want to do this): You'll get three attempts to enter a valid TAN, afterwards you will be banned from the authentication server (e.g. via IP ban).

A TAN should be long and complicated enough to be not easily guessable, but I think there is no need for discussion as we will be able to see how they are structured when the source code is released.

[pitsch]

there are basic architectural decisions not taken into account with a too high level of details between alice & bob. the backend architecture is based on the Independency of 400 health offices, communal and municipal data sovereignity. now telekom/sap is providing a middleware/cloud infrastructure which is overriding DEMIS / rki and degrading the health offices to cloud users trusting in ACL rules. the decentralisation debate leads to a distraction from the risks of the centralisation of critical private health data in the backend infrastructure. you need to see the bigger picture.
instead 400 VMs with installed SORMAS would be able to replace the Telekom Cloud, directly administered by the health authorities which are legally entititled to store registered private health data (as well as the doctors). the TANs (QR codes) should be generated not by doctors but by be registration backend of the local health office where any test result has to be registered by law.
only in case of roaming requests or legal inquiries acccess to federal, communal data repositories would be allowed. with the Telekom cloud backend the centralisation debate is just where it was before, just much worse thanks to confusing the layers of the given architecture. a new call center circuit hides undocumented process flows, as well as posing privacy risks due to the outsourcing of governmental authority.
the main goal remains that proximity tracing has to be scalable on the local level and become more interoperable with manual tracing team work.

[tkowark]

Thanks for the discussion so far. We hope that the architecture documents released yesterday provided some more input on that matter, but let's also invite @tklingbeil to comment.

@pitsch could you kindly move your proposal to a dedicate issue to keep the two discussions (preventing misuse in the current architecture vs. proposing alternate approaches) separate?

[MikeJayDee]

@pitsch
I think there is a misunderstanding of what is meant by decentralised: there is no central authority that can view the social graph of everyone, and no information on non-infected persons is stored centrally. The details of infected persons need to be stored centralised anyway as contacts need to be traced across district borders (irrespective of whether tracing is done manually, with an app or both).

[pitsch]

this is just the proximity protocol layer of the BLE meshwork (including the central seed tracker), the data gathering layer. roaming can be easily added for requesting data sets in between the federated server instances by using a standard api and and auth method. (there are several well established examples for such architectures) the storage of private health data and infection status is done in the backend infrastructure, you can deny it and leave it to telephony like DP3T, use a third party call center as a fall back infrastructure, or put it into the telekom cloud which has a government contract. nevertheless "datensparsamkeit" would mean data only stays where it is absolutely needed, doctor and local health office. with docker and kubernetes etc. its possible to have 400 independent VMs running at the same backend infrastructure avoiding one central database on a national and soon schengen level, which is the exact result of this unfruitful level of detail of the cryptoboys with alice and bob playing hide and seek with the man in the middle ;)

[tkowark]

@pitsch, again, we would appreciate if you could stay on topic regarding this issue, i.e., solving the problem of TAN forwarding in the current architecture. Please open a separate issue to propose and discuss the alternate approach you envision.

[pitsch]

the TAN distribution, or better client/server validation of positive test results, should be done by the health authority backend, since by law any kind of test result requires a health authority registration. consider to use SORMAS as a basis, and a federated infrastructure of VMs. as a suggestion. https://github.com/hzi-braunschweig/SORMAS-Project

[tkowark]

We'll also close this ticket for now. @wuerzebesser, please have a look at the latest architecture documents and create a new issue if you still see the original issue reflected there.