The JDK 1.1 includes a new Java Security API which supports several important new security features, the most significant of which may turn out to be signed applets. Properly implemented, digital signatures will provide the additional trust needed to allow Java applets greater access to client system capabilities, thereby supporting more powerful Web-based applications.
What Does Everyone Want To Do?
Current browsers, which are based on the JDK 1.0 toolkit, support a very limited subset of system capability when running Java applets. Sun has taken a conservative approach and designed to the paradigm, "Everything that is not expressly allowed is forbidden." Applets have access to the monitor, keyboard, mouse and originating system. Period. This is a perfect environment for running the untrusted code common on the Internet, such as animations, forms and even applications on network computers (presumably, the data files will be stored on the server). Beyond this simple, albeit useful, capability, there's a strong desire to allow applets to do more than treat a PC as a glorified dumb terminal - but not if it introduces an unacceptable marginal risk. Home banking, electronic commerce, personal productivity applications and everything else that needs to read or write data on the client machine are waiting for a more flexible Java security policy. The Java Virtual Machine can only allow applets access to system resources outside of the sandbox when there is a reasonable expectation that the applets were not created or modified to include undesirable or even hostile functions.
Do You Trust Me?
The concept of trust is a relative one. Based on intuitive feelings, you might "trust" the Pope, but not the President. Deciding whether to trust a human artifact is a complex decision involving understanding of the object's function, the motivations of its creators and knowledge of its current state (i.e., if it has been unexplainably altered). Whether the decision is based on formal analysis or a hunch, you probably have some feelings on how far you trust any particular piece of code. It may be easier to trust source code over object code because it can be reviewed and understood, although this is not practical for the lay person. You are more likely to distrust some unknown code from an unfamiliar bulletin board than a shrink-wrapped application with a software publisher's hologram on it. Most people would trust a friend over a stranger, which is not totally due to affection. An ongoing friendship is a relationship that is significant not only in fellowship, but also in the value to both parties in being able to trust each other. The parties of a trust relationship are motivated by mutual self-interest, which is a very reliable human characteristic. Business and other organizational relationships work the same way; the greater the trust, the greater the mutual benefit.
For example, you probably can't view the source code of a bank's home banking applet (and most people wouldn't want to), but if you don't have a certain level of trust for your bank, you shouldn't do business with them. Given that you have made the decision to trust a specific financial institution and to use their home banking service, you are probably willing to let their code run on your PC. The trick with the Web is to extend this trust over the Internet. Enter the digital signature.
Digital signatures are based on a brilliant mathematical abstraction...asymmetric encryption. Unlike symmetric encryption, in which a file is both encrypted and decrypted with the same key, the asymmetric cryptographic process uses two different keys, one for encryption and one for decryption. Commonly called public key encryption, it is well on its way to being the foundation of the Internet's digital trust infrastructure. It is perfectly acceptable to freely distribute the public key, as long as the confidentiality of the private key is maintained, because it is virtually impossible to derive one key from the other. Anyone can maintain data confidentiality when sending someone else a document by encrypting it with the recipient's public key - only the recipient's private key can decrypt it. The inverse is also true - successful decryption with a specific public key is proof of encryption by the associated private key. This latter capability is the basis of digital signature, which turns out to be an extraordinarily significant and useful service because it is ideal for extending trust over the Internet. Distribution of a public key is much simpler than the distribution of a symmetric key because there is no need to maintain the key's confidentiality.
Digital signing is a simple process. A one-way hash function is used to derive a unique output of fixed size called a message digest. The digest is then encrypted with the private key and packaged with the document in a standard format, or envelope. Verification reverses this process. The object is subjected to the same one-way hash function and the output is compared to the result of decrypting the signature with the public key. If the values match, the signature is verified.
The signing capability supported with JDK 1.1 by the java.security package allows the digital signing of Java files with a private key and the verification of that signature with a public key. A convenient new feature of the JDK 1.l is the Java Archiver. Based on the ubiquitous ZIP format from PKWARE, it supports the bundling, compression and signature of .class and related files. In addition to providing convenience and efficiency, it includes a manifest identifying all the signed files, associating them with the appropriate signature. Digital signature provides two important data points about an object. Its signer can be determined and its integrity verified. We know which private key was used to sign it and we know that whatever its experiences since then, it hasn't been modified. A digital signature does not provide confidentiality; it provides trust, or assurance as to the origins of an applet and to its wholeness or integrity.
Be aware that the system has potential weaknesses that must be dealt with. First, control of the private key must be maintained - if it is stolen, anyone can counterfeit a signature. Second, the identity of the public key must be trusted also. If a bogus public key is associated with a real identity, then the holder of the matching private key can probably assume that identity. This is called a masquerade. Other potential failures include key obsolescence problems and improper identification at key creation. The proper infrastructure can reduce the risks to an acceptable level.
A Greater Authority
Manually exchanging public keys with multiple network correspondents can quickly become tedious, and there is no way to reliably guarantee the identity of a key holder remotely. If someone is able to spoof an identity at time of public key dissemination, the system breaks down. Manual distribution is like bartering for goods remotely; there is no common medium of exchange, and you do not know if you are receiving a genuine article or a fake. This problem can be solved by a Certificate Authority (CA).
A certificate is a standardized object that contains a public key and additional information such as the key holder's identity, expiration date, certificate issuing authority, name, etc. The most common standard representation format is X.509, which allows certificates to be used within existing X.500 directory service infrastructures.
A Certificate Authority is a trusted third party that acts as an authentication clearing house by issuing, renewing and revoking certificates. A certificate authority digitally signs certificates it issues with its own private key. Because trust is a transitive property, once an entity has manually authenticated itself with a CA, it can easily be electronically authenticated by any other entity which trusts that CA. This chain of trust is as strong as its weakest link There are two critical points in a certificate infrastructure. First is the original establishment of identity, and second is the confidentiality and integrity of the certificate authority's private key. VeriSign is the most well known commercial CA. For a price, they will authenticate an organization at any of several increasing levels of trust and issue them a certificate. VeriSign's vetting process for establishing the identification and authentication of a certificate holder to a specific level of certainty is quite complex. The value that VeriSign provides is the thoroughness of this identification process and the care that they take to maintain the sanctity of their own private key, which is used to sign certificates. A certificate authority must be trusted to be useful, and a decision on how far to trust a CA should be based on an evaluation of their procedures and processes.
Certificates may be issued for private use or public use. Any organization can become a certificate authority to support its own needs. Financial institutions, brokers and other firms providing on-line commercial services to regular clients may find it convenient to generate certificates for their partners or customers. Large firms will also want to issue certificates internally. Java developers involved with projects that could use certificates appropriately will probably become involved with plans for their organization's certificate authority.
Ultimately, the Public Key Infrastructure (PKIX) is planned as a country-wide, or even global, hierarchy of certificate authorities, each of which trusts its neighboring CAs. The PKIX will be based on X.500, a distributed and robust name service functionally similar to DNS. Any entity on the network will be able to verify any public certificate by querying their logically nearest certificate server using lightweight directory access protocol (LDAP). The verification process will not only verify the verifier (i.e., the CA that issued the certificate and potentially the CA above that and so on up to the root CA), but will also check the certificate against a revocation list to ensure that it hasn't been cancelled.
Bringing it all Together
The elements are becoming available to allow more powerful applets. Java now supports digitally signed applets that can be verified. Certificate authorities are available in limited form to facilitate the cryptographic exchange necessary to allow authentication of unknown or remote parties. What is not available yet is browser support. JDK 1.1 is brand new, and Netscape and Microsoft have not yet had a chance to incorporate support for signed applets into their browsers. Both vendors already support the use of digital certificates to verify servers when using the Secure Socket Layer (SSL) protocol. Adding support for signed applets means a modification to the existing security policy and requires some difficult decisions.
Netscape has already indicated future support for a subset of JDK 1.1 security capabilities. Browsers supporting JDK 1.1 will probably allow signed applets full access to the client system after signature verification. This will be acceptable for many Intranet applications and probably many extranet uses (interactions with trusted external organizations over the Internet). You might trust an applet provider to modify their own datafiles on your PC, but do you want to trust them with everything on your PC? The security needs of individuals and organizations vary, but it is fair to say that the most useful extension to the java security policy will be to allow signed applets selective access to specific system resources. This capability is planned for a future version of the JDK. A usable implementation will require browser modifications providing a detailed security administration interface. Users must be able to graphically choose the privileges allowed specific applets with specific signatures. The vast majority of users will be too unsophisticated to perform this configuration, so it often will have to be done automatically. Providing an API that allows code to safely and automatically modify the security configuration of a specific installation of a browser is a complex problem. Home banking is a good example of where such an API might be used. Perhaps a home bank user will be provided wuth a disk by their financial institution that includes their private key and personal certificate, and also modifies their browser environment to allow a home banking applet to modify Quicken data files. An even more complex scenario involves doing this on-line. These are examples of the "Who is watching the watcher?" paradox. How can a system designed to prevent outside interference safely allow itself to be externally modified? Complex security issues like these are already affecting Java programmers.
The Java Cryptography Extension (JCE) is an add-on to the JDK 1.1 that will include encryption and key exchange. For the time being, this package is not included with the JDK because of its export significance. While it's unfortunate that U.S. export regulations are delaying the implementation of convenient network security, the browser vendors are already shipping different versions of their product for the U.S. and non-U.S. markets and should be able to accommodate this complication. Confidentiality can be provided at the session level now by using SSL. The key exchange support in the JCE will be very important over the next few years until the PKIX is implemented.
Doing This Trick at Home
Just because the complete infrastructure is not yet in place does not mean that you cannot experiment with digital signatures. This is the ideal time to gain familiarity. SunSoft's Web server contains example files that demonstrate key creation, applet signature and digital signature verification. Downloading these simple examples will allow you to generate your own public-private key pair, use it to sign a JAR and attempt to run the applet in the JAR before and after modifying java.security within the JDK's appletviewer miniature browser. Even if you do not intend to run this demonstration, reviewing the example shell scripts will make the process clearer.
What The Future Holds
JDK 1.1 probably does not represent a major change in the way applets will be used over the Internet. Given browser support, it will allow specific partners to exchange keys and trust each other's applets. This will probably be most useful on the Intranet, but trusted external partners can be supported also. Putting a public key in the appropriate area on a client machine will allow signed Java applets to run with full system privileges. Promised in future versions of the JDK, a more flexible model will allow selective access to system resources by signed applets. As the public key infrastructure develops and Java security becomes more sophisticated, applets will become increasingly powerful and interesting. Within two years, today's security-bound Java applets will seem primitive and unsophisticated.
About the Author
Jay Heiser is the Director of Internet Products for HomeCom Internet Security Services, where he is currently providing network security consulting to several major financial institutions and retail chains. He has lectured on information security in the US and Europe at events such as InfoWarCon, The Internet Conference, and FOSE. Jay also has animated several presentations on basic network security topics and made them available on the Web at http://www.homecom.com/services/hiss/LearnAbout.html. He can be reached at [email protected]