Analysis of Revocation Mechanisms for Blockchain Applications and a Proposed Model Based in Self-Sovereign Identity

Introduction

In 2009 with the emergence of the Bitcoin application (Nakamoto, 2008), the world became aware of the blockchain, a disruptive technology capable of offering several properties, such as immutability, privacy, reliability, and security. Although distributed systems are commonly used and well understood, the blockchain proposed mechanisms for applications to operate in a decentralized manner, without a single point of failure, forming a new type of application, the Decentralized Autonomous Organization (DAOs). Companies created under this new model have their business supported by algorithms, and often the code represents all the company's assets   (Diedrich, 2016).

As Tapscott and Tapscott (2016) noted: "It is not the Bitcoin, and its speculative assets, that should interest you". The blockchain has been applied in several other areas (Drosatos & Kaldoudi, 2019) (Tse et al., 2017) (Goranovic et al., 2017), which confirms the technology's potential in applications beyond cryptocurrencies. However, the use of blockchain in different types of applications has shown that a revocation functionality needs to be worked on. Contrary to the main characteristic of the blockchain (e.g., immutability), a revocation operation can be a very complex and costly task in this type of system. Although some initiatives (Grigoriev & Shpilrain, 2021) (Ateniese et al., 2017)(Florian et al., 2019) allow blockchain redacting or erasing data, these solutions are not compatible with the current blockchain technology. We call the blockchain operation that cancels or reverses a transaction "revocation" because the blockchain data cannot be erased.

The Bitcoin and other cryptocurrencies were not based on the idea of canceling an operation, on the contrary, the idea was to offer a structure that would not allow changes that had already been confirmed by the network. In that way, the blockchain infrastructure is designed to not be modified. If a correction is to be made to previously stored information, it cannot be performed.

The figure 1 illustrates this statement. The image shows in a timeline changes that occurred in the Bitcoin and Ethereum networks. In the case of Bitcoin, the programmers attempt to increase the block size from 1MB to 8MB, resulted in the creation of a new network, Bitcoin Cash (Javarone & Wright, 2018). Another hard fork example occurred in October 2017, when Bitcoin Gold was created. The change consisted of modifying the current consensus mechanism Proof of Work (PoW), to work more lightly, with less processing needs (Hanke, 2016).

Figure 1 Blockchain Forks

As can also be seen in figure 1, a big change occurred on Ethereum. In 2016 the DAO application,  which stored thousands of dollars worth of currency assets,  suffered an attack and had about 50 million dollars stolen (Siegel, 2016). Faced with the impossibility of revoking such operations, even knowing they are fraudulent, the developers decided to fork the network, creating a new cryptocurrency, thus isolating the stolen operations on the old network.

These facts show the difficulty of building a solution capable of allowing revocation operations on an immutable and complex environment. Besides, not all blockchains work using the same resources, which makes the design of a compatible solution for all networks even a harder task. The community classifies blockchain applications into three categories, 1.0, 2.0, and 3.0. Categories 1.0 and 2.0 are related to cryptocurrencies or financial applications. The third classification is more extensive, being used in another kind of applications (di Francesco Maesa & Mori, 2020).

Although these examples show the big challenge to revoke credits in applications 1.0 and 2.0, in this paper we present a revocation model that supports several applications 3.0 that would benefit from the proposed functionality, without changing the existing blockchain system credit. The model we present approaches the revocation problem by creating a reverse link and a data revocation scheme.

Our experiments were related to the education area (i.e., issuing, sharing, and revoking academic certificates), however we observed similarities with other kinds of applications. These could benefit reusing the same model and approach.  For instance, in the supply chain area, the contracts management can be improved, allowing the transfer of ownership safely.  In healthcare area, families can take control of their records member, avoiding that sensitive data being revealed. In the financial area, invoices could be revoked by a legal entity (i.e., in case it was the private key stolen).

This paper is organized as follows: the next section presents an overview of the concept of revocation; then, the existing approaches that address revocation are shown; after, we demonstrate our model; and finally, the conclusions of the paper are presented.

Revocation Background

Revocation is a term used in the legal field, which means ending the validity of a rule (Sgarbi, 2014). It is commonly used in digital certificates' life cycle. After all, it marks the end of life of the digital object because it expired or was compromised, and at the same time keeps the proof of its existence alive (Vigil et al., 2015). The same term is applied to the blockchain system due to the nature of these networks that consist of preserving records permanently.

As soon as the digital certificates based on Public Key Infrastructure (PKI) emerged, the need for dealing with the revocation issue was noticed, in a way that a good solution to the problem would be crucial for the widespread acceptance of the technology. The responsibility for this task was up to the Certificate Authorities (CA), which needed to provide a reliable revocation service, and to publish a suitable privacy policy (Jain, 2002).

Several mechanisms for revocation were proposed, such as Certificate Revocation List (CRL), Certificate Revocation System (CRS), Certificate Revocation Tree (CRT), On-line Certificate Status Protocol (OCSP) and Certificate Space Partitioning With Renewals (CSPR) (Walleck et al., 2008)(Goyal, 2007), in which the CRL and OCSP (Q. Wang et al., 2020) methods stood out. The CRL method consists of creating a kind of blacklist, built based on the scheme definition which is signed by a CA, and published periodically. In the list, the certificates are identified by their serial numbers and attached to a timestamp to control their validity. The OCSP method was developed by Internet Engineering Task Force (IETF) and consists of a protocol used to identify the validate status of a certificate. It is a client-server structure.

As in the PKI structure, the revocation is also an important matter which contributes to the expansion of the blockchain networks applications. However, the solution is much more difficult to be built because a CA that, for example, controls a list or defines a server similar to the OCSP format, can not be considered. This is because the most important benefits offered by the blockchain network would be lost (e.g., decentralization). The Massachusetts Institute of Technology (MIT) tried to implement in its Blockcert application a revocation approach based on CRL, but had, as a result, a centralized solution, which compromised one of the main benefits offered by the blockchain, self-sovereignty (Rujia & Galind, 2017) (Santos & Duffy, 2019) (F. Vidal et al., 2019) (F. R. Vidal et al., 2020b) (San et al., 2020). Because of that, the Blockcerts community has been discussing the matter in an attempt to find an alternative approach to the problem (Ronning & Chung, 2019).

Given this brief comparative analysis between the digital certificates revocation and blockchain registrations, it is clear that new approaches need to be explored since the revocation solutions offered by PKI do not meet the requirements of the blockchain. One approach to this revocation problem in blockchain systems, for example, could be the use of multi-signatures.

This technique is known in the world of public-key cryptography, which allows several parties to digitally sign a combined message, using their private keys (Gilboa, 1999). The concept is commonly used in cryptocurrencies (Zhou et al., 2016), using the expression M-to-N, where M represents the minimum number of signers and N the maximum number of keys involved. The blockchain application EduCTX uses this multi-signature feature to control an entire ecosystem of universities, which vote among themselves to revoke the participation of a member of the (Turkanović et al., 2018) network.

In the next section, some of the approaches to the revocation problem in blockchains are presented.

State of the art

The following describes some of the works that proposed specific revocation mechanisms for the blockchain technology in different applications. First, some works related to the secure communication area on the internet are presented, then approaches in Internet of Thing (IoT), and finally solutions for the academic area.

CertLedger

CertLedger (Kubilay et al., 2018) is a type of PKI solution which uses blockchain technology to remove the dependency of the CAs over the Transport Layer Security (TLS) certificates (Dierks & Rescorla, 2008) (A. Freier, P. Karlton, 2011), used to create a secure communication of a channel. Its functionality is inspired by the Google Certificate Transparency (CT) solution (Laurie et al., 2013), in which a log mechanism using Merkle Hash Tree (MHT) is implemented, allowing batch verification of certificates. The benefit of the Certledger approach in comparison to the Google solution is in the decentralized distribution of these logs. Taking as an example the Bitcoin, a 51% attack type, which would be able to give total control of the network, would be extremely expensive and could cost even 500K dollars per hour of processing (Saad et al., 2019).

The CertLedger publication also presents a systemic view of several mechanisms based on PKI, describing how each solution tries to decentralize the CA functions, such as the certificate revocation. Unlike the approaches evidenced by the works mentioned (Eckersley, 2012)(Laurie et al., 2013)(Ryan, 2014)(Kim et al., 2013), CertLedger applies the use of blockchain technology. As a result, there is the elimination of Man-in-The-Middle (MITM) attacks, and also the gain in transparency in the revocation processes.

