Counterfeit academic certificates have been a longstanding issue in the academic community. Not until the Massachusetts Institute of Technology Media Lab released their project of Blockcerts, a technique which is mainly implemented by conflating the hash value of local files to the blockchain but remains numerous issues, did an effective technological approach protecting authentic credential certification and reputation appear.
Based on Blockcerts, a series of cryptographic solutions are proposed to resolve the issues above, including, utilizing a multi-signature scheme to ameliorate the authentication of certificates; exerting a safe revocation mechanism to improve the reliability of certificates revocation; establishing a secure federated identification to confirm the identity of the issuing institution.
The project consists of designing and implementing the system using Java and Javascript which covered the above solutions. The project also involves a comprehensive evaluation of the system security, and the assessment outcomes provide compelling evidence to prove that implementation is practical, reliable, secured, which might give some hints of important architectural considerations about the security attributes of other blockchain-based systems.
Congratulations on implementing the Blockcerts. I’m myself trying to implement a simplified model of Blockcerts and I’m facing lots of difficulties understanding the concepts, mostly because I have no previous exposure to bitcoin or blockchain technology. Anyways, good job.
The Blockchain-based method succeeded in protecting the integrity and authenticity of the certificate, however, it is not free from drawbacks. Its shortcomings ranged from forgery preventing, revocation mechanization to identity proving. We summarized the weakness as follows: Key Security Problem
A single private key combined with BTC address is used in Blockcerts to verify the identity of a certificate awarding institution, indicating that such private key can be adopted to pay and attach a student’s digital certificate hashes as reference. However, single private key management scheme adopted by MIT is highly risky. Firstly, if the only private key, a randomly selected number on which the limits of authority of issuing digital certificates depend, is stolen or erased, the new possessor becomes able to release or revoke whatever records they want. What is worse, any changes made illegally in blockchain will be immutable. In short, the key security problem is the core one that makes the project impractical to some degree. Secondly, the right of issuing certificates is monopolized by the exact person owning the private key, which brings up lots of rights problem like corruption. Certificate Revocation Problem
The revocation mechanism in Blockcerts version 2.0 is designed to check the URL-based certificate revocation list(UCRL), UCRL is an URL for querying the list of certificates that having been revoked by the awarding institution before their expected expiry dates. In other words, for verifying each certificate authenticity and integrity, it is required to check the revocation list by this URL. Whereas considering that the URL is fixed and embedded in the issued certificates, it is unreasonable to assume that it was completely reliable. Alternately, the URL represents a single point of failure which caused the revocation mechanism unreliable and vulnerable. Certificate Awarding Institution’s Identity Problem
In Blockcerts version 2.0, to determine whether a certificate is real or not, an independent verifier only needs to verify the timestamp and the issuing key owner. Specifically speaking, such auditor is only required to confirm the certificate awarding institution did own the key when the certificate was awarded. However, the project failed to provide this confirmation functionality, as identity proof was still regarded as an external layer in Blockcerts 2.0. @kim
Hi Rujia,
The issues you mention are on our roadmap, and we’ve been actively working on them, e.g issuer identity through DIDs.
My concern is that you are not (as far as I can tell) describing your technical approach or releasing source code. So we cannot tell if your approach to solving them is proprietary, or even valid.
I welcome you to address this concern by providing technical details and source code, otherwise we will need to flag your posts as potentially misleading. It would be irresponsible of us to allow vendors to advertise Blockcerts-compatible claims without proper warning to our readers.
You are right. my posts tend to cause some misleadings to the reader, I apologize for these posts and you can delete that post directly. It seems that the BTCert project is trying to solve technical problems itself but not Blockcerts for the reasons that:
1 So far, the issues such as certificate revocation and issuer identity had been solved or are solving by the Blockcerts.
2 I have not forked and submitted the Blockcerts code, from this point, I can not say I have fixed Blockcerts problems.
3 BTCert is a project which only based on the concept and standard of Blockcert but not the code and it is a totally new project which is implemented via Java and javascript. So, what I have done on BTCert has no relationship with Blockcerts.
BTCert is only a mini project for my master degree and has no commercial use. My original intention is to promote the Blockcerts and try to persuade our university to use but failed. In my next plan, I will try to add the multi-signature function for the Blockcerts as a component if you welcome.
Lastly, since BTCert is sponsored by ITIC University of Birmingham, I will ask them whether it is ok for me to publish the code, I will release them as soon as possible once I get the permission.
I am implementing block cert with etherum everything was working fine till yesterday and suddenly it started to show insufficient balance. But i confired my accout has 7 ether. I am testing with Ropsten test network. is there anybody to help me on this?