`Inside Java’ 2
`Platform Security
`Architecture, API Design,
`
`and eapreneentaten ... from the Source #4
`
`
`
`Page 1 of 275
`
`GOOGLEEXHIBIT 1016
`
`Page 1 of 275
`
`GOOGLE EXHIBIT 1016
`
`

`

`Og JAVA
` NDISWUONPldZ.PAPL
`apIsuy AVA
`
`qeoS=ge
`
`Page 2 of 275
`
`Page 2 of 275
`
`

`

`
`
`AeteeAnealtenenetaentneteenessa
`
`
`
`
`~
`‘
`
`NORTH CAROLINA STATE UNIVERSITY Li
`
`
`
` AO$01773199
`
`
`
`
`
`
`
`
`
`
`
`
`il
`
`
`
`Page 3 of 275
`
`Page 3 of 275
`
`

`

`
`
`Inside Java™ 2
`Platform Security
`
`This book is due on the date indicated
`elow and is subject to an overdue
`fine as posted at the circulation desk.
`EXCEPTION: Date due will be
`earlierif thisitemis RECALLED.
`
`
`
` FEB 0,89
`OCHUEi009
`
`KIN 2 Set"
`HEF
`aware 2 6 fhe
`Byars & NOC
`=
`:
`ye4
`Ts
`
`SEP 2.5 2002
`
`200M/06-99-991212
`
`Page 4 of 275
`
`Page 4 of 275
`
`

`

