SecureABC: Secure AntiBody Certificates for COVID-19

05/24/2020 ∙ by Chris Hicks, et al. ∙ The Alan Turing Institute University of Warwick 0

COVID-19 has resulted in unprecedented social distancing policies being enforced worldwide. As governments urgently seek to reopen society, there is a demand for technologies that may alleviate the requirement for social distancing whilst also protecting healthcare services and maintaining human and civil rights. In this work we explore the controversial technique of so-called immunity passports and present SecureABC: a decentralised, privacy-preserving system for issuing and verifying antibody certificates. We consider the implications of immunity passport systems, develop a set of general principles and security requirements for their deployment and show that these may be satisfied in practice.



There are no comments yet.


page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Governments worldwide are currently dealing with the Coronavirus pandemic, an outbreak of the SARS-CoV-2 virus which has already resulted in over 340,000 deaths [covid_tracker] and has caused unprecedented social changes for billions of people worldwide. Most countries have responded to the pandemic with policies aimed at enforcing social distancing, a technique certain to suppress the transmission of the virus when it is applied uniformly to the whole population [Imperial_Report_9]. Whilst effective, social distancing measures come at a significant social and economic cost and may not be a feasible long-term policy option in many countries. In addition it has been noted that the approach may have a disproportionate impact on disadvantaged groups in society [unequal]. As the effective reproduction rate () is reduced below 1.0, and the number of COVID-19 cases falls, there are clear benefits to governments reducing the scope of population-wide social distancing and seeking technologies that may alleviate the requirement for social distancing whilst also protecting healthcare services and maintaining human and civil rights. In particular, measures such as intensive testing, contact tracing and selective isolation have been proposed [DP3T].

A promising, but controversial [WHO_immunit_passports], technique for relaxing the need for population wide social distancing is the use of so-called “immunity passports” or “risk-free certificates”. The general idea is that a test for antibodies to SARS-CoV-2, the virus that causes COVID-19, could serve as the basis for a passport document that frees an individual from the most restrictive social distancing regulations. Assuming that strong correlates of protection to SARS-CoV-2 can be identified, immunity passports could provide a key technology in enabling the transition away from total lockdown. Chile has already announced plans to issue such passports [chile_passport] and key policy makers in the UK and Germany are also considering the approach [uk_germany_passport]. In light of the interest already shown by several governments, and the emergence of a number of commercial solutions, an academic consideration of immunity passports is called for.

We note that immunity passports are a highly controversial technology that has received criticism from many influential organisations including the World Health Organisation (WHO) [WHO_immunit_passports]. We do not claim to advocate the use of immunity passports as this is a complex policy decision that should only be considered, on a case-by-case basis, after involving all of the relevant stakeholders and experts. We do however think that it is important to provide a detailed solution to the problem that can be used to properly inform any such decision. We complement our solution with a presentation of four general deployment principles which aim to mitigate many of the concerns surrounding immunity passports.

Our contributions

  1. We provide a framework of general principles and a set of security and privacy requirements for immunity passport systems. Our general principles aim to alleviate some of the major concerns relating to such systems, and our requirements provide the basis for ensuring such systems have the right properties and can be evaluated on common terms.

  2. We present SecureABC, a decentralised and privacy-preserving solution for antibody certificates which is both designed in accordance with our general principles and that meets the our security and privacy requirements.

  3. We show that SecureABC is efficient and practical with our proof of concept implementation.


First in Section 2 we review the concerns surrounding immunity passports and derive four general principles that may minimise the risk posed by these systems. Next, in Section 3 we define our protocol model and introduce our cryptographic primitives. Section 4 presents the full details of our SecureABC antibody certificate system. Then, in Section 5 we define our desired security properties for immunity passports and then evaluate SecureABC with respect to them. Section 6 shows the results of our implementation. Finally, we review related work and other solutions in Section 7 before concluding in Section 8.

2 General Principles for Immunity Passports

