The e-sign conundrum


(P.S:  This post tries to explain the “e-sign” system of authentication of an electronic document as per the provisions of Information Technology Act 2000 as amended in 2008 -ITA 2000/8, for the benefit of students and teachers of Cyber Law. 

This is also an addendum to the e-Books published by Naavi such as Cyber Laws for Engineers”, “Cyber Crimes and ITA 2008” and “Cyber Laws for Everyone”.

I would like to however add a caveat that Naavi considers that some of the provisions of e-Sign are not completely compliant to the parent law namely ITA 2000/8 and hence can be questioned for its legality. I have brought this to the attention of CCA and sought clarifications but have failed to receive any response.

It looks strange that I have to raise Cyber Law related questions on CCA which itself is a statutory authority to frame the laws of digital signature. It is perhaps like Carrying Coal to Newcastle!. But when the law makers themselves seem to be faltering in law compliance, it is difficult not to voice the opinion even if it is futile. 

These academic discussions about the legality apart, students of Cyber Law may kindly note that even if it is a bad law, the law related to e-sign is a reality and they may take cognizance of the same for academic purpose.

It may take several years before a Cyber Law understanding Supreme Court Judge will emerge in India who will try to provide necessary legal guidance to the Government on how to properly interpret the law as in the books.

In the meantime, some Judges may even uphold the law as made by the Government and ignore the inconsistencies with the ITA 2000/8.

Hence students who write examinations in Cyber Law and teachers who teach Cyber Laws may teach what the Government has proposed which is contained here in… Naavi)

When Information Technology Act 2000 (ITA 2000) was drafted as “Draft E-Commerce Act 1998”, by the then Union Commerce Ministry, the draft was focussed on providing legal recognition to Electronic Commerce Transactions.

Hence the Act was drafted keeping in view the need to provide legal recognition to Electronic Documents and a method of authentication of electronic documents.

The very first draft of the “Draft E Commerce Act 1998” drew heavily on the then present laws of Malaysia and Singapore besides adopting the E-Contract related provisions in the UNCITRAL Model Act 1996. (The developments have been traced by Naavi here).

This “Draft E Commerce Act 1998” was an excellent provision and the next replacement draft in the form of “Information Technology Bill 1999” which later became the “Information Technology Act 2000” (ITA 2000) was not as good as the draft of the Commerce department. Nevertheless it is the law of the land which became effective from 17th October 2000. This was further amended with effect from 27th October 2009 which we call as the ITA 2008.

ITA 2000 adopted a form of authentication which was called “Digital Signature” based on the PKI system. This  used Hashing of a document and its encryption with the use of the Private key of an individual created in an Asymmetric Crypto System as the system of authentication of an electronic document recognized as equivalent to a physical signature.

After the digital signature system was adopted in law as the only form of authentication of an electronic document, several voices were raised that authentication system in ITA 2000 was digital signature technology dependent  and is not “Technology neutral”.  It is interesting to observe that the original draft in the “Draft E Commerce Act 1998” was completely technology neutral as it stated:

 

8. Electronic Signatures. Except as provided in Section 4, where any rule of law requires that a record bear a signature, or provides for certain consequences if a record is not signed, an electronic signature satisfies that rule of law if:

(a) a method is used to identify the originator and to indicate the originator’s approval of the information contained in the electronic record; and

(b) that method is as reliable as was appropriate for the purpose for which the electronic record was generated or communicated, in light of all of the circumstances, including any relevant agreements among the parties involved.

The cry of technologists for the system of authentication to be “Technology neutral” was addressed in the amendments of 2008 when new enabling provisions were introduced to enable alternative technologies to the PKI system adopted by Digital Signatures. The system of approved authentication was termed as “Electronic Signature” and the PKI based digital signature was declared as one of the types of Electronic Signatures and continued to be the sole system then recognized.

Though an alternate electronic signature technology that could be used either as a replacement of or as a modification of the digital signature system was possible since 27th October 2009, it was not until 2015 that an alternate system came into reckoning in the form of “e-sign”.

This discussion is on this new system which has been notified as an “Electronic Signature” in the Second Schedule of the ITA 2008 (the version of ITA 2000 after incorporating the amendments of 2008) and recommended to be used in the “Digi-Locker” system of the Government of India and also the e-KYC system using Aadhar which is likely to be used extensively in the coming days in many critical electronic commerce activities.

