mh-
commented
4 years ago @auschmidt You state that "If VS [...] are under authority of or directly associated with the network operator (MNO), MNO and [...] VS can collude to [...] identify infected persons."
I think this is correct (even though I personally do not think that it will happen) - but I don't see how the proposed protocol modifications could prevent this.
From here we know that "Deutsche Telekom is providing the network and mobile technology and will operate and run the backend for the app [...]". (Backend being both VS and CWAS.) Given these prerequisites, do you think that a protocol modification could securely prevent user identification assuming a malicious collusion of e.g. Vodafone as MNO and Deutsche Telekom as operator of VS and CWAS?
IMHO institutional controls will have to prevent this.
auschmidt
fwagner5
sventuerpe
OberstK
BrittaTSI
Ein-Tim
I realize this is somehow re-stirring the discusion of #147 initiated by @togermer. I don't think a resoulition was achieved there. In #147 a proper, privacy-protecting approach was also described which goes back to DP-3T development and exists as PoC. The present contribution corroborates the issue, aims to add to the discussion, and to present further examples for approaches to resolution.
Threat Description
By the architecture and protocol design of the verification process, both Verification Server (VS) and Corona-Warn-App Server (CWAS) can identify the Corona-Warn-App (CWA) uniquely within the protocol, since TAN is unique – which is of course necessary at some point to effect the verification. If VS and CWAS are under authority of or directly associated with the network operator (MNO), MNO and CWAS, respectively, VS can collude to identify a user submitting a valid (TAN, Diagnosis Key (DK) ) pair uniquely, i.e., they can identify infected persons. The ensuing privacy threat is described in the GDPR DPIA of CWA , attacks A3 and B4.
Privacy Rationale and Motivation
The threat is not minor in terms of practical import, since identification of positively tested users can be done by the MNO automatically and on a mass scale, in very short time, for instance on an administrative order. It cannot be assumed that infected users are aware or would consent to their being identified by the MNO, nor can it be assumed that their identities are somehow common knowledge in the CWA system. Other than public health authorities, the MNO is also neither legally nor otherwise entitled to obtain such data, not even by co-operating with these authorities in the CWA system. Also the scale on which personal data can be proliferated is different from a large number of regional health authorities holding them, to an MNO having access to them centrally. For the sake of the common and shared goal of broad acceptance of the CWA, I kindly ask the implementors to consider this concern seriously.
The issue lives at the intersection of technical design and real-world impact. Some people may be more seriously concerned about it than others, but it is not clear that it would be of negligible concern to everyone. The privacy implications of CWA are discussed in many different places, such as the very insightful and recommendable Forum Privatheit, but such is out of scope here. The explicit and sole intention of this contribution is to foster adoption of the CWA, as currently implemented.
Threat Mitigating Requirements
The threat can be mitigated to an (IMHO) acceptable level by following minimal-need-to-know design principles in the verification process and modify the separation of tasks between CWAS and VS slightly to fulfill the following two requirements, which are here raised as a privacy requirement on the verification process:
A. The verification process shall be such that one of the server entities CWA or VS (CWA preferably) is not able to easily identify the CWA involved in the protocol. B. The other entity (VS preferably) shall operate it under the authority of a separate TTP, not associated with the MNO.
Note that A is an enabler for B and only if both are implemented, then the threat is mitigated on an architecture/protocol level. The designers have taken the decision that "Deutsche Telekom is providing the network and mobile technology and will operate and run the backend for the app [...]". The backend includes CWAS and VS and thus may rule out implementing B. In this case the examples for alternative processes become moot, but the privacy concern persists.
However, operating VS and CWAS under the same authority affiliated with one particular MNO is just a design decision which can be discussed as any other. From @tklingbeil 's answer to #206 there clearly is awareness and aptness to apply the principles of separation of duties and minimal-need-to-know. But with the above decision, the designers have not fully done so. Institutional controls, for instance included in a law governing specifically CWA, may be another alternative to alleviate the concern. But then it remains a fact that this design decision necessitated that additional institutional control. This is exactly what security-by-design approaches try to avoid or at least minimize.
Mitigating Alternative Processes
To exhibit the fundamental possibility of mitigating the privacy concern by modified verification protocols and/or architectures in order to satisfy requirement A above (and then of course, implement B.), four examples are presented in the following. These examples are just examples and are not meant as suggestions or proposals for implementation. The first is a protocol variant that tries to stick as close as possible to the existing one and minimize modifications (although, unfortunately, it requires changes at all involved entities CWA, VS, CWAS). The second introduces a further indirection for stronger task separation such that VS never receives DK. The third and fourth – a blunt architecture change, and a hint at a de-centralization option – are only superficially alluded to.
Note that, obviously, there are countable infinitely many other variants of architecture and protocol satisfying the same functional requirements, with different security properties and privacy implications. Before beginning, some initial considerations. The functional requirement of the verification process is
Applying the minimal-need-to-know principle to this statement immediately entails that CWAS does not require having an association to the uniqueness of the CWA instance submitting the DK in the run of the verification procedure. Only VS requires this. As long as the CWAS receives valid all and only the valid DKs from some entity, this fulfills the desired function.
Example 1. Protocol Modification
The aim of the protocol modification is to disassociate the CWA instance from the run of the verification protocol from the viewpoint of CWAS. This is achieved by making the protocol stateless between VS and CWAS and by camouflaging, for CWAS, all data which could be associated to the CWA instance. If that is achieved, CWAS is still in the position of an attacker who could apply traffic analysis (in this case, of its own protocol communication) to re-associate a received verified DK from VS to the particular CWA instance which submitted it. To obstruct this, it is assumed that CWAs submit sufficiently many decoy messages to CWAS. The protocol is kept to the simplest, bare minimum.
Entities and roles:
The protocol description starts at and replaces step 13 in Figures 3 and 4 of the architecture documentation:
Example 3. DK Filter Intermediary
To allow for a further indirection which effects a stricter separation of tasks such that VS never receives DKs, not even in encrypted form, an intermediary, herein called DK Filter Entity (DKFE) may be introduced. The sole task of DKFE is to provide CWAS with precisely all valid DKs. As a prerequisite, it is assumed that DKFE has a pre-established trust relationship with VS. As a concrete example, it is assumed that VS and share a cryptographic key derivation function, KDF. This may for instance be a common function such as PBKDF2, and the trust relationship may be represented by a shared password P as input. The password P and some other data element shall be the input to KDF, for instance by concatenating them or using the other data element as the salt input to PBKDF2.
VS and DKFE also share a dictionary Dict of validation words w. Validation strings are chosen at random by VS from that dictionary and used in each validation procedure only once, and then are depreciated by removing them from the dictionary, which effects double-spending protection. VS and DKFE may need a procedure to refresh their shared dictionary, when it reaches exhaustion.
Now the procedure may run as follows.
Example 3. VS as Data Gateway
In a different split of separation of tasks, VS may act as a gateway to filter data for CWAS. This way, CWAS would have no contact with a submitting CWA in the verification. That is CWA submits DK together with RegToken to VS who forwards it to CWAS. However, a different design decision has been taken, perhaps with the intent to not let VS receive DKs at any stage, in any way or form (perhaps even encrypted). This was raised as a question in issue #206 , and the answer provided thereto shows that this strict task and data separation is what the designers had in mind. Alternatives respecting the latter strong requirement have been sketched above.
Solution Example 4. Completely De-Centralized Verification
It is clear that the verification task can also be done by the CWA itself. In the simplest case, each CWA would receive all DKs submitted to CWAS from it, calculate certain numbers of TEKs, and look for a match. Although this certainly entails computational burden on the CWA, database load at the CWAS, and communication overhead, as also all decoy and rogue submissions need to be stored, transmitted, and checked by CWAs, it is not clear how much that would impact in practice. Also, in a de-centralized solution, there might be ways to reduce the overhead, for instance by CWA submitting received TEKs together with DK, to facilitate matching.
Final Remarks / Disclaimer
Let me make it clear herein – not that it would be necessary to evaluate the foregoing technical contribution – that this author is in favor of broad use of the CWA. In fact, I came across this when writing a statement to urge people to use CWA, with data protection in mind. However the state of the matter for the CWA user right now is: “If You press this button, the MNO will very easily be able to know You are infected.” To me, this is annoyingly detrimental to public acceptance of the CWA.
Let me also make it clear that I do not, in any way, insinuate any intent of the authors of CWA regarding this issue, quite the contrary. I think the design decisions in this case were simply due to a design pattern with task separation in mind and thus a direct mapping of the well-known TAN procedures to the functional task, and maybe by that, a slight oversight of the minimal-need-to-know principle.
The content of this contribution reflects solely the author’s views and not the views of any organziation the author is affiliated with. The author has no particular interest, financial or otherwise, other than explicitly stated herein. The technical procedures provided herein in no way constitute suggestions, proposals, or requests for implementation from the author. The technical procedures described in this contribution are, to the best knowledge of the author, not protected as intellectual property by anyone in any form.
Shield:
This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.
Internal Tracking ID: EXPOSUREAPP-1919