In this section we build towards presenting some general principles for deploying an immunity passport system. We first present the general use case for immunity passports, before citing the major concerns which have been raised. Our motivation for providing this section is to address concerns that immunity passport systems may prove to be counter productive and could have a net negative impact on society. Evidence is mounting that many nations [chile_passport, uk_germany_passport] are at least considering immunity passport solutions, so it is important that techniques for minimising the risk posed by such systems are considered.

Basic use case

The use case we will use to begin our discussion is one in which citizens wishing to travel on public transport are required to present a certificate affirming that they have some level of protective immunity to the SARS-CoV-2 virus. In more detail, a healthcare provider will test citizens for antibodies to COVID-19. If antibodies are found then a so-called immunity passport will be issued issued. The citizen will now present their passport to the transport service provider who, after establishing the authenticity of the certificate, will allow access to transportation.

Immunity passport concerns

Immunity passports have attracted significant criticism, including from the WHO [WHO_immunit_passports]. The main concerns we are aware of are as follows:

  1. Alterations to scientific advice. As a novel disease, COVID-19 is not yet well understood by the scientific community [what_we_dont_know]. For example, the WHO’s main concern is that the presence of antibodies is not an accurate indicator of immunity citing that such tests “need further validation to determine their accuracy and reliability” [WHO_immunit_passports].

  2. Is discriminatory. Such a system will create an attribute for discrimination [discrimination], creating a clear distinction between those with ‘immunity’ and those without. The Ada Lovelace Institute report emphasises this [lovelace_report]: “Discrimination and stigmatisation may become commonplace if immunity becomes an element of identity.” This inequality would be exaggerated if tests were not universally and freely available to all — immunity passports, and the associated benefits, could be a luxury of the rich.

  3. Incentivises people to get the virus. Those with immunity passports will be allowed access to “the post-lockdown world” while those without could remain subject to social distancing policy. An immunity passport could become synonymous with freedom, creating a strong incentive for people to attempt to obtain a passport. Coupled with the belief that having (and surviving) the virus corresponds to gaining immunity [immunity_misinform, reinfects], it is hypothesised that immunity passports could actively encourage people to try to become infected.

  4. Feature creep by governments. Governments are currently exercising an abnormal level of control and surveillance over their populations [surveillance]. Passporting systems could provide authorities with an opportunity to implement technologies, and to collect data, that could have long-term negative consequences on society [lovelace_report].

These concerns are persuasive in advocating against immunity passports in the basic use case setting which we have described. We are therefore motivated to address these concerns with a set of general principles which aim to mitigate the risks associated with immunity passports.

General principles for immunity passports

  1. Rename, educate and revocate. Until there is strong evidence of protective immunity to COVID-19, the word “immunity” should not be used. This is misleading at best and dangerously inaccurate at worst — creating a false sense of security. We opt for “antibody certificate” as it reflects the function more accurately. Moreover, appropriate levels of public education with regard the benefits and limitations of such systems is vital. Indeed, the Information Commissioners Office (ICO) strongly advocate the principle of being transparent about the purpose and benefit of the closely related contact tracing technology [ico_report_on_contact_tracing]. Finally, we call for systems which support efficient and fast revocation of certificates and service providers. This is essential to maintain pace with the fast changing scientific understanding and dynamic policies which relate to COVID-19.

  2. Access to testing and technology. Wealth, location and demographic profile must not impact access to obtaining or using a certificate. In other words, beyond their specified purpose, antibody certificates must avoid any additional discrimination. In the case of contact tracing, the ICO state that “special consideration for different societal groups” is paramount. Moreover the Lovelace report [lovelace_report] calls for “measures for ensuring vulnerable groups are not excluded from the operation of the system”.

  3. No restrictions based on test results. The Lovelace report recommends the development of a strategy for “how immunity certification will be integrated into policy …  pertaining to travel, movement, work and schooling.” We advocate that such strategy should minimise any restriction of access to movement or provision of services. The resulting system will be less discriminatory111Without this the system potentially discriminates against those who have acted responsibly during the lockdown period, have not contracted the virus, and therefore are less likely to test positive for antibodies. and therefore will present less incentive to get the virus.

  4. Maintain user ownership of data. An antibody certificate system should be designed in such a way that users can, at all times, control the use of their data. In particular, users must control when and where to use their data to demonstrate their test result. This is supported by the ICO’s principle of “giving users control” [ico_report_on_contact_tracing] with regard to contact tracing.

