Notes on Implementing Vaccine Passports

Now that we're starting to get widespread COVID vaccination vaccine passports" have started to become more relevant. The idea behind a vaccine passport is that you would have some kind of credential that you could use to prove that you had been vaccinated against COVID; various entities (airlines, clubs, employers, etc.) might require such a passport as proof of vaccination. Right now deployment of this kind of mechanism is fairly limited: Israel has one called the green pass and the State of New York is using something called the Excelsior Pass based on some IBM tech.

Like just about everything surrounding COVID, there has been a huge amount of controversy around vaccine passports (see, for instance, this EFF post, ACLU post, or this NYT article).

There two seem to be four major sets of complaints:

1. Requiring vaccination is inherently a threat to people's freedom
2. Because vaccine distribution has been unfair, with a number of communities having trouble getting vaccines, a requirement to get vaccinated increases inequity and vaccine passports enable that.
3. Vaccine passports might be implemented in a way that is inaccessible for people without access to technology (especially to smartphones).
4. Vaccine passports might be implemented in a way that is a threat to user privacy and security.

I don't have anything particularly new to say about the first two questions, which aren't really about technology but rather about ethics and political science, so, I don't think it's that helpful to weigh in on them, except to observe that vaccination requirements are nothing new: it's routine to require children to be vaccinate to go to school, people to be vaccinated to enter certain countries, etc. That isn't to say that this practice is without problems but merely that it's already quite widespread, so we have a bunch of prior art here. On the other hand, the questions of how to design a vaccine passport system are squarely technical; the rest of this post will be about that.

What are we trying to accomplish?

As usual, we want to start by asking what we're trying to accomplish At a high level, we have a system in which a vaccinated person (VP) needs to demonstrate to some entity (the Relying Party (RP)) that they have been vaccinated within some relevant time period. This brings with it some security requirements"

1. Unforgeability: It should not be possible for an unvaccinated person to persuade the RP that they have been vaccinated.
2. Information minimization: The RP should learn as little as possible about the VP, consistent with unforgeability.
3. Untraceability: Nobody but the VP and RP should know which RPs the VP has proven their status to.

I want to note at this point that there has been a huge amount of emphasis on the unforgeability property, but it's fairly unclear - at least to me - how important it really is. We've had trivially forgeable paper-based vaccination records for years and I'm not aware of any evidence of widespread fraud. However, this seems to be something people are really concerned about - perhaps due to how polarized the questions of vaccination and masks have become - and we have already heard some reports of sales of fake vaccine cards, so perhaps we really do need to worry about cheating. It's certainly true that people are talking about requiring proof of COVID vaccination in many more settings than, for instance, proof of measles vaccination, so there is somewhat more incentive to cheat. In any case, the privacy requirements are a real concern.

In addition, we have some functional requirements/desiderata:

1. The system should be cheap to bring up and operate.
2. It should be easy for VPs to get whatever credential they need and to replace it if it is lost or destroyed.
3. VPs should not be required to have some sort of device (e.g., a smartphone).

The Current State

In the US, most people who are getting vaccinated are getting paper vaccination cards that look like this:

This card is a useful record that you've been vaccinated, with which vaccine, and when you have to come back, but it's also trivially forgeable. Given that they're made of paper with effectively no anti-counterfeiting measures (not even the ones that are in currency), it would be easy to make one yourself, and there are already people selling them online. As I said above, it's not clear entirely how much we ought to worry about fraud, but if we do, these cards aren't up to the task. In any case, they also have suboptimal information minimization properties: it's not necessary to know how old you are or which vaccine you got in order to know whether you were vaccinated.

The cards are pretty good on the traceability front: nobody but you and the RP learns anything, and they're cheap to make and use, without requiring any kind of device on the user's side. They're not that convenient if you lose them, but given how cheap they are to make, it's not the worst thing in the world if the place you got vaccinated has to mail you a new one.

Improving The Situation

A good place to start is to ask how to improve the paper design to address the concerns above.

The data minimization issue is actually fairly easy to address: just don't put unnecessary information on the card: as I said, there's no reason to have your DOB or the vaccine type on the piece of paper you use for proof.