Figure 2 Certledger Architecture (Kubilay et al., 2018)

As shown in figure 2 digital certificates are represented by objects and their status. Each object has its unique blockchain address. The states of these objects are controlled by a smart contract and are stored on Ethereum, a blockchain network. Since TLS certificates are stored in the blockchain the browser verification can be executed independently. The query of the state in the object's address can return a status of valid or revoked. Certificate owners also gain autonomy because they can revoke the certificate without relying on CA.

Blockchain Revocation Transparency (RT)

The work proposed by Z. Wang et al. (2019) consists of a solution that uses blockchain technology, but keeps the compatibility with the X.509 standard for certificates.  Its contribution is related to offering greater security for the  Secure Sockets Layer (SSL)/TLS communication channels. The mechanism allows clients (e.g., browsers) to query public immutable logs, which contain status information from secure servers.

The idea is very similar to the Certledger solution, in which certificates are published on a global blockchain network. However, this model is more extensive because it includes both SSL and TLS protocols instead of only TLS. Besides, this proposal is backward compatible with the  PKI scheme, such as the CRL and OCSP mechanism.

The provided immutable certificate database allows clients to monitor the status of a SSL/TLS server, checking whether the certificates used have been revoked, or are still valid. Although less usual, the CA itself can also be validated.

In comparison to Certledger and other works based on Ethereum (Matsumoto & Reischuk, 2017) this solution is not anchored to a specific blockchain and demonstrates the concern to provide a public log structure, which can be published on most types of blockchain. The use of multi-signatures is also presented and applied to a set of web-services (called certifiers), which validate the entry of a new server on the network.

Figure 3 Certledger Architecture (Awaji, Solaiman, & Albshri, 2020)

As shown in figure 3, the model proposes the use of two types of transactions. Type II transactions act like a header that manages all other data. The name of the server is registered by its Domain Name System (DNS) name, and all of its certificates are included in type I transactions. If there is a need to revoke all certificates, all is necessary is to cancel the type II transaction. If it is necessary to cancel a single certificate linked to that server, a new type I transaction will be created, excluding the referred group certificate. Besides, a CRT list or a  OCSP server will be updated, recording the fact that this last operation is only to maintain the system's compatibility.

To validate the model, the prototype was implemented on an Nginx web server, and a Firefox browser was used.

Certificate Revocation for 5G IoT

The work of Hewa et al. (2020) presents a revocation proposal in the context of 5G communications. The reduced storage space of IoT devices demands that each implemented resource be optimized about the storage space used. In this aspect, the blockchain contributes to the problem offering the asymmetric cryptographic algorithm of elliptic curves, which results in secure (Mahto & Yadav, 2017) (Gura et al., 2004) (Singh et al., 2016) (Mahto & Yadav, 2018) and smaller(Hankerson et al., 2004) keys. In this work, Elliptic Curve Qu Vanstone (ECQV) was used in the certificates that sign the operations. 

The purpose of the work is to automatically revoke a certificate used to record operations of a IoT device on the blockchain using a smart contract. However, unlike the Certledger in which Ethereum was used, this solution uses the Hyperledger Fabric (Cachin & Vukolić, 2017) technology.

The software uses a smart contract to categorizes the threats, and create scores for them. If the score is greater than the predefined parameter, the certificate is automatically revoked. The reasons for revocation and the certificate history data are recorded and published on the blockchain for future investigations.

Revocations for academic certificates

As observes Schär and Fabian (2019), academic certificates are useful only if they can be verified. Blockchain has brought great innovation to diplomas (Awaji, Solaiman, & Albshri, 2020) (Iragorri, 2018)(Ocheja et al., 2019)(F. R. Vidal et al., 2020a)(F. Vidal et al., 2019), because besides  offering a secure mechanism for verification it also ensures privacy. Also, there are benefits related to revoking certificates, because of the immutable timestamp. However, several issues about this operation have been raised (Hamilton Duffy, 2017)(Karasavvas, 2018)(F. R. Vidal et al., 2020b) (Santos & Duffy, 2019) (San et al., 2020), so that there is still no consensus on the best way to do it. This section mentions some of the approaches that have been taken to address the diploma's revocation problem. 