These principles may appear to reduce the functionality of any antibody certificate system that is in accordance with them. To alleviate this concern we present two additional use cases that are both in accordance with these principles and which may still benefit society:

Use case 2: indicating user risk.

Consider the use case given at the start of the section where users of the public transport are required to show their certificate before making a journey. Under our general principles we advocate that certificates are still checked, however access is granted to all. In this scenario, antibody certificates can still provide a benefit by allowing testing, cleaning and other mitigatory techniques to be optimised based on the relative use of each service by untested or tested-negative citizens.

Use case 3: helping vulnerable members of society.

When providing food delivery services for elderly people who cannot safely leave their home, preferring (based a task scheduling algorithm) the carrier to hold an antibody certificate could provide a way to reduce the risk faced by the recipient. This scenario could represent a reasonable trade-off between restricting access to work and minimising the risk faced by vulnerable groups.

3 Model and Preliminaries

Here we begin the technical part of our paper by first defining the model for our antibody certificate protocol and then introducing the cryptographic primitives we require.

3.1 Model

Our antibody certificate scheme model comprises three parties. We denote the Healthcare provider as Harry (H), the citizen or user of the scheme as Alice (A) and the service provider, who Verifies user certificates, as Verity (V). Our general protocol model is outlined in Figure 1. In step (1) A gets tested for antibodies by H. In step (2) H records the result of the test in a certificate which is sent to A. In step (3) A presents her certificate to V and then finally, in step (4), V checks the authenticity and attributes of the certificate to ensures it corresponds to A (e.g. by matching a photo and name to A). Our system model assumes a root of trust in the system (e.g. the government) that authorises both H and V as legitimate entities.

Figure 1: Our general model of an antibody certificate scheme run between a healthcare provider, a user and a service provider.

In our SecuereABC antibody certificate scheme, which we present in Section 4, we map these steps into three protocol phases: an initial setup phase where H generates the public and private system parameters, an issue phase corresponding to steps (1) and (2) where A is tested and issued with a certificate by H and finally an authentication phase corresponding to steps (3) and (4) where A’s certificate is verified by V.

3.2 Preliminaries

Our SecureABC antibody certificate scheme requires a secure public key signature scheme as well as a secure public key encryption scheme. Both of these schemes are made up of three algorithms. The first algorithm generates a public key pair, the second either signs or encrypts and the third verifys the signature or decrypts the ciphertext, respectively. We denote the signature scheme by the tuple and the encryption scheme by the tuple .

We use the signature scheme to allow the healthcare provider to sign antibody certificates and therefore, intuitively, we require the signature scheme to be unforgeable. Specifically we require it to be EUF-CMA (Existential Unforgeability under Chosen Message Attack) secure [eufcma]. Rather than define this property here, we refer the reader to Goldwasser et al. [eufcma] for the standard definition. We note that the standard Elliptic Curve Digital Signature Algorithm (ECDSA) [FIPS186] is a sufficient instantiation for our needs.

We use the encryption scheme in the authentication phase between the user and the service provider. The user will encrypt their signed certificate such that only an authorised service provider can decrypt it. Our particular use of the encryption scheme means that any public key encryption scheme that is at least IND-CPA secure will suffice. For a standard definition of IND-CPA refer the reader to Katz and Lindell [ind-cpa] .

4 SecureABC

