search

ROBERT-proximity-tracing / documents

Protocol specification, white paper, high level documents, etc.
Other
247 stars 21 forks source link

Naive question about the continuous mobile phone connectivity assumption #27

Open rdicosmo opened 4 years ago

rdicosmo commented 4 years ago

If I read well, the proposed protocol assumes that the user's phone has unfettered, continuous Internet connectivity. This connectivity is required for changing ephemeral identifiers every epoch, which seems to be something around 15m from what one can read here and there.

What happens if a phone is disconnected from the Internet for a longer period of time? Does ROBERT keep using the same identifier for proximity tracing, even if it becomes less and less ephemeral? What are the security/privacy implications?

Notice that long periods of internet disconnection are the norm, not the exception. In Paris, Internet access in the underground is sporadic at best; in theaters and cinemas internet is often jammed (on purpose). And yet, these are the places where we are going to be most exposed to contact with strangers, which is the use case where a tracing application is most useful (I may be delusional, but I do expect to learn by myself when friends, colleagues or relatives get sick).

ramsestom commented 4 years ago

The server can generate EBIDs in the future that user would download by batch. So a user can ask the server for his EBIDs for the next 24h for example so he only has to connect to the server every 24h.

rdicosmo commented 4 years ago

Sure, this is not really what I have read in the protocol specification, though. But let's push this a bit: if for some reason my app runs out of EBIDs before being able to reconnect, what happens? what are the implications?

ramsestom commented 4 years ago

Then the app could display a notification to the user telling him that he needs to reconnect to the server ASAP and that in the meantime he wouldn't be traced anymore (meaning until he connect to the server, he won't be notified if he met an infected user during this period. He would still be able to alert users he met during this period if he is diagnosed infected in the future though ). This is more of an App implementation issue though, not really a ROBERT protocol one.

ArchanaaSK commented 4 years ago

meaning until he connect to the server, he won't be notified if he met an infected user during this period. He would still be able to alert users he met during this period if he is diagnosed infected in the future though

I disagree that this is not a protocol issue. The first case where no-internet-no-EPID-user does not get notified of contact with infected user is caused by two design choices/assumptions made in ROBERT -1) all time internet connectivity to app users and 2) only central authority generates IDs. This issue is not from app development.

A potential solution could be to provide ID generation capability to both app and server. For example, since the protocol is loosely time-synchronized, as claimed in Specification, the app should have no trouble generating EPIDs for corresponding epochs. This is possible if the server key is made available to app user (have a user-server key) or if EPID generation is made key independent. The current EPID generation = EBIDA;i = ENC(KS; i | IDA). Now a no-internet-user is still able to generate EPIDs and the server can continue to generate EPIDs or generate EPIDs for this user when the user requests for EPIDs when there is internet.

ramsestom commented 4 years ago

This is possible if the server key is made available to app user (have a user-server key) or if EPID generation is made key independent.

This will raise a new problem which is the size of the ID<->EBID (or EBID<->KS key in case of a user specific KS key) lookup table needed by the server to decrypt a user ID from an EBID as already discussed here: https://github.com/ROBERT-proximity-tracing/documents/issues/8#issuecomment-616128430 So unless you are ready and able to handle such a big table on the server, you can't offer inApp EBIDs generation.