Blockchain-based certificate...useless?


#1

Hi I’ve recently become very interested in Blockcert’s approach on issuing digital certificates.

I just have a quick question. If checking the issuing organization is solely (I might be wrong) based on checking the input address of a transaction and matching it with the address specified on the Blockchain certificate, how does it stop someone from creating a transaction later in time, creating a Blockchain certificate, and claiming that the transaction and the issuing address belong to a specific organization? (MIT for example?). As an employer I wouldn’t be able to figure out due to Bitcoin’s anonymity.

Thank you!


#2

Someone please let me know if it was an idiotic question or there’s an actual way to patch this issue. Because from my understanding of blockchain and blockcerts , not only is this blockchain-based certificate essentially useless, it opens up other ways for people to exploit it. How does this stop me from:

1)Creating a transaction today on the bitcoin network with op_return value that matches the hash of my fake diploma

2)Generate a blockchain-certificate with all the information such as the correct timestamp, hashes, merkle proof, issuing address, etc

3)Give it to my employer and say, ‘hey, you can validate this using bitcoin blockchain!’

Now the problems:

  1. The receipt in the blockchain-certificate is authentic. The timestamp, hashvalue, and issuing address will match with a transaction posted on 3rd party sites such as blockchain.info, because the transaction in fact, did take place at that time.

  2. Sure, the employer could say, “hey but does this issuing address really belong to MIT?” The only way he could find out would be to call and ask MIT, which essentially makes this “blockchain-based certificate” thing pointless because the goal of it is to remove disintermediation in verification of certificates.

  3. Now the exploiters don’t even need to try hard to make their documents look authentic. All they have to do is make a poorly attempted certificate and make a transaction on the blockchain and claim that it is authentic because it is backed up by bitcoin blockchain. As for the issuing address, no one can’t prove that it’s not MIT unless they contact MIT directly.

Am I missing an important piece of information here? I just don’t see here how this will actually help prevent academic fraud instead of creating some serious issues.

Thank you!


#3

Before the coming of these blockchain-certificates, the only way one can create falsified diploma that can pass verification by an issuing institution is by having an insider, who can register in its database as valid. But this also means that the insider can also create an authentic document, which is basically game over.

I thought Blockchain-certificate was meant to address this very issue, and allow one to validate the document anywhere, anytime, without an intermediary (such as the institution itself), but I just don’t see how it can do that.

