1

A Privacy-preserving Mobile and Fog ComputingFramework to Trace and Prevent COVID-19

Community TransmissionMd Whaiduzzaman, Member, IEEE, Md. Razon Hossain, Ahmedur Rahman Shovon, Shanto Roy,

Aron Laszka, Rajkumar Buyya, Fellow, IEEE, and Alistair Barros

Abstract—To slow down the spread of COVID-19, governmentsaround the world are trying to identify infected people andto contain the virus by enforcing isolation and quarantine.However, it is difficult to trace people who came into contactwith an infected person, which causes widespread communitytransmission and mass infection. To address this problem, wedevelop an e-government Privacy Preserving Mobile and Fogcomputing framework entitled PPMF that can trace infectedand suspected cases nationwide. We use personal mobile deviceswith contact tracing app and two types of stationary fog nodes,named Automatic Risk Checkers (ARC) and Suspected UserData Uploader Node (SUDUN), to trace community transmissionalongside maintaining user data privacy. Each user’s mobiledevice receives a Unique Encrypted Reference Code (UERC)when registering on the central application. The mobile deviceand the central application both generate Rotational Unique En-crypted Reference Code (RUERC), which broadcasted using theBluetooth Low Energy (BLE) technology. The ARCs are placedat the entry points of buildings, which can immediately detect ifthere are positive or suspected cases nearby. If any confirmed caseis found, the ARCs broadcast pre-cautionary messages to nearbypeople without revealing the identity of the infected person. TheSUDUNs are placed at the health centers that report test result tothe central cloud application. The reported data is later used tomap between infected and suspected cases. Therefore, using ourproposed PPMF framework, governments can let organizationscontinue their economic activities without complete lockdown.

Index Terms—COVID-19, Community Transmission, ContactTracing, Mobile App, Data Privacy, Fog Computing

I. INTRODUCTION

THE novel corona virus disease in 2019 (COVID-19)has spread rapidly worldwide in a short duration. It

caused a significant public health crisis worldwide, and bythe end of May 2020 (i.e., within the five months of its firstinfection detection), over 6.16 million persons were infected,and over 372 thousand have died [1]. Therefore, governmentsworldwide seek solutions to minimize the infected cases fromthe COVID-19 pandemic by employing mobile application

Md Whaiduzzaman, and Alistair Barros are with Queensland Univer-sity of Technology, Queensland, Australia (e-mail: wzaman@juniv.edu, al-istair.barros@qut.edu.au).

Md. Razon Hossain, and Ahmedur Rahman Shovon are with Jahangir-nagar University, Dhaka, Bangladesh (e-mail: hossainmdrazon@gmail.com,shovon.sylhet@gmail.com).

Shanto Roy, and Aron Laszka are with University of Houston, TX, USA(e-mail: shantoroy@ieee.org, laszka.aron@gmail.com).

Rajkumar Buyya is with University of Melbourne, Australia (e-mail:rbuyya@unimelb.edu.au).

based contact tracing [2], [3]. Mobile apps can help trace bothinfected and suspected cases in almost real-time, and gov-ernments are rushing towards developing and deploying suchapplications and frameworks. However, several applicationsraise significant privacy issues as they collect sensitive andpersonally-identifiable data from users, and lack user controland transparency in data processing or usage [2]–[5].

Governments are enforcing temporary lockdowns of cities toslow down the spread of COVID-19, causing tremendous eco-nomic losses. However, we can alleviate economic impact byavoiding wide-scale lockdowns and performing more targetedisolation. Therefore, introducing fog computing in economiczones (e.g., shopping malls, organization buildings) can ensurecontinued economic activities by alerting nearby people whilemobile computing (mobile apps) can help to trace the infectedand suspected cases. However, to the best of our knowledge,there is no integrated fog computing framework alongsidecontact tracing mobile apps that allows tracing communitytransmission while preserving users’ data privacy. Therefore,we introduce the following research questions to find anappropriate solution to the cause.

Q1. Background and Issues: What are the issues and privacyconcerns in existing contact tracing apps?

Q2. Mobile and Fog Computing: How to utilize mobile andfog computing to trace and prevent COVID-19 commu-nity transmission?

Q3. Privacy-preserving Framework: How to develop anautomated privacy-preserving e-government framework?

We answer the first question by looking into the backgroundand issues of existing application frameworks as well as userdata privacy concerns (Section II). We find that there areseveral mobile application frameworks developed by govern-ments and third parties to trace the COVID-19 communitytransmission. However, most of these applications and frame-works have failed to ensure user data privacy and suffer fromother issues, such as mandatory use of apps, excessive datagathering, questionable transparency of source codes and dataflow, unnecessary data usage or processing, and lack of usercontrol in data deletion.

We answer the second question by presenting the de-sign considerations, architecture, and workflow of our e-government application framework that utilizes mobile and fogcomputing (Section III). The system consists of two types of

arX

iv:2

006.

1336

4v1

[cs

.CR

] 2

3 Ju

n 20

20

2

User Mobile

User Mobile

UserAPIBluetoothLowEnergy

UserMobile

UserMobile

AutomatedRiskChecker

BluetoothLowEnergy

AffectedUser

MobileBluetoothLowEnergySuspectedUserData

UploadNode

TestCentersTestResultsResultAPI

CloudApplication

Fig. 1: System Overview

fog nodes (ARC and SUDUN), several RESTful APIs, and acentral application. Users can register themselves using UserAPI. The ARC is used to check the risk of users visiting anypublic places (e.g., shopping mall, organization building). Testcenters send the COVID-19 test results using Result API to thecentral application. If the test result is positive, then the user isrequested to upload locally stored contact tracing informationto the cloud using SUDUN or directly from mobile app.Figure 1 presents an overview of the proposed system.

We answer the third question by discussing the implementa-tion overview and user data privacy solutions in our framework(Section IV). Here, we discuss the framework developmentbased on the Amazon Web Services (AWS) solutions. Thenwe present the privacy preservation based on user control (vol-untary, compliance, and user consent), minimal data collection(mobile number, postal code, and age group), data destructionat user’s will, transparency (open source codes, clean dataflow), and limited further usage of data.

Scope: We intend our framework to be deployed andcontrolled by the central government of a country. Govern-ments have access to the test results and can control suchan integrated mobile-fog computing framework. Moreover,relying on a private entity to manage such a framework canlimit the preservation of data privacy. Additionally, in thiswork, we primarily consider and focus on user data privacyissues. Regardless of building a standard and secure dataprocessing framework, we do not discuss advanced securitythreats related to mobile, fog, and cloud layer as there arerich literature on existing security measures [6]–[8].

Outline: The rest of the paper is organized as follows:Section II introduces the privacy and general issues of ex-isting contact tracing frameworks. Section III discusses thedesign considerations, system components, and workflow ofour proposed e-government framework. Section IV presentsthe implementation overview and privacy-oriented solutionsof the framework. Finally, Section V discusses a few relatedprivacy-preserving frameworks followed by a conclusion.

II. BACKGROUND

Contact tracing and isolation of cases are required to controlinfectious disease outbreaks, and the consequence dependsmainly on government actions and citizen responses [9].Manual tracing is difficult and time-consuming in a pandemicsituation, and governments are pushing for digital surveillanceto contain the spread of the virus in the context of healthinformatics [10]. However, these mobile apps have raisedquestions over user data privacy since digital surveillance in-volves location tracking, limits individual freedom, and exposeconfidential data [5].

A. Contact Tracing

Governments can stop transmission of COVID-19 if theyidentify cases and their contacts quickly and get them tolimit their connections with other people. Cases should isolatethemselves as long as they are infectious- for at least 10 daysafter they became ill. Contacts must quarantine for 14 daysafter the last contact with an infectious patient [11]. Somecases may have close contact with many people because ofwhere they have been or where they live, and these situationsshould immediately be reported.

Contact tracing might be difficult as an infected case maynot remember all people who came in their contacts. Addition-ally, an infected person may not know or remember the phonenumbers and address of their contacts. It may take longer forauthorities as well due to the required time to identify andget in touch with contacts. Therefore, mobile-based contacttracing might help track several contacts and determine whois at highest risk for infection.

Contact tracing usually requires three primary steps: contactidentification, listing, and follow-up [5]. People with contactwith an infected person are considered as suspected cases ifthey were in proximal range for more than 15 minutes, within6 feet [12] or the distance of more than 6 feet, but stayednearby for an hour [13].

3

B. Contact Tracing Frameworks and Applications

Due to the necessity of tracing infected or suspected cases,governments around the world have developed several tracingapplications and frameworks [4]. The most common featuresof these applications are live maps and news updates ofconfirmed cases, location-based tracking and alerts, quarantineand isolation monitoring, direct or indirect reporting, self-assessment, and COVID-19 education [2]. Some governmentsinvolved third parties to develop such applications and encour-aged citizens to use these applications.

1) Privacy Concerns: Since governments have been rush-ing to build tracing applications, the least they have consideredabout user data privacy. In most cases, users can be monitoredand tracked in real-time without users consent. If such mobileapplications store the location history, user movement canbe traced as well [14]. Apart from location tracking, thereare several other user privacy issues, such as excessive datacollection, obscure data flow, lack of user control, and datausage policies.

Abeler et al. suggested that we can achieve contact tracingand data protection at the same time by minimizing dataprocessing in the existing frameworks [15]. However, manyapplications are not following such solutions and Howell etal. has suggested five primary privacy concerns for COVID-19 application frameworks [16].

• Voluntary or Mandatory: It should be a voluntary actwhether users download and use such tracing apps. Withthe growing concern over data privacy, unnecessary datacollection, location tracking, and other issues, users musthave free wills to decide. The government or any thirdparty cannot mandate users to use these apps in anycircumstances.

• Data Usage Limitation: People are concerned over thecollected data usage for personal safety reasons [17].Therefore, the collected data must have usage limitations.For example, tracing data can only be used for publichealth and safety. Traced data cannot be used for anyother purpose, e.g., law enforcement.

• Data Destruction: Mobile applications or a frameworkshould automatically delete user records after a particularperiod [18] (e.g., usually 14-21 days and no longer than30 days). Otherwise, users should have manual controlover data deletion from the app or the central server.

• Minimal Data Collection: Several applications collectexcessive, unnecessary data from its users, for example,an application named “Aarogya Setu” requires name,phone number, age, gender, profession, and details ofcountries visited in the last 30 days. Also, Geo-locationtracing is unnecessary alongside Bluetooth or other sim-ilar wireless technologies [19].

• Transparency: The entire process of data collection andusage should be transparent to preserve user privacy.Application frameworks should have publicly availablepolicies, clear and concise data flow and database, andopen-source codes for transparency. Additionally, usersshould have full control over their data usage. Therefore,

developers must follow the compliance and consent rules(GDPR, HIPAA, CCPA, etc.) strictly [18], [20].

Apart from the privacy issues mentioned above, there arecertainly other things to consider, as well. For example, themobile application generated IDs can be breached, decrypted,and resulted in exposing user information. Additionally, appli-cations controlled by the third party may pose a severe threatas they can misuse the collected user data. Therefore, in termsof privacy, user control over the owner’s data and transparencyare notable factors.

2) General Concerns: Apart from several data privacyissues, different design issues are prevailing in the contacttracing apps. Many applications require a constant internetconnection while it is entirely unnecessary. In some otherimplementations, the user can not turn off the backgroundservice of the apps, and these apps do not feature turn-offoption. The apps continue to work at random times, such aswhile staying at home or sleeping. Therefore, it causes batterydrains too fast.

Tracing correctness depends on the distance and period ofcontact. Several applications stores the RUERC of a nearbyuser device even there is a wall between two persons. More-over, rushing to develop such applications result in false posi-tive suspected victim considerations and community transmis-sion. Communication between multiple platforms may appeartroublesome and can lead to unexpected behavior. There-fore, using Google/Apple API might be helpful to introduceBluetooth communication between two devices of differentplatforms (Google Android and Apple iOS). Apart from theseissues, insecure source code, weak data flow and process, anddifferent Bluetooth-based device attacks can cause securityhazards.

3) Google/Apple Exposure Notification API: Google andApple announced their privacy-preserving exposure notifica-tion in April 2020 and released phase one in May 2020 [21].The API uses BLE technology and applies different hashingalgorithms to generate different keys on a specific time inter-val [22] to prevent wireless tracking. Infected cases uploadonly the daily generated keys of the past 14 days, and otherusers download lists of these keys of infected cases of theircorresponding region.

All the key-generation and risk-level checks are performedin the user’s mobile device, preserving user privacy. However,this might also be a concern about the resource consumptionof that particular mobile device [23]. Moreover, as the useris only uploading their keys, the authority can not notify thecontacts of the infected case immediately. Some other essentialfunctionalities, such as preventing community transmissionand identifying the asymptomatic spreaders, can also be trou-blesome.

The responsibility of implementing this technology is on thecorresponding public health authorities. However, the authorityis required to follow the guidelines of privacy, security, anddata control rules as well as the development criteria such asfile and data format of storing, uploading, and downloading

4

keys [21], [24]. This collaborative development of the Expo-sure Notification ensures that both the platform (Android andiOS) transmits and receive similar keys, and the risk level theapp calculates is also similar.

Current contact tracing apps backed by the governmentshave numerous design and privacy issues due to the rushfor community transmission tracing. Regardless of addressingexisting issues, the question remains if the governments cancontinue the economic activities alongside. Therefore, ourintegrated mobile and fog computing-based framework cansolve the issues by effectively tracing community transmissionwhile organizations can run their economic activities.

III. FRAMEWORK DESIGN

Our proposed privacy-preserving e-government frameworkhas four major components: user mobile device and twotypes of fog nodes (ARC and SUDUN), and a central cloudapplication that integrates these nodes. Mobile Unit consistsof BLE, privacy dashboard, filter algorithm, file storage, andcommunication service. A user mobile device advertises it’sown RUERC, scans for RUERCs of other nearby devices, andsave the filtered RUERCs (see filtering Algorithm 1) in thefile storage.

Fog-based IoT-healthcare provides optimization of datacommunication, low power-consumption, and improves effi-ciency in terms of cost, network delay, and energy usage [25],[26]. The BLE in the ARC and SUDUN advertises a specificpredefined UERC, and the mobile unit does not save theseUERCs to file storage. When the user is in proximity to ARC(hospital, shopping malls, office), BLE of the ARC receivesall the RUERCs around, and the fog component checks ifthere is any infected or suspected case. The cloud applicationresponds with a positive or negative result without disclosingthe victim’s identity. If there is a positive case, the ARCtransmits another predefined UERC that signifies the risk leveland alerts all the mobile units around, including the infectedor suspected case, hence preserving the victim’s privacy. Theother fog node, SUDUN, is set either in the test centers orwhere the authority finds it necessary. When the mobile unitreceives the predefined UERC from this fog node, it checks itsprivacy dashboard. If the privacy dashboard allows the mobileunit to send the file to SUDUN, the mobile unit establishesa connection with SUDUN and send the file. Then, the fogcomponent in SUDUN transfers the file to the correspondingcloud. Here, Figure 2 presents the detailed workflow ourproposed integrated mobile and fog computing framework.

A. System Features

We introduce the following features of mobile applicationand fog nodes in our integrated framework:

1) Contact Tracing: An user gets a hashed unique referencecode upon registration from the system. Every two hours,another unique reference code is generated in the appli-cation, which is being shared with nearby devices uponuser consent. It ensures that the broadcast data cannot be

used to trace an individual. The same hashed value will begenerated in the cloud application, and it can be used tocheck the risk level of any individual without disclosinghis or her identity with others.

2) Self-checking: Users can check if he or she was nearbyany infected victim in the last 14 days using the mobileapplication. The application will upload the locally storedreference codes of the device it came in contact in thelast 14 days. The cloud application will check if anyof the uploaded RUERC is listed as an infected victimor suspected victim. The application will notify the useraccordingly.

3) Minimum Mobile Computation: Our proposed frameworkensures minimum computation by enabling user controlto turn on or off scanning, and background services. Apartfrom that, the mobile application features delay broadcastby avoiding unnecessary frequency and requires mini-mum internet connection as users only need internet whileregistering and uploading data for self-check.

4) User Data Privacy: User personal data is not stored orshared in the system. We ensure minimum data collectionand avoid user location tracking or digital surveillance.Fog nodes do not identify any infected victim.

5) Fog Node Alerts: To minimize community transmission,we introduce automatic risk checker in public places suchas shopping malls and office buildings. As there is achance of revealing the user identity, we introduce timedelay and minimum entry of people before broadcastingsimple alert messages. These messages only request usersto take precautions; do not reveal any RUERC or riskradius.

B. System Components

Our framework has four major components: a mobileapplication that broadcasts its RUERC, and stores receivedRUERCs from nearby devices. The ARC checks for in-fected cases and broadcast alerts in organization building.The SUDUN uploads data from the device of infected cases.Finally, a central cloud application integrates all these mobileand fog nodes and manages collected data.

1) Mobile Application: Users download the applicationfrom the google play store or govt server and install it inthe mobile device. The application broadcasts its RUERCand receives RUERC of other devices around. It also detectsthe special predefined UERC broadcasted by Automatic RiskChecker (ARC) and alerts the user about an infected orsuspected case around.

2) Automatic Risk checker (IoT/Fog) (ARC): This fog de-vice is set inside the hospital, shopping mall, educational in-stitutes, and in all government-supervised organizations wherethere is a possibility of community transmission. The fog canreceive the RUERC of the mobile devices within the Bluetoothrange and interacts with cloud service to detect any infectedor suspected victim. If any RUERC is found as an infected orsuspected victim, it broadcasts a specific UERC throughout theplace. The mobile application near the fog receives this spe-

5

RUERC

Central FileToSUDUN

Peripheral

FileToSUDUNFiletocloud

ForselfCheck

FileStorage

PrivacyDashboard

CommunicationService

SharedDBforUERC

FilteredRUERCFilterAlgorithm

ARCSpecificUERC

ScannedUERCtoCheckRisk

FogComponent

BLE

RiskAlert

RiskFound

Cloud

FileToSUDUN

Mobile3 Mobile4

SUDUNSpecificUERC

FogComponent

BLE

MobileUnit

Mobile2

ARC SUDUN

FileToSUDUN

SavingOwnU

ERCfrom

CloudA

fterregistration

Registration

Data

AdvertisingRUERC

Mobile1andMobile2

AdvertisingRUERC

FogNode FogNode

RUERC

RiskFound

Mobile1

FileSendingtoSUDUN

ARC/SUDUNSpecificUERC

Risk:Contact/CaseFoundNearby

Scan/Advertise:MobiletoMobile

CheckPDBeforeeachAdvertise

SelfCheckResponse

RUERCGenerator

SelfChecking

RegistrationProcess

SelfCheckerProcess

FetchRUERCFile

Fig. 2: Mobile and Fog Computing Framework for Tracing and Preventing Community Transmission

