Four things to consider before installing contact tracing apps

1. Location tracking and data privacy

In general, people do not like to be tracked. The right to privacy is considered a fundamental human right in many parts of the world. Legislation like GDPR and the CCPA is designed to enforce that belief, defining how private data should be captured, processed, shared, and stored. With so much legislation surrounding data privacy now in place, these existing guidelines and protections should be adequate to navigate the current global health crisis.

Tracking the number of coronavirus cases, regions impacted, and other macro trends, is essential to understanding the spread of the virus. Macro trends can inform how the virus is propagating and also how effective certain measures are at containing the spread.

Some form of personal location tracking has been widely accepted as an effective method of understanding the spread of the virus. However, it should only be implemented as opt-in, allowing individuals to choose when to share their personal information and whereabouts. Providing people with a choice, along with details on how their data is being managed and shared (details that are required by GDPR) should be standard practice.

Transparency in data collection methods (assumptions, gaps in data, etc.) is necessary so world experts can accurately utilize the data that is made available. Anonymization is key when sharing data, but being able to correlate cases also means that local entities need to selectively share data.

2. Bluetooth technology for contact tracing

In some countries, applications for tracing the virus are being developed with official government support. Privacy concerns have been raised on tracking the geographical location of app users, with people claiming the initiative is an excuse to advance government surveillance. For that reason, the favored approach utilizes Bluetooth technology, which can track users’ proximity to one another but not associate location data with an individual.

Several frameworks for building contact tracing apps have been developed. Apple and Google have joined forces to support a Bluetooth-based method to track the spread of infections without compromising location privacy. This involves the addition of new features to their mobile operating systems that enable certain apps that are approved by government health agencies to use Bluetooth in order to record proximity between phones, and therefore, the people carrying them.

In general, these government-approved apps work by allowing a user to report a positive Covid-19 diagnosis in the app anonymously. Then any users who have been in close proximity within a certain period of time will receive a notification. The system is reportedly Bluetooth-only, collects no GPS-based location data from users, and is fully opt-in.

The technology works by constantly broadcasting unique, rotating Bluetooth codes that are derived from a cryptographic key that changes once each day. It constantly monitors mobile devices nearby, recording the codes of any other phones they encounter.

When a user reports a positive Covid-19 diagnosis, their app uploads the cryptographic keys that were used to generate their codes over the last two weeks to a server. Every app then downloads those daily keys and looks for a match with one of its stored codes, the app will notify that person that they may have been exposed.

Read more about how the technology works here on WIRED.

3. Potential device performance issues with contact tracing

The problem with these apps is they need to be running constantly in the background and constantly monitoring their surroundings in order to function properly which means a potential side effect might be faster device battery drain.

Modern mobile operating systems prevent battery drain using various techniques to “throttle” apps which are not in use, such as reducing access to system resources. If, how much, and in what way depends on the OS version and the settings on the device.

For example, we understand that newer versions of operating systems are more aggressive in reducing Bluetooth background activity to conserve power. Android devices sometimes use additional system applications referred to as ‘battery optimizers’, which can further restrict Bluetooth background activity.

Battery level also plays a role because many devices could (and usually would) automatically switch to low battery mode, which deactivates background processes. This could potentially reduce the efficacy of the contact tracing apps which need to be constantly running in the background.

If you have decided to opt into your government’s official contact tracing app, follow these steps to increase app efficacy:

• Keep the battery charged, avoid using various battery optimizers (or if so, create an exception for your application). Carry a portable charger.
• If you’re an iPhone user, avoid using low battery mode on their device as this can prevent the app from running in the background.
• Do not use two or more similar tracking apps at the same time because there could be a conflict in usage of resources (Bluetooth access).

Developers of government-approved applications are working with both Apple and Google in order to get deeper access to device resources and thus be able to keep fully operating even in various stand-by and low-energy modes while the application is running in the background.

4. Security risks of contact tracing apps

It is extremely important not to install any apps found on unofficial sites or third-party app stores. Apps should only be downloaded from the official app stores. Cybercriminals are very active during this Covid crisis and they try to exploit the high demand for tracking applications. A very common tactic is to repack an existing application, modify it with malicious code and publish it on an unofficial store. It is always better to check the website of your local government to find information about solutions for approved contact tracing applications.

Many of our customers in different parts of the world are wondering whether they should allow employees to install and use contact tracing apps on work devices. Using App Insights, we have completed risk assessments for a small representation of the contact tracing apps available in different countries where our customers are based. Summaries of these risk assessments are available in the below tables. Jamf customers can request the full risk assessment for each of these apps by contacting their account managers. This information will be updated as we take on more requests from customers and as more apps are released and updated.

Australia | Covid Safe

Australia | Covid Safe | Developer: Australian Department of Health | Risk Indicator: LOW

Google Play [1.0.17]

• # of permissions: 8
• # of extracted URLs: 13
• Source code availability: Yes
• ATS assessment: ATS enabled

App Store [1.3]

• # of permissions: 4
• # of extracted URLs: N/A
• Source code availability: Yes
• ATS assessment: ATS enabled

Well-supported application with working bug report channel. Registration limited to Australian phone numbers only on the server side (plus few checks in the application itself).

United Kingdom | NHS Covid 19

United Kingdom | NHS Covid 19 | Developer: NHSX | Risk Indicator: LOW

Google Play [1.0.17]

• # of permissions: 2
• # of extracted URLs: 24
• Source code availability: Yes
• ATS assessment: N/A

App Store [1.3]

• # of permissions 2
• # of extracted URLs: N/A
• Source code availability: Yes
• ATS assessment: ATS enabled

