throbber

`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket