`Inside Java“ 2
`Platform Security
`Architecture, API Design,
`and Implementation
`
`
`
`
`
`Page 1 of 275
`
`GOOGLE EXHIBIT 1016
`
`Page 1 of 275
`
`GOOGLE EXHIBIT 1016
`
`
`
`
`L
`
`; ddison
`1 Wesley
`
`Page 2 of 275
`
`Page 2 of 275
`
`
`
`
`
`
`'
`L
`
`NORTH CAROLINA STATE UNIVERSITY UBhARIES
`
`
`
`
`
`
`
`
` I“
`
`
`
`
`
`
`
`301773199 .
`
`‘
`
`
`
`Page 3 of 275
`
`
`
`...~.-A....M”-m_.g..~mw
`
`
`
`Page 3 of 275
`
`
`
`
`
`Inside JavaTM 2
`
`Platform Security
`
`This book is due on the date indicated
`below and IS subject to an overdue
`fine as posted at the circulation desk.
`
`EXCEPTION: Date due will be
`earlier if this item is RECALLED.
`
`
`
`SEP 2 5 2002
`
`200M/OS-99-991212
`
`
`
`Page 4 of 275
`
`Page 4 of 275
`
`
`
`
`
`The Java‘” Series
`
`Lisa Friendly, Series Editor
`Tim Lindholm, Technical Editor
`Please see our web site (http://www.awl.com /cseng/javaseries) for more information on these titles.
`
`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, Maydene Fisher, 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 Javam
`Programming Language, Second Edition
`ISBN 0401610066
`
`Mary Campione and Kathy Walrath, The JavaTM
`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 I 999
`ISBN 0—201-43298-6
`
`Patrick Chan and Rosanna Lee, The Java‘” Class
`Libraries, Second Edition, Volume 2: java.applet,
`javaawt, java. beans
`ISBN 0—201—31003—1
`
`Patrick Chan, Rosanna Lee, and Doug Kramer,
`The Java’” Class Libraries, Second Edition,
`Volume I : java. to, java. lang, java.math,
`javanet, java.text, javaulil
`ISBN 0—201—31002-3
`
`Patrick Chan, Rosanna Lee, and Doug Kramer,
`The Java“ Class Libraries, Second Edition,
`Volume I : 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—31000-7
`
`James Gosling, Bill Joy, and Guy Steele,
`The Java“ Language Specification
`ISBN 0-201-63451-1
`
`James Gosling, Frank Yellin, and The Java Team,
`The Java‘“ Application Programming Interface,
`Volume I: Care 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 Javam 2
`Platform Security
`
`Architecture, API Design,
`and Implementation
`
`' Li Gong
`
`A
`VV
`
`ADDISON-WESLEY
`
`An imprint of Addison Wesley Longman, Inc.
`Reading, Massachusetts 0 Harlow, England - Menlo Park, California
`Berkeley, California - Don Mills, Ontario 0 Sydney
`Bonn - Amsterdam 0 Tokyo 0 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.
`
`DukeTM 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 US. patents,
`foreign patents, or pending applications. Sun, Sun
`Microsystems, the Sun logo, and all Sun, Java, Jim, 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 CHANGES IN ANY
`TECHNOLOGY, PRODUCT, OR PROGRAM DESCRIBED IN THIS PUBLICATION AT ANY
`TIIVIE.
`
`The publisher offers discounts on this book when ordered in quantity for special sales. For more information, please
`contact: Corporate, Government and Special Sales; Addison Wesley Long'man, Inc; One Jacob Way; Reading, Massa-
`chusetts 01867.
`
`ISBN: 0-201-31000—7
`1 2 3 4 5 6 7 8 9-CRS-0302010099
`First Printing, June 1999
`
`
`
`"435::memn-.-zm».Anew—OJ..~.r~,.neat-M
`
`
`
`1w‘armz‘zmw“
`
`
`
`am..-ngwam;1n“?
`1N:g*.qig;twmm_.=
`
`Page 7 of 275
`
`Page 7 of 275
`
`
`
`Contents
`
`
`
`Preface.......... ........ . ......x1
`How This Book Is Organized ......................................... xii
`Acknowledgments ................................................ xiii
`
`1 Computer and Network Security Fundamentals. . . . . . . . . . . . . . 1
`1.1 Cryptography versus Computer Security ............................. 2
`1.2 Threats and Protection............................................ 3
`1.3 Perimeter Defense ............................................... 4
`1.3.1 Firewalls ................................................. 6
`1.3.2 Inadequacies of Perimeter Defense Alone ........................ 6
`1.4 Access Control and Security Models ................................ 7
`1.4.] MAC and DAC Models ...................................... 7
`1.4.2 Access to Data and Information ............................... 8
`1.4.3 Static versus Dynamic Models ................. . ............... 9
`1.4.4 Considerations Concerning the Use of Security Models ............ 10
`1.5 Using Cryptography ............................................ 11
`1.5.1 One—Way Hash Functions ................................... 12
`1.5.2 Symmetric Ciphers ........................................ 13
`1.5.3 Asymmetric Ciphers ....................................... 14
`1.6 Authentication ................................................ 15
`1.7 Mobile Code .................................................. 17
`1.8 Where Does Java Security Fit In ................................... 18
`
`2 Basic Security for the Java Language. . . . . . . . . . . . ...... . . . . 21
`2.1 The Java Language and Platform .................................. 22
`2.2 Basic Security Architecture ....................................... 23
`2.3 Bytecode Verification and Type Safety ............................. 25
`2.4 Signed Applets ................................................ 27
`2.5 A Brief History of Security Bugs and Fixes .......................... 28
`
`
`
`Page 8 of 275
`
`Page 8 of 275
`
`
`
`vi
`
`CONTENTS
`
`3 JDK 1.2 Security Architecture ........... . ........... . . . . 33
`3.1 From the Beginning ............................................ 33
`3.2 Why a New Security Architecture ................................. 34
`3.2.1 Sandbox Restrictions on Applets Too Limiting .................. 34
`3.2.2 Insufficient Separation Between Policy and Enforcement .......... 35
`3.2.3 Security Checks Not Easily Extensible ........................ 35
`3.2.4 Locally Installed Applets Too Easily Trusted ................... 36
`3.2.5 Internal Security Mechanisms Fragile ......................... 36
`3.2.6 Summary ................................................ 37
`3.3 java. secu r‘i ty . General Securi tyExcepti on ................... 37
`3.4 Security Policy ................................................ 38
`3.5 CodeSour‘ce ................................................. 41
`
`3.5.1 Testing for Equality and Using Implication ..................... 43
`3.6 Permission Hierarchy ........................................... 45
`3.6.1 java. security.Perm1'ss1'on ............................. 46
`3.6.2 Permission Sets ........................................... 48
`
`3.6.3 java.security.UnresolvedPerm1' ssion ................... 50
`3.6.4 java.'io.F1'1ePer'm1' ss-ion ................................ 52
`3.6.5 java.net.SocketPer‘m1’ss1‘on ............................ 55
`3.6.6 java.secur1'ty.Bas1'cPermi ssion ........................ 59
`3.6.7 java. ut1'1 .Pr'opertyPer'm'i 551' on ......................... 59
`3.6.8 java. 1ang.Runt-imePerm1'ss1'on .......................... 61
`3.6.9 java.awt .AWTPermission ................................ 62
`3.6.10 java. net.NetPerm-ission ............................... 63
`3.6.11 java.1ang.ref'lect.Ref1ectPer'm1'ss1'on ................ 63
`3.6.12 java.1'0.SerializablePerm-ission ...................... 64
`3.6.13 java.security.SecurityPermission .................... 64
`3.6.14 java.security.A11Per‘m1'ssion ......................... 65
`3.6. 15 Implications of Permission Implications ...................... 66
`3.7 Assigning Pennissions .......................................... 66
`3.7.1 Positive versus Negative Permissions .......................... 68
`3.8 ProtectionDomai n ........................................... 69
`
`3.9 Securely Loading Classes ........................................ 71
`3.9.1 Class Loader Hierarchy .................................... 72
`3.9.2 java.1ang.C1assLoader and Delegation .................... 74
`3.9.3 java.secur1‘ty.$ecureC1 assLoader ...................... 79
`3.9.4 java.net.URLC'| assLoader ............................... 80
`3.9.5 Classpaths ............................................... 81
`3.10 java.1ang.Secur'1'tyManager ................................. 83
`3.10.1 Example Use of the Security Manager ........................ 83
`3.10.2 Unchanged APIs in JDK 1.2 ............................... 84
`3.10.3 Deprecated Methods in JDK 1.2 ............................ 85
`
`
`
`
`
`Page 9 of 275
`
`Page 9 of 275
`
`
`
`CONTENTS
`
`'
`
`vii
`
`3.11 java.security.AccessController ............................ 90
`3.11.1 Interface Design ofAccessContr'oller ..................... 91
`3.11.2 The Basic Access Control Algorithm ......................... 92
`3.11.3 Method Inheritance ....................................... 94
`3.11.4 Extending the Basic Algorithm with Privileged Operations ........ 95
`3.11.5 Three Types of Privileged Actions ........................... 98
`3.11.6 The Context of Access Control ............................. 101
`3.11.7 The Full Access Control Algorithm ......................... 102
`3.11.8 Securi tyManager versus AccessControl ler .............. 104
`3.11.9 A Mini—History of Privileged Operations ..................... 105
`3.12 Summary and Lessons Learned................................... 106
`
`. . . 113
`. . . . ...... .
`. . . .
`4 Deploying the Security Architecture. . . .
`4.1 Installing JDK 1.2 ............................................. 113
`4.2 Policy Configuration ........................................... 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 ................................. 118
`4.2.5 Policy File Examples ...................................... 122
`4.2.6 Property Expansion in Policy Files ........................... 123
`4.3 Digital Certificates ............................................ 125
`4.4 Helpful Security Tools ......................................... 130
`4.4.1 Keystore Databases ....................................... 130
`4.4.2 Keytool ................................... ‘............. 133
`4.4.3 Policy Tool ............................................. 139
`4.4.4 Jarsigner ............................................. 143
`4.4.5 Code Signing Example .................................... 148
`4.5 Managing Security Policies for Nonexperts ......................... 150
`
`. . . . . . . . . . 153
`. . . .
`5 Customizing the Security Architecture..... .
`5.1 Creating New Permission Types .................................. 153
`5.2 Composite Permissions ......................................... 155
`5.3 Customizing Security Policy ..................................... 156
`5.4 Migrating JDK 1.1-B ased Security Managers ....................... 158
`5.4.1 JDK 1.1 Security Manager Classes ........................... 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 ObjectSecurity............... ........173
`6.1 Security Exceptions ............................................ 173
`6.2 Fields and Methods ............................................ 174
`
`‘
`
`
`
`Page 10 of 275
`
`Page 10 of 275
`
`
`
`
`
`viii
`
`CONTENTS
`
`6.3 Static Fields ................................................. 176
`
`6.4 Private Object State and Object Immutability ....................... 176
`6.5 Privileged Code .............................................. 178
`6.6 Serialization ................................................. 179
`6.7 Inner Classes ................................................. 181
`6.8 Native Methods .............................................. 182
`
`6.9 Signing Objects .............................................. 182
`6.10 Sealing Objects ....................... -........................ 185
`6.11 Guarding Objects ............................................. 186
`6.11.1 Examples of Using GuardedObject ....................... 188
`
`7 Programming Cryptography ......... . . . .
`
`. . . ........... 191
`
`7.1 Design Principles ...... ........................................ l 92
`7.2 Cryptographic Services and Service Providers ...................... 193
`7.2.1 Installing and Adding a Provider ............................ 197
`7.3 Cryptography Classes .......................................... 199
`7.3.1 java.secur1‘ty.Security ............................... 199
`7.3.2 java.security.Prov1‘der ............................... 200
`7.3.3 java.secur‘ity.MessageDi gest ......................... 200
`7.3.4 java.security.Signatur‘e .............................. 201
`7.3.5 Algorithm Parameters ..................................... 204
`7.3.6 java.security.Key and java.security.spec.KeySpec .
`. .. 207
`7.3.7 java. security.KeyFactor‘y and java. securi ty.cert.
`210
`Ce rti fi care Facto ry
`7.3.8 KeyPai r and KeyPai rGenerator .......................... 212
`7.3.9 java.security.KeyStore ............................... 214
`Randomness and Seed Generators ................................ 215
`
`7.4
`
`7.4.1 java.security.SecureRandom .......................... 216
`Code Examples ............................................... 217
`7.5.1 Example 1: Computing a Message Digest ..................... 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 .............................................. 222
`
`7.5
`
`7.6
`
`7.6.1 Message Digest Algorithms ................................ 222
`7:62 Key and Parameter Algorithms .............................. 222
`7.6.3 Digital Signature Algorithms ............................... 223
`7.6.4 Random Number Generation Algorithms ...................... 223
`7.6.5 Certificate Types ......................................... 223
`7.6.6 Keystore Types .......................................... 224
`Algorithm Specifications ....................................... 224
`7.7.1 SHA-l Message Digest Algorithm ........................... 225
`
`7.7
`
`
`
`
`
`Page 11 of 275
`
`Page 11 of 275
`
`
`
`CONTENTS
`
`ix
`
`7.7.2 MD2 Message Digest Algorithm ............................. 225
`7.7.3 MDS Message Digest Algorithm ............................. 225
`7.7.4 Digital Signature Algorithm ................................ 225
`7.7.5 RSA—Based Signature Algorithms ............................ 225
`7.7.6 DSA KeyPair Generation Algorithm .......................... 226
`7.7.7 RSA KeyPair Generation Algorithm .......................... 227
`7.7.8 DSA Parameter Generation Algorithm ........................ 227
`
`.........229
`8 FutureDirections
`8.1 Security Management .......................................... 229
`8.2 JDK Feature Enhancement ...................................... 230
`8.3 Java Authentication and Authorization Service ...................... 232
`8.3.1 Subjects and Principals .................................... 234
`8.3.2 Credentials .............................................. 234
`8.3.3 Pluggable and Stacked Authentication ........................ 235
`8.3.4 Callbacks ............................................... 239
`8.3.5 Access Control ........................................... 239
`8.3.6 JAAS Implementation ..................................... 241
`8.4 Conclusion ....... ............................................. 242
`
`Bibliography..........................................245
`
`Index ......
`
`...... . ...... .251
`
`
`
`Page 12 of 275
`
`Page 12 of 275
`
`
`
`
`
`Preface
`
`Give me a lever and a fulcrum, and I can move the globe.
`—Archirnedes
`
`Since Java technology’s inception, and especially its public debut in the spring
`of 1995, strong and growing interest 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 phenomenon in 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 known that retrofitting security is usually very difficult, if not impossible, and
`often causes backward compatibility problems.
`'
`Thus it 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. The first is 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 second is 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 technology plays a central role, and how various security technologies
`relate to each other.
`
`
`
`Page 13 of 275
`
`Page 13 of 275
`
`
`
`xii
`
`PREFA CE
`
`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 how a feature 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.
`Some of these examples are synthesized from the JDK 1.2 code source tree.
`Third, I sought to 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 programming errors by discussing a
`number of common mistakes and by providing tips 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 ahead to future directions for Java security
`
`
`
`
`
`Page 14 of 275
`
`Page 14 of 275
`
`
`
`PREFACE
`
`This book is primarily for serious Java programmers and for security profes-
`sionals who want to 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.
`Throughout this book, I assume that the reader is familiar with the fundamen-
`tals of the Java language. For those who want to learn more about that language,
`the book by Arnold and Gosling [2] is a good source.
`This book is 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 me to 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, kept faith in me, and rescued
`me whenever I 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 of the 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, Hemma Prafullchandra, Benjamin
`Renaud, Roger Riggs, Jim Roskind, Nakul Saraiya, Roland Schemers, Bill
`Shannon, Torn 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
`Schroeder for their participation and superb insights into all matters that relate to
`computer security.
`
`
`
`Page 15 of 275
`
`Page 15 of 275
`
`
`
`xiv
`
`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 more theorems.
`
`Lz' Gong
`Los Altos, California
`June 1 999
`
`
`
`
`
`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 power it on; and do not use it.
`—Robert (Bob) T. Morris
`
`Security is all about ensuring that bad things do not happen. This brief statement
`is deceptively simple. It can in fact have very complicated interpretations. Explor-
`ing these can help in understanding What security really means.
`Certain “rule-of—thumb” principles apply to the concept of security in general.
`First, security is always related to 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 what is 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 door to prevent theft depends
`heavily on the types of thieves against which you are guarding. While the lock
`might deter a small-time thief, 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 weakest point. That is, it is not enough to 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 have installed 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
`
`
`
`CRYPTOGRAPHY VERSUS 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 computer security.
`
`1.1 Cryptography versus Computer Security
`
`Before moving on to specific topics, I 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 I], to modern cryptosystems implemented with com-
`puter hardware and software.
`Computer security first became an issue only in the 19603, 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 19905.
`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 on files.
`
`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 NETWORK SECURITY 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 methods of attack 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 student breaks into the college administration system to raise her
`examination scores, thus compromising data integrity. An attacker might also
`try to erase system logs in order to hide his footprint.
`
`3. Availability attacks. The attacker attempts to disrupt the normal operation of
`a system. These are also commonly called denial-of-service attacks. For exam-
`ple, bombarding a machine with a large number of IP packets can effectively
`isolate the machine from the rest of the network. A cyber terrorist might at-
`tempt to bring down the national power grid or cause traffic accidents by com—
`promising the computer—operated control systems.
`
`These three categories of attacks are intricately related; that is, the techniques
`and results of attacks in one category can often be used to 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 do so.
`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 dump occurs at the right time.1
`Similarly, protection mechanisms against these types of attacks in general are
`related. Roughly speaking, the mechanisms are for one or more of the following
`
` .
`
`1 Of course, attacks can be viewed from other perspectives. For example, there is widespread
`public concern regarding the privacy of the unregulated and sometimes illegal collection
`and distribution of personal data, such as birth dates and US. Social Security Numbers.
`
`Page 19 of 275
`
`Page 19 of 275
`
`
`
`
`
`PERIMETER DEFENSE
`
`purposes: attack prevention, detection, or recovery. Not all 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 not find 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. Note that, 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 any or all 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 f0 and store fix) separately. Now, if x is then modi-
`fied to be x', fix) very likely will not be equal to f(x'), according to the properties of
`f