In this section we present SecureABC, our antibody certificate scheme that realises the model defined in Section 3. SecureABC is a distributed, privacy-preserving antibody certificate protocol that allows for both paper-based and app-based user credentials. Providing printable, paper-based credentials is important because even in the most developed countries, the adoption of smartphones is not absolute. Indeed, requiring the use of electronic devices may exclude vulnerable user groups [unequal] and limit the reach of any deployment. We seek to provide strong privacy guarantees regardless of whether a user has a device capable of displaying a digital passport or not. In particular we seek to replicate the privacy of traditional identity documents, such as driver’s licenses, which do not notify the issuer each time they are presented.

As noted in Section 3 our model assumes a common trust anchor, such as the government, that authorises both H and V as legitimate entities. In practice this means that every H or V generate a new public key, the government signs it to indicate that it can be trusted.

High level overview of SecureABC

The SecureABC protocol comprises three phases: Setup, Issue and Authentication. The Setup protocol is run by Harry, who generates the public key pair for the signature scheme he will use to sign antibody certificates. Next, the Issue phase is run between Harry and Alice. At the end of the Issue phase Alice receives an antibody certificate, signed by Harry, which she can use to demonstrate her antibody status to service providers. Finally, the Authentication phase is run between Alice and Verity. The authentication phase allows Verity to convince Alice that they are an authorised service provider, and allows Alice to convince Verity that she has a valid antibody certificate from Harry. We provide two Authentication phase sub-protocols which allow Alice to choose between using either a paper-based or app-based credential.

4.1 The SecureeABC Protocol

The Setup, Issue and Authentication phases of the SecureABC protocol are as follows.


Harry initialises the list of revoked CID numbers and generates the public and private key for the signature scheme.


Harry interacts with Alice to issue a signed antibody certificate.

  1. Alice is tested for antibodies by Harry, who records the test identity number (TID) that produced the test result. If the test is positive for antibodies, and Alice has not already been issued a certificate, then Harry generates a random Certificate ID (CID), initialises a corresponding revocation bit and specifies a validity period . Harry stores in a private database

  2. Alice provides Harry with a photograph, , and a communication channel, , which will be used to send passport status updates (e.g. upon revocation or test recall). In practice, Alice will choose one of a small number of communication options such as SMS, email or post.

  3. Harry prepares and sends Alice the signed antibody certificate which is computed as follows:


Alice interacts with Verity to demonstrate the authenticity and ownership of her antibody certificate. Authentication must be mutual, that is first Alice must be convinced that Verity is authorised by the government before allowing her to verify her certificate. Since SecureABC allows Alice to present either a paper-based or app-based certificate, we require two different authentication sub-protocols which correspond to the manual and automated authentication of Verity by Alice, respectively. In both authentication sub-protocols, Verity runs an app which she uses to scan and verify Alice’s credential. The app also periodically downloads and verifies the list of revoked CID numbers and Harry’s public key .

Paper-Based Authentication:

Alice has and Verity has the list of revoked CID numbers and the Harry’s public key .

  1. Alice must manually convince herself that Verity is a government-authorised service provider (e.g. based on context or viewing an identity document). If this step fails Alice aborts the protocol.

  2. Alice shows her certificate to Verity.

  3. Verity verifies . That is she confirms , and learns , . She checks that CID has not been revoked i.e. , then compares to Alice and ensures that has not elapsed. Optionally, Verity may ask to see a second document bearing .

App-Based Authentication Protocol:

Alice runs an app that stores her antibody certificate and which periodically downloads and verifies a list of revoked verifier public keys, , from the government. Verity has a list of revoked CID numbers, Harry’s public key and also an encryption public key pair .

  1. Verity sends to Alice. In practice, Alice uses the app to scan a QR code or read an NFC tag provided by Verity. Alice verifies is an authorised public key and is not on the revocation list, i.e. . If either of these fail then Alice aborts the protocol.

  2. Alice computes which is converted to a QR code and scanned by Verity.

  3. Verity decrypts Alice’s certificate and then proceeds as in Step 3 of the paper-based authentication protocol.

If either the paper-based or app-based authentication protocol succeeds then Verity accepts Alice’s antibody certificate, otherwise she does not.

5 Security Properties and Evaluation

