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.

Tor is typically used to attain anonymity and preserve privacy online. This is by far the most common and appealing use for it. Most people without such concerns are not likely to ever install a Tor browser on their workstations, and it’s a pity; Tor has at least one additional use-case which is applicable to a much larger audience. This use-case is the prevention of certificate injection when using untrusted network connections.

A few days ago I got a Yubikey. While exploring use-cases for it, it occurred to me that there is a strong case for a mode of operation which is seldom (never?) used by IT departments: using the token while also supporting static passwords for the same services. It is not suitable for everyone, but it is suitable for the security-aware users. I will now introduce Yubikey in a few words, and then explain the purpose of adding support for one-time password to services that already support static passwords, without eliminating the latter.

A few months ago, I wrote about the problem that emerges from having to rely on digital certificates that are issued by Certification Authorities of which we, the relying parties, are not the paying customers. As a result, we rely on the CA (Certification Authority) certification process, while there is no economic incentive for the CA to actually maintain a robust certification mechanism and to justify our trust.

Unexpectedly, this post, titled “The Inevitable Collapse of the Certificate Model”, quickly became the favorite post on my blog, pulling more views than all other individual posts.

One alternative that was suggested is by CAcert.org, a community based certification organization. Here are my thoughts on the ability of such a mechanism to solve the certification problem.

A few weeks ago, I wrote about the inherent limitations of the certification model. This model cannot be expected to provide a solution to the binding of entities to public keys, primarily because Certification Authorities (CAs) have no financial incentive in performing thorough investigation on who they issue certificates to; and often on the contrary.

There is probably more than one solution to this problem. Let us examine one of them: External quality enforcement

Many had high expectations from the SSL/TLS certificate model. At least on paper it sounded promising and worthwhile. Keys are used to protect traffic; for this to be effective, keys shall be bound to business entities; for the binding to be trustworthy by the public, binding will be signed by Certification Authorities (CAs), which the public will recognize as authoritative. Once the trusted CA signs the binding between a business entity (represented by a domain name) and a key — every user can tell he is communicating securely with the correct entity.

In practice, it got all messed up. It is difficult to form authorization hierarchies on the global Internet, this is one thing. However, the model failed also due to the economics behind it.