In our last post, we talked about how eContracts are only different from physical contracts in ‘form’. We also concluded that electronic execution is critical to create a valid eContract.
Finally, we saw that the IT Act provides for both – electronic signatures and other electronic authentication methods. We discussed how, within electronic signatures – the IT Act provided for 2 types – digital signatures AND those specified in Schedule II of the IT Act.
In this post, we are going to focus on the first type – digital signatures. We will answer the question – What is a digital signature?’
We will learn about this concept through the eyes of two intrepid software professionals – Tanuj and Waqim.
We will learn this concept through the eyes of two intrepid software professionals – Tanuj and Waqim.
Waqim wants to learn the guitar. Tanuj knows how to play a guitar.
Tanuj is willing to hold weekly guitar classes exclusively for Waqim. But not for free. He wants 4 Toblerones every month – one for each week.
They quickly draw up the terms of their agreement on Word
While Tanuj fully trusts his good friend Waqim, he still cannot take any chances.
He is going to be expending significant resources and time in preparing a monthly lesson plan for Waqim. So he wants to ensure trust and credibility in the transaction in a foolproof way.
To do this, Tanuj wants Waqim to sign the agreement.
Ordinarily, they would print it and both sign on the sheet. But there’s a pandemic raging – and they find themselves 500km apart.
Sure they could courier it and all that.
But Waqim wants to start lessons right away (through Zoom of course).
He has already bought a new guitar, a pick, 8 backup picks AND a Hendrix wig as well. Naturally – he cannot wait.
So they decided to execute a eContract.
To start with, Waqim saves the final draft as a PDF.
Now if you read last week’s post you’d know that Waqim has two options to execute this eContract:
Tanuj insists on an electronic signature.
“Ok, but what kind of electronic signature Tanuj?” asks Waqim.
Indian law defines two types of electronic signatures:
“What’s a digital signature? I’ve heard this term before” asks Tanuj.
Waqim – who for some reason is intimately familiar with digital signatures – begins to explain.
A Digital Signature is a combination of algorithmic processes.
When applied to an eContract, a digital signature:
The algorithmic processes for digital signatures are largely the same around the world. However their role and form in the legal contracting differs country-wise by regulation.
In India, the Information Technology Act, 2000 (“IT Act“) and various accompanying regulations GIVE LIFE to digital signatures.
In this piece, we will explain the technical process of a Digital Signature – step by step. At each step, we will also identify what legal provision or regulation is relevant for that step.
Right, let’s begin.
To perform the digital signature process, you need 3 starting ingredients –
Without an electronic record – you will have nothing to affix the signature on! It’s pretty much the whole point of the digital signing process.
Section 2(1)(t) of the IT Act defines electronic record as:
For all practical purposes, ANY piece of information that is in electronic form is an electronic record.
But, practically, digital signatures can only be applied upon electronic records which are either PDFs or XMLs (we will analyse why this is in a subsequent post)
Digital signatures rely on a process known as asymmetric cryptography.
Asymmetric cryptography is itself a further combination of 2 functions:
The private key is UNIQUE and CONFIDENTIAL to the signer that owns the key pair.
The public key UNIQUE but NOT CONFIDENTIAL to the signer. It can, and must, be seen by anyone who views the digital signature.
A Private Key and Public Key in the same key pair are inextricably connected
The two keys together are known as the Secure Key Pair.
Legal: Section 2(1)(z) of the IT Act) legally defines Secure Key Pair
Legal: The necessity of the Secure Key Pair in the digital signing process is laid down in Section 3(2) of the IT Act:
A hash function is – an algorithm – that derives a unique alphanumeric code to represent a particular electronic record. This code is known as a Hash Result.
A Hash Result is essentially the algorithmic fingerprint of an electronic record.
2 things you need to remember about Hash Results:
Clarification: hash result represents the electronic record ONLY AT THE TIME at which the hash function was performed. If even a full stop is added to the electronic record, the hash result changes. The document basically becomes a new document.
Legal: the Hash Function is specifically elaborated in the Explanation to Section 3(2) of the IT Act:
The explanation of Hash Function in Section 3(2) of the IT Act
2 of the starting ingredients above – the Hash Function and the Secure Key Pair are stored in a common “container”.
This container is known as a Hardware Security Module.
The Hardware Security Module is activated by a Unique PIN or Identifier. So, if someone wants to use the Hash Function AND Secure Key Pair on the device – the device will ask them to enter a Unique PIN or Identifier.
Upon entering the Unique PIN – BOTH the Hash Function AND the Secure Key Pair are activated
This is an important security measure to prevent unauthorized use of the algorithms.
The Hardware Security Module is a piece of hardware with cryptoprocessor chips. It can come in various forms – but is usually a detachable device.
A very common example of a Hardware Security Module is the USB Pendrive on which DSC Tokens are stored.
Waqim is now ready to begin the digital signature process.
This is what he has so far:
Waqim inserts his USB Device containing the digital signature into his laptop – and, on the PDF reader – indicates that he wants to sign the document.
The software client opens up and asks him for his Unique PIN. He enters his PIN.
The hash function contained in the Hardware Security Module generates a unique hash result for the PDF copy of Waqim and Tanuj’s contract.
Thus, the electronic record now has a unique hash result.
Waqim’s private key gets to work and encrypts the hash result generated in the first step. This encryption derives a scrambled hash result for the electronic record.
Waqim now has a scrambled hash result for the electronic record (the PDF Contract).
Both the scrambled hash and public key are stored on what is known as a ‘Digital Signature Certificate’ and are affixed on the document
In India, a “Digital Signature Certificate” is also known as an “Electronic Signature Certificate”
In this case, a Digital Signature Certificate containing the scrambled hash result – ABC997196 and Waqim’s public key is affixed on the PDF Contract.
When this happens – a document is said to be digitally signed.
But the digital signature process is still not over.
Waqim sends the agreement to Tanuj.
The document opens on Tanuj’s PDF reader.
What follows is an elegant three part process:
(I) The same hash function is performed on the document itself – with the same algorithm. This shows Tanuj the hash result of the signed document. If the document has not been changed then the hash will be identical to the one derived from the first part of the digital signing process.
(II) The Public Key decrypts the scrambled hash result contained in the Digital Signature Certificate.
Remember, the decryption will only work if the Public Key corresponds to the Private Key used to perform the encryption. If the Public Key is unable to decrypt – then the signature is considered invalid.
(III) Both hash results – the one derived from the contract when the fresh hash function is applied AND the unscrambled hash contained in the Digital Signature Certificate – get MATCHED with each other.
IF both hashes are identical then the integrity of the document is assured AND the digital signature is verified to be valid.
If they do not match – then the signature is shown as invalid.
And this, in essence, is how the Digital Signature process works!
What if there are multiple signatures on a document?
If, in the above example, Tanuj also signed the document. Would the hash of the document not change? And if so, wouldn’t Waqim’s signature be invalidated? Not quite.
PDF Reader’s REMEMBER the history of hash results of a document!
So, if Tanuj signs the document – a new hash result is indeed generated. But the PDF reader WON’T FORGET the hash result of the document when Waqim had signed it.
This ensures that even if Tanuj signs it – the PDF reader is able to validate BOTH signatures.
If Tanuj CHANGES a part of the document and then signs it – then Waqim’s signature will be invalidated.
If Tanuj doesn’t change anything in the document and merely digitally signs it – then both signatures will be deemed valid.
The law does not crystallise this process. But it is inherent to PDF technology itself. In fact, one could say that the law and accompanying regulations (like the CCA regulations) that have been drafted keeping in mind this technological feature!
To evaluate the efficacy of digital signatures, it is important to see how they meet the end goals of the signing process that we discussed in our first post.
The digital signature process seems to meet ALL the end goals!
Read goal one of the signature process above – identifying the signatories. This refers to the human identity of the signatory. People want to sign things with other humans – not algorithms.
In the above example – did the digital signature actually identify Waqim?
We did establish that the key pair was a functioning, secure system. But this merely provided algorithmic consistency. We didn’t know how the secure key pair itself tied back to Waqim the human.
We just assumed it.
Such assumptions work well in thought experiments designed to convey a point. But in real life, digital signatures can’t operate on the basis of such assumptions.
We need someone to actually certify that the secure key pair indeed belongs to the signer.
This certification is performed, world over, by neutral, trusted entities known as Certifying Authorities.
The 2 primary functions of Certifying Authorities are:
Legal: In India, Section 35 of the IT Act gives Certifying Authorities power to issue Electronic Signature Certificates and Section 36 details the scrutiny that a Certifying Authority must apply for issuance
Certifying Authorities are, in turn, licensed by a master regulator – the Controller for Certifying Authorities.
Legal: Section 18 of the IT Act lays down the Functions of the Controller
The CCA also has several specific guidelines that govern both CAs and Electronic signatures on their website. We will be covering these in more detail in a subsequent post.
Anyone applying for a Digital Signature Certificate will need to undergo a KYC process before the Certifying Authority. The KYC process will involve identity verification through personal identity documents – just like when opening a Bank Account.
Once KYC has been successfully complete the Certifying Authority will issue an Electronic/Digital Signature Certificate to the subscriber consisting of a Secure Key Pair AND basic details describing the subscriber (name, gender etc.).
The Electronic/Digital Signature Certificate is digitally signed by the Certifying Authority itself – to ensure its integrity.
It is impossible for the subscriber to receive a Digital Signature Certificate in the name of any other person – because the Certifying Authority’s KYC process will not allow this.
So, in reality, Waqim’s Digital Signature Certificate would also contain his personal details and not just the public key and scrambled hash represented in our thought experiment above.
When Tanuj receives the document with Waqim’s digital signature he is:
Therefore, identity of the signer is ensured in a watertight manner in the digital signature process.
In our next post, we will analyse the second type of electronic signature – Schedule II Notified signatures – of which the most common is the Aadhaar eSign.
Don’t miss a single post of The eContract Bulletin – subscribe to our mailing list HERE.
Already subscribed? Then do spread the word and share the subscription link to friends, family, colleagues who may also find this relevant.
We’d also love to hear what YOU think about the Bulletin so far. Right over here