Contact Tracing: The Most Amazing And Scariest Technology of The 21st Century

Contact Tracing: The Most Amazing And Scariest Technology of The 21st Century

Our phone, Bluetooth and contact tracing could rebuild our economy and save lives

Please note, this is a quick analysis of the Google specification, and not a deep dive yet.

A while back I posted an article about the usage of Bluetooth beacons, and how LinkedIn could find out who you had been in contact with. In fact, at a recently conference, I demonstrated it live and where I showed these beacons being sent out, and how these could be used to find out our contact. I often joked at conference that “you’ll see my contact on LinkedIn tomorrow, as they know we’ve been in contact”, and often I received emails back saying that it was true.

And so in this way, a social network could determine the places you had visited, and also the people you had been in contact with, without you actually having to add them yourself. At the time I thought that the technology would eventually be pushed aside because of privacy issues, but I had no idea what was coming next …

How are we going to go back to normality?

We are going through difficult times just now, and we need to find a way out which supports the future health of our population, and helps to recover our economy. It is probably one of the greatest threats we have faced across the world in the 21st Century. A core part of our recovery must be two things: testing and tracking.

Like it or not the phone in your pocket might be a record that you have had the virus, but more importantly it will trace where you go, and who you have been in contact with. But tracking every citizen? Isn’t that a Big Brother world? And, so we come to a point where we need to build protocols that can be used to trace the contacts between people, but which respects privacy.

And so, to support contact tracing, Google and Apple are working together in a way never thought before. Why? Because they hold the keys to the castle: Android and iOS. If our phones can be integrated with Bluetooth Advertising at its core, we can then build applications which seek out other devices, and then link them to those who have COVID-19, or who have been tested not to have it. In the following, we see that device details and other information such as signal strength is sent by each device to the rest of the network:

It would be one of the most amazing usages of technology probably ever, but it also brings an Orwellian nightmare, if not handled correctly. Those in control of the data gathered could thys use it to track citizens and who they had been in contact with, and social media companies could use the data to automatically find out who you were in contact with, and for how long, and where.

Privacy-preserving contact tracking with Bluetooth

And so, in a spirit of openness, Google has released their cryptography specification for a new privacy-preserving Bluetooth protocol. This could thys alert Bob that he is in contact with Alice, and who has been tested positive for COVID-19. The privacy rights of this type of system, of course, are to the forefront. The specification is defined [here]:

Three keys

Google’s core focus is on key scheduling and Bluetooth Advertisements (what would be thought of as Bluetooth beacons). Overall there are three main encryption keys:

These keys are defined next.

Tracing Key. This is a randomly generated key that is stored on the device, and kept private. It is generated as:

Key_Tr= Random(32)

and which creates a random 32-byte (256-bit) value. Some sample code to generate this is [here]:

import os

K_track = os.urandom(32)    # 256-bit random key

print ("Tracing key: "+binascii.hexlify(K_track).decode())

Daily Tracing Key. This key is generated every 24 hours when there is contract tracing. The tracing key (K_track) is then used to generate the Daily Tracking Key (Key_dtk_i) through a 16-byte KDF (Key Derivation Function):

Key_dtk_i =HKDF(Key_Tr , NUL L, (UTF8(“CT-DTK”) || D_i),16)

and where D_i is the day number for the broadcast. If the user tests positive, this key is broadcast from the device, but when proven healthy, it will never leave the device. Some sample code is [here]:

## HKDF(Key, Salt, Info, OutputLength)

# DayNumber ← Number of Seconds since Epoch/ (60 × 60 × 24)

DayNumber = str(int(time.time()/(60*60*24)))

print ("\nDay number: "+DayNumber)

D_i = "CT-DTK" + DayNumber

Key_day_i = PBKDF2(K_track, D_i).read(16)

print ("Daily key: "+binascii.hexlify(Key_day_i).decode())

In this case we are using PKBKF2 as our key derivation function, as it is a slow method of creating the keys, and thus more robust against dictionary and brute force attacks.

Rolling Proximity Identifiers. This is used identify the devices within the local promixity and are sent out with Bluetooth Advertisements. These are generated from the Daily Tracing Key (Key_day_i) through a Message Authentication Code (and which is a hash value which is encrypted with a secret value). A change in the Bluetooth MAC address causes a new identifier to be generated. The RPI_i is generated as a 16-byte value as:

RPIi, j ← Truncate(HMAC(Key_day_i, (UTF8(“CT-RPI”) | |TINj)),16)

and where TINj is the interval time that the Bluetooth MAC address changes. We can thus code [here]:

# TimeNumberInterval ← Seconds Since Start of DayNumber/(60 × 10)

today = datetime.date.today()

seconds_since_midnight = time.time() - time.mktime(today.timetuple())

TINj=str(int(seconds_since_midnight //(600*10)))

print ("\nTINj (Time interval number): "+TINj)

TINj_str = "CT-RPI" + TINj

rpi = hashlib.pbkdf2_hmac('sha256', Key_day_i, TINj_str.encode() , 10000)[:16]

print ("Rolling ID: "+binascii.hexlify(rpi).decode())

The Diagnosis Keys are then the Daily Tracing Keys which are used when the owner of the device has been proven positive for COVID-19, and uploaded to a server. Here is a very rough demo of the code:

and a demo:

So why private and secure?

Google and Apple outline the following:

• The key scheduling is embedded into the operating system, and cannot be changed by other applications.
• The Rolling Proximity Identifiers cannot be correlated to the Tracing Key, as we would need the Daily Tracing Key to discover it, and where it is almost impossible for it to be discovered from hash collision analysis.
• Trent (such as the NHS) cannot track a device, unless the related user reports their Diagnosis Keys.
• A Rolling Proximity Idenifier is only valid for 10 minutes.
• When the Diagnosis Key is sent, the Rolling Proximity Identifier is only valid for 24 hours.

The basic use case is where Alice has been identified as having COVIT-19. Her device will then send the daily key to Trent. Trent will then be able to trace every one of the rolling ID keys that Bob might send. On a new day, if Alice does not send the daily key, then Trent will not be able to trace any of the new rolling ID keys back to Alice.

Conclusions

I repeat … Contact Tracing is The Most Amazing And Scariest Technology of The 21st Century! We get this wrong, we are in big trouble .. for our health, our economy, and for our privacy! Please support and build things that help us recovery, but which protect fundamental rights.

Here is another related article on how privacy can be dealt with: