January 25, 2021
Hot Topics:

Problems with Digital Signing of Documents in Web-based Systems

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

Signed Java Applets

Signed Java Applets present a mechanism for increasing regular applets permissions. Like all other applets they represent JAR archives, which contain a set of compiled Java classes, but in addition to that they also contain digital signatures of all these classes as well as a digital certificate (along with its complete certification chain), by which these signatures can be verified. Upon execution of a signed applet the Web-browser displays the information from the certificate used for signing the applet, and asks the user whether he or she trusts this certificate or not. If the user trusts it, the applet executes without any rights restrictions and is free to have full access to the local file system of the machine it is running on. Trusting applets that are signed by an unknown software vendor, or are signed with a certificate that cannot be verified, is highly risky, because these applets gain unrestricted access to the machine and can execute all kinds of malicious code, for example viruses or trojans.

Let's step forward to the particular problems that occur when writing a Java-applet for digitally signing documents.

Signing Java Applets with jarsigner

In order to access the local file system the applet must be signed. Suppose we have written the applet's code and we have compiled it to the file Applet.jar. It is necessary to sign this JAR file. For this purpose we can use the utility jarsigner that is distributed standartly with the JDK 1.4. Here is an example:

jarsigner -storetype pkcs12 -keystore keystore.pfx -storepass store_password -keypass
private_key_password Applet.jar signFilesAlias

This command signs the JAR file Applet.jar with the private key, saved in the protected keystore keystore.pfx with the name signFilesAlias, using the passwords store_password and private_key_password to access the keystore and the private key respectively. The jarsigner utility supports two types of protected storage for keys and certificates (keystores) - Java Key Store (.JKS) and PKCS#12 (.PFX files). In order to use it we must either have a certificate issued by a certification authority (PFX file containing the certificate and its correspondinig private key) or we must generate our own self-signed certificate.

Generating Self-Signed Certificates

We can generate our own self-signed certificate with the utility keytool, which is also by standard distributed with the JDK 1.4. Here is an example:

keytool -genkey -alias signFiles -keystore SignApplet.jks -keypass !secret -dname "CN=My Company"
-storepass !secret

This command generates a X.509 certificate and a corresponding private key and saves them under the name signFiles in the keystore SignApplet.jks. In the certificate its owner is written as "My Company", and to control access to the keystore and private key the password "!secret" is used. By default the keytool utility uses the storage format JKS (Java Key Store).

Furthermore, we can use the thus made certificate to sign our applet like so:

jarsigner -keystore SignApplet.jks -storepass !secret -keypass !secret Applet.jar signFiles

This command signs the applet Applet.jar with the private key that is saved under the name "signFiles" in the keystore SignApplet.jks using for access the password "!secret". As a result we get a signed JAR file that contains all the files form the Applet.jar archive, together with the digital signatures of these files, and the certificate from the keystore SignApplet.jks with its full certification chain. If no file name is given to write the output file to, as is shown in the example, the input JAR file is also used for the output JAR file.

Embedding Applets in HTML Documents

The code we use to embed a signed applet in a HTML document is by no means different from HTML code we would use to embed a regular applet. Nevertheless when using signed applets it is not recommended to use the obsolete tag <applet>, because it has no way to indicate the minimum JDK version that is required for the proper functioning if the applet. Some Web-browsers (for example Internet Explorer) have standard support for JDK version 1.1 and unless explicitly stated that the signed applet requires a higher version of the virtual machine, the applet is started with restricted rights (as normal non-signed applet) and as a result does not work as intended, or does not start at all. To avoid this it is recommended that the <object> tag is used in Internet Explorer or <embed> in the rest browsers, and that the minimum JDK version the applet requires be pointed. A special utility called HtmlConverter.exe can be used for automatic tag conversion from <applet> to the newer, JDK 1.4 applet embedding tags.

The environment that executes applets in the client's Web-browser (generally this is Java Plug-In) is responsible for determining whether given applet is signed or not. If it is, upon its loading a dialog is shown that warns that a signed applet, requiring full access to the client system for proper functioning, is loaded. The environment provides detailed information about the certificate the applet is signed with, announces whether it is valid, afterwards it asks the user should it execute the applet without any security restrictions. If the user consents, applet starts with full access rights, otherwise it executes as a regular, non-signed applet.

Accessing the Web Server from Applets

Let us now think upon another problem. The document-signing applet must have some means, by which to send the server the calculated digital signature. This can be realized in several ways - the applet opens a socket to the server and uses this socket to send the signature, or it sends the information by an access request to a server URL, or it communicates with the Web-browser and sends the information to it, which in turns resends it to the server. The last approach is the most convenient, because it requires the least programming efforts in order to send and receive a signed file. In this case the server can receive the file along with its signature in one single Web-browser request, with no need for any other actions.

Communication between Applets and Web Browser

Suppose we have an ordinary HTML form that is used to send files to a certain Web-application without signing them. If we want to expand this form so that it supports digital signing of documents, we can simply integrate a Java-applet for file signing in it. In case we have an applet that calculates digital signature of a file and writes this signature in some field of the HTML form, the efforts for sending the digital signature are minimal. When submitting the HTML form, the Web-browser will send the signature with it, so there is no need for the applet to establish any client-server communication.

Accessing HTML Form's Fields from Applets

Usually Java-applets can access the code of the HTML they are embedded into. This ability can be used to get from the HTML form the name of the file the user is sending, so that its content can be read and signed. The result from the signing can be returned in some field of the same HMTL form. Technically such interoperability between applet and Web-browser can be realized with the standard class netscape.javascript.JSObject, which is accessible by all browsers that support applet execution. This class offers functionality for accessing all properties in the current Web-browser window the applet has been loaded from, which effectively means we gain access to the HTML document in this window, to the HTML forms in it, to the fields in these forms and in short everything we can access with JavaScript. Some browsers allow applets to run JavaScript and access the HTML document they are loaded from only after explicit declaration in the tag, used to embed them in the page. Such are the "mayscript" and "scriptable" parameters, and they must have value "true".

Page 2 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