Digital Signatures

Cryptography is the science of enabling secure communications between sender and one or more recipients. This is achieved by the sender scrambling a message (with a computer program and a secret key) and leaving the recipient to unscramble the message (with the same computer program and a key, which may or may not be the same as the sender's key).

There are two types of cryptography: Secret/Symmetric Key Cryptography and Public Key Cryptography.
Secret key (symmetric/conventional) cryptography - is a system based on the sender and receiver of a message knowing and using the same secret key to encrypt and decrypt their messages. One weakness of this system is that the sender and receiver must trust some communication channels to transmit the secret key to prevent from disclosure. This form of cryptography ensures data integrity, data authentication and confidentiality.

Public key (asymmetric) cryptography - is a system based on pairs of keys called public key and private key. The public key is published to everyone while the private key is kept secret with the owner. The need for a sender and a receiver to share a secret key and trust some communication channels is eliminated. This concept was introduced in 1976 by Whitfield Diffie and Martin Hellman.

The Digital Signatures created using the private key ensure data integrity, data authentication and nonrepudiation. However, to ensure confidentiality, encryption of the data has to be done with the recipient’s public key.

The Office of Controller of Certifying Authorities (CCA), issues Certificate only to Certifying Authorities. The CAs in turn issue Digital Signature Certificates to the end-users. You can approach any of the CAs for getting the Digital Signature Certificate. For more information about the respective CAs kindly visit their websites (provided below).

A CA is a trusted third party willing to verify the ID of entities and their association with a given key, and later issue certificates attesting to that identity. In the passport analogy, the CA is similar to the Ministry of External Affairs, which verifies your identification, creates a recognized and trusted document which certifies who you are, and issues the document to you.

a. Safescrypt

b. NIC

c. IDRBT

d. TCS

e. MtnlTrustline

f. GNFC

g. e-MudhraCA

Prior to cessation of operations, the CA has to follow procedures as laid down under the IT Act. Therefore, such problems should not exist.

In case a person wants to authorize someone else to sign on his/her behalf, then the person being authorized should use his/her own PKI credentials to sign the respective documents.

Yes

Under the IT Act 2000, Digital Signatures are at par with hand written signatures. Therefore, similar court proceedings will be followed.

No. The Digital signature changes with content of the message.

No, there is no threat to the security of the owner / users digital signature, if the private key lies on the smart-card/ crypto token and does not leave the Smart Card / crypto token.

It depends upon how the owner has kept his private key. If private key is not stored securely, then it can be misused without the knowledge of the owner. As per the IT Act 2000, the owner of the private key will be held responsible in the Court of Law for any electronic transactions undertaken using his/her PKI credentials (public/private keys).

A new message saying that the current message supersedes the earlier one can be sent to the recipient(s). This assumes that all messages are time stamped.

The DSC can be revoked when an officer is transferred, suspended or his/her key is compromised.

Suppose Sender wants to send a signed data/message to the recipient. He creates a message digest (which serves as a "digital fingerprint") by using a hash function on the message. Sender then encrypts the data/message digest with his own private key. This encrypted message digest is called a Digital Signature and is attached to sender's original message, resulting in a signed data/message. The sender sends his signed data/message to the recipient.

When the recipient receives the signed data/message, he detaches sender's digital signature from the data /message and decrypts the signature with the sender's public key, thus revealing the message digest. The data/message part will have to be re-hashed by the recipient to get the message digest. The recipient then compares this result to the message digest he receives from the sender. If they are exactly equal, the recipient can be confident that the message has come from the sender and has not changed since he signed it. If the message digests are not equal, the message may not have come from the sender of the data/message, or was altered by someone, or was accidentally corrupted after it was signed.

When a Certificate is installed in a web server, it allows users to check the server's authenticity (server authentication), ensures that the server is operated by an organization with the right to use the name associated with the server's digital certificate. This safeguards the users from trusting unauthorized sites. A secure web server can control access and check the identity of a client by referring to the client certificate (client authentication), this eliminates the use of password dialogs that restrict access to particular users. The phenomenon that allows the identities of both the server and client to be authenticated through exchange and verification of their digital certificate is called mutual server-client authentication. The technology to ensure mutual server-client authentication is Secure Sockets Layer (SSL) encryption scheme.

The e-Governance applications have to be developed in compliance with RFC5280 certificate profile. A number of commercial and open source PKI toolkits are available which can be used to develop a standard validation process, for example, Microsoft CNG, Sun Java Toolkit. Please refer to Annexure IV of the Digital Signature Certificate Interoperability Guidelines (http://cca.gov.in/cca/sites/all/DSC_Interoperability_Guidelines_R2.5.pdf ) for further details.

Yes

CA Key is 2048 bits and the end user keys are 1024 bits. However from 1 Jan 2011, the end user keys are 2048 bits as well, as per the notification by CCA.

The size of the Digital Signatures varies with the size of the keys used for generation of the message digest or hash. It can be a few bytes.

Key escrow (also known as a fair crypto system) is an arrangement in which the keys needed to decrypt encrypted data are held in escrow so that, under certain circumstances, an authorized third party may gain access to those keys. These third parties may include businesses, who may want access to employees' private communications, or governments, who may wish to be able to view the contents of encrypted communications.

The applications download the CRLs from the respective CA sites at a specified frequency. The applications than verify the public keys against this CRL at the time of Digital Signature verification. The CCA is in the process of implementation of the OCVS (Online Certificate Verification Service). This will ensure online verifications of the CRLs by the applications.

As per the IT Act 2000, each CA stores the Public Key in their repository for a period of 7 years from the date of expiration of the Certificate.

In view of the fact that the CAs have a mandate to save the DSCs for a period of 7 years, it may be advisable for the e-governance applications which would need to verify the records for authenticity for periods beyond 7 years.

Yes, a document can have multiple Digital Signatures. For example, in the MCA21 application, the forms are signed by different Directors as part of the application workflow.

They are hardware security tokens used to store cryptographic keys and certificates. For example, USB etc.

There are different ways of verifying the content and the digital signatures of the document. Some of the mechanism are enlisted below:-

1. Via Unique Request ID (manual content verification only) - In this process the user can verify the validity of his/her document by logging onto the Department website and providing the unique request number printed on the document. The Department application will display the electronic version of the document stored in the application repository. However in this process since the digital signature on the document is not verified, the contents have to be verified manually by the user by comparing the online document from the website with the hardcopy of the document. This process thus provides content verification only. The verification of the Digital Signature does not take place in this process.
2. Verification by the 2D Barcode – In this process, the barcode printed at the bottom of the document is used for the digital signature verification. The barcode has the Digital Signature embedded in it. The two verification mechanisms enlisted below verify the Digital Signature only. Since the complete content of the document is not being scanned, the content verification has to be done manually.

a) Online Verification

In this process, a bar code reader is used to scan the 2-D bar code printed at the bottom of the certificate. The verification utility of the Departmental application would verify the digital signature embedded in the document and after successful verification, show the corresponding electronic record on their website. However the user needs to compare the contents of the electronic record and the hard copy. This method requires a computer, an internet connection and a 2D bar code reader.

b) Offline Verification

