Blockchains/Ledgers and Vaccine Passports

Posted by ekr on 29 May 2021

Via Gareth T. Davies I see that IBM has posted a whitepaper on their "IBM Digital Health Pass" system on ePrint. It's a white paper not a complete specification so some of the details are kind of sketchy, but at a high level it's similar to the kind of design I talked about and that used by the Vaccine Credentials Initiative (VCI): a digitally signed credential with the user's health status (vaccination or testing status). Unlike the VCI system -- at least as being deployed in their pilot -- the signing keys are contained in X.509 certificates which chain up to a set of trust anchors stored in a "Trusted Registry", which is implemented via a distributed ledger, specifically Hyperledger.

The Trusted Registry #

Here's the description of the Trusted Registry:

Trusted Registry is an entity controlled by (one or more) Administration Authorities. Its objective is to maintain and provide upon request public metadata of authorised Issuers, as well as Health Certificate revocation information that are crucial for the secure verification of Health Certificates. The Trusted Registry implements the following functionalities upon properly authorised requests:

This seems like the wrong architecture for a system like this as an online service of this type is neither necessary nor desirable: Once the trust anchors have authorized the issuers (i.e., given them a certificate) there's no need the trust anchors to do much of anything [Yes, I know about revocation; see below). In particular, they don't need to regularly be part of the verification process, because the credentials they supply to the issuers (i.e., certificates) are self-contained and can be verified without contacting the trust anchors at all. The same thing is true for the credentials issued by the issuers: they too are self-contained (as long as they contain they issuer's certificate). A verifier can just take the entire credential and verify it offline. This has obvious advantages both for the verifier -- they don't need to be online -- and the operator of the system -- they don't need to offer high availability.

Revocation #

It's true that in a system like this, revocation of issued credentials may have to be done online. On the other hand, it's not clear how much we need revocation: the stakes of falsely accepting a single misissued vaccine credential are quite low, comparable to letting someone with a fake ID drink at a bar, and we just accept that risk all the time. It's worth noting that physical credentials such as driver's licenses are largely unrevocable as far as ordinary people are concerned, and yet we happily accept them as identification in all sorts of contexts.

Even if we decide we do need vaccine credential revocation, it's not clear why you need some trusted registry involved. In a conventional PKI system, the entity which issued the certificate (in this case the Issuer) is responsible for publishing revocation information. This makes sense because they are the ones who generated it. Of course, it might be inconvenient for them to actually host the servers which distribute that information; it's not uncommon for WebPKI CAs to use content distribution networks to distribute their certificate status (OCSP) information, but it's important to realize that the OCSP responses are signed by the CA and so you don't need to trust the CDN. Similarly, the system described here could have some sort of revocation information distribution service, but it's just a convenience and doesn't have to be trusted.^[1]

There is one case where we probably do need some sort of revocation: if a trust anchor or issuer key is compromised it can be used to issue a lot of fake credentials. However, this can be easily handled by some sort of centralized update system like OneCRL that just updates the apps. This kind of large-scale revocation happens quite infrequently, so again there's no need for a high availability service; it's probably easier for each app just to update itself, as browsers do now.

What are we trusting the registry for? #

The general argument offered by the white paper is that implementing the Trusted Registry via a ledger reduces the risk of compromise/misbehavior:

More specifically, IDHP security relies on the assumption that the trusted registry will update issuer metadata and health certificate revocation lists according to authorised issuer and administration authorities requests. Moreover, IDHP security provisions rely on the fact that the trusted registry will respond to verifier queries correctly, i.e., in accordance to the content of the registry.

First, as I said above, you don't generally need a service in the first place because the certificates are self-contained. Second, because the objects in the system (certificates, CRLs, etc.) are signed, the registry doesn't need to be trusted to respond to verifier queries "correctly". It can choose not to respond at all, thus creating a denial of service condition, but if it responds with false information, then that information will be rejected by the verifier because the signature doesn't validate.^[2]

Clearly, one could implement the trusted registry as a robust, but centrally controlled service. This would still position the trusted registry as a single point of failure for IDHP: if the single entity that controls the registry is compromised, then the answers of the trusted registry to verifier queries can no longer be trusted, and the system would no longer be able to accurately assess health certificate validity.

The IDHP Trusted Registry is implemented using permissioned Distributed Ledger Technology(DLT), as we wanted our registry to provide resistance to authority missbehavior/compromise by shifting the functional responsibility to the system’s stakeholders, while at the same time ensuring that these stakeholders would enjoy full control over the system’s governance (adding new members, upgrade functionality, etc.). Figure 4 demonstrates IDHP interactions with a decentralised Trusted Registry.

To be honest, I'm having a lot of trouble making sense of this argument. Forgetting about the technology, let's just look what the trust relationships are here.

At the end of the day, the verifier has to trust some entity or set of trust anchors (what the IDHP calls them "Administration Authorities") to authorize some other entities (e.g., clinics) to issue vaccine credentials. The white paper is vague on who the Administration Authorities are, but it seems likely that they are governmental or quasi-governmental because we want everyone in a given jurisdiction to have the same set of trust anchors and thus trust the same set of issuers. Within a given jurisdiction, the trust anchor(s) are essentially authoritative for who is a valid issuer. For example, suppose that California ran a vaccine passport system with the California Department of Public Health (CDPH) actually operating the trust anchor. They would be responsible for authorizing Walgreens, CVS, etc. to actually issue people's credentials.

So at one level, it's trivially true that authorities who misbehave are a threat to the system. If the CDPH decides to authorize the Educated Guesswork COVID Clinic to issue vaccine credentials even though actually we don't actually give out any shots. But there's this is very difficult to stop technologically because the actors in the system generally don't know that I'm not operating a real COVID clinic: after all, the state could have set one up at my house, they just didn't and have decided to lie about it. It's true that there are other stakeholders in the ecosystem (e.g., the State of Oregon) but their opinions aren't relevant as to whether California has authorized me to run a clinic. The point here is that the trust relationships here are inherently centralized and trying to map them onto a decentralized technology doesn't change that.

The usefulness of a ledger #

Even if we are concerned about this kind of misbehavior and want to stop it, it's not really clear that putting the data in a ledger helps much: the primary service that a ledger provides is "consensus", ensuring that everyone agrees on a specific set of data, but that's not really that important here because CDPH's opinion is the only one that matters. All you need to know in order to know whether to accept a credential from a given issuer is that the state says that that issuer is valid.

There is one semi-useful property of some kind of ledger-type structure, but it's not really that applicable here: if every piece of information published by the trust anchors is public, then it in theory allows for third parties to detect cheating. For instance, one could download the list of all of the valid issuers and look to see if any of them looked fishy (e.g., "I live in this neighborhood and there is no clinic here", or "I went to the clinic and they're injecting people with Tailwind rather than COVID vaccine). But the risk of this seems comparatively low and it's not clear how you'd have a scalable way of detecting these cases, as there's no canonical public list of real clinics.

