Blockchain-based certifications

Blockchain technology, known for its transformative role in finance, is breaking new ground in the realm of education. Traditionally seen as a foundation for cryptocurrencies, blockchain’s potential extends far beyond just a secure transaction ledger. At the University of Nicosia, we have embraced this revolutionary technology to reimagine how academic achievements are recorded, shared, and verified.

The introduction of blockchain into the world of academic credentialing marks a paradigm shift. Far from its roots in financial transactions, and specifically for the use-case of verifiable academic credentials, blockchain serves as a decentralized, permanent, and unalterable repository of academic achievements. The applicability of the technology to education indicates blockchain’s versatility and its capacity to ensure trust, and transparency in systems beyond the financial sector.

Introducing

Digital Academic Certificates on Blockchain

In an increasingly digital age, the concept of academic certificates has evolved. The University of Nicosia proudly leads this change by leveraging blockchain to issue digital academic certificates. These are not mere digital replicas of traditional paper diplomas or professional certificates; they are advanced, secure, and verifiable credentials stored on the blockchain.

In brief, the issuance process involves cryptographic signing and hashing, for recording these certificates on the blockchain. This not only ensures their authenticity but also allows for instant verification of their validity, without the need to contact or involve the issuing institution, during the verification process.

This pioneering approach places the University of Nicosia at the forefront of educational innovation, harnessing the power of blockchain to provide students with secure, verifiable, and tamper-proof academic credentials.

BTC-based Certificates

The Process of Creating and Issuing Blockchain Certificates

Creating and issuing a digital certificate is relatively simple with blockchain: a digital PDF file is created which contains some basic information such as the student name, degree name, year of graduation, name of the university, an issue date, etc. Then the contents of the certificate are signed using a private key to which only the institution has access, and will append that signature to the certificate itself. Next, a document hash using SHA-256 algorithm is created which can be used to verify that nobody has tampered with the content of the certificate. Finally, private key is used again to create a transaction that anchor the hash of that record on the blockchain; which means that a certain certificate is issued on a certain date, with proof of its validity. This makes it possible to verify who a certificate was issued to, by whom, and validate the content of the certificate itself.

The University of Nicosia’s Milestone

The University of Nicosia has become the first university in the world to issue academic certificates whose validity, and authenticity can be verified through the Bitcoin blockchain. These certificates are being issued since 2015 to students who successfully completed or participated in DFIN-511 (Introduction to Digital Currencies), which is the first Massive Open Online Course (MOOC) offered by a university on the topic of cryptocurrency. Since 2017, UNIC started to issue all university diplomas on the Bitcoin blockchain using its own technology, which is developed as open source and has already been adopted by other universities and certificate issuers around the globe. For example, the British University in Dubai’s (BUiD) graduating batch of 2017 was the first in the country and third in the world to receive a self-verifiable blockchain certificate issued using the protocol developed by the University of Nicosia.

Purpose and Functionality

The University of Nicosia’s protocol for issuing and revoking digital certificates on public blockchains is an important contribution to on-chain academic credential management. Designed with both security and accessibility in mind, our approach redefines the issuance and verification of academic certificates. The core functionality of our platform and protocol is centred on creating digitally verifiable certificates that are both easily accessible and highly secure. Personal data are kept on the certificate itself (along with other metadata) where a digital fingerprint (i.e., the hash) of the certificate object is stored on-chain.

Leveraging Bitcoin’s OP_RETURN for Data Storage

Our protocol utilizes Bitcoin’s OP_RETURN operator. This feature of the Bitcoin blockchain allows for the inclusion of a small amount of arbitrary data — in this case, information pertinent to academic certificates. By utilizing OP_RETURN, we embed a unique document hash of each certificate directly onto the Bitcoin blockchain. This method ensures that the integrity of each certificate is permanently recorded and publicly verifiable. More specifically, and to enable issuances in batches our protocol enables the issuance of thousands of credentials by hashing them together using a Merkle tree data structure.

Overview of Processes

Creating Credentials