San et al. (2020) presents a proposal to create a structured blockchain record, able to reference the revoked diplomas. One single transaction can keep several records, which are identified by a sequential integer number, called $id$. The number of the id by a transaction is limited to the size of 640 bits. The model suggests this size due to the limitation of the tested network, the Bitcoin, which only allows storing about 80 bytes in the OP_RETURN field (Bartoletti & Pompianu, 2017).

Blockcerts has tried two approaches for revocation. One approach to revoke certificates recorded control data in Bitcoin Unspent Transaction Output (UTXO) transactions. The other approach was developed using the Open Badge standard (IMS Global Learning Consortium, 2018), and for this reason, it operated in the form of CRL. There is a third approach planned (Ronning & Chung, 2019), where the use of Verifiable Credentials (VC) is discussed. In this approach, there is a discussion about how to use the available endpoints of the standard. For example, they can point either to a CRL or to a smart contract.

Santos and Duffy (2019) identified the opportunity to revoke certificates using Ethereum smart contracts. For this method to work, the issuance of the certificate must be prepared to instantiate a smart contract. The model deals with the revocation of records in two ways: revocation in batch batchRevocationStatus and individual revocation individualRevokedList. The operation is very similar to the other examples cited here in this work (which used smart contracts) and consists of modifying and checking the status of the digital object (i.e., revoked or not). Similarly, other studies also implement the issuance of certificates using smart contracts, for example, Palma et al. (2019).

1. R. Vidal et al. (2020b) presents and discusses some questions related to the blockchain storage limitation and the difficulty to create a revocation solution to academic diplomas, capable of working with most blockchains. The work proposes the use of a complimentary file to allow the storage of a large amount of data, which would be unfeasible to be stored in the blockchain. The model suggests using a Interplanetary File System (IPFS) network to distribute the complementary file as well as other approaches, that use blockchain and IPFS together (Kumar & Tripathi, 2019) (Yu et al., 2020) (Rajalakshmi et al., 2018).

After analyzing these solutions, we conclude that the revocation is applied in a very particular way by each application. In the next section, we present our solution which uses a scheme global identity,  that can be applied in several kinds of applications.

Model Based Self-Sovereign Identity

The revocation models we have described imply that the functionality of the revoke operation is linked to a structural change in the asset's original record. This means that it would only be possible to revoke new records created from a newly defined structure.  For example, the works (San et al., 2020) (Santos & Duffy, 2019) (Palma et al., 2019) present a solution for the revocation of academic certificates, but require a change in the process of issuing the certificates to ensure that functionality. Therefore, these approaches are not compatible with old records.

We suggest that the record of the revocation operation for blockchain applications references the original transaction, indicating that it has been revoked. However, storing assets in transactions that operate in a decentralized and sovereign manner is a recent challenge, which did not even exist four years ago (Avellaneda et al., 2019). Therefore, we propose a model using VC and Decentralized Identifier (DID), which, combined, provide a mechanism to store the revocation operation, and at the same time, keep the sovereignty of the asset's owner.

In our model, the application is the owner that has control over all blockchain data. The DID standard allows to delegate one identity, and this functionality is used by the application to expand the control.

Before the blockchain, digital identity solutions were based on federated identity protocols that worked on the Internet, such as OpenID. The goal was to centralize identity data, mainly on social networks.

With the use of the blockchain and the concept of decentralized sovereign identity, new protocols have been proposed. In this work, we combine the use of VC and DID standards that are being developed by World Wide Web Consortium (W3C) VC had its first version published in November 2019 (Reed et al., 2019) and consists of a new data model for interoperability of self-sovereign identity technologies. A DID is a data structure containing the user's identifier (public key) and other metadata required to create transactions with that identifier.

The figure 4 shows a revocation operation triggered by a generic application, which is revoking three transactions, tx1,tx2 and tx3. The proposed model considers that there may be several public addresses being managed by a single system. That is because an owner may decide to have multiple keys to separate control from several different types of assets. For example, a university may have separate keys to managing the academic records for each of its colleges or schools.

Figure 4 Revoking a group of transaction

To create a DID it is necessary to choose the method on which the model's operation will be based. There are different methods and those can be applied for different purposes[1]. For this model we used the did: sov method, a specification focused on addressing identity. In this type of method, the identifiers are published on a sovrin[2] blockchain. As can be seen in figure 4, an identifier is generated, which has two functions: uniquely identifying the document, and providing mechanisms to the owner to prove his ownership, while keeping his privacy.

