Blockchain and Self-Sovereign Identity: how to fight covid-19 without sacrificing privacy

Tracing contamination through mobile phone locations — balancing effectiveness with privacy and individual freedom protection

Tiziano Lattisi — Hyeon Kyeong Hwang — Enrico Talin
Editing and input provided by Florentin Blanc

To trace the contacts of each single Covid case, two approaches are possible: the connections of the mobile phone to the network cells, and the use of GPS positioning by applications installed on the phone. Both of these approaches have been used to great effect in South Korea, but in a context of strong restrictions to individual privacy, accepted by the majority of the population.

Applying the same approach without changes would not necessarily yield the same effects if many citizens refused to use the system (i.e. refused to give consent to the necessary data sharing, or stopped using their phone altogether, etc.), and in any case raises concerns about privacy and individual rights. Rather, it may make sense to adopt the most successful features of the South Korean approach, while adjusting the overall system to address these issues.

Applying the same approach without changes would not necessarily yield the same effects if many citizens refused to use the system

Several ways to do this have already been suggested, but they all tend to rely on a “trusted third party” to receive the private data from a patient found to be infected, trace the contacts and then keep anonymity of the data. This approach is both weak in terms of security (with too much risk linked to the “trusted third party” role), and unlikely to be found convincing by citizens, political groups and other stakeholders worried about respect of privacy and individual rights. It would be more effective to combine the tracing system with a platform able to safeguard privacy by design, and one that is already broadly recognized by the general public and by professionals.

Several ways to do this have already been suggested, but they all tend to rely on a “trusted third party” to receive the private data from a patient found to be infected

What worked in South Korea

The South Korean App (Corona 100m) informs the population in real time about diagnosed Covid19 cases. App users are alerted when they come within 100 meters of a location visited by an infected person, based on the entire travel histories of those infected.

The Korean government also provides information using a website called “Coronamap” that shows the travel histories of confirmed cases where each confirmed patient is given a numeric ID and his/her gender and age range are also revealed. The travel histories are reconstructed using the data from cellular phones, credit card transactions and surveillance cameras installed. Furthermore, another web service called “Coronaita” acts as a search engine that allows users to search for information on coronavirus-hit areas. These applications not only have helped citizens to avoid being in the vicinity of infected persons but also raised self-awareness of the possibility of having been exposed to the virus, prompting voluntary self-isolation and visits to a testing facility.

Applicability in other countries

Using the same approach in OECD countries or indeed most countries worldwide with a high level of smartphone adoption and network coverage does not present substantial technical challenges. Phone operators are able to reconstruct connections and positions going back 15 days, and there are already proposals to make available monitoring data on the movements of positive cases (e.g. SM_Covid19, developed by a spin-off of the University of Salerno, in Italy). The obstacles and oppositions generally put forward, by contrast, are linked to individual privacy and rights.

Even though the initial use of the data is pandemic response, it is difficult to guarantee that the data would not be put to further use. Though many (though not all, far from it) have been consenting, in practice, to give control of their data to private services, there is much more widespread resistance to ceding such control to governments or public authorities. There is also opposition (and justified skepticism) about the effects on human rights, public trust and legitimacy of authorities of a system of “automated enforcement” (e.g. monitoring quarantined persons 24/7 and automatically initiating law enforcement measures against them if the system indicates an unauthorized movement).

To offer a successful approach, that can be adopted widely and remain in use to avoid resurgence of the pandemic in the future (and also be used for potential other epidemics in future), these justified concerns need to be addressed effectively and convincingly.

rather than having an organization or a government that is deemed “sufficiently trustable”, this function is delegated instead to already existing instruments that can guarantee privacy

Privacy by design

The aim is to reduce to the minimum the privacy loss, both in terms of effective data protection and of citizen perceptions. To this aim, rather than having an organization or a government that is deemed “sufficiently trustable” (which raises unavoidable issues), this function is delegated instead to already existing instruments that can guarantee privacy by design. The proposed solution combines two elements: a Self-Sovereign Identity and a Blockchain.

The first element represents the third generation of systems of identity management, which can put back in the final users’ hands sovereignty (control) on their own identification data, rather than in the hands of third parties that provide such services (for “free” or not). In appendix A we present a short summary of current standard and best practices for Self-Sovereign Identity.

The second element is based on the third generation of Blockchain which, by contrast with Bitcoin (first generation) and Ethereum (second generation) allows for a more “granular” management of the anonymity of transactions (data exchanges, contacts). In appendix B we present an example of the logical architecture that could be used to support such an approach.

Combining these two elements would allow to guarantee citizen privacy, not constraining citizens to put their faith in the reliability and effectiveness of the organization delegated to data protection.

Outline of key elements of the solution

The proposed solution combines several elements:

• Providing the tracing system only without automated enforcement of quarantine measures (rather, control and enforcement measures remain done in a more compliance-promoting, trust- and risk-based approach, emphasizing voluntary compliance and targeted actions)
• Giving the information about past or current proximity to infected persons to each user.

The information about locations is kept in a centralized database but totally anonymized in a way that can only be matched through the Blockchain. The resolution of anonymity can only be done upon the request of each individual user, and only for his own positions. Thus, when a person is diagnosed as infected, the system can know that there was a user infected, but not who it is. When another user does a query for his own sake, he gets notified if his own “key” shows that he was one of the people in the vicinity of an infected person.

The information about locations is kept in a centralized database but totally anonymized in a way that can only be matched through the Blockchain.

When all other users update their App’s data (which can be set to automatic, frequent and regular update), those that have been in contact or proximity with this infected person will receive the notification from the system that this contact has taken place and that they should thus test — but no information on who this person is/was. Thus, privacy is kept constant at all stages, and only the affected users get the notification. To ensure full effectiveness, the health system should then treat such notification as a valid reason to get tested for infection.

In addition to this, which is the key functionality (tracing of cases and notification to potentially infected people, so that they can get tested ASAP), a feature inspired from Singapore could be added, i.e. allowing users to easily notify any respiratory or related symptoms that they currently feel. The aim would not be to provide an approximated and possibly misleading “diagnosis” but to crowdsource identification of possible “clusters” and spread. While individual symptoms may not necessarily be significant enough to determine infection, a large concentration of reports indicating potentially-Covid-related symptoms in a location would denote a very high probability of spread in this area. This could then form the basis for a rapid public-health intervention (testing in the identified area). Such a functionality would be easy to add, and would be voluntary, so that no significant privacy issue is at stake.

APPENDIX A Self Sovereign Identity Primer

DID: Decentralized Identifier (ref: https://w3c-ccg.github.io/did-spec/)

• Identifies a person, object, entity etc.
• Has a method (i.e. reference to «how interpreting the DID).
• It’s decentralized on a blockchain.

DDO: Did Document (ref: https://w3c-ccg.github.io/did-spec/)

• It is univocally associated to the DID. It contains, at least, cryptographic material and — possibly — endpoint to check revocation or to gather VCs.
• It should be «resolvable», i.e. given a DID, via the DID method, I can retrieve the associated DDO.
• It is recommended to store it on the blockchain

Important facts about DID and DDO

• Neither the DID, nor the DDO give any information about the DID subject.
• One person, object or entity, can control any number of DIDs and DDOs
• DIDs and DDOs can be public (i.e. written on the blockchain) or private / pairwise, and live locally.

VC: Verifiable Credential (ref: https://www.w3.org/TR/vc-data-model/)

• A Verifiable credential is a set of attributes, that a subject issue for itself or for another subject.
• It may include cryptographic proof (i.e. signature) of these attributes.
• It should NOT be public, in order to avoid privacy issues

Trust Scheme

• Government: it is the Root of truth and it has it’s DID, DDO and VC public on the Genesis Block. Government issue VC credential for TSP
• TSP (Trust Service Providers): are the entities that provide trust services, i.e. verifies identity of persons and companies and issues VCs for them.
• Company/Institution, Sign transaction with its own verification key (included in the DDO), satisfying a chain of trust that goes up until the government DID and provide, if required, all the properties included in its verifiable credential, including the proof signed by the company.
• End User, Sign transaction with its own verification key (included in the DDO), satisfying a chain of trust that goes up until the government DID and provide, if required, all the properties included in its verifiable credential, including the proof signed by the person.

Appendix B Logical Architecture Example

Institution

The reference organisation gathering information from all users, compiling Location Risk maps and give access to users to free immediate Covid-19 Testing

End user

The single individual (associated to a single phone number via external VC Verifiable credential) that provides anonymous geolocation data and self health daily check in exchange for risk map data and free immediate Covid-19 Testing if needed.

End user Mobile App

The multiplatform (iOS and Android) application that allows users to send geoLocation and send selfHealthCheck to the blockchain. This mobile app shall allow the user to interact anonymously with the blockchain, since the cryptographic material that controls the DID never ever leaves the device.

Institutions Web App

The web app shall allow institutions to interact seamlessly with the blockchain, thanks to the back end integration with the institution / site associated Wallet and elaborate any epidemiological model and prediction.This app allows institutions to originate send geoRiskMap and send freeTestVoucer and send redeemTestVoucer with positive negative attributes or the blockchain

Blockchain Type

First and second generation or DLT (Distributed Ledger Technology) blockchains are only pseudo anonymous, in the sense that all transactions are public and immutable. For this reason It’s advisable to use a third generation Proof-of-stake (more privacy oriented) type of Blockchain

Wallet Type

It’s a standard HD (Hierarchical Deterministic) Wallet with the Self Sovereign Identity paradigm based on WC3 Decentralised Identifier and DID Method

Decentralised Storage

Must permanently and Anonymously stores all user data referenced in send geoLocation and send selfHealthCheck and send freeTestVoucer and send redeemTestVoucer transaction

BIOS

Tiziano Lattisi

Has a background in mathematics, and over 20 years experience in applying information technology to public administration issues. He is currently a consultant for the OECD’s project supporting regulatory inspections and enforcement in Italy.

Hyeon Kyeong (Chloe) Hwang

has a PhD in Computer Science with vast experiences in the IT sector. Currently involved in crowd-sensing project which gathers real-time information on urban movement patterns and is a technical coordinator for C-Roads Italy 2, European project on Cooperative-ITS.

Enrico Talin

Created the first proof of stake documents blockchain called Commercio.network based on third generation CosmosSDK/Tendermint open-source framework. Commercio was the creator of the first accepted DID Method on WC3 Decentralised Identifier in Europe.

Florentin Blanc

Holds a PhD in public law, with a background in historical social anthropology, and has been working for over 15 years in issues of regulatory control, enforcement and compliance, in over 40 countries. He is currently working for the OECD, after many years at the World Bank Group.