Identification of diagnosed people by their contacts, or an active malicious agent

[hwti]

How would the system prevent someone from getting many different names, so that they could use them for every contact ? If I broadcast unique pseudonym, let's say Charles1 when I meet Alice, and Charles2 when I meet Bernard, and I get a warning when I check Charles1, I know Alice has been diagnosed.

On a larger scale, if a video-surveillance camera sends a unique name for each person walking by, then it can get pictures of diagnosed people.

[Matioupi]

The second part of the question is excluded from design goals by assumption (not saying its legitimate) but the first part is a interresting low tech alternative.

[hwti]

Both are in fact linked, the question is how could we prevent a registration for each "physical contact". I don't see why a private video-surveillance camera would be excluded from the design goals (a state-operated camera could already do passive listening with access to the authority server anyway).

That would require organization, but I think something could be done physically. The french president has said each people would be able to get a mask, so this is an opportunity. There could be either distribution points (for example town halls), or packages distributed in each mailbox, with masks and a registration code (on a paper, hidden until we unwrap it). In town halls, the ID could be checked to restrict distribution to one per person, but the package would be picked randomly. In mailboxes, the registration code wouldn't be visible to the person doing the delivery.

The mobile application would require the registration code to be entered (or with a QR code), and the server would check it (signature, and unique registration). Maybe the code could be the key, no need to really register to the server in this case : when checking status, the application would sent it to the server, which would look if any identifier reported by diagnosed people matches.

[aboutet]

@hwti We assume the implementation of a technical solution to avoid automatic registrations by bots (e.g., the app must verify the smartphone's phone number at registration). The adopted solution will be described later. To be noted that ephemeral identifiers (EPID) are not generated by the app (and are not generated at any time) and the validity of these EPID is restricted in time.

[hwti]

Preventing automatic registration by bots (for example using a captcha) isn't enough, since a user could still track specific people like neighbors individually.

How could the application verify the phone number to prevent multiple registrations, without giving the real identity of the user to the authority ? Even if it does so using a different service :

• The user would have to trust no link is done server-side (I know it could still be done using the IP, but at least there are VPNs or TOR, and the phone number is a bigger risk)
• The application having the permission to read the phone number would be bad, and would generate fears. The only way to counter it would be to analyze the source code and prove the binary matches it, which is too technical for most users.

[strubbi77]

You need only log2(n) accounts to identify the time slot where you have been infected. For 21 days and 15 minutes time slots at most 11 Accounts are necessary.

A tech-savvy user can install log2(n) instances of the system and every 15 minutes (or when he encounters other people) he changes the amount of instances which are sending the EphIDs in a binary form. So for the first time slots the following pattern of instances will send: 1: Instance(1,0,0,0,0,0,0,0,0,0,0) 2: Instance(0,1,0,0,0,0,0,0,0,0,0) 3: Instance(1,1,0,0,0,0,0,0,0,0,0) 4: Instance(0,0,1,0,0,0,0,0,0,0,0) ... 1024: Instance(0,0,0,0,0,0,0,0,0,0,1)

Creating 11 accounts doesn't sound very complicated.

[ramsestom]

You need only log2(n) accounts to identify the time slot where you have been infected. For 21 days and 15 minutes time slots at most 11 Accounts are necessary.

A tech-savvy user can install log2(n) instances of the system and every 15 minutes (or when he encounters other people) he changes the amount of instances which are sending the EphIDs in a binary form. So for the first time slots the following pattern of instances will send: 1: Instance(1,0,0,0,0,0,0,0,0,0,0) 2: Instance(0,1,0,0,0,0,0,0,0,0,0) 3: Instance(1,1,0,0,0,0,0,0,0,0,0) 4: Instance(0,0,1,0,0,0,0,0,0,0,0) ... 1024: Instance(0,0,0,0,0,0,0,0,0,0,1)

Creating 11 accounts doesn't sound very complicated.

In fact, if you wanted to use such an approach, it would be a little more complicated. Indeed, you may have seen an infected person (be it the same actual person or different ones) on more that one timeframe, which would mask your instances encoding. For example, suppose that I have been in contact with an infected user at timeframes 1: Instance(1,0,0,0,0,0,0,0,0,0,0) and 2: Instance(0,1,0,0,0,0,0,0,0,0,0) in your example. My "risk_status" for instances 1 and 2 would be "1" and "0" for the 9 other ones. So it would make me wrongly think that I have been in contact with an infected person during timeframe 3: Instance(1,1,0,0,0,0,0,0,0,0,0).... Furthermore, there is no garantie that the contact with one of your 11 instances wouldn't have been missed by an infected user at one timeframe (so a "1" could be wrongly reported as a "0"). So to use such an approach you will need some redundancy encoding in your instances pattern (meaning you would need more than 11 accounts), and even with that there is no garantie that you would be able to unmask the "at_risk" instances final statuses pattern to individual timeframe patterns.

Furthermore, unlike other protocols that communicate the EBIDs of infected users to other ones, like the one proposed by Apple/Google or the DP3T, with ROBERT you would have to not only to set up the identification solution of the infected person a priori (so this supposes a desire of the user to be able to identify the person who potentially infected him from the start), but in addition you cannot identify (or at least try) more than one infected person each time. So you need a very large number of accounts if you want to try to identify all infected people who pass a certain place for example. Unlike the protocol proposed by Apple/Google or the DP3T, where it is enough to have only one listening device placed at a location (potentially coupled with a camera system) to know when each infected person has passed at this location, with the approach proposed by ROBERT it will take a very large number of instances (number which increases with the number of infected you want to be able to identify)