Threat model is unrealistic
light opened this issue · 2 comments
In the specification v1.0 document, under section 1.4 Adversarial Model :
The authority running the system [...] is ”honest-but-curious”.
I understand that it might be an interesting academic exercise to operate under such an assumption, however if the goal is to apply the described protocol in practice then history has shown that governments absolutely cannot be trusted to use the information at their disposal strictly for their original intended purposes and never extend them to new purposes. Examples of misuse abound.
It is also virtually impossible for individuals to audit code run by government bodies. Even if the source code were made available, it would not be possible to be sure that it is actually what the servers are running. So the threat model must be adapted accordingly.
Furthermore, the actual assumptions made in the document indicate that the authority is in fact trusted, which is a more stringent model. See section 6.2. Server Operations :
Upon reception of a hA = (HELLOA,TimeA), the server:
[...]
10. securely erases (HELLOA,TimeA).
A curious entity would keep that information to be able to infer more about the contact graph of the users. Other design decisions are the result of that threat model.
I feel that this is a serious issue, basing further development on flawed assumptions would be misleading and undermine the adoption of the protocol and apps by the population.
Seems a duplicate of issue #13.
I believe the issue is slightly different. Issue #13 does not argue the reality or not of the trusted / HbC assumption. Correction of issue #13 would be syntactic. This issues argues that the HbC model (thus the trusted model according to #13) should not be considered because it does not fit "the real world". Correction of this issue would mean either i) issuing a new threat model and proposing countermeasures, or ii) arguing why the HbC model is realistic.