The NHS app is currently still in beta and being tested on the Isle of Wight. Reportedly uses data stored on a central server rather than the decentralized approach created by Apple and Google.

The United States | Safe Paths

The United States | Safe Paths | Developer: MIT | Risk Indicator: MED

Google Play [0.5.19]

• # of permissions: 34
• # of extracted URLs: 41
• Source code availability: Yes
• ATS assessment: N/A

App Store [0.5.19]

• # of permissions: 4
• # of extracted URLs: N/A
• Source code availability: Yes
• ATS assessment: ATS enabled

Extremely low number of users have downloaded it. The purpose of this application is wider than only contact tracking (health check, for example). It communicates with log service using insecure http channel (reason for disabled ATS).

Italy | SM_Covid19

Italy | SM_Covid19 | Developer: Softmining | Risk Indicator: MED

Google Play [3.6]

• # of permissions: 34
• # of extracted URLs: 41
• Source code availability: Yes
• ATS assessment: N/A

Only test version available on request for iOS. The application is requesting user consent while launching in order for SoftMining to acquire/manipulate user data.

Spain | Corona Madrid

Spain | Corona Madrid | Developer: Comunidad de Madrid | Risk Indicator: LOW

Google Play [1.0.10]

• # of permissions: 7
• # of extracted URLs: 5
• Source code availability: No
• ATS assessment: N/A

App Store [1.0.10]

• # of permissions: 3
• # of extracted URLs: N/A
• Source code availability: No
• ATS assessment: ATS disabled

This app communicates with the fewest number of external websites. It communicates only with Coronavirus Comunidad Madrid among other legitimate cloud hosts over HTTPS. It also had a low number of permissions requested.

Spain | Stop Covid19 Cat

Spain | Stop Covid19 Cat | Developer: Generalitat de Catalunya | Risk Indicator: MED

Google Play [1.0.2]

• # of permissions: 12
• # of extracted URLs: 18
• Source code availability: No
• ATS assessment: N/A

App Store [1.0.2]

• # of permissions: 4
• # of extracted URLs: N/A
• Source code availability: No
• ATS assessment: ATS disabled

The app sends data to a backend server using HTTPS. Shares location data with Mubiquo, a mobile marketing company.

Germany | Ito

Germany | Ito | Developer: Ito | Risk Indicator: MED

Github

• # of permissions: 9
• # of extracted URLs: 72
• Source code availability: Yes
• ATS assessment: N/A

The app is not available on official stores and therefore must be sideloaded. This means Android users need to enable third-party app installs which might lead to the device compromise if a malicious app download is triggered while that setting is enabled. At the time of analysis, this app is only available in Alpha version, for demonstration purposes only.

How we assess the risk level of applications

Application risk assessments consist of two main types of app analysis:

1. Static analysis is done by reverse-engineering the app code, by disassembling and decompiling the application package. During this stage we extract various metadata like version, permissions, URLs, used libraries, etc. We also check records in the corresponding application store, if available.
2. Dynamic analysis observes and analyses app behavior and network traffic in real-time. During this stage, we can identify if the application is using safe methods to transfer sensitive data, if it contacts only remote servers which it claims to do, etc.

When it comes to application risk assessments, there are a large number of risk indicators we consider. In the above summaries we have included the following:

App permissions – App permissions govern what an app is allowed to do and access. This ranges from access to data stored on your phone, like contacts and media files, through to pieces of hardware like your device’s camera or microphone. The available app permissions on iOS and Android are quite different. We always recommend auditing the permissions of each app to make sure they aren’t asking for access to resources they don’t need to minimize the risk of having your sensitive information exposed to unwanted parties. Do the permissions serve the functionality of the application? Are there any potential risks related to sensitive permissions (i.e., access to SMS)?

Extracted URLs – The number of URLs embedded in a mobile app is indicative of the number of web services that the app communicates with. Low numbers and high numbers are not necessarily indicative of risk but looking at this number and checking that it is in line with similar apps is a good place to start before checking each individual URL so suspicious connections. We factor in the number of websites an app communicates with relative to similar apps to check for anomalies which might raise questions.

Source code availability – When the source code is publicly available it means any researcher could look line-by-line at what the developer has programmed the app to do which can potentially identify flaws and malicious code in applications. But as proprietary or intellectual property, source code is often not accessible for testing. If source code is available, we check key components of the application – how it communicates with remote servers, if it properly uses certificates, how permissions are used, how it communicates with wireless peripherals (Bluetooth, Wi-Fi, NFC), if the code style follows best practices, etc.

ATS assessment – On Apple platforms, a networking security feature called App Transport Security (ATS) is available and enabled by default. ATS is basically a set of rules that ensure iOS apps and app extensions connect to web services using secure connection protocols such as HTTPS. iOS apps with ATS enabled are using encryption, while those with ATS disabled may mean they are still using encryption but only for selected network connections.

Other risk indicators include the following:

• Components: what are the building blocks of the application? The language used, programming techniques, libraries, and their versions, frameworks, etc. The goal is to check if the application is using safe components without known vulnerabilities and/or potential problems.
• Communication: what are remote parties the application communicates with? It could be a server on the internet, it could be a remote device contacted through Bluetooth or a beacon accessible through NFC. In all cases we monitor the type of communication, how often the application communicates, and what data it sends. We also evaluate contacted URLs against the list of remote services and application components to verify if it does not try to send something sensitive without the user’s consent.
• App store records: Who is the developer? How many installations does it have? How often is it updated? Is there any working bug report process?
• Third-party party intelligence: we check what other reports or assessments have been made available by other researchers.