How secure are contact tracing apps?
I have been fortunate enough to be part of a Portuguese working group that is actively analyzing and discussing the security and privacy implications of a future contact tracing app in Portugal. In particular, with regard to securing these apps from potential threats. We have seen some countries taking different approaches (centralized, decentralized) and several different technologies being leveraged to build these apps (both native technologies and web technologies like JavaScript).
About the author
Pedro Fortuna is the Co-Founder and CTO of Jscrambler.
Most discussion on contact tracing apps is centered around the issue of privacy, so one of my roles has been to shed light on the underlying security issues that may make it easier for attackers to tamper with contact tracing apps and potentially breach privacy on a massive scale. With several countries all over the world developing and launching contact tracing apps, it is timely to analyse the differences between these apps and to highlight relevant security issues. Let’s take a closer look.
When it comes to COVID-19 apps, there are 2 types of apps that handle sensitive data – symptom tracking and contact tracing. Contact Tracing is the more controversial of the two because of the fear that people have of being monitored. Non-digital contact tracing has existed for a long time. Once someone has been infected, health officials interview the person to check with whom the person had contact recently.
They ask for contact info of people that had contact and interview them as well. This enables tracking contagion and isolating required persons. But the main problem is that this is ad-hoc – people are often interviewed too late in the game and can’t remember everyone who they have been in contact with. Plus, the interviewee may not have their contact info. Another problem is that people are only being isolated after they display symptoms.
Digital contact tracing aims to expand upon this and solve some of these limitations. Most contact tracing apps are based on Bluetooth Low Energy (BLE). Each app instance transmits short-range beacons; so, as people move, their devices pick up other people’s beacon. Each beacon has an ephemeral anonymous identifier that is unique. The ephemeral IDs seen are stored locally in the device. When someone is diagnosed, that person receives an official code from health officials, and by entering that code in the app, that person is officially and voluntarily registered with the infection status.
Then, a list of its own ephemeral IDs used in the last 14 days will be sent to a central server; all other devices periodically download the list of infected people’s IDs and then locally determine if they have been in contact with them recently. For positive contacts, the application then calculates the risk of infection, taking into consideration the estimated proximity and duration of the contact. If the risk is over a certain threshold, the app triggers a notification recommending that the user self-isolates and contacts the national health authority.
Exposed code and reverse-engineering
Due to the fact that they handle very sensitive data, contact tracing apps should offer robust security and be subject to independent security audits. To this end, these apps should follow the general recommendations of the OWASP Mobile Security Testing Guide, specifically the use of Code Signing to reduce the risk of publishing an adulterated version of the application, and also Certificate Pinning, to reduce the risk of Man-in-the-Middle (MITM) attacks. Additional security threats that should be taken into account can be found here.
Of particular note here is the risk posed by exposed code. As outlined by OWASP, this is where an attacker can either directly modify the code, change the contents of memory dynamically, change or replace the system APIs that the application uses or modify the application’s data and resources. Subsequently, this can provide the attacker with a direct method of subverting the intended use of the software for personal or monetary gain. The impact from code modification can be wide ranging in nature, depending upon the nature of the modification itself. But it is especially relevant in decentralized Contact Tracing apps where the data and sensitive algorithms all stay inside the local environment.
OWASP also highlights the risk of attackers reverse-engineering the source code as a gateway for more advanced attacks. In this way, an attacker may exploit reverse engineering to achieve any of the following aims – to reveal information about backend servers, to reveal cryptographic constants and ciphers, to steal intellectual property, to perform attacks against back end systems or to gain intelligence needed to perform subsequent code modification.
Framing this into contact tracing apps, both these security risks (exposed code & reverse engineering) must be addressed in order to block this security gap. This issue is especially important in JavaScript-based apps – where, by default, the source code is not compiled and is therefore completely exposed, greatly facilitating tampering and reverse-engineering.
Currently, there are dozens of different contact tracing apps either under development or released. We can see that more than a few of these are being developed using JavaScript-based frameworks such as React Native and Ionic – namely, the official Israeli app Hamagen, Germany-based ito, and Canada-based COVID Shield (which are all based on the React Native framework) and Switzerland’s WeTrace which is built with the Ionic framework.
Accordingly, it is critical that these apps protect their JavaScript source code from the attacks described previously, with a special focus on protection against data exfiltration attacks that can be achieved by manipulating code or by memory inspection. To this end, OWASP advises that the mobile app must be able to detect at runtime that code has been added or changed, and that the app must be able to react appropriately at runtime to a code integrity violation and must protect itself from memory tampering or scraping. They go on to state that in order to prevent effective reverse engineering, a code protection tool must be used.
With the teams behind these projects facing the giant challenge of delivering these highly complex apps in record time, it’s essential that they consider these security threats still during the development stage. This need for source code protection in mobile apps mustn’t be ignored with stakes as high as these. To ensure that their apps are protected against attacks to the integrity of the source code, these teams must look for resilient JavaScript code protection.