cific UERC and alerts the user about the risk. As the fog nodeis registered via cloud fleet management service, the ARCnode can be monitored in real-time. Thus it allows identifyingany ARC node with a high rate of COVID-19 affected patient’spresence. If the number of infected patients or the numberof suspected patients gets higher than a predefined maximumthreshold value per hour, it automatically generates emergencyalert service to the organization’s authority by sending emailsand messages. It informs the nearby health authorities as well.The notification is broadcast only when there are at least 5persons within the range of ARC to ensure the privacy of theinfected victim. On the contrary, the notification is not sentinstantly when the ARC identifies an infected or suspectedvictim. It notifies the users after a certain period, which ensuresthe identity of the infected or suspected victim is not disclosedto others.

3) Suspected User Data Uploader Node (IoT/Fog)(SUDUN): These fog nodes are similar to ARC and are setat the health centers or the COVID-19 test centers. When atest center reports a positive test result, the infected personcan voluntarily allow the application to enable uploadingits RUERC list from the privacy dashboard and keep themobile phone within the range of a SUDUN. A SUDUNautomatically connects with the user’s device and fetches thelist of stored lists of hashed RUERC from the device. Here,we enable monitoring each SUDUN using a cloud dashboardon a real-time basis. Additionally, the infected victim canalso upload the RUERC list by using the mobile applicationand an internet connection without the help of a SUDUN.

4) Cloud/Server: The government provided secure datastorage and computing server. Receiving and storing datafrom SUDUN, mining to predict essential patterns or superspreaders, computing to provide required information to ARC,and handling standard authentication to maintain security andprivacy are its primary responsibilities.

C. System Workflow

1) User Registration: Initially, users need to register inthe cloud using mobile number, age group, and postal code.The mobile number field is mandatory; however, the agegroup and postal code are optional. The Cloud Applicationgenerates and sends a One Time Password(OTP) to the user-submitted mobile number through SMS. Then the user entersthe OTP in the mobile application, and the app sends the OTPto Cloud. The cloud application matches the user sent OTP,with the generated one. If both matches, the cloud applicationgenerates a UERC for the user and send it back to the userinstalled mobile app. Finally, the mobile app stores the UERCin encrypted format in the user device and then proceeds toscan IDs broadcasted by other users. The user device itselfbroadcasts a rotational UERC (derived from the initial UERC)as well. Figure 3 presents the complete registration process.

2) Key Generation: Our framework generates RotationalUERC (RUERC) with an interval of two hours. A person isconsidered a suspect case if he stays nearby to an infectedperson for an hour. As the RUERC changes every two hours,possibly the users are supposed to receive more than oneRUERC if they stay nearby longer than an hour (e.g., in

6

Opensnewregistrationwindow

Doesuseragreetoretry?

No MAabortsregistrationprocess

UserstartsregistrationprocessinMobileApplication(MA)

Userinsertsmobilenumber,agegroupand

postalcode

MAsendsmobilenumber,agegroupandpostalcodetoCloudApplication(CA) Yes

UserinsertsOTPinMA

MAsendsOTPtoCA

CAsendsOneTimePassword(OTP)to

user'smobile

NoDoesOTPmatch?

Yes

CAnotifiesMAaboutunmatchedOTPand

MApromptsusertoretry

MAstoresencryptedUERCinuserdevice

USERS

UERC,AGE_GROUP,POSTAL_CODE,

MOBILE,ADDED_AT

CAstoresUserPublicInformation

CAsendsUERCtoMA

MAnotifiesuseraboutsuccessfulregistration

EndRegistrationProcess

Doesmobilenumberexist?

No

CAgeneratesUERC

CAfindsmappedUERCfromUsersTable

Yes

Fig. 3: User Registration Process

case they are neighbors). Our mobile application ensures thateven if a person comes in close at any minute, it will storeindividual key and compare against the timestamp. It increasesthe accuracy of finding contact without a rigorous need forcomputation. Moreover, the RUERC enhances the privacy ofthe user because always broadcasting the same UERC mayresult in wireless tracking. While registering, the mobile unitreceives a UERC from the cloud, and from this UERC, itgenerates RUERCs using the AES algorithm on each two-hourinterval for the next 14 days. When two devices come close,they transmit and save these RUERCs. Figure 4 presents thesteps of RUERC generation.

3) RUERC Scan Service: Scan service allows the applica-tion to run in the background. It creates a new thread so thatthe user does not feel any obstacle while using other mobileapps. The user has the privilege to stop and then restart runningthe service at any time. Scanning and advertising RUERC,creating files, and saving data are its primary responsibilities.

Scan service uses Bluetooth Low Energy (BLE) technol-ogy to share RUERC between two mobile devices. TheBLE consumes significantly less power to communicate,

Stage1 Stage3

Stage2 Stage4UERCThecentralapplicationgeneratesUERCandsendsittotheuser'sMobileApplication(MA)upon

successfulregistration.

RUERCTheCloudApplication(CA)generatesRotationalUERC

usingAESalgorithmforevery2hoursfornext14dayswhichismappedwithinitialUERC.

SelfCheckingMAsendsthestoredRUERCtoCA.CAwillfindtheUERCoftheRUERCandcheckifthey

arelistedasinfectedorsuspectedvictims.Itwillnotify

theuseraccordingly.

ShareRUERCThemobileapplicationalsogeneratethesameRUERC.

Whentwomobiledevicescomenearbytheysharethe

RUERC.Itisstoredfornext14daysinthedevice.

Fig. 4: Key Generation Steps

control, and monitor IoT devices. It uses “central” and“peripherals”, which define a network called piconet [27].Central scans for the advertisement and peripheral makes theadvertisement. In our framework, the advertisement consistsof the defined RUERC. The Generic Attribute Profile (GATT)is designed to send and receive short pieces of data known as”attributes,” and it is built on Attribute Protocol (ATT), whichuses 128-bit unique ID [27]. In our framework, to maintainthe minimal data collection policy and preserve device power,we are omitting the use of GATT and ATT. We are usingemphperipheral to transmit the RUERC and the central to scanthese RUERCs. While scanning, we filter these RUERCs withour suspect filtering algorithm and save accordingly.

4) RSSI: The framework uses a Received Signal StrengthIndicator (RSSI) to identify the distance between devices.RSSI shows the strength of the received signal. It is calculatedin dB and depends on the power and chipset of the broad-casting device. It also depends on the transmitting medium.If there is any obstacle between the receiver and the sender,the signal strength will decrease, so the RSSI. Therefore, for adifferent manufacturer, the value of RSSI in a specific mediumshows different values. However, for a particular manufacturer,RSSI shows the intensity of the signal strength. RSSI does notprovide the accurate distance but using path loss model [28],an approximate distance can be found,

RSSI = −10 · n · log10(d) + C

Here, n is the path loss exponent that depends on the trans-mitting medium, d is the distance, and C is a constant.

