Java Security (Scott Oaks) (Z-Library)

📄 File Format: PDF

💾 File Size: 1.4 MB

📖 Read Online ⬇️ Download

Registered users can read the full content for free

Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.

📄 Page 1

Table of Contents Preface..................................................................................................................................................................1 Who Should Read This Book?.................................................................................................................1 Versions Used in This Book....................................................................................................................2 Conventions Used in This Book..............................................................................................................2 Organization of This Book.......................................................................................................................3 What's New in This Edition.....................................................................................................................5 How to Contact Us...................................................................................................................................5 Acknowledgments....................................................................................................................................6 Feedback for the Author..........................................................................................................................6 Chapter 1. Java Application Security...............................................................................................................7 1.1 What Is Security?...............................................................................................................................7 1.2 Software Used in This Book..............................................................................................................9 1.3 The Java Sandbox............................................................................................................................14 1.4 Security Debugging.........................................................................................................................17 1.5 Summary..........................................................................................................................................19 Chapter 2. The Default Sandbox.....................................................................................................................21 2.1 Elements of the Java Sandbox.........................................................................................................21 2.2 Permissions......................................................................................................................................22 2.3 Keystores..........................................................................................................................................32 2.4 Code Sources...................................................................................................................................33 2.5 Policy Files......................................................................................................................................33 2.6 The Default Sandbox.......................................................................................................................37 2.7 The java.security File.......................................................................................................................39 2.8 Comparison with Previous Releases................................................................................................40 2.9 Summary..........................................................................................................................................40 Chapter 3. Java Language Security................................................................................................................41 3.1 Java Language Security Constructs.................................................................................................41 3.2 Enforcement of the Java Language Rules........................................................................................46 3.3 Comparisons with Previous Releases..............................................................................................50 3.4 Summary..........................................................................................................................................51 Chapter 4. The Security Manager...................................................................................................................53 4.1 Overview of the Security Manager..................................................................................................53 4.2 Operating on the Security Manager.................................................................................................57 4.3 Methods of the Security Manager....................................................................................................58 4.4 Comparison with Previous Releases................................................................................................73 4.5 Summary..........................................................................................................................................74 Chapter 5. The Access Controller ...................................................................................................................77 5.1 The CodeSource Class.....................................................................................................................77 5.2 Permissions......................................................................................................................................78 5.3 The Policy Class..............................................................................................................................87 5.4 Protection Domains..........................................................................................................................90 5.5 The AccessController Class.............................................................................................................91 5.6 Guarded Objects...............................................................................................................................96 5.7 Comparison with Previous Releases................................................................................................97 5.8 Summary..........................................................................................................................................97 i

📄 Page 2

Table of Contents Chapter 6. Java Class Loaders........................................................................................................................99 6.1 The Class Loader and Namespaces..................................................................................................99 6.2 Class Loading Architecture............................................................................................................101 6.3 Implementing a Class Loader........................................................................................................102 6.4 Miscellaneous Class Loading Topics.............................................................................................110 6.5 Comparison with Previous Releases..............................................................................................112 6.6 Summary........................................................................................................................................112 Chapter 7. Introduction to Cryptography....................................................................................................113 7.1 The Need for Authentication.........................................................................................................113 7.2 The Role of Authentication............................................................................................................117 7.3 Cryptographic Engines...................................................................................................................118 7.4 Summary........................................................................................................................................122 Chapter 8. Security Providers.......................................................................................................................123 8.1 The Architecture of Security Providers.........................................................................................123 8.2 The Provider Class.........................................................................................................................127 8.3 The Security Class.........................................................................................................................132 8.4 The Architecture of Engine Classes...............................................................................................137 8.5 Comparison with Previous Releases..............................................................................................137 8.6 Summary........................................................................................................................................138 Chapter 9. Keys and Certificates...................................................................................................................139 9.1 Keys...............................................................................................................................................140 9.2 Generating Keys.............................................................................................................................143 9.3 Key Factories.................................................................................................................................151 9.4 Certificates.....................................................................................................................................160 9.5 Keys, Certificates, and Object Serialization..................................................................................171 9.6 Comparison with Previous Releases..............................................................................................172 9.7 Summary........................................................................................................................................172 Chapter 10. Key Management.......................................................................................................................175 10.1 Key Management Terms..............................................................................................................175 10.2 The keytool..................................................................................................................................178 10.3 The Key Management API..........................................................................................................188 10.4 A Key Management Example......................................................................................................194 10.5 Secret Key Management..............................................................................................................199 10.6 Comparison with Previous Releases............................................................................................205 10.7 Summary......................................................................................................................................206 Chapter 11. Message Digests..........................................................................................................................207 11.1 Using the Message Digest Class..................................................................................................207 11.2 Secure Message Digests...............................................................................................................210 11.3 Message Digest Streams..............................................................................................................212 11.4 Implementing a MessageDigest Class.........................................................................................216 11.5 Comparison with Previous Releases............................................................................................219 11.6 Summary......................................................................................................................................219 ii

📄 Page 3

Table of Contents Chapter 12. Digital Signatures.......................................................................................................................221 12.1 The Signature Class.....................................................................................................................221 12.2 Signed Classes.............................................................................................................................230 12.3 Implementing a Signature Class..................................................................................................237 12.4 Comparison with Previous Releases............................................................................................241 12.5 Summary......................................................................................................................................241 Chapter 13. Cipher−Based Encryption.........................................................................................................243 13.1 The Cipher Engine.......................................................................................................................243 13.2 Cipher Streams.............................................................................................................................256 13.3 Sealed Objects..............................................................................................................................259 13.4 Comparison with Previous Releases............................................................................................260 13.5 Summary......................................................................................................................................260 Chapter 14. SSL and HTTPS.........................................................................................................................261 14.1 An Overview of SSL and JSSE...................................................................................................261 14.2 SSL Client and Server Sockets....................................................................................................268 14.3 SSL Sessions................................................................................................................................271 14.4 SSL Contexts and Key Managers................................................................................................273 14.5 Miscellaneous SSL Issues............................................................................................................281 14.6 The HTTPS Protocol Handler......................................................................................................286 14.7 Debugging JSSE..........................................................................................................................289 14.8 Summary......................................................................................................................................290 Chapter 15. Authentication and Authorization...........................................................................................291 15.1 JAAS Overview...........................................................................................................................291 15.2 Simple JAAS programming.........................................................................................................293 15.3 Simple JAAS Administration......................................................................................................296 15.4 Advanced JAAS Topics...............................................................................................................303 15.5 Summary......................................................................................................................................316 Appendix A. The java.security File...............................................................................................................317 Appendix B. Security Resources....................................................................................................................321 B.1 Security Bugs................................................................................................................................321 B.2 Third−Party Security Providers.....................................................................................................325 B.3 Security References.......................................................................................................................327 Appendix C. Identity−Based Key Management...........................................................................................329 C.1 Javakey..........................................................................................................................................329 C.2 Identities........................................................................................................................................333 C.3 Identity Scopes..............................................................................................................................338 C.4 Key Management in an Identity Scope.........................................................................................344 C.5 Summary.......................................................................................................................................351 Appendix D. The Secure Java Container.....................................................................................................353 D.1 The 1.1−Based Class Loader........................................................................................................353 D.2 The 1.1−Based Security Manager.................................................................................................358 D.3 Running Secure Applications........................................................................................................375 D.4 Summary.......................................................................................................................................377 iii

📄 Page 4

Table of Contents Appendix E. Implementing a JCE Security Provider.................................................................................379 Appendix F. Quick Reference........................................................................................................................385 F.1 Package java.security.....................................................................................................................385 F.2 Package java.security.cert..............................................................................................................411 F.3 Package java.security.interfaces....................................................................................................416 F.4 Package java.security.spec.............................................................................................................420 F.5 Package javax.crypto.....................................................................................................................425 F.6 Package javax.crypto.interfaces.....................................................................................................435 F.7 Package javax.crypto.spec.............................................................................................................436 F.8 Package javax.net..........................................................................................................................442 F.9 Package javax.net.ssl.....................................................................................................................443 F.10 Package javax.security.auth.........................................................................................................448 F.11 Package javax.security.auth.callback..........................................................................................452 F.12 Package javax.security.auth.login................................................................................................456 F.13 Package javax.security.auth.spi...................................................................................................458 F.14 Package javax.security.cert..........................................................................................................458 F.15 Package com.sun.net.ssl..............................................................................................................460 F.16 Package com.sun.security.auth....................................................................................................466 F.17 Package com.sun.security.auth.login...........................................................................................472 F.18 Package com.sun.security.auth.module.......................................................................................472 F.19 Miscellaneous Packages..............................................................................................................474 iv

📄 Page 5

Preface When I first mentioned to a colleague of mine that I was writing a book on JavaTM security, he immediately starting asking me questions about firewalls and Internet DMZs. Another colleague overheard us and started asking about electronic commerce, which piqued the interest of a third colleague who wanted to hear all about virtual private networks. All this was interesting, but what I really wanted to talk about was how a Java applet could be allowed to read a file. Such is the danger of anything with the word "security" in its title: security is a broad topic, and everyone has his or her own notion of what security means. Complicating this issue is the fact that Java security and network security (including Internet security) are complementary and sometimes overlapping topics: you can send encrypted data over the network with Java, or you can set up a virtual private network that encrypts all your network traffic and remove the need for encryption within your Java programs. This is a book about security from the perspective of a Java program. In this book, we discuss the basic platform features of Java that provide security −− the class loader, the bytecode verifier, the security manager −− and we discuss recent additions to Java that enhance this security model −− digital signatures, security providers, and the access controller. The ideas in this book are meant to provide an understanding of the architecture of Java's security model and how that model can be used (both programmatically and administratively). Who Should Read This Book? This book is intended primarily for programmers who want to write secure Java applications. Much of the book is focused on various APIs within Java that provide security; we discuss how those APIs are used by a standard Java 2 Standard Edition implementation. This includes both how these APIs may be used from within your own application and how they may be used from within an applet that runs in the Java Plug−in. The Java Plug−in comes with all versions of the Java 2 platform and allows you to run applets in a virtual machine that is decoupled from the browser, which allows you to have full Java 2 support in most current browsers, from Internet Explorer (version 3 and higher) to Netscape Navigator (version 4 and higher) to Opera. In later versions of Navigator and Opera, the Plug−in is the only supported virtual machine. This is particularly important with respect to security since no browser supports the Java 2 security model in its embedded virtual machine. For the end user or system administrator who is interested in Java security, this book will provide knowledge of the facilities provided by the basic Java platform and how those facilities are used by Java applications and applets within the Java Plug−in. We do not delve into the specific security features of Java−enabled browsers, although we do point out along the way which security features of Java are subject to change by the companies that provide Java−enabled browsers. Hence, end users and system administrators can read this book (and skip over many of the programming examples) to gain an understanding of the fundamental security features of the Java platform, and they can understand from each of its parts how the security features might be administered. This is particularly true for end users and administrators who are interested in assessing the risk of using Java: we give full details of the implementation of Java's security model so that you can program within that model (and adjust it if necessary); we give you a deep understanding of how the model works so you can assess for yourself whether or not Java meets your definition of security. From a programming perspective, we assume that developers who read this book have a good knowledge of how to program in Java, and in particular how to write Java applications. When we discuss advanced security features and cryptographic algorithms, we do so assuming that the programmer is primarily interested in using the API to perform certain tasks. Hence, we explain at a rudimentary level what a digital signature is and how it is created and used, but we do not explain the cryptographic theory behind a digital signature or prove that a

📄 Page 6

digital signature is secure. For developers who are sufficiently versed in these matters, we also show how the APIs may be extended to support new types of cryptographic algorithms, but again we leave the mathematics and rigorous definitions of cryptography for another book. Versions Used in This Book This book is based on Java 2 Standard Edition, version 1.3 (alternately called simply 1.3). The security model of the Java 2 platform is radically different from the model of Java 1. Many basic security interfaces such as the access controller were introduced in Java 2, and other APIs went through significant changes between Java 1.1 and Java 2. On the other hand, there were few changes between Java 2 version 1.2 and 1.3; most of the information we discuss is applicable to 1.2 as well. We also discuss three Java extensions in this book: version 1.2.1 of the Java Cryptography Extension, version 1.0.2 of the Java Secure Sockets Extension, and version 1.0 of the Java Authentication and Authorization Service. These extensions all rely on version 1.3 of the Java 2 platform. Code examples used in this book are available from the O'Reilly web site located at http://www.oreilly.com/catalog/javasec2/. Conventions Used in This Book Constant width font is used for: Code examples• Class, variable, and method names within the text• Italicized font is used for: Filenames• Host and domain names• URLs• When a new method or class is introduced, its definition will appear beginning with italicized text like this: public void checkAccess(Thread t) Check whether the current thread is allowed to modify the state of the parameter thread. Command Conventions There are some examples of commands scattered through the book, especially in sections and appendices that deal with administration. By convention, most examples are shown as they would be executed on a Unix system, e.g.: piccolo% keytool −export −alias sdo −file /tmp/sdo.cer Enter keystore password: ****** Certificate stored in file </tmp/sdo.cer> In these examples, the text typed by the user or administrator is always shown in bold font; the remaining text is output from the command (the string piccolo% indicates a command prompt). On other systems, the names of the files would have to be changed to conform to that system (e.g., C:\sdo.cer for a Microsoft Windows system). Keep in mind, however, that the command−line arguments often specify a URL rather than a filename, in which case you must use forward slashes. In that case, the argument is often the same, although 2 Preface

📄 Page 7

on Microsoft Windows systems you must specify a drive: the Unix directory file:///files/sdo/ is rendered on Microsoft Windows as file:/C:/files/sdo/. When an argument requires a URL, we always specify the protocol to distinguish it from a filename, even though tools will often accept the string without a protocol. However, note that while Microsoft Windows systems often use a forward−slash (/) for command−line options, Java tools (even on those systems) universally use a hyphen (−) to indicate command−line options. In these examples, then, only the file and URL names are different between platforms. Code Conventions The code examples in this book (and in the online samples) are organized by chapter. Each class belongs to a package based on the chapter when it is introduced; e.g., the class Test from Chapter 3, is in the package javasec.samples.ch03. When you unpack the online code, you'll end up with a single directory (javasec), from which the remaining directories and source files descend. There are two simple ways of proceeding. The first is to remain in the directory where you unpacked the sources, not set your classpath, and reference everything by full package name. Hence, to compile and run the Test class from Chapter 3, you'd execute these commands: piccolo% javac javasec/samples/ch03/Test.java piccolo% java javasec.samples.ch03.Test Your account number is 0001 0002 0003 0004 Alternately, you can work in the directory containing the source and set your classpath as follows: piccolo% javac −classpath ../../.. Test.java piccolo% java −classpath ../../.. javasec.samples.ch03.Test Your account number is 0001 0002 0003 0004 When required for space, commands may be continued on multiple lines, in which case a backslash character is used: piccolo% java −classpath ../../.. javasec.samples.ch09.PrintCert \ /files/sdo/foo/bar/very/long/command Commands that appear like this should be typed on one line or typed on multiple lines using whatever escape character is appropriate for your system (e.g., the backslash for a Unix system). Organization of This Book This book is organized in a bottom−up fashion: we begin with the very low−level aspects of Java security and then proceed to the more advanced features. Chapter 1 This chapter gives an overview of the security model (the Java sandbox) used in Java applications and sets the stage for the rest of the book. Chapter 2 This chapter discusses the parameters of the default sandbox and how the sandbox may be changed administratively. It provides instructions for end users and administrators on how to set up Java security policies (including the use of policytool) and introduces the concepts by which these policies are implemented. Preface 3

📄 Page 8

Chapter 3 This chapter discusses the memory protections built into the Java language, how those protections provide a measure of security, and how they are enforced by the bytecode verifier. Chapter 4 This chapter discusses the security manager, which is the primary interface to application−level security in Java. The security manager is responsible for arbitrating access to all local resources: files, the network, printers, etc. Chapter 5 The access controller is the basis for security manager implementations in Java 2. This chapter discusses how to use the access controller to achieve fine−grained levels of security in your application. Chapter 6 This chapter discusses the class loader, which is the class that reads in Java class files and turns them into classes. From a security perspective, the class loader is important in determining where classes originated and whether or not they were digitally signed (and if so, by whom), so the topic of class loaders appears throughout this book. Chapter 7 This chapter provides an overview to the cryptographic algorithms of the Java security package. It provides a background for the remaining chapters in the book. Chapter 8 This chapter discusses the architecture of the Java security package and how that architecture may be used to extend or supplant the default cryptographic algorithms that come with the SDK. Chapter 9 This chapter discusses the APIs available to model cryptographic keys and certificates. Chapter 10 This chapter discusses how keys can be managed within a Java program: how and where they may be stored and how they can be retrieved and validated. It also discusses programmatic transfer of digital keys. Chapter 11 This chapter discusses message digests: how to create them, how to use them, and how to implement them. Chapter 12 This chapter discusses how to create, use, and implement digital signatures. It also contains a discussion of signed classes. Chapter 13 This chapter discusses the encryption available within Java Cryptography Extension (JCE), which allows developers to encrypt and decrypt arbitrary data. Chapter 14 This chapter discusses how the Java Secure Sockets Extension (JSSE) provides SSL encryption, which can be used to encrypt data over TCP sockets. It also provides an implementation of the HTTPS Internet protocol. 4 Preface

📄 Page 9

Chapter 15 This chapter discusses how the Java Authentication and Authorization Service (JAAS) enables applications to authenticate users and grant them particular permissions based on their login ID or other credentials. Appendix A This appendix provides an annotated listing of the java.security file, which is the standard configuration file for the Java security architecture. Appendix B This appendix discusses how to keep up−to−date with information about Java's security implementation, including a discussion of Java security bugs and general resources for further information. Appendix C Key management in Java 1.1 was radically different than the systems we explored in the main text. This appendix discusses how key management was handled in Java 1.1; it uses classes that are still present (but deprecated) in Java 2. Appendix D This appendix details how the security manager operated in Java 1.1 (in the absence of an access controller) and shows how you can write an application that uses the 1.1 security model. Although most of the techniques in this appendix have been superseded in Java 2, there are exceptional cases in Java 2 when you might want to follow the tips given in this appendix. Appendix E In the text, we discuss how to implement standard security providers. JCE security providers require some additional steps that are outlined in this appendix. Appendix F This appendix is a simple reference guide to the classes discussed in this book. What's New in This Edition The second edition of this book provides new chapters on JSSE and JAAS, which have only recently been released. It provides updated information on JCE version 1.2.1, including modified code examples. The remainder of the text has been reorganized, including a new chapter that presents an overview of the default sandbox and how it is administered. Information and examples are now arranged by topic rather than by package: the Diffie−Hellman key exchange algorithm, for instance, is presented in the chapters on key management rather than appearing in a chapter on JCE. We treat the core Java security packages and the three optional security packages as an integrated API (which is how it is scheduled to be packaged in the next release of Java). How to Contact Us We have tested and verified the information in this book to the best of our ability, but you may find that features have changed (or even that we have made mistakes!). Please let us know about any errors you find, as well as your suggestions for future editions, by writing to: O'Reilly & Associates, Inc. Preface 5

📄 Page 10

101 Morris Street Sebastopol, CA 95472 (800) 998−9938 (in the United States or Canada) (707) 829−0515 (international/local) (707) 829−0104 (fax) We have a web page for this book, where we list errata, examples, or any additional information. You can access this page at: http://www.oreilly.com/catalog/javasec2/ To comment or ask technical questions about this book, send email to: bookquestions@oreilly.com For more information about our books, conferences, software, Resource Centers, and the O'Reilly Network, see our web site at: http://www.oreilly.com/ Acknowledgments I am grateful to the many people who have helped me with this book along the way; this book is as much a reflection of their support as anything else. I offer my heartfelt thanks to Mike Loukides and Deb Cameron for stewarding me through the editorial process. Various drafts of this book were foisted upon my colleagues Mark Bordas, Charles Francois, David Plotkin, Nick Jacobs, and Henry Wong; I am indebted to each of them for their feedback and support, and to Lynne Doherty for all her support. In addition, I was extremely fortunate to receive technical assistance from a highly talented group of individuals: to Jim Farley, Li Gong, Jon Meyer, Michael Norman, and especially to David Hopwood, I offer my deepest thanks for all your input. Roland Schemers expertly handled my last−minute barrage of questions with patience and insight. The second edition benefited greatly from the input of Eric Brower, Jonathan Knudsen, and John Zukowski. The staff at O'Reilly & Associates was enormously helpful in producing this book, including Colleen Gorman, the Production Editor; Robert Romano, who created the figures; Seth Maislin and Ellen Troutman−Zaig, who wrote the index; Hanna Dyer, the cover designer; David Futato, the interior designer; Mike Sierra for Tools support; and Linley Dolby for quality control. Finally, I must offer my thanks to James for all his patience and support and for putting up with my continual state of distraction during phases of this process. Feedback for the Author I welcome any comments on the text you might have; despite the contributions of the people I've listed, any errors or omissions in the text are my responsibility. Please send notice of these errors or any other feedback to scott.oaks@sun.com. 6 Preface

📄 Page 11

Chapter 1. Java Application Security When Java was first released by Sun Microsystems, it attracted the attention of programmers throughout the world. These developers were attracted to Java for different reasons: some were drawn to Java because of its cross−platform capabilities, some because of its ease of programming (especially compared to object−oriented languages like C++), some because of its robustness and memory management, some because of Java's security, and some for still other reasons. Just as different developers came to Java with different expectations, so too did they bring different expectations as to what was meant by the ubiquitous phrase "Java is secure." Security means different things to different people, and many developers who had certain expectations about the word "security" were surprised to find that their expectations were not necessarily shared by the designers of Java. This book discusses the features of Java that make it secure. In this book, we'll discuss why Java is said to be secure, what that security means (and doesn't mean), and −− most importantly −− how to use the security features of the Java platform within your own programs. This last point is actually the focus of this book: while some of Java's security features are automatically a part of all Java programs, many of them are not. In this book, we'll learn about all those features and how to utilize them in our own Java applications. 1.1 What Is Security? The first thing we must do is to discuss just what Java's security goals are. The term "security" is vague unless it is discussed in some context; different expectations of the term "security" might lead us to expect that Java programs would be: Safe from malevolent programs Programs should not be allowed to harm a user's computing environment, such as Trojan horses and harmful programs that replicate, like computer viruses. Non−intrusive Programs should be prevented from discovering private information on the host computer or the host computer's network. Authenticated The identity of parties involved in the program −− both the author and the user of the program −− should be verified. Encrypted Data that the program sends and receives −− over the network or through a persistent store such as a filesystem or database −− should be encrypted. Audited Potentially sensitive operations should always be logged. Well−defined A well−defined security specification should be followed. Verified Rules of operation should be set and verified.

📄 Page 12

Well−behaved Programs should be prevented from consuming too many system resources: too much CPU time, too much memory, and so on. C2 or B1 certified Programs should have certification from the U.S. government that certain security procedures are followed. In fact, while all of these features could be part of a secure system, only the first two were within the province of Java's 1.0 default security model. Other items in the list have been introduced in later versions of Java: authentication was added in 1.1, encryption is available as an extension to the Java 2 platform, and auditing can be added to any Java program by providing an auditing security manager. Still others of these items will be added in the future. But the basic premise remains that Java security was originally and fundamentally designed to protect the information on a computer from being accessed or modified (including a modification that would introduce a virus) while still allowing the Java program to run on that computer. The point driving this notion of security is the new distribution model for Java programs. One of the driving forces behind Java, of course, is its ability to download programs over a network and run those programs on another machine. This is something most computer users do today within the context of a Java−enabled browser, although the idea behind portable code like this is beginning to seep into other applications, such as those based on Jini technology. Coupled with the widespread growth of Internet use −− and the public−access nature of the Internet −− Java's ability to bring programs to a user on an as−needed, just−in−time basis has been a strong reason for its rapid deployment and acceptance. The nature of the Internet created a new and largely unprecedented requirement for programs to be free of viruses and Trojan horses. Computer users had always been used to purchasing shrink−wrapped software. Many soon began downloading software via FTP or other means and then running that software on their machines. But widespread downloading also led to a pervasive problem of malevolent attributes both in free and (ironically) in commercial software, a problem which continues unabated. The introduction of Java into this equation had the potential to multiply this problem by orders of magnitude, as computer users now download programs automatically and frequently. For Java to succeed, it needed to circumvent the virus/Trojan horse problems that plagued other models of software distribution. Hence, the early work on Java focused on just that issue: Java programs are considered safe because they cannot install, run, or propagate viruses and because the program itself cannot perform any action that is harmful to the user's computing environment. And in this context, safety means security. This is not to say that the other issues in the above list are not important −− each has its place and its importance (in fact, we'll spend a great deal of time in this book on the third and fourth topics in that list). But the issues of protecting information and preventing viruses were considered most important; hence, features to provide that level of security were the first to be adopted. Like all parts of Java, its security model is evolving (and has evolved through its various releases); many of the notions about security in our list will eventually make their way into Java. One of the primary goals of this book, then, is to explain Java's security model and its evolution with each subsequent release. In the final analysis, whether or not Java is secure is a subjective judgment that individual users will have to make based on their own requirements. If all you want from Java is freedom from viruses, any release of Java should meet your needs. If you need to introduce authentication or encryption into your program, you'll need to use a 1.1 or later release of Java. If you have a requirement that all operations be audited, you'll need to build that auditing into your applications. If you really need conformance with a U.S. government−approved definition of security, Java is not the platform for you. We take a very pragmatic view of security in this book: the issue is not whether a system that lacks a particular feature qualifies as "secure" according to someone's definition of security. The issue is whether Java possesses the features that meet your 8 Chapter 1. Java Application Security

📄 Page 13

needs. 1.2 Software Used in This Book The information in this book is based on the Java 2 Standard Edition, version 1.3 (or 1.3, for short). There are slight differences between how Java security operates in 1.2 (that is, the Java 2 Standard Edition, version 1.2) and 1.3. When we refer to a specific release, we'll use its number; otherwise, we'll say Java 2 to refer to either platform. In addition, there are great differences in how Java security operates between the Java 1.1 and the Java 2 platform. While we concentrate on Java 1.3, the end of each chapter contains a section that elucidates the differences between Java 1.3 and previous releases of Java. Some of the very different topics of Java 1.1 are presented in the appendices of this book; it is not generally recommended that you use the facilities and APIs discussed there since they are not compatible with the Java 2 platform. We present information in this book from three standard Java extensions: the Java Cryptography Extension (JCE) version 1.2.1, the Java Secure Sockets Extension (JSSE) version 1.0.2, and the Java Authentication and Authorization Service (JAAS) version 1.0. Each of these contributes certain technologies to the Java security story. These extensions require 1.3. Information about the extensions is presented thoughout the book as it makes sense. The JSSE API defines a set of classes that are used to perform SSL operations, and these are discussed in a separate chapter. The JSSE API also defines a set of classes that are used for key management; these are discussed along with the classes in the core API that handle key management. So even though these three packages are standard extensions, we recommend that you install them now along with the SDK so that you can become familiar with their features when they arise. In version 1.4, all these extensions are scheduled to be included in the core SDK, which is another reason why it helps to think of them as an integrated unit. In the next few pages, we'll discuss how to obtain and install the platform and extensions. Configuring the extensions may require some steps that you don't understand right now because they have various security options that apply to them. However, we recommend that you just follow the instructions for now and install the extensions. The extensions use Java's standard security framework, and as we discuss each aspect of the framework, we detail how the extensions relate to that aspect. Thus, while the core features of each extension is discussed in its own chapter, information about the extensions appears throughout the book. 1.2.1 The Java 2 Platform The core Java 2 platform supplies the basic facilities of Java security: A configurable security policy that lets you prevent Java programs from reading your files, making network connections to other hosts, accessing your printer without permission, and so on. This policy is based on Java's access controller, which in turn depends upon Java's class loaders, security manager, and language protections. • The ability to generate message digests if you want a simple (but not secure) way to determine if data your program reads has been altered. • The ability to generate digital signatures if you want to detect if data your program reads has been altered (or if you want to send data and enable the recipient of that data to detect if the data was altered in transit). • A key management system to manage the keys necessary for digital signatures.• An extensible infrastructure to support all of this.• Chapter 1. Java Application Security 9

📄 Page 14

Java 2 version 1.3 can be obtained for Solaris, Linux, and Windows systems from http://java.sun.com/j2se/1.3/. If you need Java for other platforms, check with your platform vendor or check http://java.sun.com/cgi−bin/java−ports.cgi. The Java 2 platform contains two flavors: the Software Development Kit (SDK, also known historically as the JDK) and the Java Runtime Environment (JRE). Administration of the security model applies to both the JRE and SDK, but to use the security APIs that we discuss, you'll need the SDK (which includes the JRE). Throughout this book, we'll use the environment variable $JDKHOME to refer to the directory in which the Java 2 SDK was installed and the $JREHOME variable to refer to the directory in which the Java 2 JRE was installed. If you installed the SDK into C:\files\jdk1.3 then $JDKHOME would be C:\files\jdk1.3 and $JREHOME would be C:\files\jdk1.3\jre. Installed or Bundled Extensions? When you work with the extensions that we use in this book, you have the option of treating them as installed or bundled extensions. Installed extensions are much easier to work with: they require no special configuration once they are installed. However, they must be installed into special directories within $JREHOME, and they may require files in $JREHOME to be modified. Depending on your setup, this may require special operating system privileges. A bundled extension requires no special installation privileges, but it does require you to set up things within your environment: you must modify your classpath, and you must set up special policy files. In addition, some of this configuration must be done programatically, so this option will not work for third−party applications. We assume in our examples that you've set up the extensions as installed extensions. 1.2.2 The Java Cryptography Extension JCE leverages the Java 2 core platform's security architecture to provide a variety of cryptographic operations: Encryption (Ciphers)• Secure Key Exchange• Secure Message Digests• An alternate key management system• JCE can be downloaded from http://java.sun.com/products/jce/. Version 1.2.1 is an important version because it takes advantage of a change in the policy of the United States regarding export controls of cryptographic engines. Prior to early 2000, the United States government considered cryptographic engines to be a munition and severely restricted the export of such technology. After this policy was changed in early 2000, JCE 1.2.1 was modified to meet the new standards. As a result, although it performs strong encryption, JCE 1.2.1 can be exported from the United States. JCE consists of some documentation and a lib directory that contains four jar files: US_export_policy.jar, jce1_2_1.jar, local_policy.jar, and sunjce_provider.jar. Like most extensions, you can install JCE as a bundled or unbundled extension. To use JCE as an installed extension, you must: Copy the four jar files to $JREHOME/lib/ext• Add the following line to $JREHOME/lib/security/java.security:• 10 Chapter 1. Java Application Security

📄 Page 15

security.provider.3=com.sun.crypto.provider.SunJCE This line should immediately follow the line that reads: security.provider.2=com.sun.rsajca.Provider To use JCE as an unbundled extension, you must: Add the four jar files to your classpath.• Add some configuration information to $HOME/.java.policy. The information to be added depends on where you have placed the jar files; if you've put JCE into /files/jce1.2.1 then the appropriate lines are: grant codebase "file:///files/jce1.2.1/lib/US_export_policy.jar" { permission java.security.AllPermission; }; grant codebase "file:///files/jce1.2.1/lib/jce1_2_1.jar" { permission java.security.AllPermission; }; grant codebase "file:///files/jce1.2.1/lib/local_policy.jar" { permission java.security.AllPermission; }; grant codebase "file:///files/jce1.2.1/lib/sunjce_provider.jar" { permission java.security.AllPermission; }; You must substitute the appropriate path for /files/jce1.2.1. Note that this is a URL; you use forward slashes no matter what your platform. On Microsoft Windows, the beginning of the appropriate URL is file:/C:/files/jce1.2.1. • In every program that you run, you must insert the following line: Security.addProvider(new com.sun.crypto.provider.SunJCE( )); • More details about how this works can be found in later chapters. Chapter 8, discusses the addition to the java.security file and its programmatic alternative, and the .java.policy file is discussed in Chapter 2. 1.2.3 The Java Secure Sockets Extension JSSE provides Secure Sockets Layer (SSL) encryption facilities. If you need to communicate with an SSL server or SSL client, you can use the APIs in this extension. If you are writing both a client and server and want to do encryption, you can use this extension or you can use the cipher facilities of JCE. JSSE can be downloaded from http://java.sun.com/products/jsse/. Version 1.0.2 takes advantage of the relaxed export restrictions of the U.S. and is exportable. Unlike JCE, however, there are still two different versions of JSSE: one for domestic use (use within the United States and Canada) and one for global use. The difference between these two versions is that the domestic version allows you to substitute new implementations of the SSL algorithms. Such substitution is still prohibited by export rules, so the global version does not allow it. However, both versions provide exactly the same API and the same key strength for their encryption. JSSE consists of documentation and a lib directory containing three jar files: jcert.jar, jnet.jar, and jsse.jar. To use JSSE as an installed extension, you must: Copy the three jar files to $JREHOME/lib/ext.• Add the following line to $JREHOME/lib/security/java.security: security.provider.4=com.sun.net.ssl.internal.ssl.Provider • Chapter 1. Java Application Security 11

📄 Page 16

This line should immediately follow the line you inserted for JCE. To use JSSE as an unbundled extension, you must: Add the three jar files to your classpath.• In every program that you run, you must insert the following line: Security.addProvider(new com.sun.net.ssl.internal.ssl.Provider( )); • 1.2.4 The Java Authentication and Authorization Service JAAS provides for user authentication within the Java platform. It performs a unique function in the Java platform. All of the core facilities of Java's security design are intended to protect end users from the influences of developers: end users give permissions to developers to access resources on the end user's machine. JAAS, on the other hand, allows developers to grant (or deny) access to their programs based on the authentication credentials provided by the user. JAAS can be downloaded from http://java.sun.com/products/jaas/. It comes in two parts: a Java library which defines the interface to the service (the JAAS proper), and platform−specific modules to perform the authorization (the JAAS modules). Sample modules are available to perform authentication based on JNDI directory services, Windows NT login services, and Solaris login services. JAAS itself contains documentation and a lib directory with a single jar file (jaas.jar). The jar file should either be installed into $JREHOME/lib/ext, or the user must add it to her classpath. The lib directory of the JAAS modules contains an additional jar file (jaasmod.jar) that must be handled similarly. It also contains platform−specific shared libraries. On Solaris systems, these libraries must be installed into $JREHOME/lib/sparc. If that is not possible, the libraries can be placed into any directory (e.g., /files/jaasmod1_0/lib) and that directory can be added to the user's LD_LIBRARY_PATH. On Microsoft Windows systems, these libraries are named nt.dll, nt.lib, and nt.exp and they must be installed into $JREHOME\bin. If that is not possible, then you must set the java.library.path property on the command line. For instance, if the libraries are in \files\jaasmod1_0\lib, you would specify the following property on the command line: −Djava.library.path=\files\jaasmod1_0\lib No modification to the java.security file is required for JAAS. 1.2.5 More About Export Controls The U.S. is not the only government that regulates the use of encryption, and encryption software can face import restrictions as well as export restrictions. In France, for example, it is illegal to import many encryption packages without a license. Other countries have regulations for cryptography, but in most cases they are less onerous than those of the United States. However, it is always wise to check your local policies to be sure (see Appendix B, for resources to find more information about these limitations). Even though the U.S. has relaxed its export rules, some restrictions still apply. You may not export either JCE or JSSE (and, hence, any programs that use them) to the following countries: Afghanistan, Cuba, Iran, Iraq, Libya, North Korea, Serbia/Montenegro (Yugoslavia), Sudan, Syria and parties listed on the Denied and Restricted Parties List (available at http://bxa.fedworld.gov/prohib.html). Additionally, it is Sun company policy not to ship products to Burma. 12 Chapter 1. Java Application Security

📄 Page 17

The encryption extensions, like many aspects of the Java platform, allow for third−party implementations; just like you can buy a third−party JDBC driver, you can buy third−party implementations of JCE. However, many of the popular algorithms that are used by the extensions are patented algorithms, which also restricts their use. RSA Data Security, Inc. holds a patent in the U.S. on several algorithms involving RSA encryption and digital signatures; Ascom System AG in Switzerland holds both U.S. and European patents on the IDEA method of performing encryption. If you live in a country where these patents apply, you can't use these underlying algorithms without paying a licensing fee to the patent holder. In particular, this means that many of the third−party security providers and third−party implementations of JCE cannot be used within the United States because of patents held by RSA (although some of them have reached a licensing agreement with RSA Data Security, Inc. −− again, it is best to check with the provider to see what restrictions might apply). Sun has an agreement with RSA Data Security to redistribute its implementation of the RSA algorithms. Encryption and Weaponry The whole question of importing and exporting encryption technology occurs because it is often classified as a munition. While this position is sometimes questioned, it comes from a long tradition in computer science. During WWII, the Allies waged a successful and pivotal campaign in the Atlantic against the Axis navy. The success of this campaign was greatly due to the work of Alan Turing, who with his colleagues broke the German encryption algorithm known as Enigma. Turing was also one of the founding fathers of modern computer science, much of which was based on the work he developed in service to his country during the war. Ironically, the reward that Turing reaped for his efforts was that some years after the war, he was arrested and forced to undergo harmful chemical treatments because he was gay. There's an odd parallel here: many of the harsh restrictions that are sometimes placed on encryption technology make no more sense in a world with a global Internet than did England's persecution of Alan Turing in the 1950s. Perhaps the relaxation of export restrictions is a good sign in general. Note that import and export restrictions apply only to the encryption technology contained within JCE and JSSE. Although the core Java APIs perform important cryptographic operations, those operations are not considered to be munition−grade operations. 1.2.6 Other Software Versions Though Java−enabled browsers are very popular, we do not discuss most of the popular ones. This is because their security implementations are very different from the official Java security model. Both Netscape and Microsoft, for example, introduced new (and proprietary) APIs to allow for security extensions. Both companies also developed their own (again proprietary) mechanism to sign applets. The better way to run Java applets from within a browser is to use the Java Plug−in, which comes standard with every release of the Java 2 platform; when you install Java 2, you install the Java Plug−in. In Netscape 6 and later releases, the Java Plug−in is the only way to run Java applets; there is no Java virtual machine built into Netscape 6. The Plug−in is also compatible with Internet Explorer 4.x and higher, as well as Netscape 4.x versions. The security model of the Java Plug−in is exactly the same as that of the Java platform that we describe within this book. Where the security model of older browsers is different, we point that out, and we provide directions to the vendor's web sites that give information on their non−standard systems. Chapter 1. Java Application Security 13

📄 Page 18

