On the Privacy and Integrity Risks of Contact-Tracing Applications
22020
Jianwei Huang, Vinod Yegneswaran, Phillip Porras, and Guofei Gu
On the Privacy and Integrity Risks of Contact-TracingApplications
Abstract:
Smartphone-based contact-tracing applica-tions are at the epicenter of the global fight against theCovid-19 pandemic. While governments and healthcareagencies are eager to mandate the deployment of suchapplications en-masse, they face increasing scrutinyfrom popular press, security companies, and humanrights watch agencies that fear the exploitation of thesetechnologies as surveillance tools. Finding the optimalbalance between community safety and privacy has beena challenge, and strategies to address these concernshave varied among countries. This paper describes twoimportant attacks that affect a broad swath of contact-tracing applications. The first, referred to as contact-isolation attack , is a user-privacy attack that can beused to identify potentially infected patients in yourneighborhood. The second is a contact-pollution attack that affects the integrity of contact tracing applicationsby causing them to produce a high volume of false-positive alerts. We developed prototype implementa-tions and evaluated both attacks in the context of theDP-3T application framework, but these vulnerabilitiesaffect a much broader class of applications. We foundthat both attacks are feasible and realizable with a min-imal attacker work factor. We further conducted an im-pact assessment of these attacks by using a simulationstudy and measurements from the SafeGraph database.Our results indicate that attacks launched from a mod-est number (on the order of 10,000) of monitoring pointscan effectively decloak between 5-40% of infected usersin a major metropolis, such as Houston.
Keywords:
Privacy, Contact-Tracing, Bluetooth Secu-rity
Jianwei Huang:
Texas A&M University, E-mail:[email protected]
Vinod Yegneswaran:
SRI International, E-mail:[email protected]
Phillip Porras:
SRI International, E-mail: [email protected]
Guofei Gu:
Texas A&M University, E-mail:[email protected]
Contact-tracing applications (CTAs) have emerged asa critical tool used by many countries to combat thespread of the Covid-19 virus within their borders. Todate, more than 70 countries have launched contact-tracing smartphone apps. These apps rely on eitherBluetooth Low Energy (BLE) or GPS to track usermovements and contacts. Many countries have man-dated the installation of these apps on the smartphonesof all of their citizens. Among the most widely deployedtracing apps is India’s Aarogya Setu application [1] withover 50 million users in the first two weeks. Anotherwidely deployed application is China’s contact-tracingsoftware that uses a color-coding system (red, yellow,green) to classify citizens based on their infection riskprofiles [9]. Russia’s CTA requires its citizens to down-load a QR code and to declare intended travel routes tonavigate through major cities, such as Moscow [20].The value proposition of CTAs is that they pro-vide a service to inform users when they have experi-enced close-proximity contact with another CTA userwho has tested positive for Covid-19. When deployedubiquitously throughout a community, the applicationenables users to continually assess their Covid-19 ex-posure risk. The majority of CTAs advertise an abilityto preserve two important properties. ( i ) User privacy :the CTA will not reveal the identity of any Covid-19 in-fected CTA user. ( ii ) Exposure report integrity : the CTAservice provides its users with accurate and timely ex-posure reports that enable them to continually monitortheir personal infection risk.However, the emergence of these applications hasspawned significant community discussion and seriousconcerns regarding the extent to which these applica-tions meet these privacy and reliability assertions. Inparticular, applications adopting a centralized trackingapproach have faced significant criticisms from humanrights organizations and the security community [4]. Anappalling example is the case of the BeAware applica-tion from Bahrain, where users became unwitting con-testants in a television game show, with the host ran-domly calling citizens and rewarding them for follow-ing social-distancing guidelines. Other countries adopt-ing centralized data-collection approaches include Qatarand Norway. Wen et al. [46] analyzed the privacy usage a r X i v : . [ c s . CR ] D ec n the Privacy and Integrity Risks of Contact-Tracing Applications in 41 CTAs and found that some applications exposeidentifiable information that can enable tracking of spe-cific users. Sun et al. [42] evaluated existing applicationsand proposed a venue-access-based contact-tracing so-lution which preserves user privacy while enabling prox-imity contact tracing.To alleviate the privacy concerns introduced by cen-tralized data-collection strategies, both Google and Ap-ple have released alternative CTA frameworks that havebeen adopted by many countries. These frameworks es-pouse a fully decentralized approach, with no exchangeor upload of personal information or location data, ex-cept for random numerical strings that change every 10-20 minutes. Despite these efforts to reduce user privacyconcerns, serious risks in using CTAs persist, and mul-tiple recent studies [14, 42] have concluded that the vastmajority lack security controls and often leak sensitiveuser information [46].This paper provides a deeper examination of theprivacy and integrity properties of the dominant CTAframeworks. We describe and formalize two adversar-ial strategies to violate the privacy and integrity as-sumptions of a wide range of CTAs, including thosefollowing the Google and Apple frameworks. The firstattack, which leads to the de-anonymization of Covid-positive CTA users, is the contact-isolation attack . Thisattack uses a combination of device spoofing, pool test-ing, and device re-identification techniques to efficientlynarrow potential contacts to a single victim. Pool test-ing has been used in various scenarios, including groupblood testing [30], de-anonymizing Internet sensors [25],and most recently in waste-water-based Covid com-munity tracking [16]. We extend this concept to theproblem of Covid victim identification and demonstratethat it can be implemented across communities witha modest adversary work factor. In addition, we fur-ther evaluated how attackers may leverage the Blue-tooth MAC addresses obtained in contact-isolation at-tack to deanonymize infected users by extracting per-sistent identifiers (WiFi MAC, SSID) and using onlineSSID location databases, such as Wigle [22].The second attack, contact-pollution , affects CTAintegrity by polluting the Covid contact database withinaccurate contact information leading to false positivenotification alerts. The contact-pollution attack com-bines contact-tracing relay attacks with replay attacks.While relay and replay attacks have been independentlypublished in prior work [42], the specific application ofthis attack mix in combination with Bluetooth rangeextenders has not been explored. We implemented contact-isolation and contact-pollution attacks on Android phones and evalu-ated them against the DP-3T (Decentralized Privacy-Preserving Proximity Tracing) framework [7]. We alsoassessed the implications of these attacks by using thepoint-of-interest (POI) data from SafeGraph [15], whichprovides aggregated and anonymized datasets on socialdistancing and foot traffic to businesses. Such data isinvaluable in tracking the spread of pandemics such asCovid. Based on our analysis, we found that a relativelysmall number of sensors (˜10,000), placed in strategic lo-cations across a city, could be used to effectively iden-tify devices associated with infected users. Large-scalede-anonymization of infected individuals would also bepossible if these sensors could be integrated with videocameras and combined with face-search databases [21].In summary, the contributions in this paper includethe following:– Description and formalization of two important at-tacks affecting CTAs.– A prototype system that demonstrates the feasibil-ity of both attacks and supports their evaluationagainst the DP-3T application.– An analytical evaluation of an adversarial use ofthese attacks at scale, using simulation and the Safe-Graph database.– Discussion of the implications, ethical considera-tions, and potential countermeasures to the workreported here. To mitigate the spread of Covid-19, CTAs are beingwidely deployed on smartphones all over the world.These applications work by automatically exchangingdata with nearby devices. When an owner of a cell-phone with CTA is identified as infected, the CTAuploads a report to the server. The reporting processvaries across applications and countries, but in manycases, it is either voluntary or a combination of self-reporting, health-authority-based reporting, and anal-yses of data gathered from other sources like publictransportation and banking. Infection reporting triggerscontact-notification messages that will be distributed toall CTA users who may have had close contact with thepatient over the past several days. By using CTAs, usersand authorities have been able to effectively track andreduce the spread of Covid-19 in many countries. n the Privacy and Integrity Risks of Contact-Tracing Applications Table 1.
Summary of a few published security flaws in major CTAs.
App Name Country Architecture Published Security FlawsEHTERAZ Qatar Centralized A QR-code vulnerability was discovered that leaked information potentially al-lowing hackers to harvest more than a million people’s national ID numbers andhealth status. The app is reported to be mandatory in Qatar with three yearsin prison and a fine of QR 200,000 (about $55,000) for non-compliance [13].BeAware Bahrain Centralized These contact-tracing apps export real-time GPS tracking information to acentral database which might be used for surveillance [2]. Norway hasstopped the development of its CTA due to pushback.Shlonik Kuwait CentralizedSmittestop Norway CentralizedAarogya Setu India Centralized Researchers discovered a vulnerability in the app feature to discover infectedpeople who were nearby (within a 500 m radius) using GPS coordinates. Theauthors demonstrated a triangulation attack that allows tracking infections toindividual homes in sparse locations and confirm Covid status of suspectedindividuals. The app is mandatory for moving around in India [10].NHS App UK Decentralized Several vulnerabilities were identified including lack of TLS certificate valida-tion, use of long-lived BLE BroadcastValues, device reidentification attacksbased on the use of a deterministic keep-alive counter, storing unecrypteddata on handsets that could be used by law-enforcement to determine con-tacts etc [3]. Based on these reports, UK decided to switch to a backup optionthat uses a decentralized model.Covid Safe Australia Decentralized Both of these applications use the OpenTrace framework which uses theTraceTogether Singapore Decentralized BlueTrace protocol. These are vulnerable to long-term device-re-identificationattacks due to the fact that tempIDs are used for extended periods and maypresent themselves across locations [6, 12]. These vulnerabilities could beexploited in tandem with our contact-isolation attack.
The high-level architecture of a typical CTA is illus-trated in Figure 1. When two users, A and B, becomeproximate, their phones will exchange a key code. Thecode is generated from the private information of usersusing advanced cryptographic algorithms (e.g., RSA,SHA-1). Most applications use the advertisement mes-sage in Bluetooth Low Energy (BLE) to exchange data,which persistently broadcasts messages to nearby de-vices. If user A subsequently becomes infected, he up-dates his status in the application. The design of the ap-plication determines which of the two possible strategieswill be used for distributing the notification messages.
Centralized Applications.
For centralized applica-tions, user A provides his anonymized ID plus codesgathered from other proximate phones to the centralizedserver. The server decrypts these codes or does contactmatching in the database to identify all potentially af-fected users and then alerts them.
Decentralized Applications.
For decentralized appli-cations, user A provides the code/key used in the past14 days to the server. All users of the application period-ically download the database and perform local contact matching. In this case, alerts are sent from client-sideapplications installed on user devices.Table 1 provides a summary of a few of the ma-jor published security flaws in CTAs. In most cases,governments have been quick to respond to publishedflaws, by either issuing security patches, rethinking ar-chitectural designs, or scrapping the application. Whilesecurity flaws seem more egregious and pervasive in cen-tralized architectures, they affect both classes of appli-cations. None of these disclosures specifically discuss theattacks that are described in this paper, however, thesecurrently documented adversarial techniques could becombined with the attacks presented here to increasetheir effectiveness. For example, the GPS-based trian-gulation attack could be combined with the Bluetooth-based contact-isolation attack.
As mentioned in 2.1, most CTAs will communicatewith nearby devices to record close contacts. To satisfythe privacy and feasibility requirements of CTAs, thedata-exchange protocol should be easily implementableand able to guarantee the anonymity of exchanged mes-sages. Hence, Bluetooth, as one of the most widely usedwireless communication protocol, is used in almost allthe contact tracing applications as the data-exchangingprotocol. Specifically, CTAs leverage the advertisement n the Privacy and Integrity Risks of Contact-Tracing Applications When A and B meet, their phones exchange a key code
When A becomes infected, he updates his status in the app Users provide ownanonymised ID plus codes gathered from others to centralized database
Infected people provide the code/key he used in the past
14 days
The server uses database to do contact matching, risk analysis and send alertsUsers download database. Then they do contact matching, risk analysis and send alerts
Fig. 1.
Illustration of the messaging workflow in centralized and decentralized architectures used by Covid-19 CTAs. message to actively send generated code to nearby de-vices. Meanwhile, the applications will continue collect-ing advertisement messages and extract the code ofnearby devices from these messages. The benefit of ad-vertisement messages is that no device-specific informa-tion is included in the message.
App Framework/Bluetooth Framework/Bluetooth
State RequestGenerate Temporary Key15minsBluetooth Broadcast(..., Rolling Proximity Identifier, ...)Bluetooth Broadcast(..., Rolling Proximity Identifier, ...)24hoursBluetooth Broadcast(..., Rolling Proximity Identifier, ...)Generate Temporary Key local Remote
Fig. 2.
Data Exchange Protocol used by Google and AppleFrameworks.
As an example, the detailed workflow of the senderpart of the data-exchange protocol in Google and Ap-ple contact tracing frameworks is shown in Figure 2.When the local CTA requests to send the state codeto nearby devices, the framework first generates a tem-porary key. Each time the framework sends an adver-
Table 2.
Inputs for exchanged code-generation functions.
Application Temporary Key Timestamp Location Algorithm tracetogether (cid:88) (cid:88) (cid:88)
AESmytrace (cid:88) (cid:88)
AESaarogya (cid:88) (cid:88)
AES, SHA-256rakning (cid:88)
AES, SHA-256erouska (cid:88)
HKDF, AESCovidsafe (cid:88) (cid:88)
AESgeohealthapp (cid:88) (cid:88)
AESnovid (cid:88)
AESstop corona (cid:88)
HKDF, AESsmittestop (cid:88)
AEShamgen (cid:88)
AESswissCovid(DP-3T) (cid:88)
HKDF, AES tisement message, a rolling proximity identifier will begenerated from the temporary key. The default intervalof updating the identifier is 15 minutes. Since the iden-tifier generation algorithm is open-sourced, it is possibleto associate different identifiers and further identify thedevice with enough identifiers. To mitigate the securityissue, the temporary key is updated every 24 hours.Different applications generate the exchanged codewith different inputs. We collected 12 popular CTAs indifferent countries and analyzed the information used(see Table 2). Most applications generate a temporarykey periodically and use an advanced cryptography al-gorithm to generate the code.
Central to the appeal of CTAs is the premise that theyprovide users a timely and accurate risk assessment ser-vice while also protecting each user’s personal Covid-19infection status. More specifically, CTAs typically ad-vertise an ability to preserve two important properties:( i ) User privacy , which ensure that each user’s Covid-19 n the Privacy and Integrity Risks of Contact-Tracing Applications status is protected from other users, and ( ii ) Exposurerisk integrity , which ensures that users receive timelyand accurate risk indicators when near-proximity expo-sure to other Covid-19-infected CTA users occurs. Onemay observe that these two properties are mutually con-tradictory, as the satisfaction of one property will likelyprevent satisfaction of the other property. For exam-ple, if a sequestered CTA user meets only one otherperson during a given week and then subsequently re-ceives a Covid-19 exposure report, then it is trivial toinfer that the other user is Covid-19 positive. However,withholding the exposure report to avoid such a de-anonymization would violate the requirement for accu-rate and timely report delivery to ensure that the se-questered user can properly assess their personal risk.Even when considered separately, we find that ad-versarial models exist that directly violate each of thesetwo properties across multiple CTA frameworks. In thissection, we discuss these models and present specificmethods to implement attacks within a reasonable ad-versary work factor. The first attack, (i.e., contact-isolation attack ) enables one to selectively violate theuser privacy property of CTAs. The second attack (i.e., contact-pollution attack ) enables adversaries to preventCTAs from satisfying the exposure risk integrity prop-erty. These attacks are quite general, and affect a broadclass of applications, and are agnostic to whether theCTA follows the centralized or decentralized model.
Our threat model assumes that attackers have full ac-cess to their own devices. Attackers can modify the ap-plication stack running on phones, Bluetooth drivers oftheir devices, data exchanged with other devices, anddata uploaded to remote servers from their devices.However, attackers have no access to other user devicesand servers. We also make no assumptions about theability of attackers to exploit remote servers or otheruser devices.The model further assumes that attackers can fullyreverse-engineer the workflow of the clients of target ap-plications by analyzing the source code or binary file ofthe clients of target applications. Attackers know howto ( i ) create multiple accounts; ( ii ) upload records toservers; ( iii ) exchange data with other devices; and ( iv )check notification messages. We do not consider the ap-plications if strict restrictions are deployed on the serverside to stop attackers from emulating these four opera-tions. Although attackers know the workflow of clients,we assume that all communication between differentuser devices and all communication between devices and servers are well-protected by HTTPS and Bluetoothprotocols.For automated large-scale de-anonymization, we as-sume that these sensors are placed at popular locations(cafes, gas stations, etc.) in the city. We further assumethat these sensors have integrated video cameras for ef-fective device-to-victim persona mapping. To clearly illustrate the attacks, we first formalize theworkflow of typical CTAs, assuming an attacker is theuser of the target application. When the attacker hasclose contact with other users, each of these deviceswill mutually exchange anonymized data. The data dis-tributed by the attacker’s device is indicated as c att , andthe data that the attacker’s device receives is C att = { c , c , c , ..., c n } . The test result of the attacker is r att .By default, r att is f alse . Similarly, the set of receivedtest results is R att = { r , r , r , ..., r n } and r i = f alse ,where i = 1 , , , ..., n .A user k who is confirmed to be infected, will reporttheir infection to the server, which sets r k to true . If theattacker had recent close contact with user k , d k ∈ D att and r k = true . Now, the attacker is considered to be atrisk for the infection. In this case, notification messages,denoted as N , will be sent to the attacker. Here, N is Σ R att . By abusing notification messages, the contact-isolationattack allows an attacker to identify the device whoseowner is confirmed Covid positive, which breaks theanonymity of CTAs.When the devices of confirmed cases in R att are R att _ confirmed = { r c , r c , r c , ..., r cm } , the contact-isolation attack aims to divide C att into many sublists C , C , C , ..., C s . Ideally, for each confirmed case r p ∈ R att _ confirmed , if r p ∈ C q , r p / ∈ C k , where ≤ p ≤ m , ≤ q ≤ s , k = 1 , , , ..., s and k = q .Then the attacker creates s new accounts. For eachnew account u i , the attacker uploads C i to the server.If the notification message is sent to u i , there must beat least one confirmed case in C i . If | C i | is 1, the deviceis exactly the one that belongs to the confirmed case. Ifnot, by repeating the approach, the attacker can finallyreduce | C i | to 1 and find the device. False positive (and negative) alerts are a significant con-cern for most security applications and healthcare as-sessment tests. The same holds true for CTAs. For ex- n the Privacy and Integrity Risks of Contact-Tracing Applications Pool testing
Fig. 3.
Illustration of the contact-isolation attack. Many applications are simulated in the device simulator. The attack device ex-changes the data from simulated devices with normal devices, monitors 802.11 activity, as well as captures a video feed of visitors en-tering the location. When normal user updates his status in the server, only the simulated application whose data is exchanged withthe confirmed case will receive the notification message. ample, Schneier et al. [11] observe that CTAs typicallydefine a risk exposure based on a six-foot proximityof two CTA users for more than ten minutes. Unfor-tunately, the dependencies on GPS and Bluetooth sig-naling are imprecise due to a range of factors that areinherent with RF propagation or mobile GPS signal in-accuracies or location update delays.While our paper refrains from making any suchhigh-level determinations on the utility of Covid CTAs,the key takeaway is that high false positive or false nega-tive rates can render these applications useless. This sec-tion describes how a contact-pollution attack corruptsthe contact database of target applications and resultsin many false positive notification messages. Increasingthe false positive rate of a contact tracing applicationwill decrease its reliability initially making them para-noid and subsequently cavalier to alerts produced by thesystem.Existing CTAs assume that all the data from otherdevices is trustworthy because they use advanced cryp-tographic algorithms to generate the exchanged data.However, since we can both send and receive data, thereare two avenues for the attacker to insert fake contactdata that pollutes the contact database.1. The attacker can send the data received from otherdevices to all the devices in range; i.e., attackersends C att to d i where d i is in range of attacker’sdevice. As shown in Figure 4, when Alice and Bobare in range of the attacker’s device, but not in mu- c 𝑎 c 𝑏 Alice BobAttacker 𝐶 𝑖 Ø Ø {c 𝑎 , c b } c 𝑎 c 𝑏 Alice BobAttacker 𝐶 𝑖 {c 𝑏 } {c 𝑎 , c b } {c 𝑎 } c 𝑏 c 𝑎 Before Attack:
After Attack:
Fig. 4.
Example of contact-pollution attack. Both Alice and Bobhave close contact to attacker but they are out-of-range of eachother. However, when the attacker impersonates them, Alice andBob will receive the data from each other and think they hadclose contact with each other. tual range, they will still receive fake contact datafrom each other.2. If the attacker has multiple devices in differentplaces, these devices can communicate with eachother and share the received data. Thus, C att con-tains the data we received through all attacker’sdevices, and the attacker keeps sending C att toall other devices in range of his devices. In thiscase, when Alice is shopping while Bob is attend-ing classes, if they are in range of attacker’s devices, n the Privacy and Integrity Risks of Contact-Tracing Applications they will receive fake contact data from the attacker,who is impersonating both of them.While the first approach effectively doubles the attackrange, the second approach infinitely extends it. Bothof these approaches will result in additional r k in R Alice and R Bob . Thus this attack can stimulate a large numberof fake notification messages when r j = true is insertedinto R of other users. This section describes how the previously described at-tacks can be implemented. As discussed in Section 2,most CTAs leverage Bluetooth to collect contact infor-mation, therefore, our attacks are primarily focused onthe Bluetooth medium. We use the DP-3T frameworkas an example to illustrate how we can apply the attacksto real-world CTA scenarios.
The architecture of our prototype implementation forthe contact-isolation attack is illustrated in Figure. 5.Our implementation is divided into four components.The first component, the
Contact Collector , is deployedon the attackers’ devices and is used to exchange datawith normal CTA users. The second component, the
Contact Distributor , separates the collected data intoseveral groups and sends them to the
Device Simulator based on the algorithm illustrated in Algorithm 1. Theinitial value of { C i } is C att , so we divide C att into n parts to produce C i for the first run. Each Device Sim-ulator will have a unique account created by attackers.When the Device Simulator receives the contact data,it will upload the data to the server and wait for notifi-cation messages. All received notification messages willbe forwarded to the Contact Analyzer, which extractsthe device information of confirmed cases. Contact Collector.
To collect the contact informa-tion, the target application will be running as a normaluser. We use Frida [8] to dynamically instrument thetarget application. Since most CTAs are based on Blue-tooth, we hooked the Bluetooth API to intercept thebeacon data from other devices before they are handledby the application. More specifically, we hooked
Mes-sageListener.onFound on Android.
Contact Distributor.
When C i is sent to the ContactDistributor, C i is divided into several subsets and sentto different simulated devices to communicate with theserver. Normal UsersContact Collector Contact Distributor Contact AnalyzerSimulatorSimulated UserSimulated UserSimulated User … … 𝐶 𝑖 𝑁 𝑖 Device information of confirmed cases 𝐶 𝑎𝑡𝑡 𝐶 𝐶 𝐶 𝐶 𝑖 𝑁 𝑁 𝑁 𝑁 𝑖 𝑅𝑒𝑓𝑖𝑛𝑒𝑑 {𝐶 𝑖 }𝐶 𝑎𝑡𝑡 Fig. 5.
Prototype implementation of the contact-isolation attack.
Device Simulator.
The Device Simulator creates aset of simulated devices. Each device will maintain asimulated user and the communication between the de-vice and the server. Our implementation extracts therelevant logic of the target application and repackagesit. So each simulated device is actually a process run-ning on our device. The challenge in the Device Simula-tor is how to create the necessary number of accounts,as most CTAs require personal information to sign up,however, only a few required personal attributes are ver-ified. Most applications only verify the phone number,which can be easily obtained from an online temporaryphone number service. Since the number of accountsneeded for most cases is under 30, we can manually reg-ister the accounts for our attacks.DP-3T does not have difficult restrictions for ac-count creation. For confirmed infection cases, users areidentified by a Covidcode, which is assigned to users bythe government or hospital. Other users do not need toupload any information to the server. The only chal-lenge in launching the contact-isolation attack is thepossible firewall deployed on the server side, which isnot included in the application itself. Therefore, we de-ployed DP-3T on our local machine with a simple fire-wall, which rejects connections from the same IP addresswhen the number of connections reaches the threshold(10 in our evaluation).
Contact Analyzer.
When all the N i have been col-lected, the Contact Analyzer will check if one of themis true . If so, the Analyzer will refine sets of C i for sim-ulated users to get another set of N i . The algorithm torefine C i is as shown in Algorithm 1. Scenario 1: Controlled-Encounter Scenario.
Inthis scenario, the target set includes frequent contacts(e.g., coworkers, neighbors). The attacker walks around n the Privacy and Integrity Risks of Contact-Tracing Applications Algorithm 1
Contact-Refinement Algorithm
Input: { C i } , where i = 1 , , , ..., n used in last run, cor-responding status { N i } and number of simulated de-vices/applications n . Output: refined { C i } C i = ∅ T = ∅ positive _ counts = 04: for k from 1 upto n do if N k == true then positive _ counts = positive _ counts + 17: T = T S N k set _ pool = n/positive _ counts counts = 010: for N p ∈ T do set _ size = | N p | /set _ pool for j from 1 upto set _ pool do C counts ∗ set _ pool + j ={the (set_size*j)th to(set_size*j+j)th elements in N p }14: counts = counts + 1 (the neighborhood, apartment, dorm, office building)choosing a different (potentially overlapping) set ofhouses or offices in each round. In each round, the at-tacker spoofs a different device identifier. By repeatingthis experiment for a few rounds and using pool test-ing, the attacker can quickly narrow down to a smallnumber of infected neighbors. The key point is that theattacker can have a potentially unlimited number of en-counters with each contact since they reside in the samecommunity. In addition, Bluetooth range extenders alsoimprove the feasibility of the attack, as interactions nolonger have to be close physical interactions.If the attacker creates n accounts for pool testing,and the number of users of the application in the com-munity is N , the attacker only needs to do log n N roundsof pool testing to identify all the infected users. Scenario 2: Opportunistic-Encounter Scenario.
This scenario requires three additional capabilities foruncontrolled de-anonymization of infected users to dealwith the challenges involved in scaling and device re-identification. First, we address scaling by using a pool-testing strategy that involves reusing a set of identi-fiers across groups of contacts. Second, we will trackWiFi broadcast activity in addition to Bluetooth ac-tivity, and use temporal correlations to map WiFi ad-dresses with Bluetooth activity. While recent Androidand iOS versions implement MAC address randomiza-tion, this happens only during the probe stage and per-SSID MAC consistency is maintained to facilitate au-tomatic re-authentication. In addition, automatic WiFiprobes also broadcast the names of recent networks to which a device has connected to that leak additionalinformation, such as names of home or work networks,airports, cafes visited, etc. This information can then beused or combined with other device re-identification at-tacks [12] to track repeated visits by users that help tonarrow the precision from groups of devices to individ-ual devices. Thus, 802.11 (SSID, MAC) pairings providea means to go from an ephemeral identifier (BluetoothMAC) to a persistent identifier. Third, information fromthe integrated video camera could be used to derive themapping from device identifiers to individuals. In addi-tion, private SSID information can be used for locationtracking of individuals using public databases, such asWigle [22].To associate the WiFi probes to Bluetooth ad-dresses, we differentiate the pair of probes and addressesby checking their existence and the time we first de-tected them. Since the signal strengths of WiFi andBluetooth are different, we may not be able to iden-tify all pairs if they only appear once. That is, for mostdevices the attacker will be able to associate the WiFiprobe and the Bluetooth address if it communicatesmultiple distinct times (encounters) with the attack de-vice. Based on our analysis in Section 5.3, most pairscan be identified with two encounters. Each visit to amonitoring location (e.g., store, cafe) would likely resultin multiple encounters.
The prototype implementation of contact-pollution at-tack has three main components, as illustrated in Figure6. We continue to use the
Contact Collector to gathercontact information from the devices of other users. Allcollected contact information will be transmitted to the
Contact Concentrator . Once the Contact Concentratorreceives new data, all the
Contact Polluters will receivea new database. The Contact Polluters use this infor-mation to continuously broadcast as many contact mes-sages as they can. Contact Concentrator.
The Contact Concentrator isimplemented as an HTTP server, which provides twoAPI functions for the Contact Collector and ContactPolluter, respectively, to upload and download contactinformation.To further spread false contacts, attackers need tocollect the contact information from the original user The actual number of messages in practice is limited due tothe physical limitation of devices. Details will be described inSection 5.2) n the Privacy and Integrity Risks of Contact-Tracing Applications Contact ConcentratorContactCollector/PolluterDevice 1Device 2 … … 𝐶 𝐶 𝐶 𝑖 … Normal Users(Starbucks)Normal Users (Walmart)
Normal Users (Other places) 𝐶 𝑖 𝐶 𝑖 𝐶 𝑖 𝐶 𝑖 𝐶 𝑖 Fig. 6.
Prototype implementation of the contact-pollution attack and replay it to another user. To introduce n false con-tacts to the database, attackers should participate in atleast n interactions with other users. This section presents our evaluation results that focuson the practicality and impact of the two attacks. Morespecifically, our evaluation seeks to answer the followingresearch questions:R1. How feasible are the proposed attacks?I. Are the attacks practical for real-world applica-tions?II. How much time do attackers need to completethe attacks?R2. How can the attacks affect the users of CTAs?I. Is it possible to de-anonymize the victims?II. How many users are at risk?To answer R1.I, we evaluated the challenges in launch-ing the attacks on real-world applications (Section 5.2).We also analyzed the limitations and performance ofeach attack to determine the answer to R1.II. For R2.I,we tested the existing techniques of identifying userswith Bluetooth MAC address (Section 5.3). The resultsshow that user identities can be leaked to attackersin specific cases. Finally, we empirically evaluated thenumber of possible victims in different cities with thedatabase from SafeGraph to answer R2.II (Section 5.4).
To answer the first set of questions, we evaluated ourattacks on the sample application and the backend ofDP-3T. We simulated the attacks with different victimdevices and different attacker devices. The threshold ofdistance that devices will exchange data is 5 meters,and the time threshold is set to 1 second to simplify theevaluation process.
Table 3.
List of devices used for the simulation experiment
Device Model OS version
A iPhone 11 iOS 14.0B iPhone SE (2nd ed.) iOS 13.5.1C Xiaomi Mix 2 MIUI 10 Global 9.6.27D Macbook Pro (2020) MAC OS X 10.15.5
We obtained POI datasets from SafeGraph. Thedatasets contain addresses, open hours, visitor counts,and popular times of over 1 million places. We lever-aged these datasets to explore the question of large-scaleattack deployment strategies that could maximize theattack coverage across city populations. We performedfurther analyses regarding de-anonymization based onthe results of our attacks. This paper uses Houston andBryan, TX and Chicago, IL as examples to show howthe attacks can possibly affect the users of CTAs. To simulate the attack on the sample application of DP-3T, we deployed the server on AWS. The devices we usedin the simulation are shown in Table 3. For iOS devices,we made some modifications to the source code of theclient to avoid jailbreaking the devices. The modifica-tions include the following elements. ( i ) When a deviceexchanges data with another device, the data and infor-mation of the other device will be stored into local file.( ii ) All contact-tracing-related operations (i.e., broad-cast data, retrieved data, data uploaded to the server)will be logged with timestamps.For Android devices, we use Frida to instrument theapplication and implement functionalities analogous tothose we implemented on iOS devices. To store the dataand device information of another device, we hooked the MessageListener.onFound
API function and extractedthe parameters sent to it. To log all contact tracing re-lated operations, we looked into the source code of thesample application and found corresponding methods(Table 6) that were hooked to log operations.
Account Creation. . The contact-isolation attack re-quired the creation of accounts to simulate users. How-ever, most applications limit the number of accountseach person can create by requiring unique informa-tion(e.g., medical ID, phone number) from users. Table4 shows the required information for applications thatwe have tested. Unfortunately, due to possible privacy For these analyses, we assume that CTAs are mandatory toeveryone and have been deployed on all user devices. n the Privacy and Integrity Risks of Contact-Tracing Applications Table 4.
Required information for creating account in CTAs
Application Phone Number Valid ID * Device ID tracetogether (cid:88) (cid:88) (cid:88) mytrace (cid:88) (cid:88) aarogya (cid:88) (cid:88) rakning (cid:88) (cid:88) erouska (cid:88)
Covidsafe (cid:88) (cid:88) geohealthapp (cid:88) novid (cid:88) stop corona (cid:88) smittestop (cid:88) hamgen (cid:88) swissCovid(DP-3T) (cid:88) * passport, driver license, medical ID, etc. Table 5.
Summary of recorded encounter data in devices
Device Name Encounter Recorded Encounter V A V B V C A B C issues, not all applications require user to provide sensi-tive unique information (e.g. passport number, medicalID). Instead, they use a phone number or device ID toidentify users, which can be easily forged by attackers.In our evaluation, we successfully registered users in allapplications in Table 4 except tracetogether , which re-quires a valid ID in Singapore. Stop corona , swissCovid ,and erouska use the Google and Apple framework togather anonymous ID, from other users, and device ID isthe only required information to create accounts. Thus,we created multiple users by emulating Android phonesusing Bluestack. Mytrace , aarogya , rakning and Covid-safe require phone number to create account but thephone number will only be verified during the regis-tration. Hence, we leveraged online temporary phone-number services to receive the tokens for registrationand created accounts in the four applications.
Contact-Isolation Attack.
To simulate the contact-isolation attack, four devices (A, B, C, and D) are placed so that the attacker device (D) is the one and only de-vice that communicate with all three other devices. A,B, and C are all normal devices and the user of C is as-sumed to be Covid positive. The attacker’s device D hasclose contact with the three devices. The goal of the at-tacker is to pinpoint the confirmed case. As mentionedin Section 4, D will create three accounts to commu-nicate with A, B, and C (i.e., denoted as V A , V B , and V C , respectively). Then D exchanges data with the threedevices using the corresponding identity. When all datahas been exchanged, C reports its status to the serverand other devices pull the report from the server. Thedata stored in each device/account are as shown in Ta-ble 5. The recorded encounters of V A , V B , and V C areassigned by our tool, according to Algorithm 1. The re-sults show that only data from C can be matched tothe database from the server. Hence, C is the confirmedcase, and D can obtain the corresponding device infor-mation from its log file. Contact-Pollution Attack.
We leveraged the Blue-tooth advertisement message to simulate the contact-pollution attack. The Bluetooth advertisement messageis the most popular communication tunnel for CTAs. Inour evaluation, we implemented a tool for Mac OS toautomatically broadcast the advertisement messages itreceives. The four devices are carefully placed such thatA, B, and C can all communicate with D but are outof range to communicate with each other. Since D willreplay the messages it receives, c A , c B and c C , will bebroadcast. Hence, A, B, and C will receive the messagesand record the message since they are within the spe-cific range of D. Then we use C to report its positivediagnostics to the server. The results show that both Aand B received the notification messages although theydid not have close contact with C.The number of advertisement messages that a de-vice can send at the same time is limited by its physicallimitation. According to the Bluetooth specification, themaximum time interval between two messages is fourseconds. For most applications, the duration for record-ing a close contact is at least five minutes, which meanswe need to continuously send the advertisement messageduring the five minute period. Each time we send anadvertisement message, we need about 100 milliseconds(varies across devices). Summing the time cost of otherlogic (including regenerating and capturing messages) inthe application, adding an advertisement message intoour list will cost around 400 milliseconds. Thus, we cantarget at most /
400 = 10 devices at the same timewith one attack device. Although the number of vic- n the Privacy and Integrity Risks of Contact-Tracing Applications Table 6.
Summary of operation methods hooked in Android Applications
Class Method Description
GoogleExposureClient getTemporaryExposureKeyHistory Retrieves key history from the data store on the deviceGoogleExposureClient provideDiagnosisKeys Provide the keys of confirmed cases retrieved from serverGoogleExposureClient getExposureInformation Provides a list of ExposureInformation objects, fromwhich you can gauge the level of risk of the exposure tims are limited, the distance between attackers and vic-tims can be much larger. By leveraging commodity long-range Bluetooth transmitters, attackers may be able tolaunch attacks from as far away as 100 meters.
Since devices often randomize their Bluetooth MACaddresses, it is still hard to identify the real personwith the Bluetooth MAC address obtained by the ba-sic contact-isolation attack. Hence, we evaluate how wecan further de-anonymize user devices by associatingWiFi probe messages with observed Bluetooth MACaddresses ( M bt ). Our objective here is to move from anephemeral identifier to a more persistent identifier, (i.e.,WiFi MAC address and SSID tuple).A WiFi probe message is sent when WiFi is enabledbut no connection has yet been established. These mes-sages are typically broadcast with the name of recentlyconnected SSIDs. Since most private SSIDs are unique,we can use a tag, ( M wifi , SSID ) , to uniquely identifyuser devices if we can associate M bt with the correspond-ing tag. Both iOS and Android will randomize M wifi to preserve user privacy. However, the implementationrandomizes the MAC address only for different SSIDs(i.e., the MAC address will be consistent with respect tospecific SSIDs for extended periods). To associate M bt with the tag of the same device, we can monitor theentry and exit time of devices to find the possible pairsand further reconfirm the exact association when theysubsequently reappear.Based on the assumptions above, we designed thefollowing approach to automatically identify the tag, tag inf , of a given M bt that has been identified to bean infected user.1. Tag Collection.
For each M bt detected at t , weconsider all tags detected ∗ ( r wifi − r bt ) /s secondsbefore t . Here, r wifi and r bt represent the detec-tion radius of WiFi probe messages and Bluetoothadvertisement messages. s is the average speed ofusers, which varies in different scenarios. In otherwords, we consider all tags detected at t if t ≥ t − ∗ ( r wifi − r bt ) /s . All qualified tags will be storedin T and we use ( M bt , T ) to record the encounter.2. Tag Matching.
When M bt _ inf of infected user isidentified by the Contact-Isolation Attack, we per-form retrospective tag matching for ( M bt _ inf , T inf ) .The candidate tags corresponding to an infecteduser are determined as follows: 1) tag cand ∈ T inf ,2) ∀ ( M bt , T ) , if T ⊃ { tag cand } , M bt must have beenidentified as belonging to an infected user. Finally,among all candidate tags that satisfy the require-ments, tag inf is the one that appears most fre-quently.The aforementioned approach works well if all the in-fected users appear multiple times and their WiFi mod-ules are always enabled. If an infected user only appearsonce or his WiFi module is disabled, false positives couldbe introduced when another tag happens to be in T inf ,but never appears again. False negative cases may re-sult from multiple reasons. For example, (1) users mayhave explicitly turned off WiFi probing or (2) stay inrange for a very short amount of time. Finally, if aninfected user always happens to appear along with an-other unrelated normal user, we will not be able to nar-row down to a single infected user. However, such casesare a small fraction of the dataset, and even in thesecases our approach can still help us narrow down to asmaller suspicious user set.We evaluated the feasibility of the approach in asimulated environment. Table 7 shows the parametersconsidered in the simulation whose range of values werederived from published literature. The frequency andradius values are defined based on the observations ofexisting works [31] [32] [19]. Here, 10000 users (of which100 are infected) move from the outside toward our at-tack devices at a constant speed, stay for several sec-onds, and then leave at the same speed. When thedata is distributed evenly, we generated 26,874 ( M bt , T ) pairs in total and successfully identified 72 (out of 80)tags that belong to infected users. For the remaining 20infected users, we observed neither the Bluetooth norWiFi MACs because they never came in range. We also n the Privacy and Integrity Risks of Contact-Tracing Applications D e t e c t i on R a t e (a) Encounter Count D e t e c t i on R a t e (b) WiFi Probing Frequency D e t e c t i on R a t e (c) Speed Fig. 7.
Change in detection rates when the specific parameter for infected tags [(a): encounter count, (b):wifi_frequency (c): speed]vary according to values shown in the X-axis. In each case, all other parameters for both infected tags and normal tags are chosenfrom a uniform distribution, as described in Table 7.
Table 7.
Summary of simulation parameters that were used in the large-scale deanonymization experiment.
Parameter Description Value
Population Total user population in the simulation 10000Infection Rate Percent of infected users in the simulation 1%Time Duration of the experiment 16:00-18:00, 2 daysDuration Total time that each user stays in the range of sensors 30-300 secondsEncounter Count Expected encounter count of users 1-5 r wifi Detection radius of WiFi Probe messages 50 m r bt Detection radius of Bluetooth advertisement messages 10 m evaluated the effect of each parameter on the detectionrate. We fixed the parameters of infected users to spe-cific value and the parameters of other users are stillevenly distributed. The simulation results are shown inFigure 7. We find that WiFi probing frequency can sig-nificantly affect the detection rate. The reason is thatonce the frequency is too low, it is likely that the attackdevice will miss the messages, especially when users aremoving at a high speed. Another important factor isvisit encounter. The eight false negatives occur whenthe tags show up only once and other tags in the samepair cannot all be excluded. In this case, we cannot nar-row down the suspicious infected users to the exact tag,but we can generate a smaller list of possible tags. Sincethe simulation does not incorporate information beyondwhat might be observed in the real environments, we be-lieve that it demonstrates the practical viability of theattack. With the unique tag, attackers would be able tophysically locate the user [44] (e.g. by leveraging WiFilocation data published by Wigle [22]) or track the userin the future [29]. In addition, video feeds could be com-bined with Tag database information to obtain a picture of candidate victims who might then be de-anonymizedusing face detection search engines like PimEyes [21].
We leverage the POI database from SafeGraph to ap-proximate the number of users possibly affected by ourattacks. We assume that attackers are able to deploy asmany attack devices as they want at many locations.The relevant fields we can get from the database in-clude location_name, brands, street_address, latitude,longitude, city, raw_counts (number of unique visitorsfor the period), and visits_by_day . We cannot get thecoverage of cities by adding up all the visitor counts be-cause of the possible overlap between different places.Unfortunately, due to privacy considerations, the rele-vant data of the overlap (e.g., unique ID of visitors) isnot available.Two considerations apply to the overlap: ( i ) over-lap of visitors across days for the same sensor locationand ( ii ) overlap across locations. Based on a 2017 studyfrom Sense360, the average number of monthly customervisits at a single location for popular chains ranged be-tween 1 and 2.2, with McDonalds being the most pop- n the Privacy and Integrity Risks of Contact-Tracing Applications Algorithm 2
Coverage Estimation Algorithm
Input:
Dataset of place pattern S , name of the target city N ,population in the given city n , overlap ratio p and radiusthat the overlap applies to r . Output:
Approximate coverage of victims in city c L = ∅ for i ∈ S do if i.city == N then L = L S i for i ∈ L do for j ∈ L do if i = j then dist = haversine ( i.lat, i.long, j.lat, j.long )9: if dist ≤ r then i.visitor _ counts = i.visitor _ counts − p/ ∗ min ( i.raw _ counts, j.raw _ counts )11: if i.visitor _ counts ≤ then
12: remove i from L unique _ counts = 014: for i ∈ L do unique _ counts = unique _ counts + i.visitor _ counts c = unique _ counts/n Table 8.
Customer loyalty rates (monthly visit frequency) forpopular fast-food chains.
Fast-Food Chain Customer Frequency (Monthly)
McDonalds 2.19Starbucks 1.97Sonic 1.83Tim Horton’s 1.82Dunkin Donuts 1.79Whataburger 1.74 ular at 2.19 visits per month [18]. Table 8 provides thesummary of monthly customer frequency values for themost popular fast-food chains.On the other hand, by comparing the raw_counts and the sum of visits_by_day , we can obtain theoverlap across days in a given month for eachlocation. Based on the dataset from May 2020to June 2020, the average overlap for locationsin the United States across days is 0.3674 ( − raw _ visitor _ counts/ Σ( visits _ by _ day ) ). That means,that the average frequency of the SafeGraph visitor ateach location ( Σ( visits _ by _ day ) /raw _ visitor _ counts )was 1.58 during the month.To address the cross-location overlap problem, weassume different ratio of overlap with different radius ofthe places and try to estimate the coverage of cities. Forexample, {overlap:0.05, radius: 5} means that we con-sider each two places of which the distance is 5 milesand the overlap between them is 5%. We use Haver-sine formula [40] to calculate the distance between eachtwo places from the coordinates. The algorithm of cal- culating the coverage is as shown in Algorithm 2. In ourevaluation, we tested the coverage for three cities: Hous-ton, TX; Bryan, TX; and Chicago, IL. To calculate thecoverage, we got the population of the two cities fromthe United States Census Bureau[17]. For Houston, theestimate population is 2,326,090. The coverage of pos-sible victims with different overlap ratio and radii isillustrated in Figures 8(a), 8(b), and 8(c). The resultsshow that the attacks can possibly affect a relativelylarge portion of people. Even when we assume the vis-itor overlap for each two sensors within a 5 km rangeis as high as 30%, the coverage of possible victims isstill about 25%. For Chicago, this number drops to 5%,which is still significant. From the analysis of SafeGraphdata from these three cities, we can see that our attackis effective in both big cities and small towns.While it is difficult to get exact numbers for over-lap and coverage, a slight variance in these results doesnot fundamentally discount the potential of the attack.More importantly, they have implications for how thesystem is engineered. For example, a lower overlap num-ber implies that coverage of the attack is higher; andimplies that we may have fewer opportunities to nar-row down the victim set using pool testing. Since thecontact-isolation attack relies on encounters and not vis-its, and each visit might have multiple encounters, thede-anonymization attack may be successful with a sin-gle visit. On the other hand, a higher overlap numbermeans less coverage but more opportunities to winnowdown using pool-testing strategies. Specifically, a loweroverlap corresponds to more victims of contact-pollutionattack and a higher overlap corresponds to higher suc-cess rate in contact-isolation attack. This paper is not the first to uncover security flaws inCTAs. However, to our knowledge this is the first aca-demic work to systematically analyze CTAs and pointout the use of device simulation, pool-testing,and on-line databases to enable large-scale de-anonymization ofCTA users. We also raise awareness of the vulnerabilityof contact-tracing databases to data pollution attacksas well as the potential of Bluetooth range extenders inscaling such attacks. To our knowledge, we are also thefirst to use the SafeGraph database to assess the sig-nificance of contact-tracing attacks. The following sum-marizes and acknowledges related prior work that in-formed our research across various domains, includingsocial media, Bluetooth, and contact-tracing protocols. n the Privacy and Integrity Risks of Contact-Tracing Applications Overlap C o v e r age radius=1 kmradius=2 kmradius=3 kmradius=4 kmradius=5 km (a) Houston Overlap C o v e r age radius=1 kmradius=2 kmradius=3 kmradius=4 kmradius=5 km (b) Bryan Overlap C o v e r age radius=1 kmradius=2 kmradius=3 kmradius=4 kmradius=5 km (c) Chicago Fig. 8.
Fraction of potential victims tracked using SafeGraph sensors in different cities, assuming varying rates of overlap between sen-sors within a certain radius. Houston (10,171 sensors), Bryan (446 sensors), Chicago (7,675 sensors).
SafeGraph for Human Cluster Tracking.
Our pa-per explores the use of the SafeGraph POI dataset [36]as a resource for identifying the placement of contact-isolation attack devices to maximize engagement withcontact-tracing mobile apps. This use of SafeGraph isquite consistent with other academic studies that ex-amine the impact that Covid-19 has had on patternsof human movement. A number of live Covid-19 track-ing projects (dashboards and interpretive studies) haveemerged, including studies of fine-grained shelter-in-place compliance [26, 35], social-distancing complianceby region and political view [27, 28, 34], and the impactof this pandemic on categories of retail business [35].Government policy studies on the effects of uncoordi-nated Covid-19 social-distance measures have also em-ployed SafeGraph [33]. These studies use the mobiledevice geographic reporting information anonymizedwithin the SafeGraph POI dataset to measure humanfoot-traffic patterns. This paper uses this informationto identify human cluster points in a region to maxi-mize the number of potential CTAs that a stationaryattack device would reach.
Bluetooth Security.
As one of the most popular wire-less communication protocols, the security of Bluetoothhas been a hot topic for security researchers. Ben etal.[41] found eight vulnerabilities in the implementationof Bluetooth on different platforms, which are namedBlueborne. Daniele et al. [23] proposed Bluetooth im-personation Attacks (BIAS) which allow attackers toimpersonate other devices. BIAS abuses the switch-rolemessage in the Bluetooth protocol to bypass the au-thentication process. The BlueFrag exploit (CVE-2020-0022) allows a remote attacker within proximity tosilently execute arbitrary code with the privileges of theBluetooth daemon [5].
Contact Tracing.
To establish a common privacy-preserving standard for contact-tracing protocols,Google and Apple announced a two-phase exposure no-tification solution on April 10, 2020 [32]. Their solu-tion provides a set of API for developing CTAs. Thespecifications and code are all available from the of-ficial website. Almost at the same time, an indepen-dent group started by academics in EPFL released DP-3T [43], which is fully open-sourced. We built and evalu-ated our prototype attacks on the DP-3T platform, butour attacks are generic and can be extended to theseplatforms.Lars et al. show how the Google/Apple contact-tracing framework and DP-3T could be abused to phys-ically locate infected persons in a large metropolitancity [24]. However, their de-anonymization techniquediffers from ours in that it relies on continuous trackingof Bluetooth activity from infected users across the cityfrom multiple vantage points and does not leverage de-vice spoofing, WiFi information, or online databases. Incontrast, our attack only requires a single vantage point.Thus, the two efforts are complementary and could becombined for greater efficacy. Serge [45] also find thatDP-3T is vulnerable to relay and replay attacks, whichcan introduce false alerts. However, this work does notactually demonstrate the feasibility of the attack andtheir proposed mitigation requires interactions betweendevices, which is not supported for Bluetooth advertise-ment messages. Krzysztof [38] proposed a more practicalsolution by explicitly also checking for time and loca-tion. Similarly, the PACT protocol [39] uses a seed andtimestamp to generate encounter chirps. Both solutionsimprove resilience against the contact-pollution attackbut are still vulnerable to contact-isolation attack. Inaddition, these mitigation may not always work againstcontact-pollution attacks, as sharing location with otherdevices is not always available and checking encounter n the Privacy and Integrity Risks of Contact-Tracing Applications time is insufficient to completely defend against contact-pollution attacks (e.g., the attacker may still broadcastrecent encounter codes collected from other users). Fi-nally, there have been recent academic efforts such asEpione [37], which uses cryptographic techniques suchas private set intersection cardinality (PSI-CA) and pri-vate information retrieval (PIR) to protect user privacy.Our proposed contact-isolation and contact-pollutionattacks are fundamental (much like DDoS) and alsoaffect this system. Section 7 discusses some potentialcountermeasures that could be deployed to deal withsuch attacks. This section discusses the ethical considerations of thiswork, potential countermeasures for the two attacks pre-sented in the paper, and some limitations of the adver-sary models.
A full evaluation of attack efficacy and our analysisof deployment challenges using existing live deployedcontact-tracing systems raises prohibitive ethical con-cerns. Such evaluations could hinder server operations,pollute contact-tracing databases, and cause false notifi-cation messages to be sent to users. Therefore, we do notpropose the execution of experiments that interact withfielded contract-tracing services. Rather, the evaluationapproach presented in Section 5 involves experimentaldevices that are divided into an attack set and a victimset, in which neither device set has contact with non-evaluation devices. All adversarial models evaluated inthis paper were operated in isolation.Another important ethical consideration is the ap-propriate strategy for vulnerability disclosure. Giventhat the specific attacks affect a broad class of appli-cations, there is not an efficient and optimal strategyfor privately disseminating this information. Instead, weintend to share the specific attacks with popular frame-work designers for further guidance.
Identity Verification.
For the attacks presented inthis paper, an adversary will need to create multipleaccounts for uploading data and receiving notificationmessages. Based on our observations, most applicationsdo not impose strict validations that could counter anattacker from producing a large account sets. For ex-ample, Smittestopp only requires a phone number tocreate a new account, which can be obtained using on-line phone-number services. Hence, employing multiple factors to reduce or restrict acceptable verification cre-dentials can reduce the attack population that drivesthese attacks. Unfortunately, due to the possible pri-vacy issues, to implement such an approach is difficult,may reduce the desired adoption rate of the CTA, ormay be illegal in some countries.
Integrity/Consistency Check.
An assumption of theattacks is that the server will not check the integrity ofthe data or the consistency between the data uploadedby users and its origin device. Though attackers are ableto send fake data to other users or to the server, addi-tional integrity and consistency checks could be appliedto guarantee that the data-exchange process cannot besniffed or spoofed.
Notification Restrictions.
To launch the contact-isolation attack, attackers need to receive notificationfor each subset C i , which means they need to contin-uously request the notification with a small encounterlist. To mitigate this attack, we can set restrictions onthe server side before we send notifications to users. Forexample, we may require a minimum-length encounterlist to receive notifications. However, if this becomeswidely deployed, attackers may attempt to evade this re-striction by introducing fake (synthetic) encounters intotheir submissions. Therefore, incorporating a threshold-length encounter list should be coupled with integrity-consistency checks that vet and reject fake encounters. We now discuss some limitations associated with ouradversary models. First, our attacks require the deploy-ment of devices that must achieve physical proximityto victims, which limits the scalability of the attacks tothe number of devices that can be created, deployed,and maintained. The cost may be unacceptable if theattack goal is to introduce a large volume of fake datainto the database. Second, our attacks are highly de-pendent on the application implementation. While theadversary models presented here are broadly applicableto a breadth of CTA schemes, the attack implementa-tions need to be individually tailored per CTA. Finally,our attacks are most effective in scenarios where a largeportion of the user population runs a monolithic CTA.
The paper examines two adversary models that canbe applied to a wide range of Covid-19 CTAs thatare emerging across the globe and are even beinglegally mandated among numerous countries. CTAs arebroadly categorized into centralized coordination strate- n the Privacy and Integrity Risks of Contact-Tracing Applications gies, which raise inherent public privacy concerns, anddecentralized peer-oriented strategies that claim to re-duce end-user privacy concerns. However, we show thatour adversary models apply equally well to both the cen-tralized and decentralized strategies. The first adversarymodel, called contact-isolation attack, presents a pri-vacy attack against app users who become infected withCovid-19, enabling an attacker to deploy probes thatcould essentially mine infected user identities at loca-tions where humans commonly congregate. This attackcombines large-scale device spoofing with pool testing,device re-identification strategies, and online databasesto de-anonymize infected user devices. We evaluate theefficacy of this attack both using a simulation studyand the SafeGraph POI dataset. The second adversarymodel employs a data-poisoning attack that enables anadversary to undermine the reliability of the CTA, re-sulting in false positive alarms that would be highlydisruptive to any contract-tracing user base. We alsodiscuss some mitigation strategies that could reduce theefficacy of both attacks. References
Pro-ceedings of the IEEE Symposium on Security and Privacy(S&P) , 2020.[24] Lars Baumgärtner, Alexandra Dmitrienko, Bernd Freisleben,Alexander Gruler, Jonas Höchst, Joshua Kühlberg,Mira Mezini, Richard Mitev, Markus Miettinen, AnelMuhamedagic, Thien Duc Nguyen, Alvar Penning, Der-mot Frederik Pustelnik, Filipp Roos, Ahmad-Reza Sadeghi,Michael Schwarz, and Christian Uhl. Mind the gap: Security& privacy risks of contact tracing apps, 2020.[25] John Bethencourt, Jason Franklin, and Mary Vernon. Map-ping internet sensors with probe response attacks. In , 2005.[26] Kristi Bushman, Konstantinos Pelechrinis, and AlexandrosLabrinidis. Effectiveness and compliance to social distancingduring covid-19, 2020.[27] Jonathan A Cook, Noah Newberger, and Sami Smalling.The spread of social distancing, June 2020. https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3610504.[28] Christopher J Cronin and William N Evans. Private precau-tion and public restrictions: What drives social distancingand industry foot traffic in the covid-19 era? Technical re-port, National Bureau of Economic Research, July 2020.[29] Mathieu Cunche. I know your mac address: Targeted track-ing of individual using wi-fi.
Journal of Computer Virologyand Hacking Techniques , 10(4):219–227, 2014.[30] D.Z. Du and F. Hwang. Combinatorial group testing and itsapplications.
World Scientific , 2000.[31] Julien Freudiger. How talkative is your mobile device? anexperimental study of wi-fi probe requests. In
Proceedings ofthe 8th ACM Conference on Security & Privacy in Wireless n the Privacy and Integrity Risks of Contact-Tracing Applications and Mobile Networks , pages 1–6, 2015.[32] Google and Apple. Exposure notification. [online]https://developer.apple.com/exposure-notification/ , 2020.[33] David Holtz, Michael Zhao, Seth G. Benzell, Cathy Y. Cao,Mohammad Amin Rahimian, Jeremy Yang, Jennifer Allen,Avinash Collis, Alex Moehring, Tara Sowrirajan, DipayanGhosh, Yunhao Zhang, Paramveer S. Dhillon, Christos Nico-laides, Dean Eckles, and Sinan Aral. Interdependence andthe cost of uncoordinated responses to covid-19. Proceed-ings of the National Academy of Sciences
IACRCryptol. ePrint Arch. , 2020:418, 2020.[39] Ronald L Rivest, Jon Callas, Ran Canetti, Kevin Esvelt,Daniel Kahn Gillmor, Yael Tauman Kalai, Anna Lysyanskaya,Adam Norige, Ramesh Raskar, Adi Shamir, et al. The pactprotocol specification.
Private Automated Contact TracingTeam, MIT, Cambridge, MA, USA, Tech. Rep. 0.1 , 2020.[40] C Carl Robusto. The cosine-haversine formula.
The Ameri-can Mathematical Monthly , 64(1):38–40, 1957.[41] Ben Seri and Gregory Vishnepolsky. Blueborne.
Armis.[online] https://armis. com/blueborne , 2017.[42] Ruoxi Sun, Wei Wang, Minhui Xue, Gareth Tyson, SeyitCamtepe, and Damith Ranasinghe. Vetting security andprivacy of global covid-19 contact tracing applications, July2020. https://arxiv.org/pdf/2006.10933.pdf.[43] Carmela Troncoso, Mathias Payer, Jean-Pierre Hubaux,Marcel Salathé, James Larus, Edouard Bugnion, WouterLueks, Theresa Stadler, Apostolos Pyrgelis, Daniele An-tonioli, et al. Decentralized privacy-preserving proximitytracing. arXiv preprint arXiv:2005.12273 , 2020.[44] Mathy Vanhoef, Célestin Matte, Mathieu Cunche,Leonardo S Cardoso, and Frank Piessens. Why mac addressrandomization is not enough: An analysis of wi-fi networkdiscovery mechanisms. In
Proceedings of the 11th ACM onAsia Conference on Computer and Communications Secu-rity , pages 413–424, 2016.[45] Serge Vaudenay. Analysis of dp3t between scylla and charyb-dis.(2020), 2020.[46] Haohuang Wen, Qingchuan Zhao, Zhiqiang Lin, Dong Xuan,and Ness Shroff. A study of the privacy of covid-19 contacttracing apps. In