This section first presents the main technical security properties we require of an antibody certificate protocol before evaluating our SecureABC scheme with respect to them.

5.1 Desired Security Properties

In this work we do not pursue a rigorously defined, formal definition for every requirement but rather we intend to provide an unambiguous set of terms for evaluating antibody certificate systems. It is unlikely that any scheme can simultaneously satisfy all of of these properties as several of them present a trade-off. For example, there is an inherent compromise between the anonymity of user certificates and the binding between the user and their certificate. We provide some additional intuition after the definition of each term.

Correctness: If all parties are honest, the service provider will be able to view the certificate produced by the healthcare provider for the user at the end of an execution of protocol. — Correctness ensures that the protocol computes the expected functionality.

Soundness: A user cannot create a valid certificate alone. — In other words an adversarial user cannot forge a valid certificate.

User-Cert Binding: The only certificate a user can successfully use is the one that is assigned to them and which has not been revoked. — This prevents a user from swapping their certificate with that of another user and then succeeding in using it.

Uniqueness: A user can have at most one valid certificate associated to them at any one time. — This property is important when User-Cert Binding is imperfect, for example when considering twins who may share a similar photograph but that may not share the same antibody test result.

Cert-Attribute Binding: The value of the attributes associated with a certificate cannot be altered by the user. — In other words, the certificate must be tamper proof.

Peer Indistinguishability: We define a peer as an unauthorised service provider (for example, a malicious citizen). We require that a peer cannot learn any information about the user from viewing the certificate. — Intuitively, Peer Indistinguishability ensures that a user cannot be pressured into revealing their certificate by anyone except authorised service providers, this alleviates the “bully on the bus” problem.

User-Auth unlinkability:

  1. (From healthcare provider) The healthcare provider cannot link a user to their authentication phase interactions.

  2. (From service provider) The service provider cannot link a user to an authentication phase interaction.

This property prevents the healthcare and the service provider, respectively, from learning when and where a users certificate is authorised.

Revocation of certificates: A users certificate can be revoked. — Certificates may be invalidated in the following situations:

Loss/Stolen: If a certificate becomes lost or compromised.

Error: If a batch of tests are recalled because they were incorrect.

Misuse: If evidence of certificate misuse is presented.

Revocation of service providers: A service provider can be revoked from the list of authorised providers. — An authorised service provider may be revoked in the following situations:

Change of policy: A change in government policy may mean some service providers are no longer authorised.

Sanctioning: If a service provider is deemed to not be following recommended guidelines it may lose its authorised status.

5.2 Evaluation of SecureABC

Here we first evaluate the SecureABC system in relation to the security properties from Section 5 and then with respect our general principles from Section 2. We make the assumption that the healthcare and service providers do not collude. Figure 1 summarises and compares the properties observed by the paper-based and app-based versions of SecureABC.

Correctness: The correctness of the system is reduced to the correctness of the signature scheme and, optionally for app-based users, the encryption scheme used by our protocol.

Soundness: We require that the signature scheme is EUF-CMA secure therefore no forgery of certificates is possible.

User-Cert-Binding: Alice is bound to her certificate by the photograph and name that are signed by Harry. Alice would have to go to significant effort to change her appearance and name to match that of another user, and would also face legal and social pressure for doing so.

Uniqueness: Harry checks that to see if Alice has already been issued a certificate in the Issue phase, meaning uniqueness is satisfied to the degree that it is already assured for medical record keeping.

Cert-Attribute Binding: The certificate is signed by Harry using an EUF-CMA secure signature scheme. As Alice cannot produce any forgery, let alone one with specific attributes, she cannot modify the attributes in her certificate.

Peer Indistinguishability

  1. (Paper-based) The paper-based authentication sub-protocol provides negligible peer indistinguishability for users. In particular, the protocol only guards against non-technical peers without the ability to scan QR codes.

  2. (App-based) The app-based authentication sub-protocol enforces mutual authentication by requiring Verity to present a valid public key, signed by the government, which has not been revoked. As Verity’s public key is signed using an EUF-CMA secure signature scheme, peer indistinguishability can be reduced to the difficulty of forging a government signature.

