access anything on your machine that it wants to. Its also a reason why the fine−grained nature of the access controller is important: if you buy classes from acme.com but only give them access to certain things on your
machine, you are still somewhat protected if by mistake acme.com includes a virus in their software.
Even if all commercial software were virus−free, however, there is a problem with assuming that code downloaded from a commercial site is safe to run on your machine. The problem with that assumption −− and
the reason that Java by default does not allow that assumption to be made −− has to do with the way in which the code you execute makes its way through the Internet. If you load some code from www.xyz.com onto your
machine, that code will pass through many machines that are responsible for routing the code between your site and XYZs site. Typically, we like to think that the data that passes between our desktop and
www.xyz.com enters some large network cloud; its called a cloud because it contains a lot of details, and the details arent usually important to us. In this case, however, the details are important. Were very interested to
know that the data between our desktop and xyz.com passes through, for example, our Internet service provider, two other sites on the Internet backbone, and XYZs Internet service provider. Such a transmission is
shown in Figure 7−1. The two types of authentication that we mentioned above provide the necessary assurance that the data passing through all these sites is not compromised.
Figure 7−1. How data travels through a network
7.1.1 Author Authentication
First we must prove that the author of the data is who we expect it to be. When you send data that is destined for www.xyz.com, that data is forwarded to site2, who is supposed to forward it to site1, who should simply
forward it to XYZs Internet service provider. You trust site1 to forward the data to XYZs Internet service provider unchanged; however, theres nothing that causes site1 to fulfill its part of this contract. A hacker at
site1 could arrange for all the data destined for www.xyz.com to be sent to the hackers own machine, and the hacker could send back data through site2 that looked as if it originated from www.xyz.com. The hacker is
now successfully impersonating the www.xyz.com site. Hence, although the URL in your browser says www.xyz.com, youve been fooled: youre actually receiving whatever data the impersonator of XYZ
Corporation wants to send to you.
There are a number of ways to achieve this masquerade, the most well−known of which is DNS spoofing. When you want to surf to www.xyz.com, your desktop asks your DNS server which is typically your Internet
service provider for the IP address of www.xyz.com and you then send off the request to whatever address you receive. If your Internet service provider knows the IP address of www.xyz.com, it tells your desktop what
the correct address is; otherwise, it has to ask another DNS server e.g., site1 for the correct IP address. If a hacker has control of a machine anywhere along the chain of DNS servers, it is relatively simple for that
hacker to send out his own address in response to a DNS request for www.xyz.com. 114
Now say that you surf to www.xyz.com and request a Java class or set of classes to run a spellchecker for your Java−based word processor. The request you send to www.xyz.com will be misaddressed by your
machine −− your machine will erroneously send the request to the hackers machine since thats the IP address your machine has associated with www.xyz.com. Now the hacker is able to send you back a Java class. If that
Java class is suddenly trusted because, after all, it allegedly came from a commercial site, it has access that you wouldnt necessarily approve: perhaps while its spellchecking your document, it is also searching your
hard disk to find the datafile of your financial planning software so that it can read that file and send its contents back over the network to the hackers machine.
Yes, weve made this sound easier than it is −− the hacker would have to have intimate knowledge of the xyz.com site to send you back the classes you requested, and those classes would have to have the expected
interface in order for any of their code to be executed. But such situations are not difficult to set up either; if the hackers stole the original class files from www.xyz.com −− which is usually extremely easy −− all they
need to do is set themselves up at the right place in the DNS chain.
In the strict Java security model we explored earlier, this sort of situation is possible, but it is not dangerous. Because the classes loaded from the network are never trusted at all, the class that was substituted by the
hackers is not able to damage anything on your machine. At worst, the substituted class does not behave as you expect and may in fact do something quite annoying −− like play loud music on your machine instead of
spellchecking your document. But the class is not able to do anything dangerous, simply because all classes from the network are untrusted.
In order to trust a class that is loaded from the network, then, we must have some way to verify that the class actually came from the site it said it came from. This authentication comes from a digital signature that comes
with the class data −− an electronic verification that the class did indeed come from www.xyz.com.
7.1.2 Data Authentication
The second problem introduced by the fact that our transmissions to www.xyz.com must pass through several hosts is the possibility of snooping. In this scenario, assume that site2 on the network is under control of a
hacker. When you send data to www.xyz.com, the data passes through the machine on site2, where the hacker can modify it; when data is sent back to you, it travels the same path, which means that the hacker on site2 can
again modify the data.
This lack of privacy in data transmission is one reason you might want data over the network to be encrypted −− certainly if the spellchecking software youre using from www.xyz.com is something you must pay for, you
dont want to send your unencrypted credit card number through the network so that site2 can read it. However, for authentication purposes, encrypting the data is not strictly necessary. All that is necessary is
some sort of assurance that the data that has passed through the network has not been modified in transit. This can be achieved by various cryptographic algorithms even though the data itself is not encrypted. The simpler
path is to use such a cryptographic algorithm known as a message digest algorithm or a digital fingerprint instead of encrypting the data.
Encryption Versus Data Authentication
When you send data through a public network, you can use a digital fingerprint of that data to ensure that the data was not modified while it was in transit over the network. This fingerprint is
sufficient to prevent a snooper from substituting new data e.g., a new Java class file for the original data in your transmission.
However, this authentication does not prevent a snooper from reading the data in your transmission; authenticated data is not encrypted data. If you are worried about someone stealing