The undersigned has brought to the attention of the CCA (Controller of Certifying Authorities) certain doubts about the compliance of the proposed system to Information Technology Act 2000/8 but has not been able to get a reply. Let’s ignore these objections for the time being and see what is the new law of e-sign.

On 28th January 2015,  Government of India through its gazette notification number G.S.R. 61(E), published the rules called “Electronic Signatures or Electronic Authentication Technique and Procedure Rules 2015” to come into force immediately.

These rules added the following into the Second Schedule of Information Technology Act 2000 (21 of 2000).

(P.S: This version of ITA 2000 is the 2008 version of the Act in which the earlier Schedules numbered as First, Second, Third and Fourth Schedules were replaced with a set of new schedules numbered as First and Second Schedule.)

Sl No Description Procedure
1 e-authentication technique using Aadhaar e-KYC services Authentication of an electronic record by e-authentication Technique which shall be done by-

(a) the applicable use of e-authentication, hash, and asymmetric crypto system techniques, leading to issuance of Digital Signature Certificate by Certifying Authority

(b) a trusted third party service by subscriber’s key pair-generation, storing of key pairs on hardware security module and creation of digital signature provided that the trusted third party shall be offered by the certifying authority. The trusted third party shall send application form and certificate signing request to the Certifying Authority for issuing a Digital Signature Certificate to the subscriber.

(c) Issuance of Digital Signature Certificate by Certifying Authority shall be based on e-authentication, particulars specified in Form C of Schedule IV of the Information Technology (Certifying Authorities) Rules, 2000, digitally signed verified information from Aadhaar e-KYC services and electronic consent of Digital Signature Certificate applicant.

(d) The manner and requirements for e-authentication shall be as issued by the Controller from time to time.

(e) The security procedure for creating the subscriber’s key pair shall be in accordance with the e-authentication guidelines issued by the Controller.

(f) The standards referred to in rule 6 of the Information Technology (Certifying Authorities) Rules, 2000 shall be complied with, in so far as they relate to the certification function of public key of Digital Signature Certificate applicant.

(g) The manner in which information is authenticated by means of digital signature shall comply with the standards specified in rule 6 of the Information Technology (Certifying Authorities) Rules, 2000 in so far as they relate to the creation, storage and transmission of Digital Signature Certificate.”

 

The key aspects of this notification are :

  1. This notification was issued in order to provide acceptance of the Aadhar E-KYC services.
  2. The issuance of Digital Certificate was by a Certifying authority but based on the e-authentication of the application form of the subscriber using the e-KYC services of Aadhar
  3. The e-KYC process included “Digital Signature of the Aadhar authorities” but only an “E-Consent” of the subscriber.
    In other words, the subscriber application did not carry the authentication as required by ITA 2000/8 but the UIDAI sending the KYC information such as the name, address, e-mail address etc as contained in the subscriber’s  application form with UIDAI’s digital signature.
  4. The request for digital signature certificate will be received by the Certifying authority from a “Trusted Third Party” who generates the key pair in a “hardware security module”. (It is understood that the trusted third party should be a Registration Authority appointed by the Certifying Authority)
  5. Further detailed instruction to be issued by the Controller from time to time.
  6. CCA issued the more detailed instructions on the use of the e-sign process in its e-authentication guidelines issued on 24th June 2015.

In this entire process, the Certifying Authority is receiving a “Request for issue of digital certificate” from its own agent namely the Regisration authority. (e-Sign Service Provider).

In the normal digital signature certificate issue process, the agent would be responsible for doing the KYC process. In the e-sign process, the agent is using a verification of the subscriber information from the UIDAI authorities under their digital signature.

The request for digital signature is however triggered by the aadhar holder who wants to avail some online service where there is a need for digital signature. It could be a digi-locker service or a banking service. Then that service provider would send a request for digital signature issue online to the Certifying authority through its designated registration agency which is capable of issuing online digital certificates.

This request from the e-sign user agency may come in the form of an API integration of its own service with the e-sign issue service.  i.e. Let’s say Mr X requests a Bank Y to withdraw some money from his account. Bank Y wants the request to be digitally signed and wants to use the e-sign system. It then contracts with a Certifying Authority for issue of e-sign certificates.  The Certifying authority requests a Registration Authority to manage the application processing. The registration authority will develop an API to be used by the Bank to deliver its service.