We are suggesting in this paper the Sovrin method for DID. However, the DID standard is compatible with several methods. In this case, the Sovrin had performance issues or was unavailable. Our model seeks to change DID method. There are alternative methods that can be implemented, such as DID: IPFS, which generates a link for an IPFS system.

The identifier's generation works in two steps: in the first step, all owner addresses are concatenated in a single address, applying a base58 function (the same as Bitcoin). The result of the expression Base58 (address x, address y, address w), generates the id owner, a 21 or 22 character string. The second step is to mark the transactions that will be revoked. Considering that each transaction on the blockchain is uniquely identified by its txid, this will be the information stored in DID to represent each revoked transaction. Several txids will form an owner revocation group. The identifier of this group is calculated by a base58 function, in which all txids of the group are concatenated, together with id owner previously calculated. In this example the generated identifier was:  did: sov: 2wJPyULfLLnYTEFYzByfUR.

Also noted in figure 4, an area represented by the transaction tx6, which contains the content of the group identifier. The registration address is done with one of the owner's addresses. The goal is to have a simplified registration on the blockchain, so that the application, by consulting a DID, can verify its integrity in a "disconnected" way (Sovrin is a private blockchain network). Currently, Sovrin has few operators distributed geographically, which can impact unavailability or low-performance (Tissato Nakamura et al., 2019).

We use DID for two functions: identifying the owner and identifying revoked transactions.

Some operations can be performed, such as updating the revoked transaction group. To do this, simply register the DID again with an update operation. Note that the operation does not change the original identifier of  DID, which makes it easier for tracking. In this case, the transaction  tx6 remains valid to assert that the document exists on the local network.

In the example below, a new transaction is created for the revoked records.

{

  "submitterId": #2wJPyULfLLnYTEFYzByfUR,

  "signature": [...,]

  "reqId": 1,

  "operation": {

      "type": "NYM",

      "did": #25GaKN4EpUENN,

      "document": {

          "publicKey": [{

              "id": #TX1

              "type": ED25519VerificationKey

              "publicKeyBase58": ...

          },{

              "id": #TX2

              "type": ED25519VerificationKey

              "publicKeyBase58": ...

          },{

              "id": #TX3

              "type": ED25519VerificationKey

              "publicKeyBase58": ...

          },{

              "id": #TX0

              "type": ED25519VerificationKey

              "publicKeyBase58": ...

          }

          }],

          "authentication": [{

              "type": "ED25519SigningAuthenticationThreshold",

              "threshold": 1,

              "publicKey": [...]

          }],

          "service": [{

            "type":apiService,

            "serviceEndpoint": http:\\ufp.edu.pt\api

          }]

      }

    }

}

This update operation brings a lot of flexibility to the system, because it is possible, for example, to change a controlling public key (i.e., through the authorizations tag), in a scenario such as a stolen key or management change.

Thus far the model presented has shown how to reference existing records to a reversed state, however, there is still an important issue to be addressed. The complementary information in the registration of a revocation. As F. R. Vidal et al. (2020b) observe, due to its architecture, it is not practical to consider recording justifications and other data related to a revocation operation, using the blockchain as a database.

As an alternative to this problem, we propose the use of VC. Among the several meta-data offered by the standard, there is one called credential object, which contains statements on one or more subjects (Reed et al., 2019). At this point, we refer to the revocation DID created, thus relating the complementary file to the document that identifies the revoked data. We also use Extensibility, standard metadata that allows us to create custom fields (Reed et al., 2019). This information can be viewed through figure 5.

Figure 5 VC Information Revocation File Structure

The code below demonstrates an example of a complementary file in which detailed information regarding academic certificates that have been revoked is stored.

