Logical issue

[seriyvolk83]

There is a logical issue in the protocol.

Consider the following use case:

• A and B are users.
• A walking and the app generates TCNs (for other app users, except B).
• A became infected and sends a report about this fact. The report covers all TCNs from 14 days in the past till now.
• Then later A walks near B.
• B discovers newly generated TCN from A. It's a new TCN and it's not covered by earlier generated report. Hence, even if B (app) will fetch the report from the backend it will not find that this TCN was ever infected.
• Hence, reports are useless for saving in local storage because they can be only applied to TCN in the past.

Solution 1: Once infected and generated a report, A must periodically generate new reports (or for every new generated TCN), until he will be clear.

Solution 2: Change TCN or report generation logic. It should be possible to obtain all new TCNs generated from the same device AFTER report is generated, not just from j1 > 0 to j2, but from j1 to current time.

[scottleibrand]

We are aware of this issue (though likely haven't documented it well enough) and currently intend to implement Solution 1. We don't intend to use solution 2 because it would allow an attacker to generate TCNs matching any already-public report.

[ruseinov]

@scottleibrand Curious if this has been addressed or if there are plans to do it. I'd be happy to help if needed.

[scottleibrand]

We haven't yet implemented automatic new-report generation. Our current plans for the CoEpi app are to allow users to choose to be periodically prompted to enter their symptoms, at which point a new report would be generated. If you'd like to assist with that, LMK your email address and I can add you to the CoEpi Slack.

[ruseinov]

@scottleibrand Gotcha! I'm currently looking into sample implementation of BlueTrace protocol in Rust, but will definitely help out when I come back to TCN.