Countries and insititutions are racing in building Big Data solutions and privacy compliant smartphone apps for tracking Coronavirus infections. The goal of all efforts is to determine and break infection chains as quickly as possible. One potential solution is Bluetooth driven Coronavirus apps which do not violate privacy. Below, we reveal a complete privacy compliant concept for Coronavirus Bluetooth apps with a possible Blockchain backend. Thereby, we share experiences from building other Bluetooth apps. We discuss potential security threats openly, talk and explain where a Blockchain makes sense.

Now, computer science fellows can advance, or conceptualise further, use it as template for their own open source Coronavirus Bluetooth apps or compare the privacy possibilities with upcoming apps.

Why open source and privacy compliant Coronavirus Bluetooth apps?

Many press announcements have been about countries which want to do a Bluetooth Low Energy (LE) tracking app for the Coronavirus. Researchers and institutions are starting initiatives for Coronavirus Bluetooth tracking app templates to certify then apps using their components.

Israel and Singapore have an app, Germany, Malaysia and the UK are on the way to an app way as well, and in South Korea and in plenty of more nations are planning or already using an app or already introduced apps in other Coronavrius containment areas like Poland.

All Bluetooth and Geotracking apps raises the question on the anonymity they really are working on and how much control a government still has on the information sourced out of it.

Requirement privacy compliance

Complete privacy is an important aspect of a tracking app; as long as privacy is not inbuilt by default, large user groups might reject an app.

Even when an app would be required by law, there are many ways to manipulate a smartphone, and that makes it important enough that users accept the usage of this app.

In addition, complete privacy makes a Coronavirus tracking app useable in different countries as different laws in different countries have high demands on privacy.

Open source as innovator for openess

In the big picture, it is the community of the world who is fighting together to get the Coronavirus contained. Citizens require transparency to use a Coronavrous app and we believe that only open source and an app based on open standards can offer the necessary transparency to beat this virus, and in future other epidemics/pandemics, together.

Open source allows the world community to leverage synergie effects, innovate faster and speed up development and work in open source together.

Ultimately, the time in making faster and better development is then ultimately cruicial in fighting the Coronavirus and will allow that countries with new rise in cases could benefit from an open app.

An an economic foundation and an open source of the time is also important, because in this way the development is not done behind closed doors and the faster the Coronavirus is beaten the faster the economy runs normally.

A privacy-aware Coronavirus app needs a transparent backend

This opens the question: if a privacy compliant Coronavirus tracking app is generally possible where a governments have no access at all?

In addition, a privacy compliant Coronavirus tracking app should be able to work with a distributed backend to enable quick deployments. This will ease setups when the Coronavirus tracking app should be used at a new part of the world. Furthermore, the backend should be scalable and distributed that new nodes can be added easily.

Open standards for innovation and compatibility

Nevertheless, many countries building different Coronavirus tracking apps leads likely to competing approaches. When different Coronavirus tracking apps fragment the the user groups it will not help anyone. Therefore, a Coronavirus tracking app approach should build on open standards and therefore be even to enable adoption in different Coronavirus tracking apps.

In the following, we explore an approach for a Coronavirus tracking app which is privacy compliant and based on open standards which can be used cross country. This allows complete privacy by design and opens the possibility of different apps even working together as long as they follow the same protocol.

How a privacy compliant Coronavirus tracking app works

In the following, we describe the different steps in the concept to create a mobile privacy app for Coronavirus tracking with Bluetooth and a blockchain backend.

Potential privacy threats

We enlist the remaining privacy issues in our Coronavirus Bluetooth app concept. In case you have additional remainders, please let us know so we can complete the list.

Human memory and meeting time

One logical inherited problem is that when a person finds out that he/she might be infected, this person can remember the carrier by looking a the meeting time. This is an inherent problem and cannot be solved in a cryptographically secure way, because the sender of the information can never ensure that the recipient does not store the time.

Sender ID Emission

Another privacy threat is the emmision of their own ID. When some entity (including machines) has seen a sender one time a person is associated with an ID. For instance, a supermarket could use this to track a person’s way through a building by listening to the emitted ID.

In addition, by default a Bluetooth sender always emits its unique hardware ID (MAC- address) when sending packages which then also needs to be changed randomly in what seems to be natively working in Android. Further and detailed package inspections need to verify that the change of the physcial address is cryptographically secure.

