Cwa-documentation: Dummy messages and plausible deniability

[cascremers]

The current design does not yet provide plausible deniability with respect to ISPs or anyone in control of the WiFi (home, public spaces, work spaces).

• A repeated poll pattern by the phone indicates a user awaiting a test result.
• A poll pattern followed by a push message type indicates a positive test result.
  The current dummy messages in the system do not yet sufficiently hide the above patterns.

This can be solved by a proper dummy message setup, and addressing all potential side channels (size, frequency, patterns, and response times). This will likely increase the overall load, and will need in-depth analysis.

Solving this also involves a trade-off between external dependency (e.g., it would be easier through push-notification but this relies on external parties) and complexity (e.g., the polling setup adds additional structure that must be hidden).

---

Internal Tracking ID: EXPOSUREAPP-2892

[tklingbeil]

You are absolutely right! We'll have to carefully make sure that those requirements are met, as otherwise the plausible deniability is endangered.

[hoelzlw]

Is plausible deniability actually a design goal?
At least when it comes to the employer, people with a positive test result have to tell anyway.
Otherwise they'd need a good excuse why they'll have to stay at home for the next six weeks.
Furthermore, their coworkers will get a notification that they were in proximity to someone tested positive.
If you're at home with some excuse and all your coworkers get a warning, one needs to be really blind to not add one and one.

Regarding the ISP and the one running an access point: These people already know your usage of the app by the regular poll of settings.json and infected.json.

Since you only want to conceil the wait for a test, a possible solution is:
Poll for settings.json, infected.json and additionally for result.json.
So, with every polling, there will be three files anyway and, if there's no result, that file will just say that to the app: no result.

No need for a push.
If you poll every four to six hours anyway, a positive result arrives at latest after this time period, which shouldn't really create that much trouble.

Finally: If you're at someone else's home and use their wifi, you probably want them to know about your positive result, don't you?

[egandro]

Is plausible deniability actually a design goal?
At least when it comes to the employer, people with a positive test result have to tell anyway.

Sure! But not to a company's admin or to a sub contractor having access to the companies router.

Just imagine a "bad admin" giving this informations to stock traders one day ahead... very very bad szenario :)

[hoelzlw]

@egandro So, just poll three files: settings.json, infected.json and results.json.
The results.json contains just a single char: 'p' for positive, 'n' for negative and 'e' for empty.
Since the connection is encrypted anyway nobody can read the results, and since all three possibilities have the same size nobody can infer the result by looking at the ciphertext.

[egandro]

Since the connection is encrypted anyway nobody can read the results, and since all three possibilities

As we discussed this many times before :) there are Companies having their own APNs + Full Trusted Root certificates - so it's either use the firewall/UTM/proxy (that does layer 7 packet inspection) - or no App on the business phones - for security reasons.

SAP / Telekom needs to solve this - because it affects millions of phones.

[hoelzlw]

The items you talk about do a man-in-the-middle-attack and as already mentioned before and also discussed here corona-warn-app/cwa-documentation#93, there are easy techniques to prevent this, such as certificate transparency and DANE.
Just like banks do in their online banking apps.

Yes, the result may be, that the app cannot be used on business smartphones which are forced to route their traffic through the company's firewall, for instance via a forced VPN when not connected to the company's wifi.
In that case, the company's sysadmin might just create an exception for the well-known servers or simply break the app for their employees - at least on these business smartphones.

There are always special corner cases and this is one of them.
It breaks down to a sysadmin who forces their users to use the company's firewall and insists on the man-in-the-middle-attack.
This is nothing SAP and Telekom can solve in any way.
But it may raise legal questions about whether the sysadmin creates any danger to the employees which may bring the company's lawyers and C*Os into the arena.

[tkowark]

@egandro man-in-the-middle attacks are also not the topic of this issue - the pattern of dummy message sending and their goal auf plausible deniability are.

We already asked to stay on topic multiple times in other issues and would highly appreciate if you could just focus on the respective topic at hand.

If you continue to move discussions off-topic, we unfortunately have to issue a temporary ban in accordance with our Enforcement Guidelines for the Code of Conduct..

EDIT: In case you want to argue against this warning, please contact us via corona-warn-app.[email protected] but keep this comment section open for comments regarding the original issue.

[hoelzlw]

@tkowark @tklingbeil @cascremers Back to topic, regarding plausible deniability.
For a positive test, wouldn't it be enough for the device to find its own ID in the infected.json?
Just tell the app "test done", so it will show some notification, once its own ID shows up in the next days.
This, of course, fails, if the user does not update their infected.json every day.
If they're offline for some days, they might just miss the notification.
But: How exactly does the app handle long offline times without the latest infected.jsons anyway?

Now, you only have to communicate a negative result somehow, which, however, is not that urgent at all.
You could simply use the way, we communicate results right now: have the lab call the patient when there's time.

[tklingbeil]

@hoelzlw: We also had that exact proposal on the table, to make available a list of hashed GUIDs, which confirm a positive infection.

However, this would have the following consequences:

• the hash(GUID) needs to remain on the list until the test result is not considered relevant anymore (we could then start building delta lists, just as we do with the keys)
• to make sure people are informed as soon as possible, you'd have to query in a interval of let's say one hour. The deltas would also need to be made available in that interval.
• to assure plausible deniability random clients would have to query this list regularly (otherwise you would again be able to identify those, who are really trying to get their test result from the query pattern). Same applies to the regular polling.
• you would not be able to communicate negative test results. This is still important, as people might be in self-isolation until they receive their results.

As it in the end did not solve any of our problems, we discarded it again.

[tkowark]

This topic is currently being worked on, hence we move the issue to the CWA backlog repository.
https://github.com/corona-warn-app/cwa-server/issues/658