`
`
`The Java™ Series
`Lisa Friendly, Series Editor
`Tim Lindholm, Technical Editor
`Please see our website (http://www.awl.com /cseng/javaseries) for more information onthesetitles.
`
`Jonni Kanerva, The Java™ FAQ
`ISBN 0-201-63456-2
`
`Doug Lea, Concurrent Programming in Java™:
`Design Principles and Patterns
`ISBN 0-201-69581-2
`
`Sheng Liang, The Java™ Native Interface:
`Programmer's Guide and Specification
`ISBN 0-201-32577-2
`
`Tim Lindholm and Frank Yellin, The Java™ Virtual
`Machine Specification, Second Edition
`ISBN 0-201-43294-3
`
`Henry Sowizral, Kevin Rushforth, and Michael
`Deering, The Java™ 3D API Specification
`ISBN 0-201-32576-4
`
`Kathy Walrath and Mary Campione, The JFC Swing
`Tutorial: A Guide to Constructing GUIs
`ISBN 0-201-43321-4
`
`Seth White, MaydeneFisher, Rick Cattell, Graham
`Hamilton, and Mark Hapner, JDBC™ API Tutorial
`and Reference, Second Edition: Universal Data
`Access for the Java™ 2 Platform
`ISBN 0-201-43328-1
`
`Ken Arnold and James Gosling, The Java™
`Programming Language, Second Edition
`ISBN 0-201-31006-6
`
`Mary Campione and Kathy Walrath, The Java™
`Tutorial, Second Edition: Object-Oriented
`Programming for the Internet (Book/CD)
`ISBN 0-201-31007-4
`
`Mary Campione, Kathy Walrath, Alison Huml, and
`the Tutorial Team, The Java™ Tutorial Continued:
`The Rest of the JDK™ (Book/CD)
`ISBN 0-201-48558-3
`
`Patrick Chan, The Java™ Developers Almanac 1999
`ISBN 0-201-43298-6
`
`Patrick Chan and Rosanna Lee, The Java™ Class
`Libraries, Second Edition, Volume 2: java.applet,
`java.awt, java. beans
`ISBN 0-201-31003-1
`
`Patrick Chan, Rosanna Lee, and Doug Kramer,
`The Java™ Class Libraries, Second Edition,
`Volume I: java.io, java.lang, java.math,
`java.net, java.text, java.util
`ISBN 0-201-31002-3
`
`Patrick Chan, Rosanna Lee, and Doug Kramer,
`The Java™ Class Libraries, Second Edition,
`Volume 1: Supplementfor the Java™ 2 Platform,
`Standard Edition, v1.2
`ISBN 0-201-48552-4
`
`Li Gong, Inside the Java™ 2 Platform Security
`Architecture: Cryptography, APIs, and
`Implementation
`ISBN 0-201-3 1000-7
`
`James Gosling, Bill Joy, and Guy Steele,
`The Java™ Language Specification
`ISBN 0-201-6345 1-1
`
`James Gosling, Frank Yellin, and The Java Team,
`The Java™ Application Programming Interface,
`Volume 1: Core Packages
`ISBN 0-201-63453-8
`
`James Gosling, Frank Yellin, and The Java Team,
`The Java™ Application Programming Interface,
`Volume 2: Window Toolkit and Applets
`ISBN 0-201-63459-7
`
`Page 5 of 275
`
`Page 5 of 275
`
`

`

`
`
`
`
`
`
`Inside Java™ 2
`Platform Security
`Architecture, API Design,
`and Implementation
`
`Li Gong
`
`A
`vv
`ADDISON-WESLEY
`
`An imprint of Addison Wesley Longman,Inc.
`Reading, Massachusetts + Harlow, England * Menlo Park, California
`Berkeley, California * Don Mills, Ontario « Sydney
`Bonn * Amsterdam * Tokyo * Mexico City
`
`Page 6 of 275
`
`Page 6 of 275
`
`

`

`
`
`Copyright © 1999 Sun Microsystems, Inc., 901 San Antonio Road, Palo Alto, CA, 94303, USA.
`All rights reserved.
`
`Duke™ designed by Joe Palrang.
`
`Sun Microsystems,Inc. has intellectual property rights relating to implementations of the technology
`described in this publication. In particular, and without limitation, these intellectual property rights
`may include one or more U.S. patents,
`foreign patents, or pending applications. Sun, Sun
`Microsystems, the Sun logo, and all Sun, Java, Jini, and Solaris based trademarks and logos are
`trademarks or registered trademarks of Sun Microsystems, Inc.,
`in the United States and other
`countries. UNIX is a registered trademark in the United States and other countries, exclusively licensed
`through X/Open Company,Ltd.
`
`THIS PUBLICATION IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER
`EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
`OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGE-
`MENT.
`
`THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHI-
`CAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN;
`THESE CHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THE PUBLICATION.
`SUN MICROSYSTEMS, INC., MAY MAKE IMPROVEMENTS AND/OR CHANGESIN ANY
`TECHNOLOGY, PRODUCT, OR PROGRAM DESCRIBED IN THIS PUBLICATION AT ANY
`TIME.
`
`The publisher offers discounts on this book when ordered in quantity for special sales. For more information,please
`contact: Corporate, Governmentand Special Sales; Addison Wesley Longman,Inc.; One Jacob Way; Reading, Massa-
`chusetts 01867.
`
`ISBN: 0-201-31000-7
`12345678 9-CRS-0302010099
`First Printing, June 1999
`
` LSRSEEDSERSETET
`
`RACECoRR
`safeahReactsae
`STURN
`
`Page 7 of 275
`
`Page 7 of 275
`
`

`

`Contents
`
`
`Preface ...........0.0000, cece eee Chee e erence reece seve e XE
`How This Book Is Organized... 0.2.0... ccc ccc eece cece... xii
`Acknowledgments... 00... ce eee ece cece, xiii
`1 Computer and Network Security Fundamentals..............1
`L.1 Cryptography versus Computer Security 6.022000. eee eee, 2
`1.2 Threats and Protection... 6... e ee ceee ee cec eee. 3
`13° Perimeter Defense... 0.2... eee eee ece cece. 4
`13.1 Firewalls 200. ceee cece, 6
`1.3.2 Inadequacies of Perimeter Defense Alone........................ 6
`1.4 Access Control and Security Models .... 2.02... eee cece. 7
`1.4.1 MAC and DAC Models... 0.0.6 cece cece. 7
`1.4.2 Access to Data and Information.............................., 8
`1.4.3 Static versus Dynamic Models .................an 9
`1.4.4 Considerations Concerning the Use of Security Models............ 10
`1.5 Using Cryptography«0... 11
`1.5.1 One-Way Hash Functions... 0.2.0... 0. ec ec ccc eee cece, 12
`1.5.2 Symmetric Ciphers «0.2.00... eee cece, 13
`1.5.3 Asymmetric Ciphers .. 2.0.0...e cece! 14
`1.6 Authentication 0...ee, 15
`1.7 Mobile Code 0.00.0... eee ec cccec ee. 17
`1.8 Where Does Java Security FitIn.. 2... ee, 18
`2 Basic Security for the Java Language...............00. wee 21
`2.1 The Java Language and Platform ©... 2.0.00. ee cece cece cee. 22
`2.2 Basic Security Architecture... 0... eee ece eee. 23
`2.3 Bytecode Verification and Type Safety... 2. eee. 25
`2.4 Signed Applets 0.2.0... eee cece ccc cee 27
`2.5 A Brief History of Security Bugs and Fixes... .2..000...0...0........ 28
`
`
`
`Page 8 of 275
`
`Page 8 of 275
`
`

`

`vi
`
`CONTENTS
`
`3 JDK 1.2 Security Architecture........... cece ee eeees wee. 33
`3.1 From the Beginning ........ 0.0... ccc cc eee eee e eens 33
`3.2 Why a New Security Architecture... 0... cece eee eee 34
`3.2.1 Sandbox Restrictions on Applets Too Limiting................6. 34
`3.2.2 Insufficient Separation Between Policy and Enforcement.......... 35
`3.2.3 Security Checks Not Easily Extensible ..................20005. 35
`3.2.4 Locally Installed Applets Too Easily Trusted..............+.00 36
`3.2.5 Internal Security Mechanisms Fragile ...............--2 00000. 36
`3.2.6 Summary..... 2.2.0... cc ee eee eee eens 37
`3.3 java.security.GeneralSecurityException .......... cece ee eee 37
`3.4 Security Policy... . 0... cece cc cee cee cee teen teen e eens 38
`3.5 COUCSOUPCE 2... Le ccc cece eee ee eee een eee te neeene 41
`3.5.1 Testing for Equality and Using Implication.................0005 43
`3.6 Permission Hierarchy .......... 0... ce eee eee 45
`3.6.1 java.security.Permission .......... 0... cece e ee ee eee 46
`3.6.2 Permission Sets...... 2.2.0. c ec cee ee eee eee eee ne ens 48
`3.6.3 java.security.UnresolvedPermission................0.. 50
`3.6.4 java.io. FilePermission.. 12... 2... ce eee eee eens 52
`3.6.5 java.net.SocketPermiSSiOn ........... eee cee eee ees 55
`3.6.6 java.security.BasicPermission .............. 0.0 cee eee 59
`3.6.7 java.util.PropertyPermisSSion .............. 20. cee ee eee 59
`3.6.8 java. lang.RuntimePermiSSiOn .........-.-. 2. eee ee eee 61
`3.6.9 java.awt .AWTPermiSSion........ 0. ee cee eee cee eae 62
`3.6.10 java.net.NetPermiSSion. ...... 00... cece ce eee eens 63
`3.6.11 java.lang.reflect.ReflectPermission .............06. 63
`3.6.12 java.io.SerializablePermission..................000. 64
`3.6.13 java.security.SecurityPermisSion...............0 00 64
`3.6.14 java.security.Al]PermiSSION ........... cee eee eee es 65
`3.6.15 Implications of Permission Implications ..................0005 66
`3.7 Assigning Permissions ........0 6. cece eee cee ee tenet e eer eees 66
`3.7.1 Positive versus Negative Permissions. ............0 00 cee vee eeee 68
`3.8 ProtectiOnDOMAiNn ....... cc eee eect ee eee eee eet een eee 69
`3.9 Securely Loading Classes... 0... cece cee cee ce eee teeter ees 71
`3.9.1 Class Loader Hierarchy ..........-.... 00. e eee eee eee eee 72
`3.9.2 java. lang.ClassLoader and Delegation ..................4. 74
`3.9.3 java.security.SecureClassLoader ......... eee eee eee
`719
`3.9.4 java.net.URLClassLoader........... 0... eee eee eee ees 80
`3.9.5 Classpaths . 02... ce cece etree eens 81
`3.10 java.lang.SecurityManager ............ cee eee eee eee ene 83
`3.10.1 Example Useof the Security Manager... 1.0.0.0... ccc eee ees 83
`3.10.2 Unchanged APIs in JDK 1.2 .......... 0.0.0 eee eee 84
`
`
`
`3.10.3 Deprecated Methods in JDK 1.2 2.0... ccc ccc ee cere 85
`
`Page 9 of 275
`
`Page 9 of 275
`
`

`

`vii
`
`,
`CONTENTS
`3.11 java.security.AccessController ..................00-00- 0. 90
`3.11.1 Interface Design of AccessController ..................... 91
`3.11.2 The Basic Access Control Algorithm .. 0.00.0... 0.0... cece eee 92
`3.11.3 Method Inheritance... 0... cece cece cee eee ee, 94
`3.11.4 Extending the Basic Algorithm with Privileged Operations... ..... 95
`3.11.5 Three Types of Privileged Actions.................-00-00..... 98
`3.11.6 The Context of Access Control...........00...00--.eeee ee 101
`3.11.7 The Full Access Control Algorithm ...............020-...... 102
`3.11.8 SecurityManager versus AccessController.............. 104
`3.11.9 A Mini-History of Privileged Operations ..............0..000. 105
`3.12 Summary and Lessons Learned... 0000.0... cece eccececcce eee... 106
`
`4 Deploying the Security Architecture...............0.. oe. 113
`4.1 Installing IDK 1.2.0.0... eeeee ce cccececccece. 113
`4.2 Policy Configuration....... 0.0.6.0. cece cece cee vececececce. 115
`4.2.1 Configuring System-Wide and User-Specific Policies............ 115
`4.2.2 Configuring Application-Specific Policies..................... 116
`4.2.3 Configuring an Alternative Policy Class Implementation ........ 117
`4.2.4 Default Policy File Format .......0000.000 0000. cceceee sees. 118
`4.2.5 Policy File Examples.....0...000.. 00 ec ceecccecece eee... 122
`4.2.6 Property Expansion in Policy Files... 0.0... cc cece cece eee 123
`4.3 Digital Certificates 0... cece cece ecece cee. 125
`4.4 Helpful Security Tools... 00.0... eee ccc cece cee eeee cee. 130
`4.4.1 Keystore Databases ©... 6... cecccceee. 130
`4.4.2 Keytool 0.0.0...c ec eeceeeee bev ceeeeees 133
`4.4.3 Policy Tool .......... 0c eee e cece eceeeeececccece, 139
`44.4 Jarsigner oo... cece cece cece ccc ee eee. 143
`4.4.5 Code Signing Example ........000.. 000. cece cceec cece ee... 148
`4.5 Managing Security Policies for Nonexperts 0.00... cece cece 150
`
`5 Customizing the Security Architecture. .... sesecceceseeeee 153
`5.1 Creating New Permission Types............00 0000 ccc ccc ceceeee eee 153
`5.2 Composite Permissions... 0.6... eee cece cc ccc eee ceeeeeeee. 155
`5.3 Customizing Security Policy... 0.0.0.0... 0.00 ccc cee c cece ececeee ee 156
`5.4 Migrating JDK 1.1-Based Security Managers .............0.......0., 158
`9.4.1 JDK 1.1 Security Manager Classes..............000.00000055. 158
`5.4.2 Accommodating JDK 1.1 Security Managers on JDK 1.2......... 160
`5.4.3 Modifying JDK 1.1 Security Managers for JDK 1.2.............. 163
`6 Object Security ............c..0cceecee ste eceeeeeenees 173
`6.1 Security Exceptions... 00... cce cece ccccceee ce. 173
`6.2 Fields and Methods... 20... ce cece cece cccecee cc. 174
`
`
`
`Page 10 of 275
`
`Page 10 of 275
`
`

`

`
`
`viii
`
`CONTENTS
`
`6.3 Static Fields .... 0.0... cee eee eee nee 176
`6.4 Private Object State and Object immutability .........0.....0.....0.0. 176
`6.5 Privileged Code .. 0... ee cece einer e ee eee 178
`6.6 Serialization ...... 0... cece eee eee eee eens 179
`6.7 Inner Classes... 2... cece cence nen e ences 181
`6.8 Native Methods ....... 0.0... eee eee ee eee eee e eens 182
`6.9 Signing Objects... 0... cece ee eee e rete neces 182
`6.10 Sealing Objects............ 0. cee ee eee ketene eee eee eens 185
`6.11 Guarding Objects... 0... cee cee cee tee teenies 186
`6.11.1 Examples of Using GuardedObject ........... 0... eee eee 188
`
`7 Programming Cryptography ......... cece tence ees eeees 191
`7.1 Design Principles .....ee ete 192
`7.2. Cryptographic Services and Service Providers ...............0000005 193
`7.2.1 Installing and Adding a Provider .-........ 0... cece eee ee eee 197
`7.3 Cryptography Classes... ec cece ete ete erence eee 199
`7.3.1 java.security.S@curity...... cece cece ee eee eee 199
`7.3.2 java.security.Provider........... 2.0.0... eee eee eee 200
`7.3.3 java.security.MessageDigeSt .......... cee eee eee 200
`7.34 jJava.security.Signature...... ieee ccc eee ees 201
`7.3.5 Algorithm Parameters... 0.0.0.0... ee cee cee eee eee 204
`7.3.6 java.security.Key and java.security.spec.KeySpec .... 207
`73.7 java.security.KeyFactory and java. security.cert.
`210
`CertificateFactory
`7.3.8 KeyPair and KeyPairGenerator........ ccc cece e cece e ences 212
`7.3.9 java.security.KeyStore..... ce eee ce ee eens 214
`Randomness and Seed Generators ...........0 0000002 c eee eee 215
`
`TA
`
`74.) java.security.SecureRandom ...................00-000- 216
`Code Examples... 0... ce ccc ce ee ete eee ene een eenes 217
`7.5.1 Example 1: Computing a Message Digest ................0000- 217
`7.5.2 Example 2: Generating a Public/Private Key Pair............... 218
`7.5.3 Example 3: Generating and Verifying Signatures ............... 219
`7.5.4 Example 4: Reading a File That Contains Certificates............ 221
`Standard Names... 0.2.0.0... cece ee ee ete eee eee 222
`
`75
`
`7.6
`
`7.6.1 Message Digest Algorithms ..............0 0.000000. cess eee 222
`7.6.2 Key and Parameter Algorithms. ......... 0... cece ec eee eee 222
`7.6.3 Digital Signature Algorithms .......... 0.0. c cece ee cee eens 223
`7.6.4 Random Number Generation Algorithms. ................2.-.. 223
`7.6.5 Certificate Types... 0... cee cece eee cee ener e nee 223
`7.6.6 Keystore TypeS. 1... cece cee eee eee eee cence 224
`Algorithm Specifications ... 0.2.0.0... ce ccc eee eee 224
`7.7.1 SHA-1 Message Digest Algorithm. ...............00.....2.05. 225
`
`V7
`
`
`
`
`
`Page 11 of 275
`
`Page 11 of 275
`
`

`

