HomeBlueTrace
- The short name or acronym of the protocol
-
BlueTrace
- In case multiple versions of the protocol exist, indicate the version number
-
1.0
- Technical descriptions/white papers describing the protocol. Provide one or more web addresses (one per line)
-
https://bluetrace.io/static/bluetrace_whitepaper-938063656596c104632def383eb33b3c.pdf
- If the protocol has been formally verified, provide a pointer to the proof and/or articles or paper(s) describing those efforts
-
-
Bay, Jason; Kek, Joel; Tan, Alvin Tan; Hau, Chai Sheng; Yongquan, Lai; Tan, Janice; Anh Quy, Tang
- People in the same location cannot be correlated to each other based on data sent upstream
-
- References for the field 'Co-location cannot be inferred'
-
https://reviewfacility.eu/xwiki/bin/edit/Protocols/BlueTrace/WebHome
- Temporary IDs are generated and stored client-side
-
No
-
Chapter 5 - heading "Generation of TempID by backend service vs on device"
- Assurance that future encounters will not be compromised by knowledge of current encounter
-
Yes
-
Chapter 4 - heading "Storage of encounter history"
Chapter 8 - heading "Encounter Message replay/relay attack" - Assurance that past encounters are not be compromised by knowledge of current encounter
-
Yes
-
Chapter 4 - heading "Generation of TempIDs"
- Attackers cannot trigger externally observable effects involving users they did not encounter
-
Yes
-
Chapter 8 - heading "Encounter Message replay/relay attack"
- Messages exchanged contain an adequate integrity check
-
-
Chapter 4 - heading "Generation of TempIDs"
- Users cannot broadcast identifiers they did not originate or were assigned
-
-
- Can a malicious user impersonate others by replaying broadcasted signals
-
No
-
Chapter 4 - heading "Generation of TempIDs"
Chapter 8 - heading "Encounter Message replay/relay attack" - A passive adversary with physical proximity is unable to capture information not present IRL
-
Yes
-
Chapter 8 - heading "Encounter Message replay/relay attack"
- When users are near for multipe consecutive time slots, the combined data cannot be used to infer the length of an encounter.
-
-
- Users who transmit reports never as a result reveal information to users they did not themselves come into contact with.
-
-
- Users can retrieve updates concerning their medical status without revealing information to anyone
-
-
- 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
-
Yes
-
Chapter 4 - heading "Generation of TempIDs"
- No leaks of information to other apps through timing analysis
-
-
- 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?
-
No
-
https://bluetrace.io/static/bluetrace_whitepaper-938063656596c104632def383eb33b3c.pdf
Chapter 3 - heading "DATA PROTECTION AND PRIVACY SAFEGUARDS"
-
Server has full access to all user data (Leap of faith)
- The time window of every contact is registered
-
-
https://bluetrace.io/static/bluetrace_whitepaper-938063656596c104632def383eb33b3c.pdf
Chapter 4 - "HOW BLUETRACE WORKS"
- If the protocol has a home page on the web, add the URL
-
https://bluetrace.io
- If the protocol has a separate logo, please upload
-