When an individual is discovered to be contaminated with the Covid-19, the challenge is finding the individuals they have come into contact with. These individuals could be carriers or infected individuals. This has prompted much Covid-19 application (alias contact tracing apps) being created worldwide and upheld by different governments and public health organizations.

Public places can now only be accessed after these special mobile applications have been installed and the QR code has been scanned. Apple and Google were also involved in the development, and GDPR guidelines were taken into account in EU countries as well. Slowly, a year goes by, and we need to take a closer look at whether these applications are still a cause for data security concerns.

Guardsquare already produced a report on the subject in June, an updated version posted on the blog in December.  

As App-Ray is a member of the Guardsquare family, we also consider it necessary to report this well. Our colleagues examined a total of 95 contact tracing applications, which was a considerable effort. Several new apps have been released since June, and some have been withdrawn. For a complete picture, applications from all over the world have been tested, including, of course, 13 states in the United States.

Google & Apple API

After the need for a contact tracing application arose, several developments were launched around the world. Some came from the private sphere to help with the situation, while others were prepared outright on local governments’ instructions. Google and Apple rushed to assist in the spring as it wasn’t entirely a real policy and there were growing concerns about the data security of some applications. 

The main problem was that GPS data, timeline, and phones need to keep the Bluetooth connection open at all times. The two tech giants have developed an official API for this situation. The main goal was to keep the collection of private data to a minimum. It turned out that 60% of developers used only the API in their code. Guardsquare research has since focused on only the remaining 40% of applications to determine how secure the code is without the Apple / Google API.

Of course, there were very securely built applications in the category that was further narrowed down, but some raised serious concerns. One of the most worrying types is collecting GPS data while it is not handled with high security. Several applications required the user to enter their phone number, passport number, and other sensitive information. Some applications then stored all of this in an SQLite database or managed it with an easily hackable HTTP cache. Dealing with weak unprotected private data is a severe problem. In 2021, a lack of encryption should not occur.

If an application is unsafe, users may refuse to use it, leading to a severe national health problem. The only way to safely fight the pandemic is to install and use these applications by as many residents as possible.

Centralize or decentralize?

Some applications used a centralized approach, while others used a decentralized approach. In a centralized system, data from mobile devices is uploaded to a central server and further processed. Of course, this approach gives governments more power to be able to monitor who met whom, where and when. This approach is used by, among others, the UK’s NHS COVID-19 system, TraceTogether in Singapore and COVIDSafe in Australia.

The decentralized approach has proven to be much more secure from a data protection point of view: log data does not leave the mobile device. The system only combines the data of users diagnosed with COVID-19 with other logs stored on different devices.

What should an ideally secure contact tracing app look?

If we don’t want to use the Google / Apple API at all, you need to pay attention to the following 6 points:

1. String encryption: This is the only way to keep the data stored in the source code secure.

2. Name obfuscation: It hides identifiers in the application code to prevent hackers from decrypting and parsing the source code.

3. Data-at-rest encryption: It encrypts the data, meaning there is no chance for third-party access.

4. RASP (root/jailbreak and emulator detection): The application makes it impossible to execute on rooted (Android), jailbroken (iOS) or virtual (emulated) operating systems.

5. SSL pinning: the process of associating a host with its certificate or public key.

6. App attestation: App attestation: Checks the mobile app’s integrity by ensuring that connections to the server are coming from legitimate app instances.