`CONTENTS
`
`ix
`
`7.7.2 MD2 Message Digest Algorithm. ...............0.-0.00-000. 225
`7.7.3 MDS Message Digest Algorithm. .............0..ccccccceecee 225
`7.7.4 Digital Signature Algorithm ........0000 000000 c cece ceeeee 225
`7.7.5 RSA-Based Signature Algorithms.............000000000-0005. 225
`7.7.6 DSA KeyPair Generation Algorithm............0.0.000ccceeee. 226
`7.7.7 RSA KeyPair Generation Algorithm................0.c0se0eee 227
`7.7.8 DSA Parameter Generation Algorithm .................0.0020. 227
`
`8 Future Directions .................. see e cece esecenees 229
`8.1 Security Management ..........00000 00 ccc cece ec eceuevceenes 229
`8.2 JDK Feature Enhancement .........00000 0. ccc ce cece cee eucucuenes 230
`8.3 Java Authentication and Authorization Service ..............0.0.008. 232
`8.3.1 Subjects and Principals .........00.0000 000 cece cece ccc ee eens 234
`8.3.2 Credentials... 2. ec cee ccc cee c een eeeeneees 234
`8.3.3 Pluggable and Stacked Authentication ...........0.0.0cccc cues 235
`8.3.4 Callbacks. 0.0... cece cece ence te cece ceeeceeeees 239
`8.3.5 Access Control... 0... ieee cece cece eee en eeneveeereees 239
`8.3.6 JAAS Implementation .........000000 0. cece cece ceceuceeee. 241
`8.4 Conclusion......PEE ee eee eee eee ene eee e tne e eens 242
`
`Index...... sence eee eee eee necnarcsnccsece sec ecee 251
`
`Bibliography ......... ccc ccs e eee ce eee ec ence cee e cee s 245
`
`
`
`Page 12 of 275
`
`Page 12 of 275
`
`

`