5) RUERC Storage in mobile device: To maintain userprivacy, the mobile application creates two files in the internalstorage of the mobile device. Even the user does not havepermission to access these files. When the peripheral receivesany signal, one file temporarily stores this signal information,and other stores the information of the filtered signal. Whenthe device comes within the range of SUDUN, the signalinformation of the filtered file is sent to SUDUN or directlyto the cloud to perform self-check.

6) Suspect Filtering: According to CDC, a distance of sixfeet between the case and contact is safe to maintain [12]. Aperson is considered a contact if he/she is within six feet for atleast fifteen minutes or is within the proximity for an hour [13].The scan service scans all the RUERCs within the range ofBluetooth. However, considering the rules mentioned above,

7

continuous scanning is unnecessary as it causes battery andmemory consumption. Therefore, the scanning service scansfor 700ms with three minutes interval. We develop our suspectfiltering algorithm considering these factors so that the powerand memory consumption is minimal, and identifying suspectsis more accurate.

There are two types of files in the mobile device. Onecontains all the signal information (RUERC, distance, andtimestamp) it receives from nearby devices on each interval.If any received signal passes the filtering conditions, associateinformation (RUERC, distance, timestamp, and duration) isstored in another file. This file is called the final file and sentto the cloud once the user is found COVID-19 positive. Aspecific RUERC is stored in the final file only once a day.Here, the suspect filtering algorithm is shown in Algorithm 1.

D. Data Processing

The framework is divided into three data processing layersto preserve user privacy and restrict access to data in variousprocesses. Users can register to the system using a publiccommunication process via mobile application. In this sameaccess layer, the test centers can send the test results usingRESTful API services through HTTPs protocol. The userscan connect ARC and SUDUN fog node through the BLEprotocol and send data to fog nodes. The computation andinitial screening of user-uploaded data in fog nodes is donein a protected network layer. The APIs which are consumedby user mobile applications, test centers, and fog nodes arealso in this layer. The main data processor consisting of a setof application nodes resides in a protected network, and userscannot access the data processor directly. The processed datais stored in data storage, which is configured in a restrictedprivate subnet. This subnet can only be accessed from theancestor private subnet, not from any public subnet. The datalayer is protected from SQL injection as it is not directlyconnected through any user entries. Figure 5 displays theprocess flow diagram.

IV. FRAMEWORK DEVELOPMENT

In this section, we discuss the implementation overviewof our framework with regards to Amazon Web Service.Additionally, we discuss the database design, analysis of ourcontact tracing graph, and our privacy-preserving solutions.

A. Implementation Overview

We have implemented our framework using Amazon WebServices (AWS) [29], [30]. As it is a generic framework,it can be applied in other IoT/Cloud platforms too. Thefog nodes, ARC and SUDUN, consist of AWS Greengrasscomponents and Lambda functions. They are connected to theAWS IoT Core service using the MQ Telemetry Transport(MQTT) protocol. The authenticity and security of the fognodes are ensured by using IoT Device Defender. IoT DeviceManagement service is used to monitor and audit the fog

Algorithm 1: Filtering suspected RUERC in mobile ap-plication/* TF = Temporary File, FF = Final File, *//* Tc = Current Time, Tr = Registerd Time, *//* T15 = 15 minutes, T60 = 60 Minutes, *//* Dc = Current Distance, Dr = Registered

Distance, D = Standard Distance (6 Feet), Ct

= Contact, Cs = Case, ScSn = Scanned Signal,RcSn = Recorded Signal in TF , */

/* ASU = ARC specific UERC, RSU = Risk specificUERC, */

/* SSU = SUDUN specific UERC */

1 foreach Signal in RcSn do2 if ScSn.contains(Signal) == false then3 RcSn.remove(Signal)

4 foreach Signal in ScSn do5 if Signal.RUERC == self.RUERC OR Signal.RUERC

== ASU then6 return

7 if Signal.RUERC == RSU then8 showRiskAlert() return

9 if Signal.RUERC == SSU then10 sendFileToSUDUN() return

11 if RcSn.contains(Signal) == false then12 RcSn.add(Signal)

13 else14 Set Tc = Signal.time, Tr =

RcSn.get(Signal.RUERC).time, Dc =Signal.distance, Dr =RcSn.get(Signal.RUERC).distance

15 if Dc <= D AND Dr <= D then16 if Tc − Tr >= T15 then17 Ct = Signal18 if (FF .contains(Ct) AND

FF .get(Ct).time.date ==Ct.time.date) ORisUserConsentToStoreData == falsethen

19 return

20 FF .add(Ct)

21 else22 Dr = Dc

23 else if Tc − Tr >= T60 then24 Ct = Signal25 if (FF .contains(Ct) AND

FF .get(Ct).time.date == Ct.time.date)OR isUserConsentToStoreData == falsethen

26 return

27 FF .add(Ct)

28 else29 Dr = Dc

8

UserUserdata

TestresultsdataAffecteddataSuspecteddata

DataStores

DMZ-user/fognodeboundary

Protectedvirtualprivatenetwork-fognode/applicationboundary

Restrictednetwork-application/databaseboundary

User

User

TestCenter

ARC

SUDUN

BLEBLE

TestResultsAPI

User

UserBLE

BLE

BLE

BLE

HealthStatusAPI

SQLqueriesSuspecteddataAuditlog

SuspectedIdentifier

API

HTTPsrequest

HTTPsresponse

HTTPsrequest

HTTPsresponse

HTTPsrequest

HTTPsresponse

UserAPI

HTTPsrequest

HTTPsresponse

SQLqueriesUsers

TestresultsAffecteddataAuditlog

DataProcessor

Applicationresponse

Applicationcalls(do)

Applicationresponse

Applicationcallsdo

Applicationresponse

Applicationcalls

Applicationcalls/

response

Fig. 5: Process Flow Diagram with Privacy and SecurityBoundaries

nodes. Incoming data from the fog nodes are passed to SimpleQueue Service(SQS). The queue data is processed via Lambdafunctions and moved into the application containers, whichis managed via the Kubernetes cluster within an auto-scalinggroup for dynamic scaling of the master nodes and workernodes.

After the data is processed in the application nodes, it issent to the Redis Cache tier and eventually to the AmazonRelational Database Service (RDS). For the administrationof the cloud application, an SSH connection is provided viaElastic Load Balancing to a Bastion server. The users need tobe connected to the cloud application only on the registrationprocess via HTTPs connection to a load balancer. The testcenters send the test results using RESTful API over HTTPs.The scheduled tasks, for example, generating the user’s rota-tional UERC, is done in an Elastic Container Service, whichuses the CloudWatch event rule at a specific time of the day.The application generates alarms for any irregular activitieslike device connection error or access failure via Cloud-Watch alarms to the proper authority. Users are notified fromARC, SUDUN, and cloud application via Simple NotificationService. For further communication processes to authorizedorganizations and administrators, the Simple Email Service isused. For restricting unauthorized access to the applicationsand data layers, private subnets are used. To ensure efficientdata availability in the cloud, a database instance is storedin a separate availability zone. Here, Figure 6 illustrates theimplementation overview.

B. Database

The cloud database includes several tables to trace infectedand suspected cases, to alert users, to prevent communitytransmission in organizations through ARC, and collect testresults from SUDUN. The user table stores user registrationinformation (mobile number, age group, postcode, and times-tamp) and the initial UERC. As we are generating new UERCsassociated with the primary user UERC, we need mapping inbetween those unique reference codes. We store test results(result ID, test organization ID, timestamp, test result, and usermobile number) in a separate table and extract the infectedusers (affected UERC, test result ID, and affected ID). Now,we map between the registered user table and affected usertable to find out the suspected users and store the suspectedUERC, duration, timestamp, and distance radius alongsidegenerating a new suspect ID. We also need an organizationdatabase where we store organization information (name,email, geo-location, address.) and associated permissions forARC and SUDUN. Figure 7 presents the relations between allthese tables.

C. Contact Tracing Graph

To identify and trace COVID-19 community transmission,we introduce and utilize a graph database called “Neo4j” [31]to determine the contact graph. Figure 8 presents a portion ofthe contact tracing graph with synthetic data of contact tracing.The red, blue, and green circles indicate the test centers, users,and test results. The lines present directed edges of the graphbetween infected and suspected victims. The tracing graphcan be used to identify individuals who had come in closecontact with infected victims almost in real-time. We candetermine a potential super spreader as well, using the contacttracing graph. Additionally, suspected victims identified by thegraph can be informed to take cautionary actions to preventcommunity transmission.

D. Privacy Preservation

As we discussed five major data privacy issues earlier inSection II, here, we discuss solutions to these issues in termsof implementing our framework.

1) Voluntary: Users have full control over the usage of thisapplication and the stored data in the application storage. Evenit is an e-government framework, no one can force users touse the mobile app, and the participation is voluntary. Whileusing the mobile application, users have a privacy dashboard(Figure 9a) where he can allow if the app wants to storecollected RUERCs in the local storage, use device Bluetoothto share user’s RUERC, and if the user wants to share thecollected RUERCs with the government.

2) Minimal Data Collection: Initially, the system collectsthe user’s age group, postal code, and mobile number forregistration and, in return, provides a unique ID (UERC) to bestored in a user’s mobile device. Then the mobile applicationcollects RUERC, timestamp, duration, and distance measure

9

VPCAvailability Zone 1Private subnet

CloudARC

Users

MobileDevice

MobileDevice

MobileDevice

Fog Node

Lambda Greengrass

BLE

BLE

BLE

Availability Zone 2Private subnet

Users

Private subnet

DMZ Public Subnet

Auto Scaling group

Fog Node

SUDUN

Users

MobileDevice

MobileDevice

MobileDevice

Lambda Greengrass

BLE

BLE

BLE

IoT Core

DeviceDefender

DeviceManagement

MQTT

X.509Certificate Queue

Lambda

Apps

CacheTier

Database(primary)

Database(standby)

CloudWatchAlarms

Notifications

Emails

LoadBalancer

HTTPs

TestCenters

HTTPs

MobileApplication

SSH

LoadBalancer

Admin

KubernetesCluster

BastionBLE

MobileApplication

ScheduledTasks

Fig. 6: Implementation Overview with regards to AWS

Test_Resultstest_result_idPK

test_organization_idFK

result_timestamptest_resultmobile_number

UsersuercPK

age_grouppostal_codemobile_numberUNQadded_at

Organizationorganization_idPK

organization_type_idFK

parent_organization_idFK

nameemailphoneaddresslatitudelongitudepasswordadded_atstatus

UERC_Mappermapper_idPK

user_uercFK

generated_uerc

Affected_Usersaffected_idPK

affected_uercFK

test_result_idFK

Suspected_Userssuspection_idPK

affected_idFK

suspected_uercFK

added_by_organization_idFK

durationconnection_timestampdistanceadded_at

Organization_Typesorganization_type_idPK

organization_type_title

Permissionspermission_idPK

permission_title

Organization_Permissionorganization_permission_idPK

organization_type_idFK

permission_idFK

Fig. 7: The cloud database consisting of mandatory tables

(based on RSSI) from other mobile devices that came incontact with the user’s device. Age group and postal codeare optional fields. These fields are used to define clustersand identifying super spreaders. The phone number is used toalert contact to take precautions. No personal information ofthe user is collected during or after the registration procedure.Figure 9b presents the mobile application user interface withmandatory and non-mandatory fields.

3) Data Destruction: The mobile application deletes col-lected RUERCs no later than 21 days calculated from the latesttimestamp. In the cloud application, UERC and associateddata from the suspected table is deleted in 30 days of entrytimestamp. Additionally, a user has full control over hisdata and can delete it manually from the application storageinstantly. A user can also request for account deactivation anddeletion of data from the cloud database. However, it may takeup to two weeks to synchronize data in all replica databases.

4) Transparency: Transparency is vital in data privacy, andgovernments should make the source codes open and publishthe user data flow in the whole framework. Transparencymotivates users to use an application and results in bettermanagement and increased public engagement. Consent andcompliance can play a crucial role in presenting transparentdata processes and improving decision making.

5) Limited Data Usage: The collected data should havelimited use cases, and our framework opens the opportunityto determine a super spreader, and clustered view of positivecases. Additionally, the infected and suspected lists can helpcalculate the risk factors in terms of community transmission.However, while employing, further data usage should beminimal, and users need to have a clear idea of why and howdata is being processed.

10

Fig. 8: Contact tracing graph

V. RELATED WORK

Qiang Tang discussed a few existing privacy-preservingframework solutions that attempted to solve several userdata privacy issues [32]. Author provided some observationsand privacy solutions on Singapore’s “Tracetogether”,Reichert et al.s “MPC Solution” [33], Altuwaiyan et al.s“Matching Solution” [34], and Vaudenay’s “DP3T” so-lution [35].

