We're Hiring!

Scanshake: Meeting the Need for Decentralised Contact Tracing

Scanshake_ QR Code

As we discussed in our previous blog, there is a strong argument to be made that Bluetooth Contact tracing is too Blue Sky. The technology has been overhyped, over promised and, in the UK at least , the delivery so bungled that public confidence has been completely undermined. In the meantime we are stepping back to manual contact tracing efforts, with privacy characteristics that don’t come anywhere close to the lofty aspirations of decentralised contact tracing apps.

Where Are We Now?

In the UK’s rush to return to some sort of normality, pubs and restaurants will start to reopen soon, but with the proviso that proprietors must keep a record of customers and visitors for 21 days, to aid the contact tracing process. There will of course be a rush to fill this demand with bespoke apps, with unknown data security characteristics and obvious concerns about GDPR and how the data might be used.

The manual check-in process has actually been in place in New Zealand, the poster child for the effective fight against COVID, for many months. In fact they have now progressed beyond simple paper records with a digital diary app to aid the process. The New Zealand COVID Tracer App provides an online QR code based contact tracing app to allow you to personally keep track of where you’ve been. Business place QR code posters to be scanned on entry. Each scan records the location name, address and time/date. In the event that you contract COVID this makes it far easier to share the records of where you’ve been. This information is pushed out to all the users of the app, with the times that you may have been infectious. If they checked into the same place at approximately the same time during that period then the app generates an alert.

This may foreshadow the pragmatic direction of travel for contact tracing apps elsewhere. Let’s automate a manual process using tried and trusted technologies (QR codes and apps that communicate with backend databases) rather than immediately rush to Bluetooth based nirvana.

The digital diary approach still has some shortcomings. Firstly, it’s based on a partly centralised approach. There is a central register of the QR codes that individual businesses are using. So if you share your check-ins then the details of all your movements are revealed. Secondly, it’s designed for checking into specific locations rather than tracking person-to-person contact. With individual contact tracing features the privacy aspects become much more crucial.

Surely this is the real immediate challenge going forward? Let’s embrace the pragmatism of the QR code approach and the automation of manual processes, and let the Bluetooth capabilities be added later when the technical issues are resolved and confidence is restored. Bluetooth does provide information on more transitory contacts that cannot be captured in a digital diary approach.

A New Approach

Let’s imagine how this could work. Users install the app, needing only permissions to use the camera (to scan QR codes) and send notifications. No registration or login is needed and actually no server communication is needed at all during this signup stage. The app randomly generates a key pair, comprising a public key and a private key. We rely on the fact that the keys are sufficiently big that the chances of the same key pair being chosen more than once are so small they can be ignored. When the app is launched it can either show the public key of the user, or be used to scan the public key of somebody else’s app.


When two people meet that are both using the app, they can quickly and simply scan each other’s public keys - the “scanshake”. The apps remember the day and time of the scan too, to build up the contact diary stored in the app. Sure, this isn’t quite the seamless experience of a Bluetooth solution, and can only be applied to people you are meeting rather than those you are passing in the street. But it's precisely those contacts where there is an extended period of exposure that pose the most risk, especially if a mask is worn much of the rest of the time. Like the Bluetooth approach, the code itself is completely anonymised - it reveals nothing about the real identity of the person. Unlike Bluetooth, the code is not broadcast through the air so there is no risk of tracking. Think of the scan as becoming an anonymous “follower” of that contact. If they get ill in the future, and they might have been infectious at the time of the meeting, then it allows them to contact you via the app in the future.

The intentionality of the interaction is actually an advantage. Part of the problem with Bluetooth solutions is the fact that it is so automatic and invisible. It’s impossible to know who’s using the app and who isn’t. The ritual of a QR code Scanshake is socially reinforcing. If you see others doing it then you are more likely to follow suit, and the app can be installed in seconds with no signup requirements. Moreover, it won’t require any special Bluetooth capabilities or OS upgrades - it will run on pretty much any smartphone. Users will feel more control and agency over their privacy. They decide when to scan.

