Avoiding malicious transactions to be added in blockchain

Technical
#1

Hi,

I went through the technology in https://www.youtube.com/watch?v=cEo_XwOpaow. It looks interesting. Thanks for sharing the knowledge to the world :clap:. However am curious to know how the following case is handled.

My understanding:

  • Student requests for certificate, as a part of the request a public key is sent to the issuer.
  • The issuer creates a certificate, adds the hash of the certificate to the blockchain and sends it back to the Student.
  • The certificate sent to the student contains the following:
    a.Transaction address
    b. Public key of the institution.
  • Verifying party does the following:
    a. Computes the hash of the local certificate
    b. Compares the local hash with the block hash (of the transaction address mentioned in the cerificare.
    c. Verifies the signature of the institution
    d. If the above two (b and c) looks good, then the certificate is valid

What am failing to understand
Can’t the person with an intent to forge the certificate do the following:

  1. Create a transaction that contains the hash of the forged certificate and add it to the blockchain.
  2. Modify the public key present in the certificate to be the key corresponding to forged transaction’s public key
  3. Modify the transaction address present in the certificate to the forged transaction.

What connection am missing here? Please explain.
Thanks for your help.

#2

Vivek,

Let me make one unrelated correction and then explain the answer to your larger question.

Small Correction
The Certificate also contains the recipient’s public key, which is generated by the mobile app and sent to the issuer during the handshake (when the recipient is adding this issuer). It is by virtue of the record containing the recipient’s key that they can prove ownership of it later.

Answer
A hash of the local certificate is generated at the time of verification using JSON LD normalization, and compared to the one stored on the blockchain. The hash is not stored in the certificate itself. This way the verifier knows that nothing has been tampered with since it was originally issued. It is not possible to create a fake certificate that generates the same hash as another legitimate certificate.

I hope this helps! Great question.

#3

Hi Chris,

Thanks for taking time to respond! Appreciate your help.

Additionally just give you some context about me, I am a graduate student specializing in networking, and am looking for some network/digital security projects to contribute/work on as that will give me learning, and also a satisfaction of contributing to something progressive. That’s the background of why am asking these questions :slight_smile:

Since am new to this technology, am still missing some connect. This question is in the following statement

A hash of the local certificate is generated at the time of verification using JSON LD normalization, and compared to the one stored on the blockchain.

Question:
To compare the hash generated during the verification process with the one in block chain, we need some reference to that transaction in the block-chain, and I believe that reference is provided by the ‘Block-chain address’ field which is stored in clear in the certificate. So the question is what if a malicious party does the following

  1. Changes the certificate (to whatever he wants), and computes the hash of the new certificate and adds it to the block chain.
  2. Make the block-chain address in the certificate point to the block-chain address of the transaction in step-1.
  3. Of-course step-1 will lead to change in hash, but since that hash is compared against the malicious transaction and not the original transaction corresponding to the University, the verify code will pass right?

In order for the above not to happen, either of the following should be true:

  1. Blockchain should be private.
  2. Ownership of public key is assumed. (Means verifying party knows that the specific public key belongs to the institution, and not anyone else). If that’s the case then malicious transactions (by public keys other than institutions) can be filtered.
  3. Or am missing something basic :slight_smile:
#4

Pretty interesting. The original transaction and the malicious transaction would have different signatures, because the fraud would need to use his own private key to write his new malicious receipt to the blockchain.

This means the new certificate would need to contain the fraud’s public key now, rather than the proper university’s public key as it did initially, in order to pass the verifier’s initial checks.

Which means I agree that this condition must be true in order for us to feel safe: "Verifying party knows that the specific public key belongs to the institution, and not anyone else"

Something like a public registry, where we can link our identities to our public keys, might be of use in the near future.

Although we could both be missing something basic :smirk: