Assessing the security and privacy of Vaccine Passports

There has been a lot of development lately in the field of health credentials, especially in the field of vaccine credentials. This has largely been driven by a perceived need to track and validate an individual’s vaccination status with respect to COVID-19.

This post attempts to explore the security and privacy concerns related with vaccine credential systems, by way of threat modelling and exploring the various risks and attacks conceivable against such systems. There are other concerns about these systems apart from security and privacy, mainly in the social and political realm; those issues are best left discussed by others, and we’ll restrict treatment to technical topics and attacks here. Furthermore, we’ll look at these concerns through the lens of the users of the system, rather than the maintainers of such systems – i.e from the perspective of end users looking to prove their vaccination status, and businesses or entities looking to validate said credentials. Essentially, just the public-facing parts of the system.

General overview

There are many vaccine credential systems (VCS) currently in use around the world. Many share a common format as a base for credential (such as CommonPass), while others have gone their own way in defining what a vaccine credential is. Quite a few of these initiatives are planning for going beyond the immediate need for COVID-19 vaccination tracking, branding themselves as a “smart health card” (like https://smarthealth.cards/) encompassing a broader range of health and vaccination information.

For the purposes of this exercise, we assume a simple vaccine credential system with a few defined entities. These entities include:

• End-user: The individual trying to acquire a vaccine credential (VaxCred), which proves their COVID-19 vaccination or test status
• Vaccination lab (VaxLab): The entity or organization that performs COVID-19 vaccination and/or SARS-CoV-2 tests and stores the result in a health backend
• Health backend: A system that stores vaccination and test results from vaccination labs, and makes them available to the health site.
• Health site/mobile app (HealthSite or HealthApp): The user-facing website or mobile application an end-user uses to acquire, and possibly store and display, a vaccine credential from the health backend
• Scanner app (ScannerApp): An application that businesses or entities use to validate a vaccine credential

A generalized flow of such systems usually proceeds in the following manner:

• End-user approaches a Vaccination lab, proves their identity to the vaccination lab, and acquires a vaccination/test
• VaxLab communicates/stores result to health backend
• End-user authenticates to HeathApp and acquires a VaxCred
• End-user presents VaxCred to an entity (such as an event venue or restaurant) requiring proof of vaccination, who uses a ScannerApp to validate authenticity of their vaccine credential
• End-user gains access to venue/physical event space on successful validation of their vaccine credential

We assume that the vaccination lab, health backend and HealthApp trust each other, can communicate securely, and store user identity and vaccination status securely. In practice, there may be many discrete labs or organizations communicating vaccine administration information to a public health authority or health backend. Since these interfaces are not generally publicly exposed, we omit discussions about securing these systems in this post.

Understanding Potential Security Threats

We break down possible security threats and concerns by phases of the interaction, namely identifying the vaccine credential system, vaccine credential acquisition, and finally, usage of the vaccine credential to prove vaccination status.

Phase 1: Identifying and trusting a vaccine credential

So far, there is no singular, standard vaccine credential system commonly used or accepted globally, and their use and acceptance varies widely across geographies and purposes. For instance, the NYS Excelsior Pass is used in New York State, whereas EU’s Digital Green certificate is more in use in the European Union. Non-government systems like IATA’s Travel Pass are used by member airlines for certain flight segments. The selection of which vaccine credential system (VCS) to use is largely dependent on the requirements of the particular activity a user wishes to engage in, and generally isn’t a choice for the user. This means an individual might have to be simultaneously enrolled in multiple VCS and have different vaccine credentials to satisfy the requirements of different entities.

Since there is no real “choice” for the end user on which VCS to use, being dependent on the context it is needed, identification of which VCS to use often becomes moot. For instance, let’s say New York State mandates use of the Excelsior Pass as validation to enter a concert venue, and users are expected to acquire a credential before reaching the venue. Users couldn’t really select another VCS as that would not be acceptable proof. the The concert organizers may share a link to the legitimate NYS Excelsior Pass app/website, making finding the the legitimate site easy for end users. There is a small likelihood of a user searching for the VCS themselves, either online on the web or on mobile app stores, and ending up on a rogue site or app seeking to harvest their personal information. This is hardly a non-zero chance possibility, and a quick search on iOS and Android app stores already shows a number of apps which claim to be “vaccine credential passports” and “health credential vaults”, but seem of sketchy provenance.

It’s worth mentioning that – like so many internet-based software systems people have for the last several years been required to use to participate in anything from electronically filing their income taxes, to ordering pizza online from their favorite pizza shop, to car registration, to the purchase of event tickets for many theatres and sports games – this lack of choice means that users are forced to accept privacy and data sharing policies of the specific VCS, without having a say in the matter (other than opting out entirely in participating in the activity that relies upon this system). This is an opportunity of VCS administrators to inspire trust in users by having clearly defined, restrictive privacy policies that reassures users of the privacy and security of their data. Vaccine credentials systems which follow principles of data minimization (i.e. limiting data collection and disclosure to the minimum required to fulfill a specific purpose) are more likely to be trusted and adopted by users.

Phase 2: Acquiring a vaccine credential

Once a user has identified a legitimate health website or mobile app VCS, they would look to actually acquiring a vaccine credential. This is usually done by providing authentication data to the HealthSite to validate the user’s identity. Authentication information may include government-issued identifiers, such as the health insurance number for some systems in Canada and a NemID for Denmark’s Coronapas, or identity verification questions such as for New York State’s Excelsior Pass.

Cybersecurity considerations for vaccine credential acquisition are listed below.

• Security of the connection between the HealthApp and HealthSite: Does the website/application use HTTPS with modern ciphers? Can an attacker eavesdrop or intercept communications between the user’s device and the HealthSite and obtain personal information or vaccination status?
  
• Authentication to HealthSite: How does the HealthSite verify my identity before producing a vaccine credential for me? Can an attacker impersonate someone else and acquire a credential for them? Does the HealthSite inadvertently let an individual ascertain someone else’s vaccination status without their consent, or leverage an information leak that lets them acquire non-public information about another user?
  
• General application security concerns on the HealthSite: Is the HealthSite and supporting infrastructure built with security in mind? Is the HealthSite secure against common attacks such as SQL Injection, Server Side Request Forgery, patched server software, etc. which may be leveraged to compromise the HealthSite or HealthApp?
  
• Secure storage of the vaccine credential on the user device: Is the vaccine credential stored securely on the user device? Can rogue applications or users on the device gain access to stored credentials? Does the app cache excessive information that may be revealed on compromise of the application?

While these fall under common application security concerns, the secure storage aspect of the vaccine credential is worth going into detail. After all, the vaccine credential is something that will be disclosed to external parties for verification – does it really need to be stored “securely”? The answer is, it depends! Depending on what information these credentials contain, and how they are validated, there might be a host of potential attacks and concerns unless the credential is securely stored, which is determined by how securely the system has been designed and built.

Phase 3: Validation and security of the vaccine credential

Not all vaccine credentials are the same; though many use QR-code representation as a means of providing an easy way to visually display and scan credential information, that is not universally true, and the information they hold can be vastly different. The format of the vaccine credential seems to largely fall under two categories:

1. A digitally signed object containing vaccination data, often a JSON payload, or
2. A unique web URL or identifier to an online service that hosts the vaccination information

The Vaccine Credential Initiative’s SMART cards and W3C’s Verifiable Credentials are examples of the former, whereas credentials provided by the Dubai Health Authority are examples of the latter.

There are certain advantages and disadvantages to each approach:

Signed Digital Object:

• Pros:
  • Signed objects can be validated offline, and the ScannerApp does not require a persistent connection to the health backend to verify credentials
  • If well-designed, contains a limited amount of information and will not reveal more if credential is disclosed
• Cons:
  • Information cannot be updated on a signed credential once minted; updates to vaccination status require a new credential
  • If disclosure of cryptographic signing key for credential occurs, it allows arbitrary credential forgery and requires reissuing all vaccine credentials and updating ScannerApps

Unique web URL or identifier:

• Pros:
  • Information referenced by credential can be updated without needing new credentials
  • Individual credentials can be revoked without affecting other credentials or requiring ScannerApp updates
  • Slightly less complicated system to manage; no need to “do cryptography correctly” or manage cryptographic signing keys
• Cons:
  • Requires ScannerApp to be online and have access to the health backend
  • There is additional attack surface exposed in the form of an endpoint that displays vaccination status, and the connection between the ScannerApp and health backend
  • If disclosed, may grant persistent access to vaccination status and/or health records, if the system has not been designed with URL/identifier expiry or revocation in mind

In both approaches, the amount of information disclosed by a vaccine credential is interesting to note from an end user perspective. If I, as an end user, want or need to use a vaccine credential before entry to a physical space, how much information am I disclosing to someone who scans my credential? If I need to flash my vaccine credential to the bouncer at a bar to gain entry, is that equivalent to me showing them my driver’s license for age verification? Or am I revealing more information than what is displayed in the app? Am I inadvertently sharing my email address, or phone number, or some other part of my medical history?

One would assume information in the vaccine credential includes, at a minimum, the user’s vaccination status, and their full name. Many also include the user’s birthdate, or a government-issued identifier; this is used in conjunction with a photo ID, such as a driver’s license, passport, or other government-issued identification, to prove identity of the individual presenting the vaccine credential. A good design principle seems to be one that adheres to data minimization, as mentioned earlier.

This is especially important when you consider the wide variety of businesses and entities that may scan your vaccine credential and ask for accompanying photo ID; whilst most folks have become comfortable with regularly flashing their driver’s license at bars and airports (and in doing so, disclosing their name, date of birth, and registered physical address, among other details), vaccine credentials may be required at a wider range of physical spaces. This could range from your neighborhood convenience stores and chain retail departments to pop-up event spaces; places that mostly never required identification to enter, but now might require government issued or verified identification.

Furthermore, from the perspective of a business or venue validating vaccine credentials, how much trust should I place on the trustworthiness of the credential presented by a user? Is the presented credential provably trustworthy, or is a forged credential? In other words, what guarantees are provided that the individual presenting the credential is the actual owner of the credential, and the credential is genuine and provides me with an accurate status of the presenter’s vaccination status?

With these systems and concerns in mind, let’s talk about possible attack vectors and threats:

• Information disclosed by vaccine credential: Does the vaccine credential adhere to principles of data minimization? Does it disclose excessive information beyond what is required to establish identity and vaccination information?
  
• Privacy and recording credential verification events: A threat related to the above is privacy concerns while displaying your credential to a scanner:
  • Is the ScannerApp caching vaccine credentials or information it scans, which may be compromised in case of ScannerApp device compromise?
  • Is the ScannerApp sharing scan or credential information with third parties?
  • Is the business validating my credential using the “official” ScannerApp? Are they using their own homegrown version or a modified version to keep track of every individual accessing their space?
    
    Remember that these vaccine credentials are largely government-issued or verified in some manner, which means a high confidence in the name and identity of the person displaying the credential. Consider a scenario where an individual shares their vaccine credential and their driver’s license as accompanying identification to a bouncer at a bar; there isn’t a whole lot of additional information provided here, as normally they would display their driver’s license (containing their verified name and details) anyways as age verification proof. Now consider another scenario where the same credentials are needed to enter, say, Joe’s SuperMart. Normally, no identification would be provided, but now, they may be able to record the real name and age of every individual entering their physical space. This subtle increase in “surveillance” is hard to discount completely, and privacy-respecting ScannerApps will refrain from storing this information for longer than it is needed to verify the individual’s vaccination status.
    
• Credential forgery and validation: How is the vaccine credential validated? Could someone create a forged credential without actually have been vaccinated and attempt to bypass checks on the ScannerApp?
  
  • For signed objects, things to consider include:
    • Is the cryptographic signature correctly validated with the right cipher and public key, or could someone forge credentials and bypass validation with a malformed credential?
    • Is the cipher and key size used for signatures resistant to brute force and known attacks?
    • Is the private key used to sign the object securely managed?
    • Is the public key used for verification of the signature securely distributed to the ScannerApp?
      
  • For credentials that use a URL/identifier to an online system, concerns include:
    • Can the connection between Scanner app and online system be intercepted?
    • Is the URL or identifier guessable or enumerable? Could someone list or find credentials in the system?
      

Final Thoughts

These security considerations outlined here are in no way exhaustive, and form a small but important picture of the overall concerns one would have when evaluating the security of a new public-facing health system. Hopefully this exercise helps form the basis of what to consider when using or assessing such systems. NCC Group is looking at the evolution of the systems with great interest, and plans to apply and expand on the threat model above with a look at vaccine credential systems in future posts.