by Mark Wutka
One of the biggest hindrances to some Java developers has been the security restrictions placed on applets. Many applet developers want to be able to connect to other sites on the network or to access files on the local hard disk.
You could argue that the restriction on file access is a good thing, since you may soon be writing applets for computers that have no local storage. The network restrictions, however, are another matter.
The reason for the harsh restrictions on network connections is that many users sit safely behind their company's firewall. A firewall protects the company network from outside intruders who might want to steal data or tamper with the systems.
Generally, a firewall allows access out to the Internet but does not allow sites on the Internet to access hosts on the other side of the firewall.
A Java applet with no security restrictions thwarts the firewall because it can access all the hosts on the local network. Anyone who wants to snoop around for data or damage your systems could write an applet that connects to various machines on your network, test the machines for any security holes, and then exploit those holes.
This could all happen without you knowing it. The applet might be a simple scrolling-text applet sending you nice happy messages while it merrily ravages your network.
This security problem comes about because you can download a Java applet and run it without even knowing it. Normally, this is an advantage.
You don't want to know that you are downloading applets and you don't want to do anything special to download them. But in the case of security, this is another matter.
When you download a software package, you have a certain amount of trust toward the vendor of the software. If it's a shareware program off some big archive, you might be cautious enough to run a virus checker on the program before you run it. Of course, you should do that all the time, but many people don't learn until they get bitten by a virus.
You are willing, however, to let this program have complete access to your local system. For all you know, it could snoop around your network just as well as an unrestricted applet could.
Many companies get upset at you for loading "unapproved" software for just this reason. You could expose your entire company's network to an outside attack.
You don't usually worry about this sort of thing from a well-known company like Netscape, Sun, or Microsoft. You have some degree of trust in them, partially because you know that they would be out of business if they got a reputation for distributing malicious software.
It would be nice if Java were able to establish some level of trust for each applet it loads. If you were able to verify that an applet came from Sun, you might be willing to give it a lot more access than from pHrEakR's hAvEN. Digital signatures allow you to do precisely that.
A digital signature is an offshoot of data encryption. When you encrypt data, you use a piece of information called a key to scramble your data.
The person you send the data to then uses the same key or another key to descramble the data. The several forms of encryption are discussed in Chapter 27, "Encrypting Data."
The encryption used with digital signatures is called public key encryption. The idea behind public key encryption is simple. When you want to receive data via public key encryption, you create a public key and a corresponding private key, and then publish the public key for all to see.
Whenever someone wants to send you an encrypted message, they use your public key to encode the data. When you receive it, you use your private key to decode the data.
The trick here is that you can't decode the data with the public key; you can only encrypt it. And it is usually computationally impossible to determine the private key from the public key.
The idea behind a digital signature is that you use a special form of encryption to create a much smaller version of your data. This smaller version of the data is the signature of the data.
The encrypted information in a digital signature is not a complete representation of the data-that is, you couldn't decode it and get the original information back. In other words, a digital signature is something of a one-way encoding. You can't get the original information back, but given the original information, you can verify that it was signed with a particular key. Since the signature is generated using all of the original information, if you changed even a tiny part of the original information, the digital signature would be completely different. Furthermore, you can't predict what the new digital signature will be when you change a portion of the original information. This keeps others from tampering with digitally signed information.
When someone sends you digitally signed information, they must send you both the original information and the signature generated for that information. You then use their public key to verify that the signature was generated by them. Unlike normal encryption, where the intent is to hide information, a digital signature is intended to verify the origin and contents of the information.
As shown in Figure 26.1, Bob's Software digitally signs an applet using Bob's private key.
Figure 26.1 : Bob's Software creates a digital signature using a private key.
Next, Bob's Software sends you both the applet and the applet's digital signature, as shown in Figure 26.2.
Figure 26.2 : Bob's Software transmits the applet and its signature.
Now, as shown in Figure 26.3, you verify the signature against the applet using Bob's well-known public key. The signature algorithm tells you whether the signature was generated by the private key corresponding to Bob's public key.
Figure 26.3 : You verify the applet to see that it was really signed by Bob's Software.
Now, suppose a malicious person who has a bit of ingenuity can intercept the applet transmission from Bob's software and substitute a phony applet. In addition to the phony applet, the malicious person either forwards Bob's original signature or creates a valid digital signature for the applet, but using a different private key.
Figure 26.4 shows a possible scenario for this.
Figure 26.4 : A malicious person intercepts the applet from Bob's Software and substitutes a phony one.
When you receive the phony applet, you check the applet and its signature against Bob's public key, as shown in Figure 26.5. You find that the applet was not sent by Bob's Software.
Figure 26.5 : You check the malicious applet and its signature against Bob's public key and find that they don't match.
If the malicious person had sent you the original signature generated by Bob, it would not match the applet since the applet is not the same one Bob's Software generated the signature on.
If the malicious person generates a new signature for the file, it still does not match because it was not generated using Bob's private key. You can discard the applet and call Bob's Software on the phone to ask what's going on.
The whole reason for incorporating digital signatures into Java is to be able to verify that an applet really comes from a certain place. Once you can do this, you can create a set of restrictions or permissions for any applet signed by a certain site.
In other words, you decide how much you trust a particular organization
and then decide what you will permit that organization's applets
to do on your system.
The Security API from Sun was not available at the time this book was written. It is expected that by the time you read this, the API will be available, as will a preliminary implementation. The information given here is based on Sun's statements about how the security will work.
Digitally signed applets can be restricted to access only certain areas of the network or certain local file systems. For instance, you might create a directory called /usr/local/bob and allow Bob's Software applets to access only that directory.
If Bob's Software decides they want to damage your system, the worst they could do is fill up their own directory until it takes up all your hard disk space.
Suppose you have a Web browser that accepts digital signatures and you download Bob's Software's new hard drive manager applet. Your browser would first verify the signature of the applet and determine that the applet indeed came from Bob's Software.
Next, the browser would consult its security information to see what kind of access Bob's Software is allowed. Presumably, this information would be relayed to the Java SecurityManager running in your browser.
If you download a hard drive manager, you probably have to tell
the security system to allow Bob's Software full access to the
hard drive. The point is, you must tell the security system what
kind of access you want to allow.
The Jeeves server accepts digital signatures on servlets, allowing you to use servlets from other sites and determine how much you are willing to trust the servlets.
Microsoft supports digital signatures for verification of all downloaded code in version 3 of the Internet Explorer. Under the Microsoft scheme, a digitally signed applet is allowed more access to the local machine. Under Sun's security framework, you can control access based on who signs the applet. Under Microsoft's framework, all digitally signed applets have the same amount of access.
It won't take long for you to tire of setting up security information for every different company you get applets from. There will be a market for trusted third-party verification companies who evaluate the security of applets and their companies, and provide a digital signature for the applet.
Bob's Software would send off a copy of their latest and greatest hard drive manager program to a third-party company like TrustMe, Inc., as illustrated in Figure 26.6.
Figure 26.6 : Bob's Software sends their software to a trusted third party for verification.
TrustMe analyzes the applet and determines if it is doing anything unusual. Or it just verifies the applet, depending on the company. The point is, TrustMe is responsible for ensuring that the applet didn't do anything malicious to your system.
When you download an applet from Bob's Software, you also get the signature generated by TrustMe. As shown in Figure 26.7, your browser sees that the applet is signed by TrustMe and determines the amount of access allowed, based on the restrictions you set up for any applet signed by TrustMe.
Figure 26.7 : Your browser determines the security restrictions based on TrustMe, not on Bob's Software.
The advantage here is that TrustMe can verify for many different companies. Rather than you having to enter a security policy for each different company, you can enter a policy for a small number of trusted verification companies.
For the most part, digital signatures are pretty secure. If used properly, digital signatures are very secure, but carelessness and lack of understanding can compromise that security.
In addition, digital signatures by themselves do not solve all potential security problems. Most of the problems come from putting too much trust in the digital signatures or by assuming that they protect you from something they don't.
Any time you have a public key system, you need a way to verify that the public key you have is the correct key. Otherwise, someone who wants to slip you a malicious applet could make you think that the public key for Bob's Software is something other than the real key value.
For example, they might send you a fake e-mail saying "To All Bob's Software Customers, Our private key was recently compromised, forcing us to use a new private/public key pair. Please visit our Web site at ." Of course, the malicious person could give you an incorrect Web site address or, through a process called "spoofing," impersonate Bob's Web site.
This potential security problem is usually handled by using a certification authority (CA). This CA is a trusted signing authority. When you create your own private/public key pair, you send the public key to a CA along with information verifying who you are. The CA then verifies your information and digitally signs your public key with the CA's digital signature.
When you download digitally signed code, you also receive a certificate
containing the server's digital signature, signed by the CA. You
then use this certificate to verify the signature on the code.
In other words, the server is saying to you "Here is some
code that I have signed, and here is a copy of my signature that
has been notarized by a CA." While the term "certificate"
sounds good, it is really just a digitally signed public key.
It is extremely important that your browser have some built-in knowledge of a CA's key. Everything that comes from the network has the potential of being fake. The browser needs some piece of information that does not come from the network before it can make any assumptions about the validity of network information. In this case, the browser needs the CA's public key so that it can verify that the CA really did sign a particular certificate.
Most certificate authorities have very stringent security procedures to keep people from sabotaging the certification process. A significant risk for a certificate authority is having its private key compromised. Once someone gets the private key for a CA, they can create false certificates. For instance, if you had the private key for a CA, you could create a certificate for Bob's Software and sign it with the CA's key, allowing you to pretend that you are Bob's Software. A good CA uses a system that hides the key from everyone, even the employees at the CA. In these cases, the CA's signature is produced by a machine that cannot reveal the private key. Some of these machines will even destroy the private key if they are tampered with. Overall, the likelihood of someone getting the private key for a CA is very remote.
As technology has improved in the area of security, humans are almost always the weak link in the security chain. You may not be able to get the private key for a CA, but you can bribe someone at a CA to sign a false certificate for you. In other words, you create a certificate that says that you are Bob's Software and get someone at the CA to sign it. Most CA's have fairly stringent security procedures, making even this kind of security breach unlikely. Unfortunately, there is no way to render it completely impossible.
Another potential weakness in the area of phony signatures is that someone might be able to successfully impersonate Bob's Software and obtain a signed certificate from a CA without bribing anyone at the CA. You can always forge credentials, perform spoofing over the network, and tap or reroute phone lines. Of course, this is not an aspect of digital signatures. This situation can occur in everyday business and occasionally does. If you are creating an electronic commerce system, you should be careful which CA's you accept certificates from. A certificate authority that does not take adequate precautions in verifying the identify of a person or corporation makes fraud a lot easier. You don't want to trust certificates from a CA that issues certificates to anyone that mails them a request.
The Pretty Good Privacy (PGP) encryption package uses an interesting alternative to a certification authority. Rather than using a CA, PGP users pass keys around to each other.
The idea is that you generate your own private/public key pair and then give your public key to some friends, who digitally sign your key. In other words, instead of going to a central certificate authority, your friends act as CAs for you (see Figure 26.8).
Figure 26.8 : You get your public key signed by people who trust you.
These people are now your introducers. They vouch for you. When a stranger gives you their public key, they also give you a list of signatures from their introducers (see Figure 26.9). This is like giving an employer a list of references.
Figure 26.9 : When giving your public key to a stranger, you also give them a list of introducers.
If you know one of the introducers, you have some idea that you can trust the key. If you don't know any of the introducers, you can't be sure that the key you get is really valid.
This scheme works pretty well for personal use, but it has some drawbacks for business use. For one thing, it is a lot easier for someone untrustworthy to sneak in and get their key verified by normally trustworthy people.
After all, the introducers are usually friends of yours or people you know over the Net. It would be easy for someone to become your "friend" just to get you to introduce them.
Another problem with key passing is that if someone's private key is compromised (stolen), there's no easy way to propagate that information. In other words, you may know Fred and trust people introduced by Fred.
Suppose Fred's private key has been stolen and someone begins creating keys that were supposedly signed by Fred. You may not have heard from Fred in a while and you may not know that his key was stolen. You may end up trusting a malicious person who was supposedly introduced by Fred.
You can also run into this problem using a CA. Because you don't verify certificates with the CA at runtime, which would be a huge performance bottleneck, you don't know immediately if a certificate is no longer valid. To address this problem, there are lists of invalid certificates called Certificate Revocation Lists (CRL). When your browser receives a certificate, it checks it against a CRL to see if the certificate has been revoked.
You may wonder what happens in a few years when the number of revoked certificates has grown tremendously. Wouldn't a CRL be very large and unwieldy? A certificate does not stay on a CRL forever because certificates also have an expiration date. As soon as a certificate expires, it is removed from the list because any browser trying to verify the certificate would reject it for being expired.
Digital signatures verify that a piece of software came from a particular person but they cannot verify that you have the most recent version of software. Someone with a knowledge of the security holes in an old piece of software could feed you that software and then exploit the holes.
For example, suppose Bob's Software Hard Disk Manager Applet version 1.0 has a serious flaw that allows anyone on the Web to access your local file system while the applet is running. Even though Bob's finds the error and corrects it shortly thereafter, a malicious person could save a copy of the applet, along with its valid signature, from Bob's Software.
When you go to load the applet from Bob's, the malicious person could give you the old version of the program and then immediately start accessing your local file system. Figure 26.10 illustrates this problem.
Figure 26.10: Someone can pass you an old piece of signed software.
As a client, you cannot solve this problem. The software vendor who is supplying you with the applet must do this.
Whenever Bob's Software releases a new version of the software, they should get a new key pair for signing the software. The new pair is registered with the CA, and the old one must be invalidated. In other words, you should revoke the signature for the old version of software.
This way, when someone tries to give you the old copy of the applet, you check the revocation list and learn that the signature key for the old copy has been revoked, so you should discard the old version.
Digital signatures are done behind the scenes in Java. This means that when you load an applet, you don't really know whether it's been signed or not.
You can take comfort in the fact that an unsigned applet or an improperly signed applet is not allowed to wreak havoc on your system. But you should not assume that an applet came from where you think it did.
This is not a problem with the digital signature mechanism itself. The problem is in the HTTP protocol (and other networking protocols).
Suppose you have been dealing with Fred's Catering for a while and you have digitally signed applets from Fred's Web page. You know that Fred's is a trustworthy company.
When you order from Fred's, you enter your credit card number in Fred's ordering applet. You cannot assume that the applet really came from Fred's just because you have Fred's public key.
A malicious person who wants to get your credit card number could impersonate Fred's Web page. The applet you run might look exactly like the applet for Fred's (see Figure 26.11). But when you enter your credit card number, it gets shipped off to someone else's list of now-stolen credit card numbers.
Figure 26.11: Someone impersonating Fred can pass you a phony applet.
The really clever thieves not only impersonate Fred's. They turn around and impersonate you to Fred's and place your order (see Figure 26.12). That way, you never suspect that someone actually saw your credit card number.
Figure 26.12: A clever credit card thief looks at your number and then passes the order on to the real company.
There are other ways of handling this. Just keep in mind that digital signatures do not solve this problem. One way of addressing this problem is to use a secure Web protocol like SSL. This technique is discussed in Chapter 30, "Performing Secure Transactions."
This particular form of attack is pretty far-fetched but certainly feasible for someone who really wants to infiltrate your company. Most Web browsers today are delivered over the Internet, with no encryption and no digital signatures. If someone wants to breach your company's security, they could impersonate the Web browser vendor and feed you a hacked version of the browser.
Suppose, for instance, that your favorite browser, the Surf-O-Matic, has just been updated and put out for download on the Net. If someone wants to infiltrate your network, they could make you think that their file server was really the Surf-O-Matic file server. You happily download the new browser, unaware that it contains a version of Java that doesn't use certain security restrictions. Figure 26.13 illustrates this problem.
Figure 26.13: By impersonating a file server, a malicious person can feed you a phony Java environment.
Some time later, you find out that someone has been sneaking into your network and stealing confidential information, and you never suspect your browser because Surf-O-Matic is a trustworthy company.
This is not really a Java problem and it's not one you can solve yourself. It must be solved by Surf-O-Matic and other browser vendors.
You must be able to download a browser and verify it by a digital signature to be sure that it really came from the right vendor. Otherwise, all the nice security within Java is useless.
Unfortunately, this is something of a chicken and egg situation. How do you get the verification software? If you download it off the Net, how do you know it isn't also a phony?
This is one of the more maddening aspects of security. The only thing that keeps this from being a huge problem is that it is not a simple task to impersonate a file server. Even then, you can usually fool only one company at a time, unless you can impersonate the file server to the whole Internet.
Most companies don't have to go to this degree of worry. But if you have highly classified information on your network that people would love to get their hands on, you probably have a big headache right now.
One solution to the fakery problem is to talk to your vendor about getting an encrypted version of the software. Another solution is to send someone over to the company headquarters and get a copy directly from them.
For you to digitally sign information, you need a certificate. Unfortunately, certificates are not free. You must buy a certificate from a known CA like Verisign. Many secure Web servers provide registration information for ordering a certificate.
Typically, you must first generate a public/private key pair. This only makes sense because the certificate is just a digitally signed verification of a public key. Next, you send your public key, along with a lot of information about yourself or your company, to the certificate authority. Next, the certificate authority verifies your identity. Depending on the CA, this may be a lengthy process, especially if the CA has a reputation of being very thorough when investigating identities. Companies requesting a certificate from Verisign, for instance, must provide a letter from an authorized representative of the company along with certain official documents like the company's articles of incorporation. Once the CA has verified your identity, it digitally signs your public key and sends you a completed certificate.
For more information, try the Verisign home page at http://www.verisign.com.
In general, digital signatures are useful in cases where a handwritten signature would normally suffice. For instance, you could use a digital signature to sign e-mail messages so that recipients could be sure that you really sent the mail. This is especially important given the ease at which e-mail may be faked.
Digital signatures may also be used to sign receipts when purchasing goods and services online. It is extremely important to use a secure certification process when setting up an electronic commerce system. You want to ensure that the person who digitally signs the receipt is really the person you think it is. Likewise, when you obtain a digital certificate for performing electronic commerce, it is important that no one be able to forge your certificate. It is extremely important that no one be able to access your private key. Once someone has the private key for your signature, they may forge your signature on any digital receipt. Many digital signature systems store your signature in an encrypted form where you must enter a password any time you go to digitally sign a document. If the signature is not encrypted, any piece of software that can read your local hard disk may be able to find your signature.
If you haven't had much experience with digital signatures yet, that will change. You may soon find that you can't do business without one.