`
`Preface
`
`Give mea lever and a fulcrum, and I can move the globe.
`—Archimedes
`
`Since Java technology’s inception, and especially its public debutin the spring
`of 1995, strong and growinginterest has developed regarding the security of the
`Java. platform, as well as new security issues raised by the deployment of Java
`technology. This level of attention to security is a fairly new phenomenonin com-
`puting history. Most new computing technologies tend to ignore security consider-
`ations when they emerge initially, and most are never made more secure
`thereafter. Attempts made to do so typically are not very successful, as it is now
`well knownthatretrofitting security is usually very difficult, if not impossible, and
`often causes backward compatibility problems.
`Thusit is extremely fortunate that when Java technology burst on the Internet
`Scene, security was one of its primary design goals. Its initial security model,
`although very simplistic, served as a great starting place, an Archimedean ful-
`crum. The engineering talents and strong management team at JavaSoft are the
`lever; together they made Java’s extensive security architecture a reality.
`From a technology provider’s point of view, security on the Java platform
`focuses on two aspects. Thefirstis to provide the Java platform,primarily through
`the Java Development Kit, as a secure, platform on which to run Java-enabled
`applications in a secure fashion. The secondis to provide security tools and ser-
`vices implemented in the Java programming language that enable a wider range of
`security-sensitive applications, for example, in the enterprise world.
`I wrote this book with many purposes in mind. First, I wanted to equip the
`reader with a brief but clear understanding of the overall picture of systems and
`network security, especially in the context of the Internet environment within
`which Java technologyplaysa central role, and how various security technologies
`relate to each other.
`
`
`
`Page 13 of 275
`
`Page 13 of 275
`
`

`