The creation of verifiable credentials begins with the generation of a digital certificate in a PDF format. This document contains essential details such as the student’s name, degree, graduation year, and issuing institution. These details are attached to the PDF as additional metadata and are kept off-chain attached to the PDF object itself (metadata can only be programmatically retrieved). The certificate is then cryptographically signed using a private key, ensuring that it is uniquely tied to the issuing authority.

Issuing Credentials

Once a certificate is created, it is issued by recording its hash on the blockchain. A hash function is used to derive the message digest (aka the hash) of the PDF object. Then, and for performing a batch issuance, hashes of each object are hashed together in a Merkle tree structure, leading to the creation of a Merkle root. This root represents all the credentials, and even a minor alteration in any certificate changes this root completely.

The issuance process concludes with creating a Bitcoin transaction incorporating the OP_RETURN operator with the Merkle root as part of the data. This transaction is sent to a Bitcoin node, and upon confirmation, it gets securely stored in the blockchain. This is the immutable and publicly verifiable proof needed to ensure that the credentials are not only secure and tamper-proof but also verifiable independently by anyone.

Post-issuance, additional information that proves that the credential has been issued on-chain is added as part of the metadata of each PDF object; establishing proof that it was issued on the blockchain.

This includes the Merkle proof, the Merkle root, and the transaction identifier (TxID). This process takes place after a successful issuance since only then we are able to know the TxID. T

The additional metadata are added in a deterministic manner, in such a way that removing them will revert the PDF to its original state; as it was when initially generated during the credential creation process. This is essential for the validation process.

Revoking Credentials

While the original record on the blockchain cannot be altered (maintaining the integrity and immutability of the ledger), we can issue a new transaction to indicate the revocation of a specific certificate. In doing so, a meta-protocol, named Blockchain

Document Issuing Protocol (BDIP) has been proposed to ensure that the status of any credential can be accurately verified at any time.

Technical Deep Dive

For those interested in a more technical exploration of our platform and protocols, we provide detailed explanations of each operation – from creation and issuance to revocation of credentials. These details delve into the cryptographic techniques employed, the specifics of the Bitcoin blockchain interactions, and the overall architecture of our platform and protocol (including details of the BDIP protocol proposed as a solution to revocation).

3.5.1. Creating Credentials 

 

In brief, creating credentials using our methodology involves populating a PDF template with data from a CSV file to generate the individual certificates, hashing these certificates, and creating a Merkle tree. The Merkle root is then published to the Bitcoin blockchain.  

 

The steps are summarized as follows: 

  1. Populate a PDF template with graduate data from a CSV file to create individual certificates.
  2. Add metadata to each PDF
  3. Hash each PDF certificate using SHA-256 to ensure integrity.
  4. 4. Construct a Merkle tree from these hashes and publish the Merkle root to the Bitcoin blockchain.
  5. 5. Ensure each PDF contains metadata with issuer information and a chainpoint
  6. 6. Once the Merkle root is published, the certificates are ready for distribution. 

 

 

 

 

 

Add metadata to each PDF 

 

Derive the Merkle root 

 

 

The process is managed through scripts that handle certificate creation, validation, and revocation, with configuration defined in a `config.ini` file. 

 

Configuration Options (config.ini) 

