April 24, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

NakovDocumentSigner: A System for Digitally Signing Documents in Web Applications, Page 3

  • January 12, 2004
  • By Svetlin Nakov, Svetlin Nakov
  • Send Email »
  • More Articles »

The Server Side of the Framework

As a part of the document signing framework NakovDocumentSigner a reference Java-based Web application is developed to fully demonstrate its capabilities. The application allows users to sign and send files and, after that, checks the digital signature and certificate of the sender.

The server-side functionality implements three functions:

  • Verification of the received digital signature
  • Direct verification of the received certificate
  • Verification of the received certification chain in case one is present

Digital Signature Verification

Digital signature verification asserts that the received signature corresponds to the received file and certificate. Direct certificate verification determines whether the certificate can be trusted without verifying its certification chain. Verification of the certification chain, when one is available, aims to confirm the sender's identity.

The verification of the received signature is done in the most trivial way by using the java.security.Signature class.

Direct Certificate Verification

For direct certificate verification, the reference Web application supports a set of trusted certificates and checks whether the user's certificate is signed by one of them. Trusted certificates are stored as .CER files in a special application directory, the name of which is specified by a constant.

Certification Chain Verification

For certification chain verification of the user's certificate, the reference application uses a set of Root certificates of trusted root certification authorities. From these certificates, a set of trust anchors that is necessary for the certification chain verification is built. Trusted Root certificates are stored as .CER files in a special application directory, the name of which is specified by a constant.

The Server-Side Architecture

The reference Web application is based on the J2EE (Java 2 Enterprise Edition) platform and the popular Web application development framework called Struts. The application consists of one Struts-based HTML form, a Struts action class to process the form, a Struts action form class to store the data from the form, a class for digital signatures and certificates, a page for processing the sent signed file, and several configuration files. The application strictly follows the programming model of the Struts framework—Model-View-Controller (MVC).

The Server Side of the NakovDocumentSigner Framework

The reference Web application's full source code is available for free download at the NakovDocumentSigner site: http://www.nakov.com/documents-signing/.

The Struts-based File Signing and Uploading Form

The starting form of the application consists of three fields: for the filename, for the certificatem and for the signature, respectively, and also contains the signing applet and a submit button:

Click here for a larger image.

On the screenshot above, the signing applet looks like a button with caption "Sign selected file." This form is produced by a JSP page, SignedFileUploadForm.jsp, that is based on the "struts-html" tag library and uses the Struts tag to send <html:file> files.

How It Works

During the data transmission from the form to the server, "multipart/form-data" encoding is used that permits the sending of files and other large data.

The signing applet is embedded within the <object> and <embed> tags. Actually, the <object> tag is recognized by Internet Explorer only and <embed> tag is recognized by all other browsers and, to make the application work properly on all machines, it is necessary that the two tags are combined.

Upon loading this page, if Java Plug-In 1.4 or later is present on the machine, a warning shows up and informs that the applet is signed and wants to proceed with full rights. In case the required Java Plug-In version is not present, the user's browser is redirected to the site from where it can be downloaded. For the normal user, this site is http://java.sun.com/products/plugin/index.html, but some browsers are capable of directly installing plug-ins (available as signed .cab files) so the Java Plug-In location for them is http://java.sun.com/products/plugin/autodl/jinstall-1_4-windows-i586.cab#Version=1,4,0,0. Note that the minimal version number of the required plug-in is encoded in the URL.

When the user permits the loaded applet to execute with full rights, it starts and can be used for signing files. On the following screenshot, the warning message produced by the Java Plug-In is shown:

Click here for a larger image.

Generally, it is very unsafe to trust such signed applets, but testing the signing applet it is required. In real-world situations, the applet should be signed by a valid trusted certificate purchased from some widely accepted certification authority. If the certificate used to sign the applet is valid, the exclamation marks in the warning dialog will be absent.

Page 3 of 5

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Sitemap | Contact Us

Rocket Fuel