Singapore’s Tracetogether: Affected users are compelledto share with the Ministry of Health the locally saved in-formation. In our framework, this is voluntary to share anyinformation with the system. Additionally, there is a risk ofdecomposition of the app and collecting the geo-location datafrom the app. As we are not storing any geo-location dataanywhere, this does not possess any risk of transpassing.

Reichert et al.s MPC Solution: This solution requiresthe users smart device to be used to acquire and save geo-location data, and this location trace is shared with the HealthAuthority (HA) [33]. This may raise a privacy issue of theusers as it does not mention if they can preserve their privacyby controlling what information they want to share with theauthority and what information they do not want to share. Weprovide a clear and concise privacy dashboard to the users sothey can choose the information they want to share and altertheir choices. The solution does not consider the scalability ofcomputation of extensive data set collected from the devices,and HA requires to arrange garbled circuits (a cryptographicprotocol that encrypts computation) for all infected users. Wetake precautionary steps in fog nodes to filter the collecteddata. Additionally, the central application uses an auto-scaling

technique and a queue service to facilitate the upcoming data.

Altuwaiyan et al.s Matching Solution: This solution uti-lizes a privacy-preserving matching protocol between usersalong with proper distance measuring procedure [34]. We areusing similar metrics to calculate the distance between mobiledevices. On the other hand, infected users’ exact location isshared with the central server, which indicates severe privacyviolation. We do not use individual users locations and thuspreserve users location privacy.

The DP-3T Solution: The DP-3T solution provides aprivacy-aware framework while considering three design con-siderations: low-cost design, unlinkable design, and hybriddesign. The solution takes advantage of the content deliverynetwork and provides a cost estimation per patient. Authorsdiscussed privacy concerns such as the social graph (socialrelationships between users), interaction graph (physical in-teraction nearby), location traceability (tracing individuals),at-risk individuals (suspected cases), positive status (infectedcases), and exposed location (partial identification of placesa positive case visited). They also discussed the addressableprivacy concerns in terms of the three design considerations.

COVIDSafe: The app collects user name, phone number,age-range, and postcode followed by the consent of the userand sends to the server. The app stores encrypted user ID, timeof contact, and Bluetooth signal strength and keeps this datafor 21 days. The case can upload these data voluntarily [36].The government has amended the Privacy Act 1988 to preventthe misuse of these data [37]. The user can uninstall the appto delete these data and to delete all data from the server, theuser needs to wait until the pandemic is over whereas, ourframework allows users to delete all data within 14 days.

11

(a) User Consent Privacy Dashboard (b) Minimal Data Collection during Registration

Fig. 9: Privacy Concerned Mobile Application User Interfaces

TABLE I: Comparison between Existing Solutions and Our Solution

Frameworks

Features Privacy-preserving Approaches Fog Computing Design Approaches

VolunataryData Usage

Limitation

Data

Destruction

Minimal Data

CollectionTransparency

Risk

Check

Infected/Suspected

Data Upload

Temporary

BLE ID

No Location

Tracking

Minimal

Internet Use

Tracetogether D D D D D x x D D D

MPC Solution D D x D x x x D D xMatching Solution x D x x x x x D D D

DP-3T Solution D D D D D x x D D N/A

COVIDSafe D D D D x x x x D D

PPMF D D D D D D D D D D

Table I presents the difference between existing mobile ap-plication frameworks and our integrated mobile-fog computingframework (PPMF). Here, we categorize different featuresin terms of privacy-preserving approaches (voluntary, datausage limitation, data destruction, minimal data collection, andtransparency), fog-based integrated solutions (risk check, in-fected/suspected data upload), and general design approaches(temporary BLE IDs, no geo-location trace, and minimalinternet requirements). We put our framework (PPMF) at theend of the list and find it ticks all these features.

VI. CONCLUSIONS

In this work, we have presented a mobile and fogcomputing-based integrated framework that can trace andprevent community transmissions alongside maintaining user

data privacy. In PPMF, we consider minimal data collectionand provide a temporary RUERC in encrypted form for storingin user devices. The ARC is responsible for tracing positivecases in public places and sending alerts to nearby peoplewithout revealing the user’s identity. The SUDUN uploads datato the central database about infected and suspected cases thatcan be processed to identify a super spreader and visualize theclusters of cases based on postal codes and age groups.

Minimal and undetectable data collection, user control,and system transparency are essential factors to ensure userdata privacy. Privacy dashboard-based on compliance anduser consent makes it convenient and encourages citizens touse such a user-friendly e-government framework. Therefore,using the structure of our proposed PPMF framework, gov-ernments can continue their economic activities while tracingand minimizing the mass-level community transmission. In the

12

future, we plan to develop a super spreader detection modeland clustering methodology of infected cases, based on ourframework.

ACKNOWLEDGEMENT

This research is partly supported through the AustralianResearch Council Discovery Project: DP190100314, ’Re-Engineering Enterprise Systems for Microservices in theCloud.’

REFERENCES

[1] “Home - johns hopkins coronavirus resource center,” https://coronavirus.jhu.edu/, (Accessed on 05/31/2020).

[2] T. Sharma and M. Bashir, “Use of apps in the covid-19 response andthe loss of privacy protection,” Nature Medicine, pp. 1–2, 2020.

[3] J. Chan, S. Gollakota, E. Horvitz, J. Jaeger, S. Kakade, T. Kohno,J. Langford, J. Larson, S. Singanamalla, J. Sunshine et al., “Pact: Privacysensitive protocols and mechanisms for mobile contact tracing,” arXivpreprint arXiv:2004.03544, 2020.

[4] H. Cho, D. Ippolito, and Y. W. Yu, “Contact tracing mobile apps forcovid-19: Privacy considerations and related trade-offs,” arXiv preprintarXiv:2003.11511, 2020.

[5] R. Raskar, I. Schunemann, R. Barbar, K. Vilcans, J. Gray,P. Vepakomma, S. Kapa, A. Nuzzo, R. Gupta, A. Berke et al., “Appsgone rogue: Maintaining personal privacy in an epidemic,” arXivpreprint arXiv:2003.08567, 2020.

[6] R. Roman, J. Lopez, and M. Mambo, “Mobile edge computing, fog etal.: A survey and analysis of security threats and challenges,” FutureGeneration Computer Systems, vol. 78, pp. 680–698, 2018.

[7] S. Yi, Z. Qin, and Q. Li, “Security and privacy issues of fog computing:A survey,” in International conference on wireless algorithms, systems,and applications. Springer, 2015, pp. 685–695.