User-Auth Unlinkability:

  1. (From healthcare provider) SecureABC is decentralised, meaning the healthcare provider is not involved in the protocol after the issue phase. Consequently to link the user to an authentication the healthcare provider would have to collude with the service providers.

  2. (From service provider) The service provider learns when a user authenticates with them. If multiple service providers collude, then the colluding group all learn the linking.

Revocation of certificates: The signed list of revoked certificate CID numbers is periodically distributed (e.g. daily) to service providers and checked during each authentication. This means a certificate that has been revoked cannot be used successfully. Let Harry periodically compute and distribute such that it comprises all CID numbers in his private store that have the revocation bit . Then, for the use-cases in Section 5.1, revocation of certificates can be realised as follows:

  1. Loss: If Alice’s certificate becomes lost or compromised, she must inform Harry. Harry looks up her CID and sets the revocation bit in his private store.

  2. Error: If a test result is recalled due to clinical error, Harry uses the TID number to identify the corresponding CID in his private store and then sets the revocation bit .

  3. Misuse: If evidence of certificate misuse emerges, a trusted authority (e.g. a court) should inform Harry of the CID that was misused. Harry sets the corresponding revocation bit .

Revocation of service providers:

  1. (Paper-based) Our paper-based authentication does not provide technically enforced revocation of service providers. This property can only be obtained if a user is constantly educated as to which service providers are no longer authorised222For example it may be advertised that a certain class of services (e.g. cinemas) are no longer authorised..

  2. (App-based) This property is realised in the app-based authentication sub-protocol. Authentication only succeeds if the service provider sends the user a public key that is signed by the government and which is not on the list of revoked verifiers . Since the user encrypts their antibody certificate using , the verifier must have the corresponding private key .

Paper-based Digital
User-Cert Binding
User-Auth Unlinkability by H
User-Auth Unlinkability by V
Revocation of Certificates
Revocation of Service Providers
Table 1: Security properties of our paper-based and app-based user passports.

Adherence to our general principles

Here we evaluate SecureABC with respect to the general principles we formulate in Section 2.

  1. Rename, educate and revocate. Firstly, we follow our naming principle. SecureABC provides Secure Antibody Certificates and implies neither immunity nor freedom of travel. Public education about our system is beyond the scope of this paper, but we do provide efficient and fast revocation of both user certificates and service providers.

  2. Access to testing and technology. We aim to reduce unnecessary discrimination in SecureABC by providing both a paper-based and app-based authentication protocol. This design decision ensures that access to, or willingness to use, technology does not discriminate against certain user groups.

  3. No restrictions based on test results. Whilst this is a policy decision rather than something that can be technically enforced, we suggest two non-restrictive antibody certificate use-cases in Section 2.

  4. Maintain user ownership of data. SecureABC is a decentralised system in which users authenticate directly with service providers. This keeps the user in control of when their data is used and for what purpose.

6 Implementation and Performance

In this section we review the implementation and practical considerations of our SecureABC antibody certificate system and present the results of our reference implementation.

QR Codes

In SecureABC, users are issued signed antibody certificates which they display to service providers using a QR code representation. QR codes are a suitable technology for this purpose because they are a widely adopted, mature technology that offers both machine-readability and error tolerance. There are a range of libraries suitable for reading and writing QR codes, users understand how to interact with them and they are resistant to wear and tear when printed. Attacks on QR code systems are surveyed by Krombholz et al. [qr_code_survey].

The storage capacity of a QR code is determined by a “symbol version” number between 1 and 40. Higher symbol numbers correspond to a greater number of modules, and more modules correspond to higher storage capacity. The maximum storage capacity for a standard QR code is 2953 bytes [qr_codes]. If higher storage capacity is needed, alternative technologies such as multi-layered QR codes [6_layer_QR, colour_QR_codes] and Microsoft High Capacity Color Barcode (HCCB) [hccb] are available.


We have created an open source, reference implementation of our paper-based antibody certificate generation and verification algorithms which can be downloaded from We use this implementation to evaluate the suitability of QR codes for this application. In particular, SecureABC antibody certificates comprise a photograph of the user, their name, a validity period, a CID number and a digital signature. Figure 2 shows a QR code that is output by our implementation and which comprises the optimised gray-scale user photograph as shown in Figure 3, the name “Alice Doe”, the validity period “6052020-16082020”, the CID 0x1fc60e1a4e238ac6cce9d79097a268af and a valid 512-bit ECDSA signature.

Figure 2: An example of a standard “version 40” QR code that is output by our reference implementation.
Figure 3: An example image, generated by the NVidia StyleGAN [nvidea_style_gan], that has been optimised to a size of 2157 bytes. This image, a name, a CID, a validity period and a 512-bit ECDSA signature is included (with 7% error correcting codes) in the standard QR code shown in Figure 2.

Our implementation shows that it is possible to provide both a high level of security (512-bit ECDSA) and reasonable user-cert-binding, in the form of a photo, using a standard version 40 QR code. Verification of antibody certificates is highly efficient and is just the standard ECDSA verification algorithm.

7 Related work

Here we review the small number of alternative antibody certificate schemes which have been proposed. To the best of our knowledge, all existing schemes are either based on a centralised architecrture or propose the use of a blockchain.

A commercially available centralised immunity passport solution is proposed by CoronaPass [coronapass]. In CoronaPass, service providers verify user passports directly with the central service. Whilst security and legal measures can be put in place to deter the central authority from misusing the data they hold, it nonetheless represents an avoidable risk and a central point of failure. Involving the central party in each authentication risks large-scale user tracking and feature creep.

Eisenstadt et al. [DBLP:journals/corr/abs-2004-07376] propose an antibody certificate scheme in which blockchain is used in conjunction with “Solid Pods” [DBLP:conf/www/MansourSHZCGAB16]. Interestingly, the authors cite two reasons why a paper-based solution is not desirable: (a) it is thought the virus can survive on surfaces (e.g. paper or plastic) for a number of hours, facilitating transmission via paper-based certificates [virus_survives_on_paper]; (b) for such a valuable certificate, a paper version is too vulnerable to alteration or forgery. In response to these concerns, we note that: (a) our paper-based solution is still contactless, as the paper certificate is scanned by the service provider; (b) the paper certificate is still digitally signed which negates the risk of forgery. In [immupass, certus_blockchain_solution, CCI] blockchain is also used to provide antibody certificate solutions. To the best of our knowledge, blockchain is generally used in these systems as an immutable ledger for recording user status’ — in particular these solutions require verifiers to query the blockchain each time a user presents their certificate.

In the broader security and privacy literature relating to COVID-19, we note that there has been significant debate over the merits of centralised versus decentralised systems for digital contact tracing [cryptoeprint:2020:531, central_decentral_contact_trace1, central_decentral_contact_trace2]. In digital contact tracing, users’ phones continually broadcast ephemeral identities which are used to determine which users have come into contact and risked infection. Decentralised contact tracing systems [DP3T] have the advantage of allowing users to compute which interactions may have risked infection locally, denying this information to a central authority. Analogously in our SecureABC scheme, users authenticate directly with service providers and the healthcare provider is denied certificate usage information.

In relation to the non-technical implications of immunity passports, and our general principles which we present in Section 2, the Ada Lovelace Institute published a “Rapid evidence report” [lovelace_report]. The report explores how non-clinical measures can be used to attempt to relax current governmental controls and restrictions without an intolerable rise in COVID-19 cases.

8 Conclusion

In this work we explore the controversial technique of so-called immunity passports and present SecureABC: a decentralised, privacy-preserving system for issuing and verifying antibody certificates. We consider the implications of immunity passport systems, develop a set of general principles and security requirements for their deployment and show that these may be satisfied in practice.