Chapter 7. Introduction to Cryptography
So far, weve examined the basic level of Javas security paradigm −− essentially, those features that make up the Java sandbox. Were now going to shift gears somewhat and begin our examination of the cryptographic
features in the Java security package itself. The Java security package is a set of classes that were added to Java 1.1 and expanded in Java 2, version 1.2; these classes provide additional layers of security beyond the
layers weve examined so far. Although these classes do play a role in the Java sandbox −− they are the basis on which Java classes may be signed, and expanding the sandbox based on signed classes is a key goal of Java
security −− they may play other roles in secure applications.
A digital signature, for example, can authenticate a Java class so that the security policy can allow that class greater latitude in the operations it can perform, but a digital signature is a useful thing in its own right. An
HR department may want to use a digital signature to verify requests to change payroll data, an online subscription service might require a digital signature to process a change order, and so on. Thus, while well
examine the classes of the Java security package from the perspective of what well be able to do with a signed class, the techniques well show will have broader applicability.
In order to use the classes of the security package, you dont need a deep understanding of cryptographic theory. This chapter will explain the basic concepts of the operations involved, which should be sufficient to
understand how to use the APIs involved. On the other hand, one feature of the security package is that different implementations of different algorithms may be provided by third−party vendors. Well explain how
to go about providing such implementations, but it is assumed that readers who are interested in writing such an implementation already understand the mechanics of cryptography. Hence, we wont give any
cryptographically valid examples in those sections. If youre interested in this type of information, a good reference is Jonathan Knudsens Java Cryptography OReilly Associates.
If you already have an understanding of the basics of digital signatures, encryption, and the need for authentication, you can skip this chapter, which provides mainly background information.
7.1 The Need for Authentication
We are primarily concerned with one goal of the security package: the ability to authenticate classes that have been loaded from the network. The components of the Java API that provide authentication may have other
uses in other contexts including within your own Java applications, but their primary goal is to allow a Java application and the Java Plug−in to load a class from the network and be assured of two things:
The identity of the site from which the class was loaded can be verified author authentication. •
The class was not modified in transit over the network data authentication. •
As weve seen, Java applications typically assume that all classes loaded over the network are untrusted classes, and these untrusted classes are generally given permissions consistent with that assumption. Classes
that meet the above two criteria, however, need not necessarily be so constrained. If you walk into your local software store and buy a shrink−wrapped piece of software, youre generally confident that the software will
not contain viruses or anything else thats harmful. This is part of the implied contract between a commercial software producer and a commercial software buyer. If you download code from that same software
producers web site, youre probably just as confident that the code youre downloading is not harmful; perhaps it should be given the same access rights as the software you obtained from that company through a
more traditional channel.
Theres a small irony here because many computer viruses are spread through commercial software. Thats one reason why the fact that a class has been authenticated does not necessarily mean it should be able to
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
Kategori