{

  "@context": [

    "https://www.w3.org/2018/credentials/v1",

    "https://ufp.edu.pt/contexts/revokecompl.jsonld"

  ],

  "id": "http://ufp.edu.pt/credentials/4643",

  "type": ["VerifiableCredential", "CustomExt12"],

  "issuer": "https://ufp.edu.pt/issuers/14",

  "issuanceDate": "2020-10-24T05:28:04Z",

  "expirationDate:" "2025-10-24T05:28:04Z",

  "generalReason": "The diploma was revoked due an internal error"

  "credentialSubject": {

    "id": "did:sov:2wJPyULfLLnYTEFYzByfUR",

    "name": "Revoked records of UFP CertEdu System",

  },

  "revokedTxs:" [{

   "id":tx0,

   "reason:" "Wrong student's ID"

   "typeReference:" Integer

   "referenceNumber:" 37705

   "referenceInfo:" "ID number registred"

  },

  {

   "id":tx1,

   "reason:" "E-mail address doesn't exist "

   "typeReference:" Integer

   "referenceNumber:" 39901

   "referenceInfo:" "ID number registred"

  },

  {

   "id":tx2,

   "reason:" "Wrong student's name "

   "typeReference:" Integer

   "referenceNumber:" 40103

   "referenceInfo:" "ID number registred"

  }

  ]

  "proof": {  }

}

The fields generalReason and revokedTxs have been customized so that applications can record information about their revoked blockchain transactions. The generated file contains a digital signature (i.e., proof tag), which serves for third parties to verify its integrity.

Conclusion

The blockchain is a database that uses cryptographic mechanisms, however, it has low storage capacity when compared to traditional databases. For this reason, usually, applications write only surrogates to the blockchain, such as the hash of academic certificates or other documents, which are used for authenticity checks. Given this characteristic of blockchains, the revocation mechanism must operate in a similar way, recording only a reversal transaction reference.

Assets that are anchored in a blockchain are usually represented by digital files, structured as JavaScript Object Notation (JSON) or Extensible Markup Language (XML). We propose that the revocation operation should work in the same way, generating a related digital file. However, we propose to use VC to make such information available, mainly due to the flexibility the standard offers, in addition to offering embedded integrity mechanisms (e.g., digital signature). We developed CertEdu (F. R. Vidal et al., 2020a), a prototype for issuing academic certificates on Blockchain, which can distribute diplomas on Ethereum or Bitcoin chains. We adapted the original revocation mechanism (i.e., developed with OpenBadge standard) to work with the VC standard.

A generic solution for revoking records needs to consider that each application has its specific requirements. There is no way to define a static structure for all of them. That is why it is necessary to consider the most diverse types of fields required, to reference the information revoked in the blockchain. In the example shown, the revocation file links the student's registration number to the internal registration system and lists the reasons for which a diploma was revoked.

The proposed model differs from other approaches described in this paper. It does not constrain its operation to a re-engineering of the original application and can be used to revoke old records.  Therefore,  solutions such as redacting, erasing or pruning, demands new blockchain designs, thus they are not compatible with the current blockchain architecture.

The use of DID enabled the secure identification of owners and their transactions and offered autonomy to revoke their operations. To prevent the process from being centralized to a controller, the standard easily allows changing the composition of the authorizing keys. In addition, the update operation preserves the document's identifier, which allows increasing the number of revoked transactions without adding new transaction registration costs.

Some limitations have been identified. For example, within the model presented, it would not be possible to implement a mechanism similar to the work (Hewa et al., 2020), in which the revocation of an existing record is done automatically, as in the example mentioned by a score calculation. There is also no way to separate revocations from records that are represented in a grouped manner, within a single transaction.

In the current transaction blockchain model, there is no difference to register a "repeatable" transaction in the network. An interesting approach would be creating a mechanism for credit compensation, to applications create the corrective records with less charge. These issues will be addressed in future work, as the model is improved.

From a business perspective, there are benefits to the use of blockchain for academic certificates. According to European Commission/EACEA/Eurydice (2018) in Europe, there was an increase in the number of degrees from 23% (2012) to 39% (2016), with 4.5 million new diplomas per year. However, is quite common tampering on academic certificates. It can take a long time for verification on average 12 days to verify that a diploma is genuine (Awaji, Solaiman, & Marshall, 2020).

  The use of blockchain in this type of application brings several benefits to the business, reducing this time and decentralizing the verification process. The use of sovereign identity demonstrated by this work improves the identity of students and universities.

Conflict of interest

The authors declare no potential conflict of interest regarding the publication of this work. In addition, the ethical issues including plagiarism, informed consent, misconduct, data fabrication and, or falsification, double publication and, or submission, and redundancy have been completely witnessed by the authors.

Funding

The author(s) received no financial support for the research, authorship, and/or publication of this article