The centralized protocol implies that user devices depend on a central server to perform key functions including computation of anonymous identifiers, data processing (reconstruction, encryption, and decryption), risk analysis, and sending of alerts to risky users informing them of their risk level. Under this architecture, users’ apps exchange anonymous Bluetooth identifiers (encrypted or/and randomized) and store them locally. When a user is infected, with the permission of a health authority, the stored data are uploaded to the central server. The central server thereafter performs risk-level computations and notifies risky users of their likely exposure to the disease. A schematic representation of the functionality of centralized protocols is shown in Figure 3. In this sub-section, we discuss the various Bluetooth-based protocols and apps developed leveraging on the centralized architectures.
Conceptual diagram of centralized protocols.
Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT): A foremost promoter of the centralized data management architecture in contact tracing systems is the Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT), an international team consisting of more than 130 members across several European countries. The team is composed of a consortium of academics, technological experts, and business stakeholders whose aim is to provide a framework that will guide developers and countries in deploying effective and privacy-oriented contact tracing systems against the coronavirus. The framework is developed in full compliance with the European General Data Protection Regulation (GDPR) which implies that no personal or location information will be shared in the framework. Furthermore, the framework source code was made open and free [31]. In the PEPP-PT framework, the system assigns each user device a permanent Identification number (id) through which it creates pseudonyms broadcasted as Bluetooth IDs. The Bluetooth ids being broadcasted and sensed by other user devices are randomized pseudonyms to provide user privacy. Sensed data is stored in the user device’s local memory. Upon infection of a user, the infected user voluntarily uploads the stored data to a central server for risk computation and notification of the close contacts of infected persons.
However, PEPP-PT being a centralized framework suffers a single point of failure. This implies that any compromise or damage to the server will render the entire system useless. The PEPP-PT framework has also been accused of lack of transparency which led to the resignation of some of the team members [32].
Blue Trace: The BlueTrace protocol [33] is powered by the Singaporean Government Digital Services. In this protocol, users’ phone numbers are mapped to the randomized temporary identities (TempIDs) generated for every subscriber. During encounters, user devices exchange TempIDs and store them locally in their local memories. If tested positive, the user uploads its contact details to a Health Authority server where the messages are decrypted and risky users contacted through their phone numbers. Figure 4 shows a schematic diagram of how the BlueTrace protocol works. The major stand-out area of this protocol is that the TempIDs are generated centrally and mapped to device phone numbers making it possible for the risky individuals to be identified and contacted without difficulty.
BlueTrace Protocol.
However, as applicable to every centralized system, the protocol suffers a single point of failure. This implies that any compromise or damage to the server where the TempIDs are stored will render the entire system useless. Furthermore, since the temps are mapped to devices’ phone numbers, an adversary may attack the system by sending fictitious messages to the phone numbers, hence creating panics capable of discrediting the system.
Robust and Privacy-Preserving Proximity Tracing Protocol (ROBERT): The Robust and Privacy-Preserving Proximity Tracing Protocol (ROBERT) [34] is powered by Inria and Fraunhofer which are French and German companies, respectively, and are members of the Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT) project. The protocol adopts a centralized data structure in its privacy-preserving contact tracing solution. To enroll in the system, users download the apps and install them on their mobile devices. For every subscriber, unlike in BlueTrace, a permanent ID is assigned by the server with which it identifies the user. Each device creates some ephemeral Bluetooth IDs which are functions of the assigned permanent ID. During daily interactions with other users, the ephemeral Bluetooth IDs are exchanged and stored in the mobile devices of the users. If a user is diagnosed with coronavirus, the stored ephemeral Bluetooth IDs are voluntarily uploaded to the central server where the risk computation is performed and risky users notified. Similarly, this protocol also suffers a single point of failure since any compromise or damage to the central server implies that the entire system has failed.
Do you have any questions about this protocol?
Post your question to gather feedback from the community. We will also invite the authors of this article to respond.