By Qusay Mahmoud
Distributable applets are one of Java's most exciting applications. Yet they add security risk; because applets are downloaded and run locally, they may potentially steal or damage local files.
This article will discuss:
The Java Development Kit (JDK1.0) introduced the SecurityManager class, which is part of the java.lang package. The SecurityManager class defines and implements a security policy. Web browsers such as Netscape Navigator and Microsoft Internet Explorer use the SecurityManager class to define and implement a custom security policy. The browser installs this custom security manager when executing untrusted code, that is, code from remote machines.
The security mechanisms in JDK1.0 protect its users from the danger of untrusted code by placing limitations on applets:
Applets cannot read from, or write to, the local disk.
Applets cannot make network connections to computers other than the one from which they were downloaded.
Applets cannot install their own security manager.
Applets cannot install their own class loader.
Of course, these limitations minimize applets' usefulness. The use of cryptography, however, can expand the capabilities of applets by providing trust between parties. The Security package in JDK1.1 is based on cryptography, so a quick review of its basics is in order.
Cryptography - secret writing - is used to protect information. The main operation in cryptography is encryption, a specialized computation that makes messages meaningless to all parties except the intended recipient. There are two types: conventional and public-key.
Conventional encryption. Conventional encryption, also known as symmetric or single-key encryption, was the only type available before the development of public-key encryption. The conventional encryption process consists of an algorithm and a key. The same key is shared by the sender and the receiver. An original message (before encryption), referred to as plain text, is converted to cipher text. The output depends on the algorithm and the key. Different keys generate different output. Once a message is encrypted, it can be transmitted to the intended recipient. When received, it can be converted back to plain text by using a decryption algorithm with the same key used to encrypt the message.
Public-key encryption. The problem of distributing keys (key management) in symmetric encryption led to the development of public-key encryption. Also known as asymmetric encryption, this type uses two keys: one public, and one private.
Differentiating between copies and originals in the "real world" is a comparatively simple task. But in the digital world, a mechanism is needed that would allow one to send a "signed" message, such that:
The receiver can verify the claimed identity of the sender.
The sender can't duplicate the message.
Such a mechanism does exist: digital signatures, which establish sender authenticity. A digital signature is analogous to a written signature on a legal document, in that:
It must indicate the author, date, and time of the signature.
It must be verifiable by a third party, to resolve disputes.
For digital signatures to be practical, they must be easy to produce, recognize, and verify. At the same time, they must be difficult to forge, either by creating a new message for an existing signature, or by counterfeiting a signature for a given message. Conventional cryptosystems don't ensure sender authenticity; remember, the sender and receiver share the same key. However, public-key cryptosystems provide a simple scheme for implementing digital signatures.
If a Java applet is digitally signed with a public key, you can identify the person who created it. With JDK 1.1's Java Security API, you can establish trusted relationships; thus, applets won't have the restrictions imposed in JDK 1.0.
The ability to verify the author of a class doesn't solve the whole problem. For example, how will the security manager, who must decide how to control access, know how much trust the user of the class places in its provider? Access Control Lists (ACLs) are a solution; they offer a useful way to represent information about users and their permitted object-access rights.
The Java Security API is cryptography-based, letting developers incorporate low- and high-level security functionality in applets and stand-alone applications. The set of APIs include support for digital signatures, key management, and ACLs. JDK1.1 provides the javakey utility for managing keys and certificates, and for digitally signing files. It also provides facilities for signing and verifying Java ARchive (JAR) files.
The class signer's identity will be used (by the security manager, for example) to make access decisions. For example, if I trust Alice, and don't mind if she creates files on my machine, then I need to verify that a class or an applet is coming from her. That is, I want to verify Alice's identity. If Alice can sign a class with her private key, then I should be able to verify (using Alice's public key) that the signature is actually Alice's. However, the story doesn't end there. One limitation of public-key encryption is the inability to verify that a public key belongs to the individual you believe it does. The fix for this limitation is called a Certification Authority.
A Certification Authority is a trusted third party that signs a user's certificate, i.e. a block of data that identifies a user. The most common certificate format is the X.509 recommendation from ITU-T (formerly known as CCITT). The X.509 certificate contains standard information about the user name, organization, e-mail address, public key, etc. A message digest of the certificate will be created and signed by the Certification Authority (CA), using the CA's private key. The message digest will then be appended to the certificate. At this point, the certificate would be available for anyone who wishes to verify the identity of a user.
Can we really trust our Certification Authorities? Well, it's up to you to find a CA you can trust. VeriSign (http://www.verisign.com), a spin-off of RSA Data Security (http://www.rsa.com), is worth checking out. Others are included in the list of CAs and products at http://www.securityserver.com.
JAR stands for Java ARchive, a feature of JDK1.1. It's a file format based on the ZIP format from PKWARE, and is used for bundling files into a single archive. It also supports compression and digital signatures. It was developed to allow Java applets and their components (class files, images, sounds, etc.) to be downloaded in a single HTTP transaction, rather than opening a new connection for each piece.
To accommodate JAR files, the HTML <APPLET> tag is used as follows:
<applet code=3DmyApplet.class
archive=3D"myApplet.jar"
width=3D500 height=3D200
<param name=3Dwhatever
value=3DchooseOne> <!-- if any -->
</applet>The code=3DmyApplet.class attribute and value specify the name of the applet where execution begins. The class myApplet.class and all other helpers (e.g. sound files, images, etc.) are loaded from the JAR file, which is identified by the archive=3D"myApplet.jar" parameter. The archive attribute may specify multiple JAR files, each separated by a comma.
Let's say you've written an applet that tries to create a file on a friend's machine. If your friend downloads and runs that applet, a security exception will be thrown. This tells us that the applet was trying to do something that's not allowed.
You must sign your applet, while your friend must configure the system to accept code signed by you. Let's explore how to do each.
# A sample certificate directive file
# The id of the signer
issuer.name=yourself
issuer.cert=1
# the id of the subject
subject.name=yourself
# X500 parameters
subject.real.name=Your Real Name
subject.org.unit=Where Do you Work -- Division
subject.org=Company Name
subject.country=Country Symbol (US for example)
# other optional parameters such as the start date,
# end date, and serial number of the certificateFigure 1: A sample directive file.
# JAR signing directive
# Signer -- must be in system's database
signer=yourself
# Certificate number
cert=1
# name of signature file
signature.file=yourfileFigure 2: A sample signing-directive file.
This involves a number of steps, outlined as follows.
Create a trusted identity for yourself (e.g. Bob):
javakey -cs Bob truetrue here means it is a trusted identity.
Generate a pair key for Bob. Store both the public and private keys in a file:
javakey -gk Bob DSA 512 pubfile privfilepubfile refers to the filename where the public key will be stored, and privfile refers to the filename where the private key will be stored. DSA refers to the Digital Signature Algorithm, and 512 is the key size.
Generate an X.509 certificate for Bob, and store it in the file named Bob.x509:
javakey -gc directivefileThe directivefile parameter refers to the directive file where your certificate information is specified. A sample directive file is shown in Figure 1.
Create an archive:
jar cf signedApplet.jar sign1.class mew.au cat.gif sign.htmlThis says that the JAR file is named signedApplet, and is a bundle of sign1.class, a sound file (mew.au), an image (cat.gif), and an HTML file (sign.html).
Sign the archive using parameters from a "signing-directive" file:
javakey -gs signdirective signedApplet.jarThis will create the file named signedApplet.jar.sig. A sample signing-directive file is shown in Figure 2.
Move the .sig file into a .jar file:
copy signedApplet.jar.sig signedApplet.jarOn UNIX, of course, you would use the cp command instead of copy.
With the applet signed, your friend will have to configure the system to accept signed code, as follows:
Get a copy of your certificate file: Bob.x509
Create the identity "Bob" in the JDK1.1 identity database, as a trusted identity:
javakey -c Bob trueAssociate the certificate with the identity in the database:
javakey -ic Bob Bob.x509Once your friend has performed these steps, he or she can load your signed applet. The applet will be able to create files (or perform other actions that conventional applets can't) on your friend's machine.
It's as simple as that. However, the most popular browsers, Netscape and Internet Explorer, don't currently support JDK1.1, and don't allow you to configure their security managers.
Downloading applets from unknown sources is risky; such applets may damage or delete files from your machine. Further, some strict limitations are imposed on applets; for example, they can't create files on a user's machine.
Cryptography is one promising solution to establish trust and making applets more useful. Security APIs and tools are provided in JDK 1.1; these facilitate the idea of signing code and establishing secure relationships.
Applet Security FAQ: http://java.sun.com/sfaq.
JDK1.1 Security Documentation: http://www.javasoft.com/products/jdk/1.1/docs/guide/security.
Q. H. Mahmoud, Java 1.1 Unleashed [SAMS Publishing, 1997], Chapter 16: "The Security Package."
Qusay H. Mahmoud is a Software Designer at a major telecommunications company in Ottawa, Canada. He holds a B.Sc. in Data Analysis, and a Masters degree in Computer Science, both from The University of New Brunswick, Canada. You can reach him at: dejavu@acm.org.