Let’s now look at the process in the light of a use case where a customer of an online Bank is using a withdrawal service from the Bank supported by an e-sign.

When the customer  Mr X completes the form for withdrawal of money from the Bank, simultaneous to the completion of the online withdrawal form, a request for e-sign certificate is generated with the particulars of the customer of the Bank already available.

This is sent by the Bank to the registration authority and then on to the Certifying authority.

When the registration authority sends the application form to the certifying authority, it sends the application along with a public key generated from the pair of keys randomly generated by its HSM (hardware security module).

The private key  generated in the process remains in the HSM and the public key comes back as a e-sign digital certificate.

The bank withdrawal form will be signed with the e-sign in the name of the subscriber but by the use of the private key pulled from the HSM in the control of the Registration Authority. The Bank based on this e-sign digital signature request acts on the withdrawal form and dispenses the amount.

In the above process, it must be recognized that e-Sign digital signature process is rendered subordinate to the Aadhar system.  For example,  the authentication of the subscriber is done with reference to the records about the subscriber held by the UIDAI. The request for this records is generated by the API upon the subscriber providing either his biometric details or through the use of OTP.

The UIDAI system checks the biometric or the OTP and then confirms the information that is available in the e-Sign application form as correct or not. If it says Mr X is Mr X and his address and e-mail address matches the UIDAI records, then the e-Sign process will issue the digital certificate in that person’s name. If the e-mail address is not available with the UIDAI or is a shared e-mail address, the Aadhar authentication is done with reference to such un available or shared e-mail address.

Since the e-KYC system can be used even with an OTP, the system will send a PIN to a mobile number given by the subscriber Mr X in his service application form and if it is received back, will assume that Mr X is what he claims to be.

If the mobile number available in the Aadhar registration is a shared mobile, then the OTP authentication is done with reference to the shared mobile. Also the authenticity based on the mobile means that the KYC of the mobile  operator becomes the reference point for the KYC under the e-KYC system of Aadhar which in turn becomes the reference point for the e-Sign subscriber identification.

While the above records the way the e-sign system is supposed to work, let’s now look at how e-Sign compares to the normal digital signature in terms of the “Non Repudiable Nature”.

The “Non Repudiable” nature of the digital signature as recognized under ITA 2000 was a result of two factors

  1. The Private Key is always under the control of the subscriber. It is generated in the system of the subscriber during the application process and never leaves the system. In the case of “Secured Digital Signature”, it is produced in the Cryptographic USB device and remains trapped there. Only the public key moves out and comes back in the form of a digital certificate and can be exported from the device.
  2. The technology of the Asymmetric encryption system and the hash algorithm ensures that the “Hash Value of a document encrypted with the private key of the person” is unique both to the person and to the content of the document and hence accepted as a “Non Repudiable Authentication” of the person for the document.

In the e-Sign system, the private key is not entirely under the control of the subscriber. It is generated in the HSM owned and operated by an agent of the Certifying Authority and hence it is compromised ab-initio. It can be misused by an authorized  employee of the e-Sign Service Provider.

Since under the proposed guideline, the e-Sign private key is a one time key and is destroyed within 30 minutes, once the transaction is completed, there is no way of verifying the signature after 30 minutes except with reference to the meta information associated with the transaction without the private key. The non verifiability of the e-Sign signature after 30 minutes and the generation and storing of the private key in the HSM makes e-Sign “Repudiable”. It is therefore to be considered as inferior to digital signature from the point of view of legal validity.

In practical terms this means that the e-Sign is not a legally acceptable authentication like a digital signature. It is only another form of the mobile number based OTP authentication and is only camouflaged as a legally valid digital authentication.

Unless there is a major modification of law, it is not possible to equate the e-Sign with digital signature and all the statutory authorities including the CCA are parties to this mis-representation of e-Sign as a legal equivalent of digital signature.

However, since CCA has endorsed the system, we can consider e-Sign as a “Second Class Digital Signature” some thing similar to an “Implied Digital Signature”. It is open to the Courts of the future to decide what value is to be ascribed to evidence digitally signed with e-Sign.

Naavi

Print Friendly