However, it's actually not straightforward to remove your name. The reason for this is that the RP needs to be able to determine that the credential actually applies to you rather than to someone else. Even if we assume that the credential is tamper-resistant (see below), that doesn't mean it belongs to you. There are really two main ways to address this:

1. Have the VP's name (or some ID number) on the credential and require them to provide a biometric credential (i.e., a photo ID) that proves they are the right person.
2. Embed a biometric directly into the credential.

This should all be fairly familiar because it's exactly the same as other situations where you prove your identity. For instance, when you get on a plane, TSA or the airline reads your boarding pass, which has your name, and then uses your photo ID to compare that to your face and decide if it's really you (this is option 1). By contrast, when you want to prove you are licensed to drive, you present a credential that has your biometrics directly embedded (i.e., a drivers license).

This leaves us with the question of how to make the credential tamper-resistant. There are two major approaches here:

1. Make the credential physically tamper-resistant
2. Make the credential digitally tamper-resistant

Physically Tamper-Resistant Credentials

A physically tamper-resistant credential is just one which is hard to change or for unauthorized people to manufacture. This usually includes features like holograms, tamper-evident sealing (so that you can't disassemble it without leaving traces) etc. Most of us have lot of experience with physically tamper-resistant credentials such as passports, drivers licenses, etc. These generally aren't completely impossible to forge, but they're designed to be somewhat difficult. From a threat model perspective, this is probably fine; after all we're not trying to make it impossible to pretend to be vaccinated, just difficult enough that most people won't try.

In principal, this kind of credential has excellent privacy because it's read by a human RP rather than some machine. Of course, one could take a photo of it, but there's no need to. As an analogy, if you go to a bar and show your driver's license to prove you are over 21, that doesn't necessarily create a digital record. Unfortunately for privacy, increasingly those kinds of previously analog admissions processes are actually done by scanning the credential (which usually has some machine readable data), thus significantly reducing the privacy benefit.

The main problem with a physically tamper-resistant credential is that it's expensive to make and that by necessity you need to limit the number of people who can make it: if it's cheap to buy the equipment to make the credential then it will also be cheap to forge. This is inconsistent with rapidly issuing credentials concurrently with vaccinating people: when I got vaccinated there were probably 25 staff checking people in and each one had a stack of cards. It's hard to see how you would scale the production of tamper-resistant plastic cards to an operation like this, let alone to one that happens at doctors offices and pharmacies all over the country. It's potentially possible that they could report people's names to some central authority which then makes the cards, but even then we have scaling issues, especially if you want the cards to be available 2 weeks after vaccination. A related problem is that if you lose the card, it's hard to replace because you have the same issuing problem.^[1]

Digitally Tamper-Resistant Credentials

The major alternative here is to design a digitally tamper-resistant system. Effectively what this means is that the issuing authority digitally signs a credential. This provides cryptographically strong authentication of the data in the credential in such a way that anyone can verify it as long as they have the right software. The credential just needs to contain the same information as would be on the paper credential: the fact that you were vaccinated (and potentially a validity date) plus either your name (so you can show your photo id) or your identity (so the RP can directly match it against you).

This design has a number of nice properties. First, it's cheap to manufacture: you can do the signing on a smartphone app.^[2] It doesn't need any special machinery from the RP: you can encode the credential as a 2-D bar code which the VP can show on their phone or print out. And they can make as many copies as they want, just like your airline boarding pass.

The major drawback of this design is that it requires special software on the RP side to read the 2D bar code, verify the digital signature, and verify the result. However, this software is relatively straightforward to write and can run on any smartphone, using the camera to read the bar code.^[3] So, while this is somewhat of a pain, it's not that big a deal.

This design also has generally good privacy properties: the information encoded in credential is (or at least can be) the minimal set needed to validate that you are you and that you are vaccinated, and because the credential can be locally verified, there's no central authority which learns where you go. Or, at least, it's not necessary for there to be a central authority: nothing stops the RP from reporting that you were present back to some central location, but that's just inherent in them getting your name and picture. As far as I know, there's no way to prevent that, though if the credential just contains your picture rather than an identifier, it's somewhat better (though the code itself is still unique, so you can be tracked) especially because the RP can always capture your picture anyway.^[4]

By this point you should be getting the impression that signed credentials are a pretty good design, and it's no surprise that this seems to be the design that WHO has in mind for their smart vaccination certificate. They seem to envision encoding quite a bit more information than is strictly required for a yes/no" decision and then having a selective disclosure" feature that would just have that information and can be encoded in a bar code.

What about Green Pass, Excelsior Pass, etc?

So what are people actually rolling out in the field? The Israeli Green Pass seems to be basically this: a signed credential. It's got a QR code which you read with an app and the app then displays the ID number and an expiration data. You then compare the ID number to the user's ID to verify that they are the right person.

I've had a lot of trouble figuring out what the Excelsior Pass does. Based on the NY Excelsior Pass FAQ, which says that you can print a paper Pass, take a screen shot of your Pass, or save it to the Excelsior Pass Wallet mobile app", it sounds like it's the same kind of thing as Green Pass, but that's hardly definitive. I've been trying to get a copy of the specification for this technology and will report back if I manage to learn more.

What About the Blockchain?

Something that keeps coming up here is the use of blockchain for vaccine passports. You'll notice that my description above doesn't have anything about the blockchain but, for instance, the Excelsior Pass says it is built on IBM's digital health pass which is apparently built on IBM blockchain technology" and says Protects user data so that it remains private when generating credentials. Blockchain and cryptography provide credentials that are tamper-proof and trusted." As another example, in this webinar on the Linux Foundation's COVID-19 Credentials Initiative, Kaliya Young answers a question on blockchain by saying that the root keys for the signers would be stored in the blockchain.

To be honest, I find this all kind of puzzling; as far as I can tell there's no useful role for the blockchain here. To oversimplify, the major purpose of a blockchain is to arrange for global consensus about some set of facts (for instance, the set of financial transactions that has happened) but that's not necessary in this case: the structure of a vaccine credential is that some health authority asserts that a given person have been vaccinated. We do need relying parties to know the set of health authorities, but we have existing solutions for that (at a high level, you just build the root keys into the verifying apps).^[5] If anyone has more details on why a blockchain^[6] is useful for this application I'd be interested in hearing them.

Is this stuff any good?

It's hard to tell. As discussed above, some of these designs seem to be superficially sensible, but even if the overall design is sensible, there are lots of ways to implement it incorrectly. It's quite concerning not to have published specifications for the exact structure of the credentials. Without having a detailed specification, it's not possible to determine that it has the claimed security and privacy properties. The protocols that run the Web and the Internet are open which not only allows anyone to implement them, but also to verify their security and privacy properties. If we're going to have vaccine passports, they should be open as well.

Updated: 2021-04-02 10:10 AM to point to Mozilla's previous work on blockchain and identity.

1. Of course, you could be issued multiple cards, as they're not transferable.
2. There are some logistical issues around exactly who can sign: you probably don't want everyone at the clinic to have a signing key, but you can have some central signer.
3. Indeed, in Santa Clara County, where I got vaccinated, your appointment confirmation is a 2D bar code which you print out and they scan onsite.
4. If you're familiar with TLS, this is going to sound a lot like a digital certificate, and you might wonder whether revocation is a privacy issue the way that it is with WebPKI and OCSP. The answer is more or less no". There's no real reason to revoke individual credentials and so the only real problem is revoking signing certificates. That's likely to happen quite infrequently, so we can either ignore it, disseminate a certificate revocation list, or have central status checking just for them.
5. Obviously, you won't be signing every credential with the root keys, but you use those to sign some other keys, building a chain of trust down to keys which you can use to sign the user credentials.

6. Because of the large amount of interest in blockchain technologies, there's a tendency to try to sprinkle it in places it doesn't help, especially in the identity space For that reason, it's really important to ask what benefits it's bringing.

The post Notes on Implementing Vaccine Passports appeared first on The Mozilla Blog.