DESIRE

Last modified by Joost Agterhoek on 2020/07/28 13:27

Name The short name or acronym of the protocol

DESIRE

Protocol Version In case multiple versions of the protocol exist, indicate the version number

1.0

Protocol Whitepaper Technical descriptions/white papers describing the protocol. Provide one or more web addresses (one per line)

https://github.com/3rd-ways-for-EU-exposure-notification/project-DESIRE/raw/master/DESIRE-specification-EN-v1_0.pdf

edit

Formal verifications of the protocol If the protocol has been formally verified, provide a pointer to the proof and/or articles or paper(s) describing those efforts

add

Authors

Claude Castelluccia, Nataliia Bielova, Antoine Boutet, Mathieu Cunche, Cedric Lauradoux, Daniel Le Métayer and Vincent Roca.

edit

Co-location cannot be inferred People in the same location cannot be correlated to each other based on data sent upstream

Yes

edit

References References for the field 'Co-location cannot be inferred'

https://github.com/3rd-ways-for-EU-exposure-notification/project-DESIRE/raw/master/DESIRE-specification-EN-v1_0.pdf Chapter 1.2 Private Encounter Tokens (PETs)

edit

Content

Private temporary ID Temporary IDs are generated and stored client-side

Yes

edit

References

https://github.com/3rd-ways-for-EU-exposure-notification/project-DESIRE/raw/master/DESIRE-specification-EN-v1_0.pdf

edit

Forward Secrecy Assurance that future encounters will not be compromised by knowledge of current encounter

Yes

edit

References

https://github.com/3rd-ways-for-EU-exposure-notification/project-DESIRE/raw/master/DESIRE-specification-EN-v1_0.pdf 1.2 Private Encounter Tokens (PETs)

edit

Backward Secrecy Assurance that past encounters are not be compromised by knowledge of current encounter

Yes

edit

References

https://github.com/3rd-ways-for-EU-exposure-notification/project-DESIRE/raw/master/DESIRE-specification-EN-v1_0.pdf 3. Risk Analysis

edit

No externally observable effects Attackers cannot trigger externally observable effects involving users they did not encounter

edit

References

https://github.com/3rd-ways-for-EU-exposure-notification/project-DESIRE/raw/master/DESIRE-specification-EN-v1_0.pdf 3. Risk Analysis

edit

Source Integrity Messages exchanged contain an adequate integrity check

edit

References

https://github.com/3rd-ways-for-EU-exposure-notification/project-DESIRE/raw/master/DESIRE-specification-EN-v1_0 Appendix C. Bluetooth communications

edit

Broadcast Origin Integrity Users cannot broadcast identifiers they did not originate or were assigned

Yes

edit

References

https://github.com/3rd-ways-for-EU-exposure-notification/project-DESIRE/raw/master/DESIRE-specification-EN-v1_0.pdf 1.2 Private Encounter Tokens (PETs)

edit

Resistance against replay and ghosting attacks Can a malicious user impersonate others by replaying broadcasted signals

Yes

edit

References

https://github.com/3rd-ways-for-EU-exposure-notification/project-DESIRE/raw/master/DESIRE-specification-EN-v1_0.pdf 1.2 Private Encounter Tokens (PETs) 3. Risk Analysis

edit

No Passive Tracking A passive adversary with physical proximity is unable to capture information not present IRL

add

References

https://github.com/3rd-ways-for-EU-exposure-notification/project-DESIRE/raw/master/DESIRE-specification-EN-v1_0 3. Risk Analysis

edit

Can the length of a meetup between people be derived externally by combining exported data from multiple time slots When users are near for multipe consecutive time slots, the combined data cannot be used to infer the length of an encounter.

edit

References

https://github.com/3rd-ways-for-EU-exposure-notification/project-DESIRE/raw/master/DESIRE-specification-EN-v1_0 2.4 Exposure Status Request

edit

Reporter Privacy Users who transmit reports never as a result reveal information to users they did not themselves come into contact with.

edit

References

https://github.com/3rd-ways-for-EU-exposure-notification/project-DESIRE/raw/master/DESIRE-specification-EN-v1_0 3. Risk Analysis

edit

Information Recipient Privacy Users can retrieve updates concerning their medical status without revealing information to anyone

edit

References

https://github.com/3rd-ways-for-EU-exposure-notification/project-DESIRE/raw/master/DESIRE-specification-EN-v1_0 note 29 on page 12

edit

No linkability of keys Different keys of the same user cannot be feasibly linked in any way by a passive observer which is able to gather a set of sufficient size by continued observation

edit

References

https://github.com/3rd-ways-for-EU-exposure-notification/project-DESIRE/raw/master/DESIRE-specification-EN-v1_0 3. Risk Analysis

edit

Use of constant time cryptography only No leaks of information to other apps through timing analysis

add

References

add

User-configurable automated pruning Can the user control the pruning behaviour of the recorded contacts? As in, can data that is no longer relevant be set to be automatically removed?