The WebPKI uses a similar system called Certificate Transparency, to detect fraudulent issuance of WebPKI certificates, but it seems like this is of fairly modest benefit in this case, for several reasons: first, unlike the WebPKI, there aren't going to be that many issuers and the procedure for registering them with the health authorities is going to involve a fair amount of official paperwork even before we get to the vaccine passport piece of the equation -- after all, it's not like anyone can order up a couple boxes of vaccine and start giving shots -- so this makes it easier to have a secure procedure for authorizing them. In particular, you can have the actual trust anchor signing key offline, making compromise much less likely. Second, a transparency scheme isn't helpful for detecting misissuance of the patient credentials themselves: for obvious reasons you don't want to publish the names of people who have been certified as vaccinated.^[3]

Summary #

The bottom line here is that this seems like a far more complicated design than is necessary. It's straightforward to build a PKI-based system that doesn't require the verifiers to contact any online service. Even if you did want to have an online service, as in the VCI prototype, then it's not clear what a ledger adds in terms of security or resistance to misbehavior. To repeat what I said above: what ledgers primarily provide is consensus, but as far as I can tell, this system doesn't needs that and so it's just a bunch of added complexity (more generally, "does this require consensus" is is one of the questions you should ask yourself whenever someone proposes using a blockchain/ledger for something).