This emitted ID problem that is still remaining when the Bluetooth’s physical address is rotating cryptographically secure, can be overcome by discarding the functionality of having the possibility to sign packages with a PKI. This can then lead to ned problems and spamming attack vectors.

A better alternative is that, a sender can generate a new public-private key pair each day and store the old private and public key pair and emit a new URL with a new public key link each day. Instead of the URL the devices could also exchange their keys directly via Bluetooth. Once an infection occurs a sender then takes the approriate older keys for the respective days and syncs the data with them. Ultimately, the longest time a sender can be tracked is then a day.

Metadata tracking

When a client searches for packages, the client checks for specifc daytimes and hash IDs. One could now tap into the internet traffic and see which packages an IP address tries to get, as well as downloads.

In addition, when a client uploads his/her public key and connects it with a short URL, the metadata can be “sniffed” and associated with an IP address. Furthermore, when a person meets another person and then retrieves the public key from the internet, then this traffic can also be sniffed, and attackers now the two IP addresses who met.

In general, sniffing is a problem and a challenge that many applications have. It is ultimately not a specific issue of this app. For that reason we propose to use a Blockchain for the backend in the next chapter to allow the maximum distribution and transparence.

Additional privacy with Blockchain

The problems with metadata tracking cannot be solved easily. However, a Blockchain backend can improve parts of the metadata tracking.

Not only out of this, the preferred solution of our concept is a Blockchain based backend. In special, the signature and key capabilities and transparency of a Blockchain based backend for Coronavirus tracking would help a lot.

For instance, a public key exchange requires a public key infrastucture and a Blockchain would be a natural match for our concept here.

There are already many ways described for the implementation a public key infrastructure based on a Blockchain. With a Blockchain based Public Key infrastructure (PKI) it will be possible to allow users to get their certificates from the distributed Blockchain storage which enables higher transparency.

There are even open source projects and publications which already provide code and decriptions on how to run a public key infrastructure on a Blockchain. Reuse of the concepts and code can even speed up the implementation of the Coronavirus tracking app Blockchain backend.

In addition to the key verification the Blockchain can be used to distribute the infection hashes directly in the Blockchain. Out of the nature of a Blockchain that the Blockchain is copied by different nodes it will make it more difficult for attackers to sniff metadata about clients downloading specific hashes if they are infected.

Instead clients can save their privacy and download the complete blockchain and then analyze offline if there is an infection in the blockchain where they are associated with.

Another key advantage of a Blockchain is that there is no central control, and it would support the openess of the project. No single entity could turn the system off or control it as long as there is a large enough community. Therefore, a Blockchain based backend would be a native distributed application.

Bluetooth Coronavirus Tracking App implementation components

The fastest and easiest way to implement this application is to leverage existing libraries and standards.

Eddystone URL and Bluetooth Beacon ID mapping

One such standard that could be used are Bluetooth beacons (also named IBeacons). This can be used with alternative payloads to emit directly urls (Physical Web/Eddystone URL) . Free open source libraries like Altbeacon can be utilized to implement the necessary functionality.

Eddystone URLs are limited to 17 digits; this means, a url shortening needs to be used. An emit payload can look like the following: url.ly/pKeyLnk?A5

Therefore the pKeyLnk (public key link) can be a shortend link to a public key. When we assume that we have seven digits for and ID of a public key and we use 26 latin letters and 10 numeric ones we have the possible amount of 7^36, which is enough for the world population. The A5 value is the random salt/secret which changes regularly, what results in 36^2=1296 possible values. In case someone does not see that as random enough, there is also the possibility of using multiple url shortners and use longer secrets.

The large advantage to use open standards like the Eddystone URL format is that there are ready to use libaries which can help the distribution, acceptance and documentation and, different apps can leverage the same standard and still interact.

Bluetooth Low Energy scanning Example

Let us do an example for Android in Java how such URLs can be recieved by using a library:

public void didRangeBeaconsInRegion(Collection<Beacon> beacons,
			Region region) {
    for (Beacon beacon : beacons) {
	float distance = (float) beacon.getDistance();
        retb.mTxPower = beacon.getTxPower();
        if (beacon.getServiceUuid() == 0xfeaa &&  
                                    beacon.getBeaconTypeCode() == 0x10) {
             // This is a Eddystone-URL frame
               EddystoneURL= UrlBeaconUrlCompressor.
                                uncompress(beacon.getId1().toByteArray());

We see that the general logic to recieve Urls is staightforward by using a libary. Similary it is easy to emit own shortended URLs where users upload their public key to.

Distributed public key storage with Blockchain linkages

The public key association to public key can be realized with an Eddystone URL or unique Bluetooth Beacon ID mapping to a public key resource.

A link to a public key can be realized simply with regular URL shortening or a Blockchain smart contract for URL shortening. Thereby, a smart contract maps a Bluetooth Beacon ID or an shortened URL directly to a public key resource.

There are even open source projects with ready to use code that can deployed on a Blockchain to realize the shortening functionality.

One way to implement a public key yourself to leverage existing systems like PGP or others and just link them via a shortened URL. Ultimately, public keys can be even stored in a Blockchain like Ethereum or Tron and linked directly as resources via URL shortening or unique Bluetooth Beacon IDs.

Sharing Coronavirus infections data via peer to peer or Blockchain

The discovery of shared infected cases can be realized with a peer to peer file sharing protocol which even overcomes the need for a central server.

One could even use a Blockchain file sharing solution such as Tron BTT or IPFS.

In contrast to Blockchain file sharing it is also an option to directly store data in a Blockchain. Storing the infection cases directly in a Blockchain opens new opportunities as well as downsides (aside potential costs when using Ethereum).

The immense advantage is that a Blockchain wallet can be directly used to proof the authenticity by Blockchain design and a wallet ID can replace the public key easily. Once a transaction is uploaded into the Blockchain form this wallet the authenticity is proven.

We described this issue already in the potential privacy threats and proposed there to change the public key regularly. Therefore, the wallet ID needs to be changed in the same manner or a blockchain with advanced privacy meachnisms should be considered.

There are some Blockchains which offer anonymous wallet IDs and zero-knowledge mechanisms which likely even simplify and solve the anonymity issue.

Mechanisms like stealth addresses can ultimately be used and linked in an emit Eddystone URL and rotated regularly to overcome the demand of a regularly public key change.

For example, a user can emit stealth addresses to pairing partners and lateron when one of the recipients is infected a transaction with metadata is send to this stealth address.

Therefore, an implementation with a Blockchain backend will need to find the right privacy based Blockchain which offers anonymity and advanced smart contract features to realize URL shortening at the same time.

Since the author does not know all Blockchains and does not want to open a huge comparision here, I would be glad for feedback on which special public Blockchains you consider best.

Energy efficent tracking and downsampling

The trickiest part in developing a Coronavirus infection tracking Bluetooth app is the general resilience in the smartphone background in an energy efficent way.

Furthermore, it is often easy to recieve signals but to program the aggregation and downsampling to get the most valid peers to keep statistics like generating histograms in a local phone database is more complex when the app wakes up only in the background and might be terminated by the OS sometimes.

In order to save energy, the scan intervals need to be optimized and obstacles have to be overcome where the phone shuts down and the background broadcasting and scanning when saving resources. Then, there also need to be workarounds for all eventualities (eg. Bluetooth turned on and off, unplanned shutdown, caching last results on disk).

However, generally speaking two main issues need to be solved:

a.) Regular downsampling, aggregation and storage of the newly recieved Bluetooth signals from another Coronarvirus tracking app to have a likelyhood of infecting when matching records.

b.) Limiting the Bluetooth scans and emmissions to a reasonible rate in the background to avoid wasting too much energy. There the right timing is needed that signals are send and recieved in the same time. A key thing to help save most energy here is, to leverage phone gyroscope motion, geoposition change, Wifi connection activity and display-on-off intelligently to time scan cycles in the most energy efficent way when they make sense.

Plenty of this can be sometimes a bit tricky. We have solved these challenges in prior projects, so we know it is possible and it sounds first harder than it is.

Nevertheless, when you think sharing our code or experiences can help then just contact us.

Special challenges of an iPhone Coronavirus tracking App

Compared to an Android Coronavirus tracking app, an iPhone Coronavirus tracking app has some special challenges.

Under iOS, apps in the background scanning for Bluetooth has certain limitations. In special waking up an app and doing work in the background can be problematic as the scanning frequency can be up to a time where a persone one had close contact and got infected to already vanished agian (15 minutes).

Additionally, there are challenges in order to advertise information as Eddystone URL in IOs. That however is not a “be all, end all” criteria, because an iPhone call still act as a normal Bluetooth beacon and it can also recieve Eddystone URls – just the sending is limited.

In the same way like for URLS our proposed infrastucture concept can work with Bluetooth Beacon ID. We propose that a beacon region is registered and then Bluetooth Beacon ID can be mapped to public keys in a database or Blockchain. The key advantage to still use the URL approach where possible is that third party clients can easier read the URLs and this openess can motivate more people to participate and contribute to the Coronavirus tracking app.

The Android libraries like Altbeacon make it possible to track Eddystone URLs and normal Beacons at the same time and the same can be done for iOS. Here, an example of how different payload layouts can be recognized which iPhones can emit normal Beacon IDs.

// adding Apple IBeacon
beaconManager.getBeaconParsers().add(
    new BeaconParser() 
       .setBeaconLayout(
            "m:0-3=4c000215,i:4-19,i:20-21,i:22-23,p:24-24"));
// Detect the Eddystone URL frame:
beaconManager.getBeaconParsers().add(
    new BeaconParser() 
       .setBeaconLayout(
            "s:0-1=feaa,m:2-2=10,p:3-3:-41,i:4-20v"));
// Detect the main Eddystone-UID frame:
beaconManager.getBeaconParsers().add(
    new BeaconParser() 
       .setBeaconLayout(
            "s:0-1=feaa,m:2-2=00,p:3-3:-41,i:4-13,i:14-19"));

The last challenge is that IOs Bluetooth Becacon apps can only advertise Bluetooth information the the foreground. Running advertisements easily in the background is not possible.

Therefore, the main limitation that comes with iPhone compatibility is the background scanning cycle that can be long where contacts are not recognied and the need for that is that, the app needs to be in the foreground while someone is outside, otherwise no Bluetooth signal is emitted. The rest of the challenges can be solved technologically.

In order for any Bluetooth tracking app to make sense for iPhone users they run the app in the foreground while they are outside. This problem needs to be solved by clever business principles in terms of marketing and telling users how to use the app.

Conclusion

We have described a maximum privacy based Bluetooth Coronavirus tracking app with a Blockchain based backend.

First we discussed how and why an open source app and a Blockchain backend can help as distributed software worldwide against the spread of the Coronavirus.

According to the requirements on an app and infrastucture, we presented a privacy-aware concept for a Cornavirus tracking app and have step by step explanations how its privacy concepts and way of operations work.

Subsequently and to our best of knowlege, we revealed potential privacy threats openly and got into potential precautions to make the app and backend potentially more secure.

Succeeding that, we provided information about concrete benefits of using Blockchain technology for a backend of such a Cornavirus tracking app and how it can help for different situations.

From the abstract concept, we proposed possible components of a solution:

• Bluetooth Beacon IDs and Physical web – Eddystone URLs
• Code examples on how Bluetooth scanning can be done in an app
• Concept and insights about distributed Blockchain storage and sharing of infections via blockchain and how privacy focused Blockchains can help even more
• Which information is needed to be store in each Coronavirus tracking app installation
• Pratices to make the energy efficency of an app more optimized

Ultimately, we gave insights about potential challenges and solution approaches when an iPhone app should leverage in a Bluetooth discovery scenario on the background.

All in all, we gave transparent insights about the first steps in concept aand implementation how to build privacy-aware Coronavirus Bluetooth tracking app with a Blockchain backend.

We hope that our work inspires others to advance our concept even further or they can use it as template for own open source Coronavirus Bluetooth apps. Furthermore, we hope that our open concept revealed details which will help to all upcoming Bluetooth Coronavirus tracking apps whic use open standards and become compatible to another.

Clearly, we see this Coronavirus crisis tracking app as that of a teamwork. Therefore, we warmly welcome feedback and missed points that should be added to the article. Let us know if you have additions or contributions that you consider noteworthy to be linked.

Related work

8.4.2020 – Netzpolitik.org
After original publishing, we find a short article “Why is contact tracing useful?”, describing a similar high-level concept to ours and published one day before. We are glad to see that other people are thinking in the same direction and this strengthens the demand for a privacy compliant Coronavirus app.

9.4.2020 – DP^3T
A similar project about Decentralized Privacy-Preserving Proximity Tracing can be found on github. In difference to to our link of ID to possibly completely changing public key, the project is using ephemeral IDs which are periodcially generated from hashing with seed on the phone. This seed is then later shared for verification when an infection happened. In order to match records a probabilistic set data structure that is used to test whether an element is a member of a set (Cuckoo filter) gets used.

We believe that the late shared seed key and the Cuckoo filter can be an valuabe addition of our proposed concept.

They concept also notes the potential privacy issue of metadata that we also adressed in our article. We believe a fully distributed system like a Blockchain like we propose it as backend holds superiority as one can upload and download data through replications of the backend that even can be accessible through the Darknet what would lead to more data transport privacy.

Furthermore, the DP^3T approach mentions also Bluetooth Beacon technology but it does not describe concrete implementation details or discuss concrete implemetation shortcomings. Here, we see our concept where we describe the usable open standards as complementative.

Additionally, we see also a privacy challenge for infected people who upload their seed ID. Once this seed ID is uploaded to a server an abuser who get sin pocession of this seed can generate all potential IDs which were emit by the smartphone (24 * 60 *days IDs). This IDs can then matched by all recipients. The problem is that each smartphone is potenially even without such an app installed a recipeint as Google and Apple collect Bluetooth and WiFi signals for a better location proximity and these are even mapped to GPS positions. Hence, once the central server is compromised all locations of all infected people are known.

However, the DP^3T mentions futher privacy threats of such apps which also require investigations how they would threaten our concept in this article.

Generally, we see the DP^3T approach and our concept as techniques which have potentially project synergies. Agian, that a similar concept has been created by another group of people points out that there is a need for privacy and also that there is substance behind the overall concepts.

10.4.2020 – Google and Apple announce nearfield tracking in OS

Google and Apple announced a privacy aware Cornavirus tracking extension for their mobile operating systems. Thereby, the system is design to interact with apps of health care authorities. It is the plan to release lateron opt-in functionality directly in the operating system and enable integrated tracking capabilities without the need to install an app.

As of now, the system seems to be purely Bluetooth based and participants emit every 15 minutes changing IDs. Once someone is tested positive with the Coronavirus the IDs which met can be matched.

There is not much technological known at this point to compare the approach with our proposed concept.

22.4.2020 Pan-European Privacy-Preserving Proximity Tracing (PEPP-PT)

The PEPP project released their documentation of Github. Thereby, each installation of a tracing application on a smartphone generates a unique PUID and then connects to a server via OAuth. Regularly anonymous Bluetooth identifiers (EBID) are generated then by this server.

Different data is stored by the government controlled server:

• Long-term pseudonym of an app (PUID)
• OAuth2 client credentials of an app
• Short term (1 h): access token (temporary client tokens)
• Mid-term / Days to weeks: Bluetooth EBIDs
  Emitted Bluetooth IDs of own device
• Mid-term / Days to weeks: BKt
  Global secret keys which apply to all users and are valid for a short timeframe
• Mid-term / Days to weeks:
  CTDs – Proximity history, containing the observed EBIDs (Bluetooth IDs) of other app installations (other user Bluetooth IDs) and timestamps
• Push Notification Service ID (PID)

Therefore, the sever can always map the user ID to the EBIDs that the applicatication emits.

Furthermore, through oAuth the server gets each hour a token refresh that can be used to trace the client and metadata.

Last but not least, the server can store a list of the proximity history of other users.

Some researchers like the prior described DP^3T see the PEPP-PT project not as privacy compliant. In special there seem to be open critiques about the PEPP project that many of the original members left.

Some cryptography researchers discuss the project even in complete detail and give recommendations how the privacy aspect of PEPP-PT can be fixed.

As of today, there is no source code of PEPP-PT published and therefore we were only able to assess the documenation which was shared already.

Therefore, we cannot compare an implementation to our approach.

From the documentation what we saw, we see huge differences to our hashing and “server does not know anything approach and we use open standards” that we described in our article.

All in all, we see the focus and the architecture of the PEPP-PT project at the current day as not comparable to what our concept describes.

Update (29th April 2021): Check out our latest project, Fahrbar!

Related Posts