Certificate security and privacy enhancements using blockchain

Certificate security and privacy enhancements using blockchain

I was recently issued an electronic certificate of appreciation for an event at the Philippines SEC. The certificate was created using an nChain tool that uses the blockchain to solve two problems:

1. To know when the certificate was issued even when private keys are compromised (security).
2. To check the live status without asking the issuer (privacy).

Let’s explore both problems, starting with issuance.

Most digital certificates contain a timestamp that records when the certificate was issued. This timestamp is secured using a digital signature from the issuer. We trust the issuer through a hierarchy of certificate authorities organised in a Public Key Infrastructure (PKI). This is a widely used and efficient security model that underpins the security of many complex systems such as the internet, for example. We should be very cautious about replacing such a system, but we can consider complementary security enhancements.

One vulnerability of PKI is that if the private key of any one of the certificate authorities is compromised, then fake certificates can be issued with backdated timestamps. This can have very severe consequences such as the DigiNotar attack in which fake certificates were issued for Google. To this day, no one knows for sure when the attack began and which certificates were real or fake.

This is not the case for my certificate. A record of issuance was embedded in a blockchain transaction published in a block on August 29th, 2023. This provides an independent and immutable timestamp of the certificate’s existence, which implies that the certificate must have been created before or on this date. The security of this timestamp relies on the blockchain’s consensus mechanism, which in proof-of-work blockchains such as Bitcoin involves hash functions only, and not digital signatures. Even if the private key of the issuer is compromised, the attacker will not be able to fake a blockchain record with a timestamp of August 29th, 2023. Therefore, my certificate has an additional security feature that complements and enhances the security of existing PKI without requiring modification.

The question of whether a certificate is valid right now is technically much harder. After all, certificates can be revoked at any time. It could be revoked by the issuer, the user, or some other authority. This might happen because the user has been put on a blacklist, because the user no longer wants a service, or if a certificate authority higher-up in the PKI has become compromised. Typically, one needs to go back to the issuer and ask specifically ‘is this certificate still valid?’ This introduces a technical overhead and loss of privacy.

We solve this problem using a novel certificate revocation system described in this paper. It works by linking the certificate status to the spent status of a blockchain output. (We use an output in the same transaction that recorded issuance.) The issuer can revoke the certificate instantly by spending this output. We can also use more complex spending scripts that allow for flexible revocation models, for example, by allowing both the user and the issuer to revoke the certificate using a 1-of-2 multisig scheme.

A blockchain transaction recording certificate issuance in output 1 and certificate status in output 2. The certificate is valid if output 2 is not spent.

Whilst the nChain tool displays my certificate’s live status, revocation can be confirmed by directly querying the blockchain network and checking the transaction status. This can be done independently of nChain — it is as easy as asking whether a blockchain transaction has been spent or not. Nodes can be queried directly using services such as Merchant API (mAPI), or one can use third party tools such as this, which query nodes on behalf of users.

High-level architecture of certificate status checks using the blockchain.

This offers a single source of information and an enhanced privacy model for certificate status checks. For example, a background check could be performed on a job candidate without asking their current employer for their employment status.

Finally, note that in the on-chain record of my certificate it is not the certificate itself that is on-chain, just a record. In this case, it is a plaintext string with the certificate name and ID, for demonstration purposes. But it could just have easily been a hash commitment. This would be completely private to anyone looking on chain. This also means the protocol can be immediately applied to popular certificate formats such as X.509.

In a Web3 world we are looking for ways in which certificates can be issued easily and can be used privately. Nevertheless, security should not be compromised. It is problems like this that we enjoy solving at nChain.

This is the second in a series of blog post on Web3 technology developed by nChain. A shorter version of this blog was published in a LinkedIn article.