Beliebte Suchanfragen

Cloud Native

DevOps

IT-Security

Agile Methoden

Java

//

Google’s and Apple’s contact tracing

16.4.2020 | 4 minutes of reading time

Technology-based contact tracing is currently heavily discussed by experts in various fields.
In the light of the ongoing coronavirus pandemic, Google and Apple announced that they will be joining forces to develop their own solution.

Why contact tracing?

Contact tracing itself is a proven tool to fight infectious diseases and pandemics. Therefore, using technology to make this process even more effective is the right thing to do.
Infectious diseases like COVID-19 are transmitted via direct contact with infected individuals. However, not everyone knows whether they are infected or not. In case that someone is diagnosed with COVID-19, it’s difficult to find every person who had contact with the infected person afterwards. To slow down the spread of the virus, it is crucial to inform everyone who has been in touch with an infected individual. This way, they can take security measures themselves (i.e. quarantine).

This is where technology comes into play. Assuming that quite a lot of people are using smartphones, the idea is to have those devices remember with whom they had contact. With that information, it’s a lot easier to notify people who have been in touch with somebody carrying the disease.
Of course this raises questions about the used technology, privacy and security.
So for the rest of the article, let’s see how Google and Apply want to tackle those issues.

How it works: Technology and protocol

The contact tracing protocol is based on Bluetooth Low Energy (BLE).
It roughly works like this:

  • The smartphone regularly broadcasts its own non-retraceable identifier to other smartphones within its reach.
  • This identifier can now be stored on the receiving phone.
  • On a regular basis, all clients fetch the IDs of all diagnosed cases from the so-called Diagnosis Server.
  • If they find a match, the device owner can now be notified that they had contact with someone diagnosed with COVID-19.

However, this is only a rough description. For security and privacy reasons, some additional measures have been taken.

Workflow

The above mentioned “non-retraceable identifier” is actually called a “Rolling Proximity Identifier”. As the name (“rolling”) suggests, this identifier is changed regularly.

When the user activates the contact tracing feature for the first time, a Tracing Key is generated. This is basically just a 32-byte random number. This Tracing Key will never leave the device.

Every 24 hours this key is used to derive a Daily Tracing Key. This works by passing the Tracing Key to the HKDF key derivation function, along with the current date.
Similarly, the client derives the Rolling Proximity Identifier from the Daily Tracing Key.
Each time the Bluetooth MAC address changes (~every 15 minutes), the Daily Tracing Key, together with a time interval number, is used to generate a message authentication code that is secured using SHA-256 (HMAC ).
This message authentication code is then used as the Rolling Proximity Identifier.

The client sends this identifier every ~250 milliseconds using BLE advertisments.
All clients will themselves scan for advertisments with a minimum interval of five minutes. They save all Proximity Identifiers they received from the scan.

Later, if someone is diagnosed with COVID-19, their client sends a set of the person’s Daily Tracing Keys (Diagnosis Key) to a Diagnosis Server.
A Diagnosis Server is a server that aggregates the Diagnosis Keys from the users who tested positive. It also provides means for other clients to download those keys.
After downloading the Diagnosis Keys, each client uses them to derive Rolling Proximity Identifiers from it. Then they compare them to the indentifiers they have discovered through Bluetooth scanning. If the device finds a match, the user is notified. Clients will not send any matches back to the Diagnosis Server.

Additional privacy considerations

Google and Apple don’t plan to develop an app, but to add the contact tracing capabilities into the operation systems.
It’s a Bluetooth-only workflow. In other words, no GPS should be used.
All calculations/derivations only happen on the device and stay on the device. The Diagnosis Server does not know who has been in proximity with others.
The Rolling Proximity Identifiers change every 15 minutes and it’s not possible to match them to a specific person without the Daily Tracing Keys. Therefore, there is little privacy risk in advertising them (according to Apple and Google).
Users have to give their consent in order to participate in the proximity tracing. Also, it should be made transparent that contact tracing is switched on. It’s an “opt-in” feature. The documents state that “maintaining user privacy is an essential requirement in the design of this specification”.
On the other hand, the specification is still a work in progress. This means that it’s unclear how the protocol is going to evolve. Also, it’s impossible to say if (and how) cunning third parties (or even governments) can misuse the data.

Further reading on contact tracing

This article is a just an aggregated summary of the documents Google and Apple published . I retrieved them on April 14, 2020.
Axios has some additional info , e.g. about device compatibility.

share post

Likes

0

//

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.

Hilf uns, noch besser zu werden.

Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.