This website uses cookies to ensure you get the best experience on our website. By using our services, you agree to our use of cookies.

Entries

Digital signatures — blockchain and PKI

29.5.2018 / Falk Borgmann, Strategy Consultant, Deepshore GmbH

The purpose of PKI in distributed networks

A public-key infrastructure (PKI) gives us the ability to use an asynchronous procedure to sign, encrypt, and subsequently verify information. A certificate authority (CA) serves as an intermediary for these transactions and guarantees the authenticity of the public key, making it possible for a recipient of data to validate the transaction’s content. In addition to other possible scenarios, the loss of a private key or a compromised CA are the most critical risks. This raises the question of whether it would be possible to use blockchain technology to provide the functionality of a PKI and possibly also eliminate existing weaknesses.

What do signatures, encryption, and entire PKIs have to do with the blockchain? The two basic functions of a blockchain are to authenticate or process transactions in a distributed network securely, and without a master node. That sounds quite similar to the purpose of a PKI. So it appears worthy of further investigation.

Let’s take bitcoin as an example:

In a Bitcoin blockchain, we could view the public key of a PKI as the account number of a participant. The private key would then be more like the transaction authentication number (TAN) necessary for accessing the balance of the account. The accountholder who wishes to transfer money thus sends what amounts to their account number together with the transaction to the cluster. A big difference between using a PKI and how things work in a typical blockchain, however, revolves around establishing the true identify of participants. We’re not talking about the technical identification here, but rather the assurance that a specific person or organization is actually registered as belonging to a specific technical account. In other words, the public key of a bitcoin “account number” would represent an account whose true owner has not been identified beyond a doubt by any authority within the system. Transactions take place anonymously, even though trust in the processing of those transactions themselves is ensured by the system. The following explanations therefore explicitly ignore CA functionality, which ensures that a key can only be assigned to an actual person or institution. The focus here is exclusively on the technical processing/certification of a piece of data.

In the case of bitcoin, every participant knows the public key of the technical sender. That means every node, by means of consensus, is also theoretically able to carry out the role of the certificate authority and validate a transaction. An attack on a central CA is impossible, since the role of a CA is embedded in the blockchain itself and thus exists n-fold distributed throughout the entire cluster. The real question is instead whether a PKI or CA is even necessary in this case, or whether the theoretical model of a certified message/transaction (digital signature) isn’t in in fact already included in the standard functionality that forms the core of the blockchain. A PKI is based on the assumption that a trusted intermediary is capable of certifying a public key (by issuing a certificate). A blockchain is fundamentally built on mistrust — using the consensus mechanism to determine if and when a transaction is valid. The functionality of a signature that requires certification is thus unnecessary in a blockchain, making the existence of a CA superfluous in this particular use case.

However, a PKI also makes it possible to encrypt data by allowing the sender of a message to encrypt it using the public key of the intended recipient. Only the recipient is able to decrypt a message that has been encrypted using their public key — specifically, by applying the counterpart to it, the recipient’s corresponding private key. In this procedure, the CA is only required to ensure that the certificate of the public key is still valid at time of encryption. The bitcoin example makes it clear that public and private keys are also used or can also be used in a blockchain. This means it is also theoretically possible in a blockchain to encrypt transactions inside the block. This part in theory works exactly the same way as a PKI does.

In both scenarios, it becomes apparent that the private key plays an important role. If a private key is lost within a PKI signature process, it can result in the public key becoming invalid. The owner must then generate new keys and have them certified by the CA (assuming the loss is detected). With encrypted communication, the loss of a private key potentially allows someone who obtains it to read messages stored elsewhere. In a blockchain, the mechanism is similar. Should you for instance lose your private bitcoin key, the balance is also lost. If the key is stolen, the thieves can do as they please with the coins. In the event that encryption is being used, there is now the additional problem that the encrypted data, if it is also being stored in the blockchain, is now fully exposed and free for the taking (if the raw data is stored in the chain, as it is in the case of bitcoin). The attackers can now access any data that has been encrypted in the past, and it can no longer be deleted by the rightful owner.

Conclusion and outlook:

A key characteristic of a PKI is the certified identification of people and organizations who have been issued a certificate for a key. At the moment, this is a service that the blockchain cannot easily provide although proposed workarounds do exist. Some of these approaches include those of L. Axon/M. Goldsmith, “PB-PKI: a Privacy-Aware Blockchain-Based PKI” and “Backing Rich Credentials with a Blockchain PKI” by K. Lewison/F. Corella. The focus here is on the implementation of a PKI within a blockchain or the functional replication of PKI identity verification for participants. None of the currently known approaches completely eliminates the necessity for a master node of some type.

Without this identification of individuals, a traditional blockchain can however still replicate the signature functionality of a PKI for validating transactions. In addition, it provides the benefit that, with the consensus mechanism, no central CA is required, which considerably reduces the risk of an attack on that vector.

It is also possible to encrypt data with a blockchain. The risk of losing a private key exists both in the blockchain and with conventional PKI methods. So long as the chain code contains the encrypted raw data, it is basically presented to the thief on a silver platter. There is generally somewhat less risk with a conventional PKI, since the thief would have to also gain access to the encrypted raw data. In both scenarios, however, the private key must always be stolen. So the actual vulnerability may lie outside of the blockchain implementation. If we separate the raw data from the blockchain and view the blockchain as a verification service, this type of system still adds value over conventional PKI methods.

From our series
»Blockchain — compliance in the business cloud«
Entry 6/7
Share: