Let's imagine we are developing an information system with Web-based user interface, which is accessible through the Internet. Users of this system must be able to send documents to the server. These documents can be files of various formats - MS Word .DOC files, Adobe Acrobat .PDF files, MS Excel .XLS files, JPEG and GIF images, text files, etc. In order to track the sender identity and to guarantee nobody modifies documents after their sending, it is necessary that the system can offer users the ability to digitally sign the files being sent. Let us discuss the problems that arise at the implementation of such a system.
The Public Key Cryptography Approach
For the needs of digital signature the system can use Public Key Cryptography, and for verifying the identity of the user who is signing the document, it is most convenient to use digital certificates.
Using Self-Signed Certificates
Certificates can be self-signed or issued by a certification authority. If users issue themselves self-signed certificates and use them to sign documents, there is no guarantee that a malicious user will not issue himself a certificate with another name and sign documents as though he is some other user. We should find better approach to avoid this security weakness.
Using Local Certification Authority
It is possible that the person responsible for the system maintenance - the system administrator - be the one to issue digital certificates. There are two ways to do that - either the system administrator generates the public and private keys for the users, or they generate these themselves. In the first case it is potentially possible for the administrator to abuse his rights. There remains the possibility that the users personally generate their public and private key, afterwards they send somehow the public key along with information about their identity to the system administrator, who in turn issues the certificate. The fault of this design is that it in no way guarantees that users would not fake their identity information. The only possibility left is that every user personally presents his public key and the administrator issues him the certificate after careful examination of his ID papers. This solution is more acceptable, but in fact the administrator acts as a certification authority and is still able to abuse his certificate issuing rights.
Using Approved Certification Authorities
We can use the services of approved certification authorities in order to manage the problems with the certificates. Every user in the system can purchase a certificate from a certification authority and this authority can guarantee that the certificate does really belong to the person it has been issued to. The private key corresponding to any certificate is only accessible to its owner and nobody else. This guarantees that when a user signs a document with a certificate, issued by an approved certification authority, this is really his signature. Faking is only possible if malicious persons obtain the user's private key, for which the user bears personal responsibility.
Digital certificate purchase involves certain expense for every user, but this is the only reliable way to guarantee security. Usually along with the certificate the user obtains a PFX file, containing the certificate and its corresponding private key, protected by a password. If as a result of the purchase the certification authority installs the certificate directly into the client's Web-browser, the user is then able to export it as a PFX file (in PKCS#12 format) and use the file from that moment on to sign documents. We assume that users that have their own certificate have also protected keystore (PFX file) that keeps their private key along with their certificate.
Signing Is Possible on the Client's Machine Only
Signing requires access to the signing user's private key. Because each user's private key is accessible only by him, it is necessary that the signing take place physically on his PC. Otherwise the user would have to send his private key to the server, which poses a potential security threat - the key could be stolen on the way. Signing documents on the user's PC in Web-applications is not an easy task, because the client has only a standard Web-browser at his disposal - which does not have built-in functions for signing documents.
Approaches to Digitally Signing on the Client's Machine
We will analyze the possible approaches for signing documents on the client's PC. We should take into account that the signing process should be integrated with the Web-application that is responsible for receiving signed documents.
Using External Signing Tool
A possible approach would be to make users install on their PCs some kind of specially designed software, but this is accompanied by certain difficulties. One is that the signing software must have separate versions supporting different operating systems that users might have. Moreover, support for such software is cumbersome, because any change in it would force users to download and install the new version. Integration with the Web-interface of the system is another difficult task, and if the software is not well integrated, its usage may be troublesome for users. There is also a possibility that users deny to install the software on their PCs because of security reasons, also if they are not using their own machines they may be physically prevented to do it.
The above considerations lead us to looking for another solution of the problem with digital signing on the client machine.
Using Client-Side Scripting Technologies
It is possible to use JavaScript or some other client-side scripting technology, such as ActiveX, Macromedia Flash, .NET Windows Forms Controls or Java-applets.
The problem with JavaScript language is that it does not support the standard functionality required for working with digital signatures and certificates. Besides it is unable to gain access to neither the certificates installed into the user's Web-browser, nor to external protected keystores. Also JavaScript can not access to local file system and thus can not read the file that should be signed.
Macromedia Flash technology also does not support digital signatures and certificates, and it cannot access local file system, which is required, because before being signed, a file needs to be read.
Technically ActiveX controls offer a solution, but they work only with Internet Explorer on Microsoft Windows. As exception some other browsers in addition to IE also support ActiveX controls, but ActiveX technology can not run on non-Microsoft operating systems. This limits the users to those that use MS Windows and Internet Explorer.
Windows Forms Controls also work only with Internet Explorer, and they additionally require that the Microsoft .NET Framework is installed. It is not acceptable to require the user to use Internet Explorer, MS Windows and .NET Framework in order to be able sign documents in Web-application.
There is one last chance - to use Java applets. They have the advantage that they work with all well-known browsers and on all operating systems. They have the disadvantage that generally have no access to the local file system of the machine they're running at, but this restriction can be overcome by using signed Java applets. Let us examine what Java applets can offer.
Java Applets
Java applets are compiled Java programs that are embedded as objects in HTML documents and are executed by the Web-browser when the document is viewed. The embedding of an applet in a Web-page is very much like embedding pictures, but unlike them applets are not just graphical images. They are programs that use for their graphical user interface a rectangular area of the page they are set in.
Applets consist of one (or several) compiled Java classes, saved in a JAR file. Like all Java programs, applets are executed by the Java Virtual Machine (JVM) and therefore all Java-enabled Web-browsers have the virtual machine either built-in, or additionally installed. When an HTML document containing an applet is opened, the browser loads its virtual machine and starts the applet in it. To ensure users security, applets are disallowed to execute any operations that might gain access to user information on the machine running the applet. As a rule an applet has no access to the local file system, which makes using this technology for the goals of digital signing somewhat difficult.
IE 7
Firefox 2.0