Option  Explanation and example 
Global   
working_direcory  The working directory for issuing the certificates. All paths/files are always relative to this directory. Example: /home/kostas/spring_2016_graduates 
PDF certificates related   
pdf_cert_template  The name of the PDF template file relative to working_directory. Example: certificate_template.pdf 
csv_file  The name of the comma separated value file that contains individual information for each awardee. It is relative to working_directory. Example: graduates.csv 
certificates_directory  The directory were all the new certificates will be stored. It is recommended that this directory is always empty before running the script. If it doesn’t exist it will be created. It is relative to working_directory. Example: certificates 
certificates_global_fields  An object that contains data for the pdf_cert_template to fill in fields that are common to all graduates. Given that there is a field called date  for the date that the certificate was awarded an example would be: { “fields”: [ { “date”: { “label”: “Date”, “order”: 2, “hide”: false, “value”: “5 Dec 2016” } } ] } 
issuer  The name of the issuer/institution. Example: UNIVERSITY OF NEVERLAND 
expiry_date  The date of expiry (if any) expressed in Unix Epoch / UTC. Example: 1553929397 
CSV file related   
cert_names_csv_column  Specifies the header of the column to use to name the certificates filenames. It has to be unique for each row or else the latter certificates will overrite the former! A good approach is to use a graduate identifier or their name. Given that csv_file contains a column with header name with all the (unique) names of the graduates an example value would be: name 
cert_metadata_columns  Specifies the header of the columns and the respective data to be added in the metadata field for each individual certificate. Global fields, as specified by certificates_global_fields can also be specified here to be included in the metadata. Example: { “columns”: [ { “student_name”: { “label”: “Student Name”, “order”: 1, “hide”:false } } ] } 
Validation related   
f  Specify the PDF certificates to be validated. 
blockchain_services  For each supported blockchain one can specify the validation services to use and how many successes required. Example (and default): { “bitcoin”: { “services”: [ {“blockcypher”:{} } ], “required_successes”: 1} }. Currently, blockchains supported are ‘bitcoin’, ‘litecoin’, ‘bitcoin_testnet’ and ‘litecoin_testnet’. Bitcoin suports ‘blockcypher’, ‘btcd’ and ‘custom_api’: … {“btcd”: { “full_url”: “http://user:[email protected]:18334” }}. Litecoin currently supports ‘ltcd’ and ‘custom_api’. 
verify_issuer  Specify the methods that an issuer identity (Bitcoin address) can be validated. Example (and default): { “methods”: [] }. Possible values are … { “domain”: { “url”: “http://kkarasavvas.com” } } and { “github”: { “user”: “karask”, “gist_id”: “db951671b1af6b1edd56df06f1b9109a” } } 
Revocation related  Mutually exclusive options 
p  Specify the PDF certificates that we need to revoke. 
batch  Specify the transaction id of the issuance which we want to revoke/invalidate. 
address  Specify the address which will be revoked/invalidated. Not implemented yet. 
Blockchain related  Note: currently only Bitcoin’s blockchain is supported. 
blockchain  The blockchain network to anchor the hash data. Currently ‘bitcoin’ and ‘litecoin’ are supported. 
issuing_address  The blockchain (testnet or mainnet) address to use for creating the OP_RETURN transaction that will issue the documents merkle root hash in the blockchain. It should be either a legacy address or a native segiwit address and needs to have sufficient funds to cover just the fees of the transaction. If more funds are present we send them back as change to the same address. Make sure that you have the private key for this address safe since that might be the only formal way of proving who issued the certificates. Example for testnet: mgs9DLttzvWFkZ46YLSNKSZbgSNiMNUsdJ 
full_node_url  The URL of the full node together with the port. Example for testnet: 127.0.0.1:18332 
full_node_rpc_user  The name of the RPC user as configured in bitcoin.conf of the full node. Note that the RPC password is going to be asked during execution of the create-certificates script. Example: kostasnode 
full_node_rpc_password  The password of the RPC user as configured in bitcoin.conf of the full node. Note that the RPC password is going to be asked during execution of the create-certificates script. Example: kostastoolongtoguess 
testnet  Specifies whether it will use testnet of mainnet to issue the hash. Example: true 
tx_fee_per_byte  Specifies the mining fee to use per byte of the transaction’s size. Consult https://bitcoinfees.21.co or another site for possible values. Example value on Jan 2017 is: 100 
issuer_identifier  It is possible to specify a value (max 8 bytes/chars) that is added in the OP_RETURN transaction to differentiate the issuer. It is optional. Example value: “UNicDC “. 

 

 

For a detailed process and scripts, please refer to the original documentation.

 

3.5.2. Issuing Credentials 

 

Issuing certificates on the blockchain involves the following steps: 

 

  1. Adding Metadata to Credentials: Add programmatically retrievable metadata, including issuer and Bitcoin address, are added to each PDF credential. 

 

  1. Calculating the Merkle Root: A Merkle tree is formed from the hashes of all credentials, resulting in a Merkle root.

 

  1. Blockchain Issuance: A Bitcoin transaction with an OP_RETURN operator, containing the institution’s identifier and the Merkle root, is sent to a Bitcoin node. The transaction ID confirms the successful blockchain storage.

 

  1. Adding Blockchain Proof Metadata: Post-issuance, additional metadata proving their blockchain issuance are attached to the PDF of each credential. This includes the Merkle proof, Merkle root, and transaction ID. As we note in subsequent sessions the additional proof information is removed, reverting the credential to its post-step 1 state, to enable the validation process.

 

 

Fig. Add blockchain proof metadata each credential 

 

 

3.5.3. Validating Credentials 

 

The validation process involves a series of steps that ensure the authenticity and integrity of the certificates: 

 

  1. Extraction of Blockchain Proof Metadata: The first step involves extracting the blockchain proof metadata from the PDF credential. The metadata set includes essential details like the Merkle proof, Merkle root, and transaction identifier (TxID). 

 

Fig. Extract blockchain proof metadata 

 

  1. Certificate Hash Calculation: The hash of the PDF credential is recalculated. For this step the credential’s metadata are extracted and removed from the PDF. Removing the proof metadata, reverts the PDF to its original state; as it was when initially generated during the credential creation process. This is crucial because any modification to the certificate (including the set of metadata) would alter its hash, indicating tampering.  

 

 

Fig. Calculate the hash of the remaining certificate 

 

  1. Retrieving Merkle Root from Blockchain: Using the TxID from the extracted metadata, the transaction containing the OP_RETURN with the Merkle root is retrieved from the blockchain. 

 

Fig. Get the merkle root stored in the blockchain 

 

  1. Calculate Merkle root from proof and compare: The final step is to validate that the recalculated hash of the credential matches the hash stored in the blockchain. By reconstructing the Merkle root using the Merkle proof and comparing it to the Merkle root retrieved from the blockchain, it can be confirmed that the credential is unmodified and was indeed issued by the institution. 

 

Fig. Calculate Merkle root from proof and compare 

 

 

3.5.4. Revoking Credentials 

 

The Blockchain Document Issuing Protocol (BDIP) leverages the 80-byte OP_RETURN operator in Bitcoin transactions to define (encode) a meta-protocol that enables operations like: issuing, revoking batches or specific credentials, and revoking issuing addresses. The protocol defines the structure of the messages that can be encoded and the semantics of each. For each operation a separate transaction is issued which consists of an input; the Bitcoin address controlled by the issuing institution, an OP_RETURN output, and optionally a change output  

 

This decentralized approach is simple, intuitive, and independent, relying solely on the blockchain. The main limitation is the 80-byte constraint, allowing only two revocations per transaction (a separate transaction per two revocations). However, given the infrequency of revocations, this is a minor inconvenience, given the protocol’s efficiency and scalability. The revocation of an entire batch of credentials is also possible by revoking the Merkle root.  

 

  1. Message Operations and Structure:  

 

 

 

Each message is transmitted via a separate transaction and is composed of a header and payload. The header includes a protocol identifier (‘BDIP’ in ASCII, converted to hex), ensuring protocol-specific processing information. The header is 8 Bytes and is comprised of three parts: 

 

  1. Protocol identifier: An identifier for the protocol; the ASCII of ’BDIP’, which is 4 bytes and corresponds to ’42444950’ in hex 
  1. Protocol version: 2 bytes for a total of 65536 versions, starting with ’0001’ in hex 
  1. Protocol operation: 2 bytes for a total of 65536 operations 

 

Every operation starts with the above header being differentiated only by the last 2 bytes. The current BDIP-v1, defines the following five operations: 

 

OP_1 – Issue Operation (operation code: 0004): Issue a batch of credentials. 

 

 

Fig.   Issue credentials — structure / bytemap 

 

The issuer identifier is used to allows the issuer to apply a unique identifier to the issuer process which is visible in the OP_RETURN message on the blockchain. Although this identifier aids in distinguishing the issuer, it is not utilized in the validation process of the credentials. 

 

OP_2 – Issue Operation (operation code: 0006): Issue credentials with expiration. 

 

 

Fig. Issue credentials with expiry data — structure / bytemap 

 

This operation indicates the issuance of a batch of credentials with a predefined expiration. This operation expands upon the standard issuance by incorporating an expiration date, which can be specified as either Unix time or as a specific future block height on the blockchain. When validating these time-sensitive credentials, the expiry date is checked first, using Median Time-Past (MTP) conventions to resolve the exact timing. This ensures the credentials are valid only within the designated timeframe. 

 

OP_3 – Revoke a batch of redentials operation (operation code: 0008): Revoke batch operation. 

 

 

Fig.   Revoke a batch of credentials — structure / bytemap 

 

This operation enables the revocation of an entire batch of credentials. This operation requires the transaction ID(s) of the batch issuance to be revoked. For validation purposes, the revocation must originate from the same address as the initial issuance. During the validation process, any such revocation operations are considered to determine the current validity of credentials. 

 

OP_4 – Revoke credentials operation (operation code: 000c): Revokes specific credentials (max two credentials). 

 

 

Fig. Revoke specific credentials — structure / bytemap 

 

The operation allows for revocation of one or two specific credentials by specifying a transaction ID from a prior issuing operation and including the hashes of the credentials to be revoked. These hashes are processed with RIPEMD-160 to fit within the message constraints (20 bytes each). During validation, the credential’s RIPEMD-160 hash is checked against the revocation list. If there’s a match, the credential is considered revoked. This operation ensures that individual credentials can be selectively invalidated. 

 

 

 

OP_5 – Revoke address operation (operation code: ff00): Revokes issuance address 

 

 

Fig.   Revoke address — structure / bytemap 

 

This operation is used to invalidate an issuing address, ensuring that it can no longer be used to issue credentials. This is particularly useful in scenarios where the private key associated with an address has been compromised. The operation targets the public key hash format of the address; both compressed and uncompressed versions of the public key can be specified. Once this operation is executed, all future activities from the address are deemed invalid, although past operations remain unaffected.  

 

 

Validation Rules 

 

To validate a credential the following validation rules should be considered: 

 

  1. Verify the credential as detailed in Section 3.5.1 and confirm the issuing operation has at least one blockchain confirmation.
  2. Check for expiration:
  3. For block height-based expiry, validate against the current block height.
  4. For Unix time-based expiry, calculate the MTP and validate accordingly.
  5. Retrieve and examine all transactions for the issuing address prior to the credential’s issuance; if a revoke address operation is present, validation fails.
  6. Retrieve and examine all transactions post-issuance for revoke operations; fail validation if a revoke batch operation or a revoke credentials operation targets the credential’s hash.

 

This process, though complex, can be efficiently executed using optimized blockchain queries. 

GitHub Resources (License: MIT License)

Blockchain Certificates (main repo)

Methodology for creating PDF certificates (sample)

Methodology for issuing certificates (sample)

Revoking certificates (CRED Protocol)

We invite you to explore these resources for a comprehensive understanding of the technological innovation behind our blockchain-based academic credentialing system.

Continuing

Innovation

Moving forward from our BTC-based approach, our exploration has extended into the use of non-fungible tokens (NFTs) to address challenges in credentialing issuance and verification. Notably, in 2022, we launched META-511: an innovative, open-access course on NFTs and the Metaverse, uniquely conducted within the metaverse and utilizing on-chain technology. Additionally, we have pioneered the issuance of Generative art NFT certificates for this course. These certificates, hosted on-chain, offer a personalized approach to digital credentialing, reflecting our ongoing commitment to technological innovation in education.

Related

BLOCK.CO is a spin-off company of the University of Nicosia. It has for the last three years been active in the Blockchain credentialing space through their proprietary platform securing to date millions of documents on the Blockchain.

Publications

Revoking Records in an Immutable Ledger: A Platform for Issuing and Revoking Official Documents on Public Blockchains

K. Karasavvas, “Revoking Records in an Immutable Ledger: A Platform for Issuing and Revoking Official Documents on Public Blockchains,” 2018 Crypto Valley Conference on Blockchain Technology (CVCBT), Zug, Switzerland, 2018, pp. 105-111, doi: 10.1109/CVCBT.2018.00019.