This is Part 2 of a series of posts presenting results of a project sponsored by an SBIR Phase I grant from the US Department of Homeland Security. These posts do not necessarily reflect the position or the policy of the US Government.
In the previous post I described the concept of a rich credential, and how a rich credential issued by an identity source can allow a subject to identify him/herself remotely to a verifier with a key pair, a password, and one or more biometric samples such as facial image, even if there is no prior relationship between the subject and the verifier. That was Solution 1, the first of five solutions that we have identified as possible alternatives to knowledge-based verification in the course of our research project on remote identity proofing.
We have now published a paper on Solution 2. In Solution 1 the identity source was a DMV. In Solution 2 the identity source is a bank.
One reason for proposing a bank as in identity source is that banks are required to know their customers, and are therefore well placed to provide identity services. In fact, banks have been providing identity services in some countries for many years. A credential issued by a bank could be used for many different purposes, such as applying remotely for a mortgage, a job, or a government service. We envision many banks issuing credentials as front line certificate authorities (CAs), backed by a one or more traditional CAs acting as root or intermediate CAs. The banks and the traditional CAs would form a public key infrastructure (PKI) that would allow a credential issued by any bank to be accepted by any verifier.
Another reason for proposing a bank as an identity source is that banks are today, uncharacteristically, at the forefront of technological innovation by exploring ways of using blockchains for a variety of purposes.
The interest of banks in blockchains led us to explore the possibility of using a blockchain to implement the envisioned remote identity proofing PKI. We discovered, to our surprise, that a blockchain with on-chain storage can be used to implement any PKI, with remarkable advantages over a traditional PKI. Most of the paper on Solution 2 is actually concerned with the details of how a blockchain can implement a PKI.
It’s actually very simple. A CA issues a certificate to a subject as usual, except that it does not sign it. Instead, it stores a cryptographic hash of the certificate in a blockchain store that it controls, dedicated to storing hashes of issued certificates. If the certificate is compromised, the CA revokes it by storing its hash in another blockchain store that it controls, dedicated to storing hashes of revoked certificates.
The subject presents the certificate to a verifier as usual. To validate the certificate, the verifier checks that its hash is present in the issued-certificate store of the CA, and not present in the revoked-certificate store. The certificate is backed by a chain of CA certificates, which are issued and revoked similarly. Each CA certificate contains the blockchain addresses of the issued-certificate and revoked-certificate stores of the CA. The verifier finds the addresses of the stores where it must look up the subject’s certificate in the first CA certificate. Then it validates each CA certificate by looking up its hash in the stores whose addresses are in the certificate that follows it in the chain, except for the last certificate, which is issued by a root CA whose stores have generally known blockchain addresses.
A blockchain PKI has the following advantages over a traditional PKI.
First, certificates are not signed. This means that they are shorter, which reduces the time it takes to transmit a certificate backed by a CA certificate chain.
Second, validation of a certificate and its CA certificate chain is trivial. A blockchain being a “distributed ledger”, the verifier has a local copy of the entire blockchain and looks up hashes of certificates in blockchain stores in the local copy, without network access. No signatures need to be verified.
A blockchain PKI solves a longstanding problem of traditional PKIs by not requiring the use of a service that issues certificate revocation lists (CRLs) or responds to online certificate status protocol (OCSP) queries. CRLs can get very big. They must be stored by the verifier and updated over the network on a regular schedule. OCSP checks add network latency to certificate validation, and leak the information that the subject is presenting the certificate to the verifier, destroying the unobservability feature of cryptographic credentials. (See our privacy postures paper for a recap of privacy features of various kinds of credentials and authentication methods.) Too often, if the revocation-checking service is unavailable, verifiers skip revocation altogether.
See also:
- The Remote Identity Proofing page, with links to other materials related to the project.