[8] S. Singh, Y.-S. Jeong, and J. H. Park, “A survey on cloud computing se-curity: Issues, threats, and solutions,” Journal of Network and ComputerApplications, vol. 75, pp. 200–222, 2016.

[9] J. Hellewell, S. Abbott, A. Gimma, N. I. Bosse, C. I. Jarvis, T. W.Russell, J. D. Munday, A. J. Kucharski, W. J. Edmunds, F. Sun et al.,“Feasibility of controlling covid-19 outbreaks by isolation of cases andcontacts,” The Lancet Global Health, 2020.

[10] J. Andreu-Perez, C. C. Y. Poon, R. D. Merrifield, S. T. C. Wong, andG. Yang, “Big data for health,” IEEE Journal of Biomedical and HealthInformatics, vol. 19, no. 4, pp. 1193–1208, 2015.

[11] R. Pung, C. J. Chiew, B. E. Young, S. Chin, M. I. Chen, H. E. Clapham,A. R. Cook, S. Maurer-Stroh, M. P. Toh, C. Poh et al., “Investigationof three clusters of covid-19 in singapore: implications for surveillanceand response measures,” The Lancet, 2020.

[12] T. C. for Disease Control and Prevention, “Social distancing,quarantine, and isolation,” https://www.cdc.gov/coronavirus/2019-ncov/prevent-getting-sick/social-distancing.html, May 2020.

[13] E. Gurley, “COVID-19 Contact Tracing, coursera, johns hopkins uni-versity, usa,” https://www.coursera.org/learn/covid-19-contact-tracing?edocomorp=covid-19-contact-tracing, May 2020.

[14] A. Berke, M. Bakker, P. Vepakomma, R. Raskar, K. Larson, and A. Pent-land, “Assessing disease exposure risk with location data; a proposal forcryptographic preservation of privacy,” arXiv preprint arXiv:2003.14412,2020.

[15] J. Abeler, M. Backer, U. Buermeyer, and H. Zillessen, “Covid-19 contacttracing and data protection can go together,” JMIR mHealth and uHealth,vol. 8, no. 4, p. e19359, 2020.

[16] T. R.-M. Patrick Howell O’Neill and B. Johnson, “A flood of coro-navirus apps are tracking us. now its time to keep track of them.”MIT Technology Review, https://www.technologyreview.com/2020/05/07/1000961/launching-mittr-covid-tracing-tracker/, May 2020.

[17] L. Simko, R. Calo, F. Roesner, and T. Kohno, “Covid-19 contacttracing and privacy: Studying opinion and preferences,” arXiv preprintarXiv:2005.06056, 2020.

[18] A. Dubov and S. Shoptaw, “The value and ethics of using technologyto contain the covid-19 epidemic,” The American Journal of Bioethics,pp. 1–5, 2020.

[19] “Aarogya setu faqs,” https://static.mygov.in/rest/s3fs-public/mygov159056978751307401.pdf, May 2020.

[20] A. R. Shovon, S. Roy, A. K. Shil, and T. Atik, “Gdpr compliance: Im-plementation use cases for user data privacy in news media industry,” in2019 1st International Conference on Advances in Science, Engineeringand Robotics Technology (ICASERT), 2019, pp. 1–6.

[21] Google, “Exposure notification - FAQ v1.1,” https://blog.google/documents/73/Exposure Notification - FAQ v1.1.pdf, May 2020.

[22] Google, “Exposure notification - Bluetooth Specification pages,”https://blog.google/documents/70/Exposure Notification - BluetoothSpecification v1.2.2.pdf, May 2020.

[23] R. Damasevicius, G. Ziberkas, V. Stuikys, and J. Toldinas, “Energyconsumption of hash functions,” Elektronika ir Elektrotechnika, vol. 18,pp. 81–84, 12 2012.

[24] Google, “Exposure notifications service additional Terms,”https://blog.google/documents/72/Exposure Notifications ServiceAdditional Terms.pdf, June 2020.

[25] R. Mahmud, F. L. Koch, and R. Buyya, “Cloud-fog interoperability iniot-enabled healthcare solutions,” in Proceedings of the 19th interna-tional conference on distributed computing and networking, 2018, pp.1–10.

[26] G. Yang, M. Jiang, W. Ouyang, G. Ji, H. Xie, A. M. Rahmani, P. Lil-jeberg, and H. Tenhunen, “Iot-based remote pain monitoring system:From device to cloud platform,” IEEE Journal of Biomedical and HealthInformatics, vol. 22, no. 6, pp. 1711–1719, 2018.

[27] C. Gomez, J. Oller Bosch, and J. Paradells, “Overview and evaluationof bluetooth low energy: An emerging low-power wireless technology,”Sensors (Basel, Switzerland), vol. 12, pp. 11 734–53, 12 2012.

[28] P. Kumar, L. Reddy, and S. Varma, “Distance measurement and error es-timation scheme for rssi based localization in wireless sensor networks,”in 2009 Fifth international conference on wireless communication andsensor networks (WCSN). IEEE, 2009, pp. 1–4.

[29] D. Robinson, Amazon Web Services Made Simple: Learn how AmazonEC2, S3, SimpleDB and SQS Web Services enables you to reach businessgoals faster. Emereo Pty Ltd, 2008.

[30] “Amazon web services (aws) - cloud computing services,” https://aws.amazon.com/, (Accessed on 06/07/2020).

[31] “Neo4j graph platform the leader in graph databases,” https://neo4j.com/, (Accessed on 06/07/2020).

[32] Q. Tang, “Privacy-preserving contact tracing: current solutions and openquestions,” arXiv preprint arXiv:2004.06818, 2020.

[33] L. Reichert, S. Brack, and B. Scheuermann, “Privacy-preserving con-tact tracing of covid-19 patients,” Cryptology ePrint Archive, Report2020/375, 2020, https://eprint.iacr.org/2020/375.

[34] T. Altuwaiyan, M. Hadian, and X. Liang, “Epic: Efficient privacy-preserving contact tracing for infection detection,” in 2018 IEEE In-ternational Conference on Communications (ICC). IEEE, 2018, pp.1–6.

[35] S. Vaudenay, “Analysis of dp3t,” Cryptology ePrint Archive, Report2020/399, 2020, https://eprint.iacr.org/2020/399.

[36] A. Government, “Privacy policy for COVIDSafe app,”https://www.health.gov.au/using-our-websites/privacy/privacy-policy-for-covidsafe-app, June 2020.

[37] A. Government, “Privacy amendment (Public Health Contact Informa-tion) act 2020,” https://www.legislation.gov.au/Details/C2020A00044,June 2020.