In this process, the user can verify the digital signature embedded in the barcode without connecting to the Department website. Thereby this process is called as “offline” verification. The user needs to download and install the verification utility custom developed by the Department (downloadable from their website). The user also needs to download the root chain certificates of CCA and NIC and the public key of the authorized taluka and the taluka official onto the computer. Once these items are installed on the computer, the user can scan the 2D barcode on the document and the verification utility will check the validity of the digital signature embedded in the document thereby proving the authenticity of the document. However, the content of the hardcopy of the document will have to be manually verified by the comparing with the electronic version available at the Department website as the content of the hardcopy is not being scanned in this process.

The digital signature verification process for a document requires the public key, root chains and the CRL. The e-Governance application should therefore have a repository of public key certificates, root chains and the CRL’s of the time the document was digitally signed. The CA’s as of now are mandated to store the Digital Signature Certificates, root chains and the CRLs for a period of 7 years as per the Rules of the IT Act. Therefore the Digital Signature Certificates can be downloaded from the CAs for a period of 7 years. However, if the digital signature on the document needs to be verified after this period, the e-Governance applications will have to have a provision to store the DSCs, root chains and the CRLs in a repository and undertake the verification of digitally signed document against this repository. However, it may be a cumbersome process to get the CRLs’ from the respective CAs for a specific period (in the past).

It is recommended that as part of the handing over of charge of a given officer, the DSC issued to the officer be revoked. Further his user credentials in the respective e-Governance applications should be deactivated so that he can no longer access the application while the Certificate revocation is under process with the CA. Once the DSC is successfully revoked, the officer will be no longer able to sign the documents.

In order to ensure that the documents are signed by authorized individuals only, the Departments should maintain a repository having a mapping between the DSC and the respective roles assigned to the officers of the Departments. The e-Governance application should check against this repository for the various documents before allowing an officer to digitally sign the document. This mechanism has been implemented in MCA21 application wherein multiple directors sign the e-forms for the application. The key challenge with this approach is to be able to maintain an updated repository at all times.

The Government of India is currently looking into the proposal for creation of a central repository of Digital Signature Certificates and CRLs’ in order to ensure that digitally signed documents can be verified at a later date ( greater than 7 years).