`PREFACE
`
`Second, I wanted to provide a comprehensive description of the current secu-
`rity architecture on the Java platform. This includes language features, platform
`APIs, security policies, and their enforcement mechanisms. Whenever appropri-
`ate, I discuss not only howafeature functions, but also why it is designed in such
`a way and the alternative approaches that we—the Java security development
`team at Sun Microsystems—examined and rejected. When demonstrating the use
`of a class or its methods, I use real-world code examples whenever appropriate.
`Someof these examples are synthesized from the JDK 1.2 code sourcetree.
`Third, I soughtto tell the reader about security deployment issues, both how
`an individual or an enterprise manages security and how to customize, extend, and
`enrich the existing security architecture.
`Finally, I wanted to help developers avoid programmingerrors by discussing a
`number of common mistakes and by providingtips for safe programming that can
`be immediately applied to ongoing projects.
`
`How This Book Is Organized
`
`This book is organized as follows.
`
`Chapter 1. A general background on computer, network, and information
`security
`
`Chapter 2. A review of the original Java security model, the sandbox
`
`Chapter 3. An in-depth look at the new security architecture in JDK 1.2, which
`is policy-driven and capable of enforcing fine-grained access controls
`
`Chapter 4. An explanation of how to deploy and utilize the new security fea-
`tures in JDK 1.2, including security policy management, digital certificates,
`and various security tools
`
`Chapter 5. A demonstration of how to customize various aspects of the secu-
`rity architecture, including how to move legacy security code onto the JDK 1.
`2 platform
`
`Chapter 6. A review of techniques to make objects secure and tips for safe
`programming
`
`Chapter 7. An outline of the Java cryptography architecture along with usage
`examples
`
`Chapter 8. A look aheadto future directions for Java security
`
`
`
`Page 14 of 275
`
`Page 14 of 275
`
`