If an app user develops symptoms of Covid and has a positive test then they will be given a verification code they can use in the app to inform their past contacts during the infectious period. The verification code prevents anybody trolling the system by making fake reports through the app. The fact that this code can be supplied through a completely independent channel to the app, perhaps via a phone call, further reinforces the fact that the app itself is fully anonymized. With the verification code the app user can make the report in the app, providing the infectious period and perhaps even including a short personal message (which, of course, may retain anonymity). This will be signed using the private key that was originally generated by the app and uploaded to the central server, which is dumb and just acts as a message board for distributing to all the apps.


The apps download from this message board server on a regular basis, perhaps every hour. The signature of each message can be checked using the public keys that have been scanned in the contact diary, which is only held on the device. Only the original app from which the scan was made can generate the correct signature, since only it has access to the private key. The private key never leaves the user’s device. If there is a match and the scan took place during the infectious period then the app user is alerted, along with the optional message. The purpose of the app is to provide advice and assistance, perhaps offering information and priority access to Covid testing, a phone number to call for more personalised help and support and a plea to self-isolate in the meantime. This of course is exactly the challenge with decentralised contact tracing approaches, and careful design is needed to ensure users take the alert seriously to halt Covid propagation.

What About Non-Smartphone Users?

This is all fine for those with smartphones but as we discussed previously this actually excludes a significant percentage of the population, many of whom are the most vulnerable. Unlike Bluetooth however, the QR code approach offers the possibility of a paper alternative. Little credit card sized paper books of QR codes can be printed, and distributed through shops and post offices at no cost to the public. They would be handed out on demand, anonymously, with no records kept. Each book contains a unique randomly generated keypair (just as the app would generate), with a private key QR code (protected behind a scratch off covering) and then a number of perforated tear off slips with copies of the public key QR code. Armed with this, there is actually no need to use a smartphone app at the point of contact at all. If you don’t use the app, then to allow someone to “follow you”, you show the public key QR code to be scanned by an app user, or hand out a tear-off copy for somebody else who doesn’t use the app for them to keep and have scanned later. Even app users should carry one of these books, to hand out codes to someone not using the app. There may be some minor fomite risk from handling slips of paper, but this can be mitigated by clever physical design of the QR code books.

These paper QR codes do need to be scanned into an app at some point in order to be useful. The app should allow multiple accounts to support this use case. So the scanning can be done on behalf of anyone else, such as a family member, neighbour or carer. The date of the contact needs to be set if not on the same day - although of course it is important to do the scanning promptly as any alerts can only be sent when this is done. The scratch-off private key should also be scanned, to allow an infection report to be made if necessary. Any user of the app can actually have a number of private keys (and can thus use any number of QR code books), and in this case multiple infection reports signed with the different active private keys are uploaded.

A cynic might argue that even though the private keys are physically protected by a scratch-off portion, the printers could be keeping a record of all of the key pairs (the system doesn’t require them to do this - they are truly random). That’s possible of course, but since the books are handed out randomly it’s difficult to see how such information could be usefully abused. Moreover, this whole process of the randomized and unrecorded distribution of QR code books provides a great reinforcement of how the app works - providing more confidence that there is no sinister tracking capability embedded within it.

what About Businesses?

This style of approach can also be extended to businesses, such as pubs and restaurants, that need to keep records of visitors for contact tracing purposes. Patrons can scan the public key of the establishment (or take a tear-off copy) and also provide their public key to the business on entry. There will likely need to be a capability for customers to check-out as well as checkin-in, so that the time period of the visit is known. If the business receives a notification from one of their customers of potential infection, then they will know from the records in the app the time range of the customer visit. They can then send out an alert, signed using their own account’s private key, to their patrons alerting of an infection risk only during that time period. Only those visiting during the same time period will be matched and receive the alert.


All this manual scanning of QR codes might seem like a retrograde step to the futuristic automation of Bluetooth based contact tracing. It probably is. But this sort of approach is tried and trusted, and importantly more comprehensible to those that are being asked to rapidly adopt it. This may be what is needed now.


Richard Taylor

- CTO and Co-Founder at Approov Ltd
Chief Technical Officer with more than 30 years of industry experience. Background in compiler optimization and processor architecture, working more recently in application security and cloud computing technologies. Richard Co-Founded and is CTO of Approov Mobile Security (previously Critical Blue Ltd) and has led a number of innovative product developments in the area of EDA, software optimization and remote software attestation.