I think it is about time I update you on my thesis work! Before reading this document you might want to look at the proposal.

This document briefly describes the concept of JAS (Java Authentication System). It also includes a schedule for the remaining part of my thesis work. 

JAS is a firewall extension for authenticity control of Java executable content. JAS actually consists of two separate systems: a proxy gateway (PGW) and an authentication server (AS). This separation is done for three reasons:

• Usage
• Performance
• Implementation technical

The AS part could be used by other system to check incoming Java executables. For example: by mail systems or automated FTP systems.

In an actual implementation, most of the HTTP requests handled by PGW would be requests for ordinary HTML or image files not executable content. Since authenticity control is time consuming and a not so frequent task for the PGW, this job is carried out by the AS component.

The major part of the system, the authentication server is written in Java. Unfortunately there is no public domain proxy server with filtering capabilities implemented in Java available. To build an own filtering proxy in Java is just too much work. Instead I decided to modify an existing filtering proxy gateway implemented in C.

How is JAS intended to work then? The picture and the comments below describes the involved parties and how they interact with each other.

1. The client uses his/her WWW browser to access an HTML page containing a reference to a signed Java archive. The client’s browser is configured to use the proxy gateway for HTTP request to Internet hosts.
2. The proxy gateway does the actual request on behalf of the client to the HTTP server holding the requested HTML page.
3. The Internet server responds to the request by sending the HTML page to the proxy gateway.
4. The proxy gateway scans the HTML page for references to Java executable content (applets). If a reference is found to a Java archive (JAR) a request is made to the authentication server. If a reference to an unsigned Java executable is found, this reference will be removed from the HTML page. The applet will then never be requested by the client.
5. The authentication server will get the URL pointing to the Java archive from the proxy gateway. The protocol the proxy gateway and the authentication server use to communicate is HTTP. There are a number of new HTTP headers and response codes defined for usage by JAS only. The authentication server will now request the archive from the Internet host holding it.
6. The Internet host will hopefully return the requested archive to the authentication server.
7. Now the archive needs to be checked by the AS. First is the digital signature checked then is the integrity of the archive examined. A signed archive that has been tampered with is worse than an unsigned archive. If the archive is Ok, respond to the proxy gateway.
8. If the proxy gateway receives an Ok response from the AS the reference to the archive on the HTML page will be left unmodified. The HTML is now (at last) sent to the client that originally requested it.
9. When the HTML page is parsed by the client’s browser it will detect the reference to the checked Java archive. The archive is then retrieved from the Internet host through the proxy gateway. Blocked HTML references to Java executables will never be requested by the browser since they were removed from the HTML page by the PGW.

This is one way to handle the flow of data in the system, there are a certainly other ways to do it. Some other methods will be discussed in the thesis report.

The proxy gateway is built on the http-gateway software called http-gw from TIS (Trusted Information Systems). http-gw is one of many components in the FireWall ToolKit (fwtk) from TIS.

The out of the box version of http-gw supports blocking of all requested Java applications while the modified version in JAS can allow or deny request for Java executables based on their digital signature. The proxy gateway detects references to Java content by scanning incoming HTML pages for the APPLET tag. This filtering strategy is sufficient for this application even if it is not perfect. (For a discussion on blocking/filtering strategies, see the Blocking Java Applets at the Firewall paper). Other filtering strategies might be a little bit more efficient but that does not add much to the overall network security. Remember that malicious code still get into the protected network environment from for example; floppy disks, by E-mail or FTP, to name a few.

The current version of the proxy gateway does not cache any information. I have though about another solution that maintains information between requests to save some time and bandwidth. These will be discussed in the thesis report.

The interface between the proxy gateway and the authentication server is based on HTTP and is quite simple and easy to extend. The PGW uses HTTP header fields to pass information to the authentication server and a couple of new response codes (9XX) are used to indicate the result of an authentication request.

JAR (Java ARchive) is a file format based on the ZIP file format. The intended use is to allow all components (class files, images, sound clips) of a more complex applet to be downloaded in a single HTTP request. The JAR format also makes it possible to sign the content of the archive. Both SUN Microsystems and Netscape provide tools for signing JAR archives. Applets not stored in JAR files will be blocked directly by the proxy gateway. JAR files, on the other hand are handled by the Authorization Server.

Since the proxy gateway and the authorization server use HTTP to communicate I decided to use a "standard" HTTP server as a foundation for the authentication server. I also decided to use the javakey tool from SUN Microsystems to manage the database of trusted signers. The actual authentication server is implemented as a servlet. A servlet is simply a server side Java applet and the servlet API provides similar functionality as CGI. The Java Web Server from SUN is a HTTP server with servlet support and the product I decided to use in my thesis. The software is free for non-commercial and educational use. From the AS servlet I am now able to interact with the database maintained through the javakey tool, and with the proxy gateway through the web server.

What does the authentication server do? The two main tasks of the authentication server is:

• To check if the archive is signed by a trusted identity
• To verify the integrity of the content of the archive

To be able to carry out these tasks a thorough understanding of the JAR file structure is necessary. The format is described in the "Manifest Format" paper. There are number of different types of files in a JAR file that must checked in order to verify the signature and check the integrity of the archive.

If we look inside a signed JAR file, we will find the following:

• A manifest file (there can be only one)
• One or more signature files (One for each signer)
• One or more digital signature files (One or more for each signer)
• Content (The actual content of the archive, this could be any number of files of any type)

The manifest file is a list of all signed files in the archive. The signature file is specific for a signer and have an entry for each file in the archive signed by that signer. The digital signature file is a signed copy of the signature file and can be of a few different types, for example DSA, RSA and PGP.

The basic steps to verify the digital signature is:

• Retrieve the identity of the signer
• If the signer exists in the database, retrieve his public key
• Verify the digital signature of the archive using the public key

Even if the archive has a valid signature we cannot be sure that the content is Ok, therefore must an integrity check be done. An integrity check is done to detect if the archive has been tampered with after it was signed. To do this a message digest must be calculated for each file in the archive and compared to a pre-calculated value stores in the manifest file. Each file entry in the manifest file has a corresponding entry in a signature file. The signature file holds a calculated digest for each entry in the manifest file. But it does not stop here. Then there is a digital signature file that is a digitally signed copy of the signature file. Why some many different files? This is done to make the JAR format flexible. For example, unsigned files can be stored in the archive together with signed files. That feature is not particular good if you think security wise, since it means that the archive cannot be trusted if there is one unsigned file in it.

This table presents the unfinished activities and how much time I plan to spend on each of them.

My estimate is that I can work 3 effective hours a day during weekdays, and 9 (3*3) hours a day Saturdays and Sundays.

[1] B. Schneier, Applied Cryptography, John Wiley & Sons Inc., 1996