February 28, 2021
Hot Topics:

Problems with Digital Signing of Documents in Web-based Systems

  • By Svetlin Nakov
  • Send Email »
  • More Articles »

Accessing Applet Methods from JavaScript

Generally there is one more way to carry out communication between the applet and the browser - instead of having the applet write the result of the digital signature calculation of the file to be sent in a form field, we could have a JavaScript function call a method of the applet, which returns the signature and again with JavaScript save it in a field of the form. This doesn't actually work because in most browsers JavaScript is run with rights that do not permit access to the file system. Regardless that the applet is signed and has the permission to read local files if it is invoked through JavaScript it loses this ability. That is why instead of calling a Java function for document signing from JavaScript we can make a button-shaped applet that upon clicking signs the selected file and writes the signature in a predefined field in the form. Optionally we could make the applet through JavaScript to automatically submit the HTML form after signature calculation, so that the user is unable to change the form after the signing is done. In that case it might be convenient to have HTML form without a submit button and submitting the form to be possible only from inside the applet and only if the signing is successful. That way the user will not be able to send unsigned or wrong signed files.

The Process of Signing Documents in the Web-browser

In the process of signing it is necessary that the server is sent not only the document and the digital signature calculated from it, but also the certificate that is being used, accompanied by its full certification chain (if available). The certificate is needed because it stores the signing user's public key, without which verification is impossible. Besides the certificate provides means to link this public key to the particular person that does the signing. If we send the server only the document, signature and public key, we are able to verify the signature's validity, but we have no information about the identity of the owner of the public key, unless the server keeps a record of the public keys of all possible clients. In general it is most convenient to send the server the user's certificate along with its complete certification chain. The particular process that begins with the clicking of the signing applet's button might be done like this:

  1. The user is prompted to select from the local file system a protected keystore file (PFX file), containing his digital certificate with its corresponding certification chain and private key. The user is required to enter his password to access the information in the selected keystore.
  2. The selected PFX file is loaded and the user's certificate, corresponding private key and the complete certification chain are extracted.
  3. The name of the file to be signed is taken out from the HTML form. The file is signed with the user's private key.
  4. The result from the signing together with the user's certificate and its full certification chain are written to certain fields in the HTML form.

The server that receives the signed file is responsible for checking if the file is correctly signed with the private key, corresponding to the received certificate. Apart from that the server must verify whether the certificate that is used is valid. This can take place immediately after file receipt, or later, if ascertaining the identity of the signer is necessary.

Verifying Signatures, Certificates and Certification Chains

Besides the applet that signs the files sent by the user our Web-based information system should also have functionality for receiving the signed files, together with verification of the signature. It is also necessary that the received user certificates and certification chains be verified in order to make clear who in fact is signing the files. Let's discuss the problems these verifications involve.

Verifying Digital Signatures

The purpose of digital signature verification is to determine whether the sent signature corresponds to the sent file and certificate, i.e. whether it is authentic. The verification takes place through the standard signature verification procedure - the sender's public key is extracted from the certificate and a check is made whether the received document's signature is obtained from the private key corresponding to this public key. There are standard classes in the Java Cryptography Architecture for digital signatures verification.

Verifying Digital Certificates

The verification of the received certificate seeks to determine if the public key stored in it is really owned by the person the certificate is issued to, that is if the user is really the one he pretends he is when he signs the document. This verification is slightly complicated and requires some preparation.

There are several mechanisms to verify a digital certificate. We will examine two of them. The classical way for certificate verification requires that the certification chain be checked. In order to verify a certification chain it is needed all the certificates that it consists of are available. Otherwise verification cannot be done.

In our system during the signing process the user utilizes standard protected storage for keys and certificates (keystore), saved in PFX files. As we already know these files usually contain a certificate and its corresponding private key. In most cases the certificate is accompanied by its full certification chain, but sometimes this chain is not available. For example when the user signs documents with a self-signed certificate, it does not have a certification chain. Therefore it is possible along with a signed file the server receives the user's certificate with a full certification chain as well as it possible to receive a certificate without a certification chain.

Verifying Certificates with Certification Chains

If a certification chain is present, it can be verified the classical way - by verification of all the certificates (and validity of the links between them) that form the chain. For this purpose Java Certification Path API can be used, and the PKIX algorithm, which is implemented in JDK 1.4. It is only necessary that the application has appropriate set of Root-certificates of trusted top-level certification authorities (trusted CA root-certificates).

Verifying Certificates without Certification Chains

In case the certification chain of the certificate used for signing is unavailable, there is another, although somewhat inconvenient, method for verification - direct certificate verification. Instead of building and verifying the certification chain of a given certificate, it is possible only to verify whether it is directly signed by a trusted certificate. The system can store a list of such trusted certificates. When verification of a given certificate occurs, it can search through the list for a certificate that appears to be a direct issuer of this one. If such a trusted certificate is found, the certificate being verified is considered valid, unless it has expired.

The major inconvenience of this certificate verification scheme is that the system needs to have at its disposal the certificates of all certification authorities that people might use. If for a given user certificate the system does not have the certificate used by the certification authority for signing it upon issuing, this user certificate will not be verified, even though it is valid. Anyway this method for verification may prove useful when users present certificates that are not accompanied by a certification chain.

Note that usually user certificates are not signed directly by the root-certificates of the certification authorities but with some intermediate certificates, signed by some root-certificate of some CA. If we use direct certificate verification, we should have a list of all possible trusted intermediate certificates that are used for direct issuing of the certificates of our clients. The certificates in this list should be certificates that we believe to unconditionally. If we use certificate verification based on certification chains, we need only a list of the root-certificates of the top-level certification authorities we trust and we don't need the intermediate ones.

Implementing Digital Document Signing System for Web Applications

We have discussed the major problems concerning digitally signing of documents in Web-applications and have proposed particular ideas for their solving through the use of a signed Java-applet. We have also analyzed the problems concerning the verification of digital signatures, certificates and certification chains. Next we are going to examine a system, where concrete solutions to the aforementioned issues have been applied. Let's move at the most interesting part - the practical implementation of the system.

The next article in this series proposes the NakovDocumentSigner system to give the developers a fully functional framework for digitally signing documents in the client's Web browsers and verifying signatures, certificates, and certification chains on the server side. The system consists of a Java applet for digitally signing and a reference J2EE Web application for signatures and certificates verification. It demonstrates how the Java Cryptography Architecture and Java Certification Path API can be applied to provide the Web applications with digital signature functionality. The full source code of the framework will be included and discussed.

About the Author

Svetlin Nakov is part-time computer science lecturer in Sofia University, Bulgaria. He has over 5 years of professional software engineering and training experience and currently works as IT consultant in a leading Bulgarian software company. His areas of expertise include Java and related technologies, .NET Framework, network security, data structures and algorithms, and programming code quality. More information on his research background, skills and work experience is available from his home site www.nakov.com.

Page 3 of 3

This article was originally published on December 12, 2003

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date