Skip to content

COVID vaccination certificates done almost right

Israel is probably the most advanced to date in terms of COVID19 vaccination. With more than one third of the residents fully inoculated, life can almost get back to pseudo-normal. This, however, requires being able to tell the vaccinated people apart from those who are not. The green pass, or vaccination certificate, is made to achieve precisely that. Technically, this government-issued certificate is not substantially different than a driver’s license, just that it’s shorter lived, can be stored in a phone app, and most importantly: was designed in a hurry.

For something that was launched so quickly, it seems to be decently architected, but slightly better work could still be done to protect that piece of attestation that is so critical to public health.

What do we require of a vaccination certificate? Not much, really. It obviously needs to be as secure as it could be made under the strict cost and distribution constraints. The certificate has to also be easily renewable (it currently expires every six months), and it has to be verifiable by a wide range of checkpoints with varying capabilities. Finally, verification has to be both reliable and fast; entry into a shopping mall cannot resemble passport control, and people cannot arbitrarily be locked out of key facilities just because of simple IT downtime.

The certificate itself is sent to its holder by e-mail (or via a web-site), to be printed at home. There are no measures that could be taken to prevent anyone with Microsoft Paint from crafting fake such certificates. The digital part of the vaccination certificate, i.e., the QR Code printed on it, is the only part of the certificate that can practically be used against forgery.

See the following write-up as a quick guide to cheap-but-secure attestation certificates; for COVID or otherwise.

Properties of an attestation certificate

Formal definitions aside, the vaccination certificate, in our case, is a ‘secure’ attestation that conveys a message like:

“The Ministry of Health hereby attests that it considers The Holder of this certificate to be vaccinated, until 2021-08-01.”

For such an attestation to have any value, the verifier (or ‘checker’) has to be convinced that:

  1. The Ministry of Health indeed issued this attestation (i.e., it is not fake), and that the attestation is what the Ministry of Health intended it to convey, including the reference to The Holder and the expiry date. Nobody should have been able to change anything.

  2. The person who presents this attestation is indeed The Holder that the Ministry of Health refers to. This is not the same as the previous bullet; when this is violated, the certificate could be entirely valid, just presented by the wrong person.

How do we usually provide those two promises with paper certificates?

  1. The first item is achieved by tamper-proofing the paper artifact of the certificate. We can use a special type of paper, holograms, special lamination, etc. All this is far from perfect, but it puts some barrier against the creation of a fake certificate or the change of the details on a real one.

  2. For the second item, there are generally two types of ways to assure that the person presenting the certificate is indeed the one to whom it was issued:

    1. The first way is by including a photo (years ago there was also a fingerprint image) to be recognized by a human gatekeeper, or by including biometric data to be used by a reader at the checkpoint.

    2. The simpler way is by linking to an existing ID, such as by referencing the name and/or a serial number of the assigned holder. This requires the holder to also present a photo ID bearing that same name (and/or serial number) that appears in the attestation certificate.

All this works well, but just as long as both of those requirements can be met.

Home-printed certificates

Vaccination certificates are issued en-masse, in a short time, and very frequently. They need to be quick and cheap to issue. The best workable way to issue such certificates is by sending them electronically to their holders, either as a PDF file for the holder to print at home, or as a mobile phone application. None of the provisions of the first item above (on protection against forgery) can apply here. Anyone can create his own PDF file by editing a legitimate one. Even if the PDF is protected from editing, it can easily be converted into an image and edited using any one of many (some free) photo editing tools. The result can then be printed out, making the fake hard to tell.

(I am amazed by the negative criticism some people sound against those certificates, noting their susceptibility to forgery as if it was big news. I wonder if anyone seriously thought that a PDF you print at home could possibly be any better, even in theory. Systems do not need to be ‘secure’; they need to be secure enough for their cause, under their circumstances. In light of the text that follows, I believe that those certificates can meet this requirement, and perhaps already do, if just used properly.)

A possible remediation to the ease of forgery is by properly using the digital version of the certificate.

Digital version

The digital version of the certificate is essentially a QR Code that is printed on the certificate, or displayed by the mobile phone application.

It is clear how integrated smartcards can protect against forgery, credit cards use them for years, but a smartcard is a silicon chip that is embedded into plastic; it’s not something you print at home. How could a QR Code, which is merely a chunk of information that is printed on paper (not substantially different than the other letters and digits), help protect against forgery?

A QR Code isn’t more than much text printed on paper, in a form that machines can read quickly. But still, the fact that it can convey much information from the paper to a checker machine quickly and without typing, can help that checker (a.k.a., ‘the verifier’) detect forgery.

There are two ways in which this can be done.

Method #1: Certificate ID for online checking

The simple way is to include in the QR Code some unique serial number of the attestation certificate. The checker will read this Certificate ID off the QR Code, connect (over the Internet) to a system maintained by the Ministry of Health (the ‘responder’), and ask about this Certificate ID. The responder will check in its database if a certificate bearing this ID has indeed been issued, and will respond with either of the following answers:

  • GOOD: Yes, a valid certificate was issued with this ID, to Holder X with expiry Y.

  • BAD: No, this ID is not recognized, or has expired.

Before considering the presenter of the certificate as vaccinated, the gatekeeper will make sure that the response is ‘GOOD’, and that the details returned by the responder (X, mainly) match those written on the paper certificate and more importantly – on the person’s ID.