Also, having a validating web service (such as https://credentials.mit.edu/) further removes the need for blockchain-based certificates, because

  1. If you have to go to a validation site hosted by an institution to validate (again, https://credentials.mit.edu/), then you are essentially trusting that the institution has not been hacked. Then what’s the point of having blockchain anyways? If you trust the institution, how is storing the hash of the certificate in the institution’s database, and comparing it with the hash of the uploaded document any less secure? Why do you need blockchain?

  2. But you might say, “oh but you can find it in the bitcoin blockchain!”. Well, anyone could’ve created the transaction. You can create a falsified document, create a valid transaction and a receipt, and later claim that the document is authentic. You might also say, “well you can go to MIT website and find out their issuing address and see if it matches up!” Well now it’s the repeat of problem 1).

This is actually worse than the current system because now anyone (with a bit of knowledge in blockchain) can create a “blockchain-passable” certificate, without having to hack or make an effort to create a good counterfeit one.
I think the most important issue that we need to address is not the proof-of-existence of the document, but rather associating a transaction to the issuing institution in a way that can be fully trusted, even when the issuing institution can’t be.


#4

Hi Justin,
Sorry for the delay – this post just came to my attention today. These are great questions, and we wanted to give you a quick answer, so @downie and I worked together to write up detailed responses. Please let us know if we missed any parts of your questions; these are excellent discussion points.

Checking the issuing organization during verification (now and roadmap)

If checking the issuing organization is solely (I might be wrong) based on checking the input address of a transaction and matching it with the address specified on the Blockchain certificate, how does it stop someone from creating a transaction later in time, creating a Blockchain certificate, and claiming that the transaction and the issuing address belong to a specific organization? (MIT for example?). As an employer I wouldn’t be able to figure out due to Bitcoin’s anonymity.

The premise (first sentence) isn’t correct; here’s how it works. The input address of the transaction is cross-checked against the issuer’s URL identifier, which is embedded in the certificate. This is step 1 of the Linked Data Signatures Signature Verification Algorithm (section 7.2):

7.2 Signature Verification Algorithm

Step 1: Get the public key by dereferencing its URL identifier in the signature node of the default graph of signed document. Confirm that the linked data document that describes the public key specifies its owner and that its owner’s URL identifier can be dereferenced to reveal a bi-directional link back to the key. Ensure that the key’s owner is a trusted entity before proceeding to the next step.

Note that, at face value, this presents centralization, availability, and longevity concerns (what if the issuer site is temporarily or permanently unavailable?) First let me unpack these, and provide context about how this will be addressed. (Later we’ll explore threats such as a compromised issuer site.)

Relying on an issuer-hosted URL puts a burden on the issuer to ensure this identifier page is available. Failing to do so compromises the certificate’s longevity. This is an issue we raise in our documentation, and we strongly advise issuers to use permanent URLs, but this is only a very short term mitigation. We describe this for example in this post.

The next phase in our roadmap replaces this form of identification with Decentralized Identifiers (DIDs), which address not only the availability concern, but also our concerns more broadly about the issuer as a SPOF and centralization point. See the DID Specification draft and the DID primer for a friendlier introduction.

Note that the group behind JSON-LD signature suites is the same one that’s drafting the DID specification, and this exact scenario is one of many DIDs are meant to address. That group is the W3C Credentials CG (Kim is co-chair).

Also note: many DID method specifications rely on a blockchain, and expanding on the longevity concerns, we are thinking through scenarios such as blockchains becoming obsolete (which can actually be mitigated through cross-chain transactions).

Detecting fraudulent issuances

But this also means that the insider can also create an authentic document, which is basically game over.

This is actually an argument for public blockchains; as any transactions against a known set of keys you are monitoring are immediately evident. Address monitoring makes it easier to detect an insider issuing a fraudulent certificate.

Verification and Trust

No one needs to store the hash

If you trust the institution, how is storing the hash of the certificate in the institution’s database, and comparing it with the hash of the uploaded document any less secure?

It’s not stored in the institution’s database, or anywhere. JSON-LD signatures and verification avoid the need to store the hash separately. Both signing and verification canonicalize the document (minus the signature) to ensure a consistent hash. Any attempts to tamper with the content will cause it to fail validation. See the RDF Dataset Normalization standard for details.

Combining the hash with the merkle proof (in the signature section) results in a merkle root which is compared against the value in the blockchain transaction record. This is the JSON-LD signature suite called Merkle Proof Signature Suite 2017,

Who do I need to trust to perform verification?

The short answer is you don’t need to trust anyone, and it’s expected that high-stakes verifiers will use a more hardened approach than used in lightweight demonstration verifiers.

The details break down into 2 aspects: where the verifier service is running and how blockchain transaction lookups are performed (for the certificate hash and, soon, DID record).

Looking up Blockchain transactions

As mentioned in cert-verifier-js README, relying on a blockchain API enables client-side transaction lookup and is a useful way to demonstrate Blockcerts verification without intensive hardware/deployment requirements.

But using a blockchain transaction lookup service is effectively putting trust into that service, but that service could be compromised in a number of ways.

The most secure approach is to run a blockchain node and look up the transaction directly. This requires machine resources that may not be feasible in all deployments. In between there are options such as lightweight verifying nodes. At minimum, an approach that rules out some attack vectors is to check multiple services to see if they agree (as enabled by cert-verfier-js).

Where the service runs

This is similar to the above (blockchain tx lookup) range of options. The simplest way to run the verification service is also the least secure – that is to the cert-web-component with in-browser verification. In a world of trustworthy people, this is by far the most convenient way to display and verify certificates. In the eye of a hacker, it’s trivial to alter/inject code to verify false documents.

However, the verifier service does not have to run in-browser. The most secure option is to run the verification service in an isolated network environment (with access to the local blockchain node, as described above).


I think we hit everything. Please let us know if you have any questions.

Thanks,
Kim and @downie


#5

Thank you Kim and @downie I really appreciate your response.