1.3 The Java Sandbox When Java security is discussed, the discussion typically centers around Java's applet−based security model −− the security model that is embodied by Java−enabled browsers. It's considered "applet−based" because in early versions of Java, it applied only to applets that run within a Java−enabled browser. In the Java 2 platform, however, this security model can apply to any Java application as well as to the Java Plug−in, which allows newer browsers to run Java 2 applets. The Java 2 security model is also configurable by an end user or system administrator so that it can be made less restrictive than earlier implementations of that model. This security model centers around the idea of a sandbox. The idea is when you allow a program to be hosted on your computer, you want to provide an environment where the program can play (i.e., run), but you want to confine the program's play area in certain bounds. You may decide to give the program certain toys to play with (i.e., you may decide to let it have access to certain system resources), but in general, make sure that the program is confined to its sandbox. This analogy works better when you consider it from the view of a close relative rather than from the view of a parent. If you're a parent, you probably consider the purpose of a sandbox to be to provide a safe environment for your child to play in. When my niece Rachel visits me, however, I consider the purpose of a sandbox not (only) to be to protect her, but also to protect my grandmother's china from her. I love my niece, but I can't give her leave to run through my house; I enjoy running the latest cool applet on the Internet, but I can't give it leave to run through my filesystem. The Java sandbox is responsible for protecting a number of resources, and it does so at a number of levels. Consider the resources of a typical machine as shown in Figure 1−1. The user's machine has access to many things: Internally, it has access to its local memory (the computer's RAM).• Externally, it has access to its filesystem and to other machines on the local network.• For running applets, it also has access to a web server, which may be on its local (private) net or may be on the Internet. • Data flows through this entire model, from the user's machine through the network and (possibly) to disk. • Figure 1−1. A machine has access to many resources Each of these resources needs to be protected, and those protections form the basis of Java's security model. We can imagine a number of different−sized sandboxes in which a Java program might run: 14 Chapter 1. Java Application Security

📄 Page 19

A sandbox in which the program has access to the CPU, the screen, keyboard, and mouse, and to its own memory. This is the minimal sandbox −− it contains just enough resources for a program to run. • A sandbox in which the program has access to the CPU and its own memory as well as access to the web server from which it was loaded. This is often thought of as the default state for the sandbox. • A sandbox in which the program has access to the CPU, its memory, its web server, and to a set of program−specific resources (local files, local machines, etc.). A word−processing program, for example, might have access to the docs directory on the local filesystem, but not to any other files. • An open sandbox, in which the program has access to whatever resources the host machine normally has access to. • The sandbox, then, is not a one−size−fits−all model. Expanding the boundaries of the sandbox is always based on the notion of trust: when my one−year−old niece comes to visit, there's very little in the sandbox for her to play with, but when my six−year−old godchild comes to visit, I trust that I might give her more things to play with. In the hands of some visitors, a toy with small removable parts would be dangerous, but when I trust the recipient, it's perfectly reasonable to include that item in the sandbox. And so it is with Java programs: in some cases, I might trust them to access my filesystem; in other cases, I might trust them to access only part of my filesystem; and in still other cases, I might not trust them to access my filesystem at all. 1.3.1 Applets, Applications, and Programs In early versions of Java, only applets were run within a sandbox. In the Java 2 platform, all programs have the potential to run in a sandbox. Applets that run through the Java Plug−in or the appletviewer will always run in a sandbox, and applications that are run via the command line (or by clicking an icon on the desktop) may optionally be set up to use a sandbox. Applications also have the option of programatically installing new versions of the sandbox. Hence, in the Java 2 platform there is little distinction between the security level of an applet and an application. There are programmatic differences, of course, but both are subject to the same security model, and the security model for both is administered and programmed in the same way. There is one significant difference, however: applets always run with Java's security model (even if that model has been administered such that the applet is allowed to do anything it wants to), and an application will only run under the security model if it is told to do so. This is typically done by the end user by specifying a command−line parameter; it may be done by the program developer who specifies that parameter in a script that starts the application, and it may be done by the developer who inserts code into his program. Any program, including an applet, can change the behavior of the sandbox under certain circumstances. However, most of them will use Java's default sandbox. The default sandbox, as we'll see in Chapter 2, is very flexible; it allows the user who runs the program to determine exactly how the sandbox will operate. This moves the definition of the security policy to the end user or system administrator of the machine running the program. 1.3.2 Anatomy of a Java Program The anatomy of a typical Java program is shown in Figure 1−2. Each of the features of the Java platform that appears in a rectangle plays a role in the development of the Java security model. In particular, the elements of the Java security policy are defined by: The bytecode verifier The bytecode verifier ensures that Java class files follow the rules of the Java language. In terms of resources, the bytecode verifier helps enforce memory protections for all Java programs. As the figure implies, not all classes are subject to bytecode verification. Chapter 1. Java Application Security 15

📄 Page 20

The class loader One or more class loaders load all Java classes. Programatically, the class loader can set permissions for each class it loads. The access controller The access controller allows (or prevents) most access from the core API to the operating system, based upon policies set by the end user or system administrator. The security manager The security manager is the primary interface between the core API and the operating system; it has the ultimate responsibility for allowing or preventing access to all system resources. However, it exists mostly for historical reasons; it defers its actions to the access controller. The security package The security package (that is, classes in the java.security package as well as those in the security extensions) allows you to add security features to your own application as well as providing the basis by which Java classes may be signed. Although it is only a small box in this diagram, the security package is a complex API and discussion of it is broken into several chapters of this book. This includes discussions of: The security provider interface −− the means by which different security implementations may be plugged into the security package ◊ Message digests◊ Keys and certificates◊ Digital signatures◊ Encryption (through JCE and JSSE)◊ Authentication (through JAAS)◊ The key database The key database is a set of keys used by the security infrastructure to create or verify digital signatures. In the Java architecture, it is part of the security package, though it may be manifested as an external file or database. Figure 1−2. Anatomy of a Java application 16 Chapter 1. Java Application Security