The QR Code did no magic here. The same Certificate ID could be read by the human gatekeeper and typed into a terminal, but that would take too much time and be too error-prone to be useful at a checkpoint. The QR Code made it practical.

You might as well ask: why not send all details from the certificate (via the QR Code), to the responder, so it can just respond with ‘GOOD’ once all details of the query match those that are on record? That would allow the gatekeeper to just read the paper version rather than confirm those details against the response from the responder. Unfortunately, a person who forges a certificate could forge it so the details on the QR Code match the Ministry’s records (possibly of a real vaccinated person), while the printed name is his own. The QR Code will pass nicely, but the wrong person will be admitted. There is no way for the human gatekeeper to notice that the QR Code and the printed name do not match, so the gatekeeper needs to just ignore the printed name.

Method #1 is simple and quick, but it has one major drawback: it relies on the responder being attentive, and it requires the whole process to be sufficiently quick. Fundamentally, it requires a reliable Internet connection to operate at all times when people need to be admitted.

Method #2: Digital signatures

Without getting into any technical discussion on Digital Signatures, a digital signature is a piece of information (which could be conveyed over a QR Code), which forms a robust checksum that can only be generated by a certain recognized entity and yet can be verified by anyone. It is a checksum that any checker can verify, but which only one entity (in this case: the Ministry of Health) can produce.

Attaching such a digital signature ‘checksum’ to the rest of the data conveyed over the QR Code, will enable the checker machine to ascertain that the data on the QR Code was indeed generated by the Ministry of Health, and that it has not been altered. This essentially carries the same effect of contacting a responder and asking for the status, just that no communication, or responder, is needed. Once the checker machine is ‘taught’ to recognize the signatures of the Ministry of Health, it can locally verify any QR Code payload data it is faced with, entirely autonomously.

This method, as opposed to Method #1, may not cope well with situations in which the Ministry of Health issues a certificate and then changes its mind and needs to revoke it after issuance. This, however, is a rare event, with implications that are well contained given that each such certificate lasts only six months anyway before it naturally expires.

Finally, one can combine this Method #2 with Method #1: the checker machine could query the Ministry of Health online, but if the Internet connection has dropped, or a response does not arrive on time, the checker machine could revert to checking the signature locally.

The method used by the Israeli Ministry of Health

The Israeli Ministry of Health seems to favor Method #1. The QR Code on the vaccination certificate contains the following data (values are imaginary, but the structure is real):

{
"idType": 0,
"idNum": "012345678",
"certNum": "B52AC64C",
"fullName": "John Smith",
"immunedSince": "02.01.2021",
"expirationDate": "01.07.2021"
}

There is no digital signature field here, so the checker machine has no means of ascertaining the authenticity or integrity of this data. All it can possibly do is take the unique Certificate ID (in this case: B52AC64C), connect to the computer of the Ministry of Health, and ask for the validity and details for the certificate with this ID.

This is not bad (given it is done, of course). If I designed this system, however, I would use Method #2, perhaps combining it with Method #1. This way, a fresh response could be used from the computer of the Ministry of Health, but proper verification can also be carried out if the Internet is down, or if the computer of the Ministry of Health is not responding fast enough. I realize that many checkpoints may operate without fast connectivity at all.

Method #1 is not less secure, but it is way more fragile, as it relies on fast Internet connectivity and on a responder computer that is up and running with no interference, which is very hard to accomplish. Unfortunately, fragility often means insecurity. Anyone can think of scenarios where system downtime will result in people being admitted without proper verification. (I am not even referring to more esoteric situations where the downtime is actually caused by people who want to be admitted without being certified.)

Of course, I am also assuming that this responder service is at all being made available by the Ministry of Health, to support Method #1. If no such responder exists, then there is no way to check vaccination certificates, and the entire system is worth even less than this post.

There is yet another important point. Since the QR Code was designed to work by Method #1, there is no use for all those details of the certificate in that QR Code. All the checker machine needs for its query is the certNum field. The rest is redundant, because the checker is only allowed to treat as valid the details as they come from the responder. Since those values are not useful, and moreover, since those values shall not be used, we are better off if they are not included in the QR Code in the first place. If they are, then there will likely be an implementer of a checker machine that will prefer showing the details as they appear on the QR Code instead of those arriving from the responder, “because it is faster”, not realizing that this information cannot be trusted. There will also be the implementer who will fallback into displaying those details from the QR Code as valid if there is no response from the responder. If the responder does not answer, the right verdict coming from the checker machine should be “I don’t know” (and let the human gatekeeper deal with it), rather than provide false-sense of security by presenting data from the QR Code that appears authentic but which could not be verified. If the certificate data did not appear in the QR Code in the first place, then a checker machine that does not know the real answer on validity would not be able to display something misleading instead.

My main concern with those vaccination certificates is not that the system is insecure by its core design, but that it might be deployed improperly. A good secure system design shall attempt to make such abuse impossible; or at least less tempting.


See also

Trackbacks

No Trackbacks

Comments

Display comments as Linear | Threaded

Yuval on :

A very interesting read, thanks. Seems like both solutions would still require the verifier to manually compare the idNum against the user's ID card and then see that the picture on the card matches the person. This might be suitable for airports but less to theatres. A further advantage of option 1 is that it could include a picture of the holder in the response.

Add Comment

Markdown format allowed
Form options

Submitted comments will be subject to moderation before being displayed.