`

`PREFACE
`
`This bookis primarily for serious Java programmers and for security profes-
`sionals who wantto understand Java security issues both from a macro (architec-
`tural) point of view as well as from a micro (design and implementation)
`perspective. It is also suitable for nonexperts who are concerned about Internet
`security as a whole, as this book clears up a number of misconceptions around
`Java security,
`Throughoutthis book, I assumethat the readeris familiar with the fundamen-
`tals of the Java language. For those who wantto learn more about that language,
`the book by Arnold and Gosling [2] is a good source.
`This bookis not a complete API specification. For such details, please refer to
`JDK 1.2 documentation,
`
`Acknowledgments
`
`It is a cliche to say that writing a book is not possible without the help of many
`others, but it is true. I am very grateful to Dick Neiss, my manager at JavaSoft,
`who encouraged meto write the book and regularly checked on my progress. Lisa
`Friendly, the Addison-Wesley Java series editor, helped by guiding me through the
`writing process while maintaining a constant but “friendly” pressure. The team at
`Addison-Wesley was tremendously helpful. I’d like particularly to thank Mike
`Hendrickson, Katherine Kwack, Marina Lang, Laura Michaels, Marty Rabinow-
`itz, and Tracy Russ. They are always encouraging, keptfaith in me, and rescued
`me wheneverI encountered obstacles.
`This book is centered around JDK 1.2 security development, a project that
`lasted fully two years, during which many people inside and outside of Sun
`Microsystems contributed in one way or another to the design, implementation,
`testing, and documentation ofthe final product. I would like to acknowledge Dirk
`Balfanz, Bob Blakley, Josh Bloch, David Bowen, Gilad Bracha, David Brownell,
`Eric Chu, David Connelly, Mary Dageforde, Drew Dean, Satya Dodda, Michal
`Geva, Gadi Guy, Graham Hamilton, Mimi Hills, Larry Koved, Charlie Lai, Sheng
`Liang, Tim Lindholm,Jan Luehe, Gary McGraw, Marianne Mueller, Tony Nadalin,
`Don Neal, Jeff Nisewanger, Yu-Ching Peng, HemmaPrafullchandra, Benjamin
`Renaud, Roger Riggs, Jim Roskind, Nakul Saraiya, Roland Schemers, Bill
`Shannon, Tom van Vleck, Dan Wallach, and Frank Yellin. I also appreciate the
`technical guidance from James Gosling and Jim Mitchell, as well as management
`support from Dick Neiss, Jon Kannegaard, and Alan Baratz. I have had the pleasure
`of chairing the Java Security Advisory Council, and I thank the external members,
`Ed Felten, Peter Neumann, Jerome Saltzer, Fred Schneider, and Michael
`Schroederfor their participation and superb insights into all matters that relate to
`computer security.
`
`
`
`Page 15 of 275
`
`Page 15 of 275
`
`

`

