We consider a blockchain-based protocol for the certi cation of academic credentials named Blockcerts, which is currently used worldwide for validating digital certi cates of competence compliant with the Open Badges standard. We study the certi cation steps that are performed by the Blockcerts protocol to validate a certi cate, and nd that they are vulnerable to a certain type of impersonation attacks. More in detail, authentication of the issuing institution is performed by retrieving an unauthenticated issuer pro le online, and comparing some data reported there with those included in the issued certi cate. We show that, by fabricating a fake issuer pro le and generating a suitably altered certi cate, an attacker is able to impersonate a legitimate issuer and can produce certi cates that cannot be distinguished from originals by the Blockcerts validation procedure. We also propose some possible countermeasures against an attack of this type, which require the use of a classic public key infrastructure or a decentralized identity system integrated with the Blockcerts protocol.
Badges standard hence provides a tool for implementing digital, enriched versions of competence certi cates and academic credentials. However, the certi cation of the competences covered by one of these digital badges is out of the scope of the Open Badges standard itself.
Justi ed by its pervasiveness and huge potential, the blockchain technology has recently
emerged as a tool to accelerate and facilitate the process of issuing and recognizing credentials
in an increasingly digitised world [
According to the Blockcerts standard, Open Badges-compliant certi cates are
cryptographically signed by the issuer, while their certi cation data is written into a public blockchain,
thus leveraging its immutability. Recipients can share them publicly on their social media
pro les, personal websites, etc., and everyone can see the contents of the certi cates with the
possibility to verify their validity and authenticity through the blockchain. The use of the
blockchain technology makes the process of veri cation globally accessible and instantaneous,
with no need for long procedures and institutional bureaucratic correspondences. Another
relevant point lays in the fact that Blockcerts passes from paper-based certi cates to software-based
certi cates. A Blockcerts certi cate is fully-machine readable since it is designed as software in
JavaScript Object Notation (JSON) format [
When analyzing and implementing blockchain-based systems, a very important issue
concerns security [
For this purpose, we generate a forged though veri able academic certi cate. Such a forged certi cate appears to be correctly issued by the Universita Politecnica delle Marche according to the Blockcerts protocol, despite it has been fabricated without involving the aforementioned institution. In fact, by generating a valid blockchain key pair, and following a few simple steps, it was possible to impersonate the issuing institution and fabricate an apparently valid academic certi cate. This is because the Blockcerts veri cation system does not check if the public keys are actually owned by the legitimate issuing institution or not. In order to prevent this type of attacks, we propose some countermeasures aimed at avoiding that a fake issuer pro le can be accepted by the certi cate veri cation protocol.
The paper is organized as follows. In Section 2 we describe the Blockcerts standard that is the object of our work. In Section 3 we describe a vulnerability in the Blockcerts certi cate validation procedure and how it can be exploited to fabricate forged academic credentials. In Section 4 we describe some possible countermeasures aimed at preventing the aforementioned attack, while in Section 5 we provide some conclusive remarks. 2
With the aim of having a global system for the veri cation of academic records, the development
of Blockcerts [
Basically, the issuer can autonomously create a structured Blockcerts certi cate, sign it and
certify its integrity by storing a hash digest of the certi cate within a blockchain transaction.
Then, the issuer can send the recipient a copy of the signed Blockerts certi cate that can be
shared in social networks, via e-mail, etc. Anyone accessing the certi cate can verify its integrity
using an open platform called Blockcerts Universal Veri er [
The whole lifecycle of a Blockcerts-based certi cate is schematically described in Figure 1. After successfully completing her/his studies, the student is asked to provide a public blockchain address by the issuing institution. For this purpose, the student generates a private/public keypair for the used blockchain, and then computes her/his public address as the output of a one-way function applied to her/his public key. At the same time (or before) a Blockcertscompliant certi cate template is created by the issuing institution. Then, a new certi cate is issued and released to the student, along with a blockchain transaction to the student's public address that enables veri cation of the issued certi cate. 2.1
Each Blockcerts certi cate contains structured data concerning the certi cate itself, its issuer and its recipient (see Figure 2.a).
Information about the issuer is contained in the Issuer Pro le, according to the Open Badge standard. Among the various elds, for the purpose of this work, an important one is the issuer id, which is the URL of a web page containing the issuer information in JSON format. As we can see from the example reported in Figure 3, such information includes the institution name, homepage, logo, e-mail address, etc., and, importantly, the public keys claimed by the issuer. Each key has a timestamp corresponding to its creation and possibly the timestamp corresponding to its expiration. Regarding information about the recipient, it concerns: name, email, and blockchain public key.
As mentioned in the Introduction, the Blockcerts standard also allows embedding the socalled diploma supplement into a certi cate. The diploma supplement is produced by higher education institutions according to international and European recommendations, and contains eight sections (see Figure 2.b). It includes additional information about the course attended (e.g., results for each exam/course with date and outcome) and the competences achieved by the recipient of the certi cate. The diploma supplement is recognized as an o cial document accompanying a higher education diploma, providing a standardized description of the nature, level, context, content and status of the studies completed by its holder. 2.2
All the preliminary steps required for issuing certi cates compliant with the Blockcerts standard
can be implemented through the cert-tools open source software [
Through the veri cation process, anyone can check the authenticity of a certi cate, having clear information about the institution that issued it and a proof that the certi cate was actually issued to the claiming recipient. The certi cate veri cation process starts with the following three steps: 1. Veri cation that the hash digest of the certi cate matches the value in the receipt. 2. Veri cation that the Merkle path is valid. 3. Veri cation that the Merkle root stored into the blockchain matches the value in the receipt.
Through the above steps, anyone can check that a certi cate has not been tampered since its issuing. The next important step of the veri cation process is authenticating the certi cate issuer, i.e., verifying the identity of the issuing institution. This is achieved by verifying that the signing key for the blockchain transaction through which the certi cate was issued corresponds to the issuer public key, and that it was valid when the transaction took place. This uses the timestamp and input address from the blockchain transaction details, and the issuer information provided along with the Issuer Pro le, described in Section 2.1. For this purpose, the blockchain transaction id is extracted from the certi cate receipt. The transaction id allows verifying that the transaction was actually registered into the blockchain and retrieving the corresponding transaction details. The issuer public key can be found within such details, as shown in Figure 4.
Then, the issuer id is extracted from the certi cate to retrieve the Hosted Issuer Pro le from the corresponding url. The issuer public key included in the Hosted Issuer Pro le is then compared with the one found in the blockchain transaction, as shown in Figure 5.
If the two keys do not coincide, an error is returned and the certi cate is considered invalid. Otherwise, the timestamps are checked to prove that the key was valid at the time of the transaction. In addition, if the public key included in the issuer pro le has an expiration date, it is checked that the transaction did not take place after that date. If all these veri cation steps succeed, then the certi cate is considered as valid. All the steps of the issuer identity veri cation are schematically described in Figure 6.
In this section we show that apparently valid certi cates issued by any institution can indeed be fabricated by a malicious attacker. This is basically due to an intrinsic vulnerability of the veri cation process described in Section 2.3. In fact, the Blockcerts protocol does not verify that the issuer id extracted from a certi cate actually points to a web domain that is owned by the legitimate issuing institution. This allows hijacking of the veri er towards a fake issuer pro le, which can perfectly resemble the one of the legitimate institution.
In our experiment, a fake issuer pro le was created for the Universita Politecnica delle Marche and hosted on a Github domain. The public key included in such a pro le has no relation with the real institution, since it was auto-generated for the purposes of this work. During the veri cation process, the Blockcerts protocol checks the public key on the blockchain transaction corresponding to the certi cate, and compares it with the key included in the issuer pro le published online. As we show next, this brings to a successful veri cation through Blockcerts, and to a forged certi cate that is practically indistinguishable from a legitimate one. This results in the fabrication of a certi cate for the Italian Laurea Magistrale in Electronic Engineering by impersonating the issuing institution Universita Politecnica delle Marche. 3.1
Two Ethereum blockchain keypairs were rst generated: one for the issuer (university) and one for the recipient (student). After that, a Blockcerts-compliant certi cate has been designed. This step can obviously be skipped if the issuer already has de ned its own Blockcerts-compliant certi cates.
A new certi cate is then issued to the student, including the blockchain public key of the student, the student's personal information and a diploma supplement. The correctness of this information is validated according to the Blockcerts and Open Badges standards, after which an unsigned certi cate is obtained. Such a certi cate is then signed with the issuer keypair and issued through a transaction on the Ethereum blockchain. The main content of such a blockchain transaction is the certi cate Merkle root. In our case, since a single certi cate was issued, the Merkle root coincides with the certi cate hash digest. This way, a signed Blockcerts-compliant certi cate is obtained, as shown in Figure 7. Note that the signed certi cate includes the blockchain receipt, providing all the necessary details for retrieving the blockchain transaction and performing the blockchain-based veri cation of the certi cate according to the Blockcerts standard.
This signed certi cate can be veri ed through any web-based or stand-alone tool compliant with the Blockcerts protocol. Let us use for this purpose the Blockcerts Universal Veri er2. The outcome of the veri cation, so performed, is shown in Figure 8. The veri cation process indeed ended with a positive result. Moreover, the veri cation window reports the issuing university logo and the title of the certi cate (in this case: Master's Degree in Electronic Engineering ), followed by the name of the recipient, the issuance date and the name of the boolean v e r i f y C e r t i f i c a t e ( C e r t i f i c a t e c ) f
B l o c k c h a i n T r a n s a c t i o n I D transID = g e t B l o c k c h a i n T r a n s a c t i o n I D ( c ) ; // g e t i n f o about i s s u e r from URL l i n k contained i n t o t h e c e r t i f i c a t e I s s u e r I D i s s u e r I D = g e t I s s u e r I D ( c ) ; URL profileURL = g e t H o s t e d I s s u e r P r o f i l e U R L ( i s s u e r I D ) ; // read t h e p r o f i l e f o l l o w i n g t h e URL l i n k P r o f i l e p r o f i l e = httpGET ( profileURL ) ; PublicKey pkey = getPublicKey ( p r o f i l e ) ; B lo c kc h ai nA d dr e ss add1 = computeBlockchainAddress ( pkey ) ; Timestamp t1 = getTimestamp ( pkey ) ; // g e t i n f o about i s s u e r from t h e b l o c k c h a i n t r a n s a c t i o n // read t h e t r a n s a c t i o n from b l o c k c h a i n B l o c k c h a i n T r a n s a c t i o n t r a n s = blockchainGET ( transID ) ; B lo c kc h ai nA d dr e ss add2 = g e t B l o c k c h a i n A d d r e s s ( t r a n s ) ; Timestamp t2 = getTimestamp ( t r a n s ) ; i f ( add1==add2 ) && ( t1 <= t2 )
return true // t h e i s s u e r i s v a l i d e l s e
return f a l s e // t h e i s s u e r i s not v a l i d g issuing institution. The diploma supplement and its contents can be visualized as well. The details of the corresponding Ethereum transaction3 are reported in Figure 9. 3.2
Let us describe how it is possible that a fabricated certi cate passes all the veri cation steps required by the Blockcerts protocol by analyzing them in detail.
As shown in Figure 8, the rst veri cation step consists in reading the transaction id, through which the details reported in Figure 9 are retrieved. Then, a local hash digest of the certi cate is computed, and the remote hash digest is retrieved from the associated blockchain transaction.
The next veri cation step consists in getting the issuer pro le referenced by the issuer id. This is a crucial point for the successful veri cation of a fabricated certi cate, and is schematically described in Figure 10. As we notice from the gure, the issuer id points to a custom url that has no relation with the legitimate issuer. This is the point where hijacking of the veri cation occurs, and the use of a fabricated issuer pro le is enforced. The next step consists in parsing the issuer keys, that is, extracting the issuer public key from the public issuer pro le, which in our case was illegally fabricated.
The veri cation process continues with a second block of steps concerning the hash digest comparison. The rst of these steps veri es that the hash of the certi cate locally computed coincides with that included in the certi cate receipt. This proves that the certi cate has not been modi ed since its issuance. In the next step, the system compares the Merkle root value written on the certi cate receipt with the Merkle root written on the blockchain. As a next step, the certi cate receipt is checked to verify that the certi cate under analysis is part of the Merkle tree. As mentioned above, in our case, only one certi cate was issued and its hash digest corresponds with the Merkle root value. This is denoted by leaving the proof eld empty in the certi cate receipt. In such a case, the system realizes that only one certi cate was issued 3Available at https://etherscan.io/tx/0x14e97be56509d716cf7f318 179753ed985360cbc6164ad3c09519fa8790f2f0c and veri es that the Merkle root values in the certi cate and the blockchain are correct and coincide with the certi cate hash digest.
Instead, when a batch of certi cates is issued, the proof eld is lled with the necessary values to create the path from the current certi cate to the Merkle root. An illustrative example is shown in Figure 11, in which the Merkle path is colored in orange. With this information, the system is able to calculate the nal value of the Merkle root of the whole batch of certi cates. If the certi cate is part of the batch, then the calculated Merkle root value is the same as the value written on the certi cate. Otherwise, an error occurs, meaning that the certi cate is not part of the batch, and therefore, is not valid.
At this point, it has been proved that the certi cate has not been modi ed since its issuance and that it is actually written on the blockchain. The next block of veri cation steps, named status check, concerns the certi cate authentication. The rst one of these checks concerns the revocation status, and is aimed at verifying that the certi cate has not been revoked by the issuer. In fact, a list of revoked certi cates is available online along with the issuer pro le, as shown in Figure 12. The system goes through such a list to check if it includes the certi cate under analysis or not. In case the certi cate identi er is found in the list of revoked certi cates, an error message is returned and the veri cation fails, otherwise the system continues with the next veri cation step.
The subsequent step, named authenticity checking step, is a very crucial element in the veri cation process. This step aims at verifying that the certi cate was actually issued by the claimed institution. According to the Blockcerts standard, the certi cate authenticity is checked as explained in Section 2.3. For the certi cate under analysis, the steps performed for checking its authenticity are schematically described in Figure 13.
For this purpose, the hosted id eld is rst read from the certi cate, and the corresponding public key is retrieved from the issuer pro le available online, at the web address speci ed in the hosted id eld. Such a public key is then compared with the one reported in the blockchain transaction. If the two keys coincide, the system checks the timestamps as explained before. If such a check is successful, veri cation proceeds by checking if the certi cate has an expiry date, after which the veri cation process is completed.
In our case, the fabricated certi cate was able to pass all the veri cation steps, and is therefore considered as a valid Blockcerts-compliant certi cate. This proves that such a protocol does not allow distinguishing the legitimate issuer from someone impersonating it. This is due to the fact that the Blockcerts standard does not require any veri cation that the keys used to sign a certi cate are actually owned by the legitimate issuing institution. For this reason, everyone creating a new keypair can sign a Blockcerts-compliant certi cate and impersonate the legitimate issuing institution. 4
The vulnerability of the Blockcerts standard described in the previous sections builds upon the lack of any certi cation about the ownership of the keys used for signing issued certi cates. In order to prevent forgery attacks exploiting such a vulnerability, suitable countermeasures must be adopted by introducing a mechanism to check that such keys indeed correspond to the digital identity of the legitimate issuing institution.
A natural solution of this type could be replacing the issuer pro le referenced from the issuer id eld with a digital certi cate containing the public key of the issuing institution, and released by an accredited certi cation authority. In this way, the authenticity of the certi cate can be checked through a classic Public Key Infrastructure (PKI), and the online information about the issuer retrieved through the issuer id is certi ed.
Starting from July 2016, the electronic identi cation, authentication and trust services
(eIDAS) came into e ect in the European Union. The eIDAS regulation de nes three types of
electronic signatures [
1. Electronic Signature: data in electronic form which is attached to or logically associated
with other data in electronic form and which is used by the signatory to sign. 2. Advanced Electronic Signature: an electronic signature which meets the following requirements: a) it is uniquely linked to the signatory, b) it is capable of identifying the signatory, c) it is produced using electronic signature creation data that the signatory can use, with a high level of con dence, under his sole control, and d) it is linked to the data signed therewith in such a way that any subsequent change in the data is detectable. 3. Quali ed Electronic Signature: an advanced electronic seal, which is created by a quali ed electronic seal creation device, and that is based on a quali ed certi cate for electronic seal.
The only type of signatures universally recognized by all EU states and given the equivalent legal e ect of a handwritten signature are quali ed electronic signatures. The eIDAS regulation also provides the requirements for quali ed certi cates. Since most of the blockchain platforms (like the Ethereum blockchain used in our case) use Elliptic Curve Digital Signature Algorithm (ECDSA) signatures, that is based on Elliptic Curves Cryptography (ECC), a natural solution would be using an ECC-based X.509 certi cate format to link the issuer identity with its ECCbased public key.
This solution provides an e ective way to overcome the Blockcerts issuer identity veri cation problem and to give a legal value to the Blockcerts academic certi cate, owing to eIDAS compliance. On the other hand, the ECC-based certi cate is signed by a Trusted Service Provider (TSP), and validity of the certi cate relies on validity of the TSP signature. The main drawback of such a solution is in the fact that, this way, the veri cation system is no longer fully decentralized, needing a Certi cate Authority (CA) to verify the identity of the issuer and sign the ECC-based certi cate.
In order to overcome such a drawback, Decentralized Identi ers (DIDs) could be
considered as an alternative solution. In fact, there are currently working groups [
We have analyzed a blockchain-based protocol for the certi cation of academic credentials named Blockcerts, which aims at certifying digital certi cates compliant with the Open Badges standard through a public blockchain. We have reviewed all the steps that are required for the creation of Open Badges-compliant digital academic credentials and for their certi cation according to the Blockcerts protocol. From such an analysis it results that the Blockchain protocol does not provide any strong mechanism for authenticating the issuing institution, since the issuer authentication is basically performed on the basis of an unauthenticated issuer pro le available online and referenced from inside the certi cate.
We have shown how a legitimate issuing institution can be easily impersonated by suitably fabricating a fake issuer pro le. This way, apparently legitimate academic credentials can be released, which the Blockcerts validation mechanisms are unable to distinguish from valid academic credentials issued by the legitimate institution. This clearly highlights a vulnerability of this protocol, especially when it is used for the certi cation of academic credentials with legal value.
In order to overcome such a vulnerability, we have proposed to resort to a classic PKI and replace the issuer pro le with a certi cate signed by a recognized certi cation authority. This, however, infringes the decentralized nature of the Blockcerts infrastructure. Alternatively, a decentralized identity system could be used instead of a classic PKI to preserve the fully decentralized nature of the paradigm. Such systems, however, are currently under development, and cannot provide an immediate solution to the highlighted vulnerability.