`PREFACE
`
`Isabel Cho, Lisa Friendly, Charlie Lai, Jan Luehe, Teresa Lunt, Laura
`Michaels, Stephen Northcutt, Peter Neumann, and a number of anonymous
`reviewers provided valuable comments on draft versions of this book.
`G. H. Hardy once said that young men should prove theorems, while old men
`should write books. It is now time to prove some moretheorems.
`
`Li Gong
`Los Altos, California
`
`June 1999
`
`
`
`Page 16 of 275
`
`Page 16 of 275
`
`

`

`CHAPTER 1
`
`
`Computer and Network
`Security Fundamentals
`
`The three golden rules to ensure computer security are: do not own
`a computer; do not powerit on; and do not useit.
`—Robert (Bob) T. Morris
`
`Security is all about ensuring that bad things do not happen.This briefstatement
`is deceptively simple.It can in fact have very complicated interpretations. Explor-
`ing these can help in understanding whatsecurity really means.
`Certain “rule-of-thumb”principles apply to the conceptof security in general.
`First, security is alwaysrelatedto utility. To ensure that bad things do not happen,
`you can simply do nothing. For example, a car stored in a garage cannot cause a
`traffic accident. But doing nothing with the car is clearly not whatis intended. The
`real goal is to ensure that bad things do not happen while good things do get done.
`Second, security is relative to the threat that one considers. For example, the
`effectiveness of your house’s securely locked front doorto prevent theft depends
`heavily on the types of thieves against which you are guarding. While the lock
`might deter a small-timethief, it might not pose a problem for a sophisticated one
`equipped with the right tools.
`Third, security must be considered from an overall systems point of view. It is
`only as secure as the system’s weakestpoint. Thatis,it is not enoughto just secure
`the front door. A smart thief will try to enter the house from all potentially weak
`spots, and in particular those furthest away from where you haveinstalled strong
`locks.
`Fourth, security must be easy to accomplish.If it takes 30 minutes and great
`effort every time to unlock a complicated lock, you will tend to ignore the lock
`: and leave the door open.
`
`
`
`
`
`Page 17 of 275
`
`Page 17 of 275
`
`

`

`CRYPTOGRAPHYVERSUS COMPUTER SECURITY
`
`Fifth, security must be affordable and cost effective. For example, it clearly
`does not make sense to install a lock that is worth more than the contents it is
`guarding. This is made more complex by the fact that different people tend to
`value things differently.
`Last but not least, security must be as simple as possible because, as experi-
`ence indicates, the more complex a system is, the more error-prone it tends to be.
`It is better to have something that is simpler but more dependable.
`Throughout this book, you will see that these “rule-of-thumb” principles
`apply equally well to computersecurity.
`
`1.1 Cryptography versus Computer Security
`
`Before moving on to specific topics, J want to clarify that cryptography and com-
`puter security are two distinct subjects. Cryptography is the art of encoding
`information in a secret format such that only the intended recipient can access the
`encoded information. The use of cryptography has progressed extensively over a
`long period of time, ranging from the ancient Caesar cipher, to cipher machines
`widely used in World War II, to modern cryptosystems implemented with com-
`puter hardware and software.
`Computersecurity first became an issue only in the 1960s, when timesharing,
`multiuser computer (operating) systems were first built, such as Cambridge’s
`early computing system [80] and MIT’s Multics [69, newref 1]. After that, the
`field of computer security remained relatively obscure for years, apart from a brief
`active period in the mid-1970s [3, 32, 36, 75, newref 2, newref 3]. Security con-
`cerns then were based mostly on military requirements. Commercial security did
`not become fully mainstream until
`the Internet and electronic commerce
`(e-commerce), and Java technology in particular, took center stage in the 1990s.
`Security mechanisms often can benefit from the use of cryptography, such as
`when running a network-based user login protocol. However, they do not neces-
`sarily depend on the use of cryptography, such as when implementing UNIX-style
`access control onfiles.
`Yet cryptography does not exist in a vacuum. Cryptographic algorithms are
`usually implemented in software or hardware; thus their correct operation depends
`critically on whether there is an adequate level of system security. For example,if
`lack of access control means that an attacker can modify the software that imple-
`ments the algorithm, then the lack of security directly impacts the utilization of
`cryptography.
`
`
`
`
`
`Page 18 of 275
`
`Page 18 of 275
`
`

`

`
`
`COMPUTER AND NETWORKSECURITY FUNDAMENTALS
`
`1.2.
`
`Threats and Protection
`
`In computer security literature, threats or attacks are usually classified into three
`categories.
`
`1. Secrecy attacks. The attacker attempts to steal confidential information, such
`as passwords, medical records, electronic mail (e-mail) logs, and payroll data.
`The methodsofattack vary, from bribing a security guard to exploiting a secu-
`rity hole in the system or a weakness in a cryptographic algorithm.
`2. Integrity attacks. The attacker attempts to illegally alter parts of the system.
`For example, a bank employee modifies the deposit system to transfer custom-
`er money into his own account, thus compromising transaction integrity [61].
`Or, a college studentbreaksinto the college administration system to raise her
`examination scores, thus compromising data integrity. An attacker might also
`try to erase system logsin orderto hide his footprint.
`3. Availability attacks. The attacker attempts to disrupt the normal operation of
`a system. These are also commonlycalled denial-of-service attacks. For exam-
`ple, bombarding a machine with a large numberof IP packets can effectively
`isolate the machine from the rest of the network. A cyberterrorist might at-
`temptto bring downthe national powergrid or causetraffic accidents by com-
`promising the computer-operated control systems.
`
`These three categories of attacks are intricately related;thatis, the techniques
`and results of attacks in one category can often be usedto assist attacks in another.
`For example, by compromising secrecy an attacker could obtain passwords and
`thus compromise integrity by gaining access to and then modifying system
`resources, which in turn could lead to successful denial-of-service attacks. When a
`system failure occurs during an attack, most systems do not fail safe—that is,
`enter into a state that is deemed secure—because they are not designed to doso.
`For example, it has been shown that a system crash sometimes leads to a core
`dump in a publicly readable directory, where the core can contain sensitive infor-
`mation if the dumpoccursatthe right time.!
`Similarly, protection mechanismsagainst these types of attacks in general are
`related. Roughly speaking, the mechanisms are for one or more of the following
`
`_| Ofcourse,attacks can be viewed from otherperspectives. For example, there is widespread
`public concern regarding the privacy of the unregulated and sometimesillegal collection
`and distribution of personal data, such as birth dates and U.S. Social Security Numbers.
`
`Page 19 of 275
`
`Page 19 of 275
`
`

`

`
`
`PERIMETER DEFENSE
`
`purposes: attack prevention, detection, or recovery. Notall of these purposes can
`be fulfilled by the same mechanisms, as explained later in this chapter.
`To protect data secrecy, you can store the data in an obscure place in the hope
`that attackers will notfind it. Or you can install strict access control procedures to
`guard against unauthorized access. Or you can use encryption technology to
`encrypt the data such that attackers cannot access real data unless they can break
`the cryptosystem, which could be extremely hard, or they can steal the encryption
`key. Of course, multiple measures can be deployed at the same time. Notethat, for
`secrecy, the most important technique is prevention. A loss of data is very hard to
`detect, and lost data are impossible to recover.
`To protect data integrity, once again you can use anyorall of the mechanisms
`mentioned previously. However, in this case, detection is easier and recovery is
`often possible. For example, for a file x, you could compute its hash value using a
`well-known one-way function f() and store f(x) separately. Now,if x is then modi-
`fied to be x’, f(x) very likely will not be equalto f(x’), according to the properties of
`JO. Thus you can recompute the hash value and compare it with Ax). A mismatch
`will indicate that integrity has been compromised.
`Ofcourse, if the correspondingf(x) is also compromised, detection might not
`be possible. If the place to store f(x) itself is not safe, you could use a keyed, one-
`way hash function andstore f(k, x) together with x. If k is kept secret, then it will
`still be difficult for attackers to modify x and the hash value in such a way as to
`avoid detection [22, 52].
`To be able to restore the data to its original form after an integrity compro-
`mise, you can back up data and store the backup in a secure place [61]. Or you can
`use more-complicated distributed computing techniques to back up the data in an
`insecure network [34, 64, 73, 77].
`Guarding against an availability attack is more complicated. This is because
`apart from applying the usual techniques of prevention and detection, surviving
`such attacks becomescritical. Here, computer security meets the fiel