`
`
`
`Get efiicisl current cryptcgrapny
`standards en encicsed'CDRUM
`
`SIBUB Blll‘llflll 3: Slfllll‘lflll Paine
`Apple 1021 (Part 1)
`Apple v. USR
`|PR2018—00810
`
`BSA Security’s flfiicial Guide ID
`
`Learn new secure date-encryptien
`techniques werk
`
`Pretect ccnfidentiel inferrneticn
`
`en ycur network
`
`Apple 1021 (Part 1)
`Apple v. USR
`IPR2018-00810
`
`
`
`_m————-—-—-—-———'—'—-'—
`
`
`
`
`
`
`
`Steve Burnett and Stephen Paine
`
`OsbornechGraw-Hill
`New York Chicago San Francisco.
`
`Lisbon London Madrid Mexico City
`Milan New Delhi San Juan
`
`Seoul Singapore Sydney Toronto
`
`
`
`OsborneMcGraw-Hill
`2600 Tenth Street
`Berkeley, California 94710
`U.S.A.
`
`.3 (3 1
`30 O ‘
`CO a
`P 1
`MILE.
`To arrange bulk purchase discounts for sales promotions, premiums, or fund-
`raisers, please contact OsbornechGraw-Hill at the above address. For
`information on translations or book distributors outside the U. S.A., please see
`the International Contact Information page immediately following the index of
`this book.
`
`BSA Security’s Official Guide to Cryptography
`
`Copyright © 2001 by The McGraw-Hill Companies. All rights reserved. Printed
`in the United States of America. Except as permitted under the Copyright Act of
`1976, no part of this publication may be reproduced or distributed in any form or
`by any means, or stored in a database or retrieval system, without the prior
`written permission of the publisher, with the exception that the program listings
`may be entered, stored, and executed in a computer system, but they may not be
`reproduced for publication.
`
`1234567890 FGR FGR' 0198765432]
`
`Book pm 0-07—213138-1 and CD pin 0—07-213137—3
`parts of
`ISBN 0-07-213139—X
`
`Publisher
`Brandon A. Nordin
`Vice President &
`Associate Publisher
`Scott Rogers
`
`Executive Editor
`Steven Elliot
`
`Technical Editors
`Blake Dournaee
`Jessica Nelson
`Copy Editor
`Betsy Hardinger
`
`Composition and Indexer
`MacAllister Publishing Services, LLC
`
`Senior Project Editor
`LeeAnn Pickrell
`
`Acquisitions Coordinator
`Alexander Corona
`
`Illustrators
`Michael Mueller
`
`Beth Young
`_
`Lyssa Sieben-Wald
`
`Information has been obtained by OsbornechGraw-Hill from sources believed to be reli-
`able. However, because of the possibility of human or mechanical error by our sources,
`OsbornechGraw-Hill, or others, OsborneMcGraw-Hill does not guarantee the accuracy.
`adequacy, or completeness of any information and is not responsible for any errors or omis-
`sions or the results obtained from use of such information.
`
`zoo/@0973
`
`
`
`
`
`
`
`
`
`To Pan—Chi, Gwen, Ray, Satomi, Michelle, Alexander,
`Warren, Maria, Daniel, and Julia
`
`—Steve Burnett
`
`To Danielle, thanks for understanding while I worked on
`this book
`
`To Alexis and Elizabeth, a father could not ask for better
`children
`
`—Stephen Paine
`
`
`
`
`
`Contents
`
`Credits
`
`Foreword
`
`Acknowledgments
`Preface
`
`About the Authors
`
`Chapter 1 Why Cryptography?
`
`Security Provided by Computer Operating Systems
`
`How Operating Systems Work
`
`Default 05 Security: Permissions
`
`Attacks on PaSSWords
`
`Attacks That Bypass Operating Systems
`
`Data Recovery Attack
`Memory Reconstruction Attack
`Added Protection Through Cryptography
`
`The Roie of Cryptography in Data Security
`
`Chapter 2
`
`Symmetric-Key Cryptography
`
`Some Crypto Jargon
`
`What Is a Key?
`
`Why is a Key Necessary?
`
`Generating a Key
`A Random Number Generator
`
`A Pseudo~Random Number Generator
`
`Attacks on Encrypted Data
`
`Attacking the Key
`
`Breaking the Algorithm
`
`Measuring the Time it Takes to Break Your Message
`
`Symmetric Aigorithms: The Key Tabie
`Symmetric Aigorithms: Brock Versus Stream Ciphers
`
`Block Ciphers
`
`Stream Ciphers
`
`.Biock Versus Stream: Which Is Better?
`
`Digitai Encryption Standard
`
`Tripie DES
`
`Commerciai DES Replacements
`
`Advanced Encryption Standard
`
`xiii
`
`xvii
`
`xix
`
`xxii
`
`_‘
`
`N—Qfi‘fi‘abLAJh-JN
`
`U1
`
`._.__.
`
`woo—bohwmmwwmwwmwmw—O‘DWU‘UT-HCDCONWO‘DDCDWNNOGD
`
`
`
`
`
`
`
` VI Contents
`
`Summary
`Real—World Example: Oracle Databases
`
`Chapter El
`
`SymmetrieKey Management
`
`Password—Based Encryption
`Programming Convenience
`Breaking PBE
`Slowing Down an Attack on a Password
`Good Passwords
`
`Password Generators
`
`HardwareBasecl Key Storage
`Tokens
`
`'
`
`Crypto Accelerators
`Hardware Devices and Random Numbers
`
`Biometrics
`
`Summary
`Real-World Examples
`Keon Desktop
`Other Products
`
`-
`
`5i
`5i
`
`53
`
`54
`59
`o3
`(:4
`65
`
`67
`
`69
`69
`
`73
`75
`
`75
`
`76
`V6
`7’7
`79
`
`Chapter 4
`
`The Key Distribution Problem and Public—Key Cryptography 8|
`
`Sharing Keys in Advance
`Problems mm This Scheme
`
`Using a Trusted Third Party
`Problems With This Scheme
`
`Public-Key Cryptography and the Digital Envelope
`
`Security issues
`Breaking a Public-Key Algorithm
`
`Some History of Public-Key Cryptography
`
`How Pu blic—Key Cryptography Works
`
`The RSA Algorithm
`The DH Algorithm
`
`The ECDH Algorithm
`
`Comparing the Algorithms
`
`Security
`Key Sizes
`Performance
`
`Transmission Size
`
`interoperability
`
`83
`84
`
`85
`86
`
`88
`
`9 I
`‘92
`
`93
`
`94
`
`98
`I 05
`
`i
`
`I
`
`I
`
`I
`
`l 7
`
`I I7
`I 19
`l 20
`
`122
`
`I 22
`
`
`
`
`
`Contents V"
`
`Protecting Private Keys
`
`Using the Digital Envelope for Key Recovery
`
`Key Recovery via a Trusted Third Party
`
`Key Recovery via a Group of Trustees
`
`Key Recovery via Threshoid Schemes
`How a Threshold Scheme Works
`
`Summary
`
`Reai-Worid Example
`
`Chapter 5
`
`The Digitai Signature
`
`The Uniqueness of a Digital Signature
`
`Message Digests
`Collisions
`
`The Three important Digest Aigorithms
`
`A Representative of Larger Data
`
`Data integrity
`
`Back to Digital Signatures
`
`Trying to Cheat
`
`Implementing Authentication, Data integrity, and Nonrepudiation
`
`Understanding the Algorithms
`RSA
`
`DSA »
`
`ECDSA
`
`Comparing the Algorithms
`
`Security
`Performance
`
`Transmission Size
`
`interoperability
`
`Protecting Private Keys
`introduction to Certificates
`
`Key Recovery
`
`Summary
`
`Real-World Example
`
`Chapter 6
`
`Public-Key infrastructures and the X509 Standard
`
`Public-Key Certificates
`Unique Identifiers
`Standard Version 3 Certificate Extensions
`
`Entity Names
`
`122
`
`1 23
`
`124
`
`1 26
`
`127
`130
`
`132
`
`133
`
`137
`
`1311
`
`141
`1 45
`
`148
`
`1 49
`
`153
`
`154
`
`156
`
`159
`
`i 59
`160
`
`161
`
`i63
`
`i 63
`
`163
`1 64
`
`165
`
`i 65
`
`166
`166
`
`169
`
`169
`
`170
`
`171
`
`1 72
`174
`I75
`
`I77
`
`
`
`V] II
`
`ASN.1 Notation and Encoding
`The Components of a PK]
`Certification Authority
`Registration Authority
`Certificate Directory
`Key Recovery Server
`Management Protocols
`Operational Protocols
`Registering and issuing Certificates
`Revoking a Certificate
`Certificate Revocation Lists
`
`Suspending a Certificate
`Authority Revocation Lists
`Trust Models
`
`Certificate Hierarchies
`
`Cross-Certification
`
`_
`
`X509 Certificate Chain
`
`The Push Model Versus the Pull Model
`
`Managing Key Pairs
`Generating Key Pairs
`Protecting Private Keys
`Managing Multiple Key Pairs
`Updating Key Pairs
`Keeping a History of Key Pairs
`Deploying a PKl
`The Future of PKl
`
`Roaming Certificates
`Attribute Certificates
`
`Contents
`
`179
`179
`1 80
`1 80
`181
`182
`182
`184
`184
`185
`186
`
`190
`190
`191
`
`192
`
`l 93
`
`194
`
`195
`
`1%
`19?
`197
`198
`199
`200
`201
`201
`
`201
`203
`
`204
`
`206
`206
`207
`
`207
`
`209
`
`209
`
`Certificate Policies and Certification Practice Statements
`
`Summary
`Real-World Examples
`Keon Certificate Server
`
`Keon Web PassPort
`
`Chapter 7
`
`Network and Transport Security Protocols
`
`internet' Protocol Security
`
`iP Security Architecture
`lPSec Services
`
`The Authentication Header Protocol
`
`Integrity Check Value Calculation
`
`210
`21 1
`
`21 1
`
`212
`
`
`
`
`
`Contents
`
`IX
`
`Transport and Tunnel Modes
`
`The Encapsulating Security Payload Protocol
`
`Encryption Algorithms
`
`ESP in Transport and Tunnel Modes
`
`Security Associations
`Combining Security Associations
`
`Security Databases
`
`Security Policy Database
`Security Association Database
`
`Key Management
`
`lnternet Key Exchange
`
`Secure Sockets Layer
`
`The History of SSL
`Session and Connection States
`
`The Record Layer Protocol
`
`The Change Cipher Spec Protocol
`The Alert Protocol
`
`The Handshake Protocol
`
`The Client Hello Message
`
`The Server Hello Message
`
`The Server Certificate Message
`
`The Server Key Exchange Message
`The Certificate Request Message
`
`The Server Hello Done Message
`
`The Client Certificate Message
`
`The Client Key Exchange Message
`
`The Certificate Verify Message
`
`The Finished Message
`
`Ending a Session and Connection
`Resuming Sessions
`Cryptographic Computations
`Encryption and Authentication Algorithms
`
`Summary
`
`Real-World Examples
`
`Chagter 8
`
`Application-Layer Security Protocols
`
`S/MIME
`
`Ovewiew
`
`S/MIME Functionality
`Cryptographic Algorithms
`
`2 1 3
`
`2 I 5
`
`2 i 6
`
`2] 7
`
`2 I 8
`2 l 9
`
`220
`
`222
`222
`
`223
`
`224
`
`227
`
`22?
`228
`
`230
`
`23]
`232
`
`233
`
`234
`
`235
`
`236
`
`236
`237
`
`237
`
`237
`
`238
`
`238
`
`239
`
`239
`240
`240
`240
`
`241
`
`242
`
`243
`
`24 3
`
`244
`
`245
`24S
`
`
`
` Contents
`
`
`
`S/MJME Messages
`Enhanced Security Services
`interoperability
`Secure Electronic Transaction [SET]
`Business Requirements
`SET Features
`SET Participants
`Dual Signatures
`SET Certificates
`Payment Processing
`Summary
`Real—World Examples
`
`-
`
`247
`252
`253
`2 53
`254
`255
`256
`257
`2 58
`260
`264
`265
`
`Chapter 9
`
`Hardware Solutions: Overcoming Software Limitations
`
`267
`
`Cryptographic Accelerators
`Authentication Tokens
`
`Token Form Factors
`
`Noncontact Tokens
`
`Contact Tokens
`
`Smart Cards
`Smart Card Standards
`Types of Smart Cards _
`Readers and Terminais
`
`JavaCards
`
`History and Standards
`JavaCard Operations
`Other Java Tokens
`
`Biometrics
`Biometric Systems Overview
`Recognition Methods
`Biometric Accuracy
`Combining Authentication Methods
`Summary
`Vendors
`
`Chaptef ‘l 0 Digital Signatures; Beyond Security
`
`Legislative Approaches
`Legal Guidelines from the American Bar Association
`Legal Concepts Related to Digital Signatures
`
`267
`269
`
`270
`
`2 70
`
`2 7 5
`
`275
`276
`276
`278
`
`279
`
`279
`280
`28i
`
`282
`282
`285
`288
`289
`29]
`291
`
`293
`
`295
`295
`2%
`
`
`
`
`
`
`
` Contents XI
`
`Nonrepudiation
`Authentication
`
`Written Versus Digital Signatures
`
`Requirements for the Use of Digital Signatures
`
`Pu biic .Key infrastructures
`
`Control of Key Revocation
`
`TimeStamping
`
`Current and Pending Legislation
`The E~SIGN Act
`
`Dealing with Legal Uncertainties
`
`Summary
`
`Real-World Examples
`
`Chapter 'I 1 Doing It Wrong: The Break-ins
`
`Measuring Losses
`
`'
`Types of Security Threats
`Unauthorized Disclosure of Data
`
`Unauthorized Modification of Data
`
`Unauthorized Access
`
`Disclosure of Network Traffic
`
`Spoofing of Network Traffic
`
`Identifying Intruders
`insiders
`
`Hackers
`
`Terrorists
`
`Foreign Intelligence Services
`Hactivists
`
`intruder Knowledge
`Case Studies
`
`Data in Transit
`
`Data at Rest
`
`Authentication
`
`implementation
`
`information Security: Law Enforcement
`
`Summary
`
`Chapter 12 Doing It Right; Following Standards
`
`Security Services and Mechanisms
`Authentication
`
`2%
`298
`
`299
`
`299
`
`300
`
`300
`
`300
`
`302
`303
`
`306
`
`307
`
`307
`
`309
`
`30‘?
`
`310
`3| I
`
`31 I
`
`312
`
`313
`
`314
`
`314
`315
`
`315
`
`315
`
`316
`3 i 6
`
`3 i 7
`3 i 2
`
`3i 7
`
`318
`
`3 l 9
`
`320
`
`32f
`
`322
`
`323
`
`324
`324
`
`
`
`XII
`
`Contents
`
`Confidentiality
`
`Integrity
`
`Nonrepudiation
`
`Standards, Guidelines, and Regulations
`
`The Internet Engineering Task Force
`ANSI X9
`
`National institute of Standards and Technology
`Common Criteria
`
`The Health insurance Portability Act
`
`Developer Assistance
`Insurance
`
`Security Research
`Case Studies
`
`Implementation
`Authentication
`
`Data at Rest
`
`Data in Transit
`
`Summary
`
`Appendix A Bits, Bytes, Hex, and ASCII
`
`Appendix B A Laymans Guide to a Subset ofASN. 1, BER, and DER
`
`Appendix C Further Technical Details
`
`Index
`
`326
`
`326
`
`327
`
`327
`
`327
`
`328
`
`328
`
`330
`
`330
`
`33]
`
`332
`
`332
`
`333
`
`333
`
`334
`
`335
`
`336
`
`336
`
`339
`
`347
`
`387
`
`407
`
`
`
`
`
`Credits
`
`Oracle is a registered trademark of Oracle Corporation. Various product
`
`and service names referenced herein may be trademarks of Oracle
`
`Corporation. All other product and service names mentioned may be
`
`trademarks of their respective owners.
`
`The ALX 300 is courtesy of Compaq Computer Corporation.
`
`The ikey 2000 and the CryptoSwift accelerator is courtesy of Rainbow
`
`Technologies, Inc.
`Data Key is courtesy of Datakey' Inc.
`
`The Java Ring is courtesy of Dallas Semiconductor Corp.
`
`The box blue accelerator and card reader is courtesy of nCipher Inc.
`
`The Luna CA3——Photos courtesy of Chrysalis—ITS®, Inc.
`
`The Smarty Smart Card Reader is courtesy of SmartDisk Corporation.
`
`The RSA SecurID Card and token are courtesy of RSA Security Inc.
`
`The BioMouse Plus is courtesy of American Biometric Company.
`The XyLoc‘proximity card is courtesy of Ensure Technologies.
`
`The Trusted Time products are courtesy of Datum.
`
`
`
`
`
`Foreword
`
`Welcome to the second book from RSA Press, RSA Security’s Official
`
`Guide to Cryptography!
`
`As the Internet becomes a more pervasive part of daily life, the need
`for e—security becomes even more critical. Any organization engaged in
`online activity must assess and manage the e-security risks associated
`
`with this activity. Effective use of cryptographic techniques is at the core
`
`of many of these risk-management strategies. This book provides a prac~
`
`tical guide for the use of cryptographic e—security technologies to provide
`for privacy, security, and integrity of an organization’s most precious
`asset: data.
`
`It is an exciting time for cryptography, with important technical, busi-
`
`ness, and legal events occurring in quick succession. This book can help
`
`the reader better understand the technology behind these events.
`
`In January 2000, the United States Government announced a signifi-
`
`cant relaxation in restrictions on the export of strong cryptography. This
`
`decision has permitted US. companies to now compete for cryptographic
`
`business on a worldwide basis. Previously, many of the algorithms dis-
`
`cussed in this book were treated as munitions and were subject to severe
`
`restrictions on their export from the'U.S.
`
`In September 2000, the patent on the RSA algorithm, arguably the
`
`most important patent in cryptography, expired. Now any firm or indi-
`
`vidual can create implementations of this algorithm, further increasing
`
`the pervasiveness of one of the most Widespread technologies in the his-
`
`tory of computing.
`
`In October 2000, the United States National Institute of Standards and
`
`Technology announced its selection of the winner of the Aducmced Encryp-
`
`tion Standard (AES) selection process, an algorithm called Rij ndael devel-
`
`oped by two Belgian researchers. The AES algorithm is intended to
`
`replace the venerable, and increasingly vulnerable Data Encryption Stan--
`
`dord (DES) algorithm. AES is expected to become the most widely used
`
`algorithm of its type in a short time.
`The security technology industry has undergone explosive growth in a
`short period of time, with many new options emerging for the dep10yment
`
`of e-security techniques based on cryptography. Ranging from new devel-
`
`opments in cryptographic hardware to the use of personal smart cards in
`public key infrastructures, the industry continues to increase the range
`of choices available to address e-security risks. This book provides the
`
`
`
`
`
`XVI
`
`Foreword
`
`reader with a solid foundation in the core cryptographic techniques of
`e—security—including RSA, AES, and DES mentioned previously, and
`many others—and then builds on this foundation to discuss the use of
`these techniques in practical applications and cutting-edge technologies.
`While this book does discuss the underlying mathematics of cryptog-
`raphy, its primary focus is on the use of these technologies in familiar,
`real-world settings. It takes a systems approach to the problems of using
`cryptographic techniques for e-security, reflecting the fact that the degree
`of protection provided by an e—security deployment is only as strong as the
`weakest link in the chain of protection.
`We hope that you will enjoy this hook and the other titles from RSA
`Press. We welcome your comments as well as your suggestions for future
`RSA Press books. For more information on RSA Security, please visit our
`
`web site at www . rsasecurity . com; more information on RSA Press can
`
`be found at www . rsapress . com.
`
`Burt Kaliskj
`
`Director and Chief Scientist
`
`RSA Laboratories
`
`bkal iskiersasecurity . com
`
`
`
`
`
`Acknowledgments
`
`The first person I’d like to thank is Stephen Paine. He did the work of
`putting together the original proposal and outline. Later on, he reorga—
`nized the structure to make the book better. He planned; I just wrote.
`Betsy Hardinger and LeeAnn Pickrell at Osborne/McGraw Hill are the
`two editors who made many suggestions (most of which we accepted) to
`improve the language, readability, and flow of the content. Stephen Paine
`and I have our names on the book, but I think they deserve plenty of
`
`credit for their contributions.
`
`Blake Dournaee of RSA did a great job of reviewing. If it hadn’t been
`
`for Blake, I would be suffering from great embarrassment for a couple of
`
`mistakes he caught. Of course, any errors still residing in this book belong
`
`entirely to Stephen and me.
`
`We received help from many people for the examples. Mark Tessin of
`
`Reynolds Data Recovery and- Dennis Vanatta of 4Sites Internet Services
`
`gave me the information and screen shot for the data recovery discussion
`in Chapter 1. Mary Ann Davidson and Kristy Browder of Oracle helped
`me put together the example in Chapter 2. For the Keon example, Peter
`
`Rostin and Nine Marino of RSA were my sources.
`
`The people at Osborne/McGraw Hill said we had complete control over
`the acknowledgments, so I’d like to thank some people who didn’t con-
`
`tribute to the book so much as contributed to my career. If it hadn’t been
`
`for Dave Neff at Intergraph, I don’t think I would have been much of a
`
`programmer and hence never could have been successful enough at RSA
`to be chosen to write this book. It was Victor Chang, then the VP of engi-
`
`neering at RSA, who hired me, let me do all kinds of wonderful things in
`
`the field and industry of cryptography, and made RSA engineering a great
`place to work. The geniuSes of RSA Labs, especially Burt Kaliski and Matt
`Robshaw, taught me most of the crypto I know today, and the engineers
`
`at RSA, especially Dung Huynh and Pao—Chi Hwang, taught me all about
`
`the crypto code.
`
`—Stcve Burnett
`
`The first person I’d like to thank is Steve Burnett. I am positive that if
`he had not agreed to co-author this book with me, I might have given up
`before I began.
`RSA Press definitely must be thanked for giving Steve Burnett and me
`a chance to write this book. Also, I’d like to thank Steve Elliot, Alex
`Corona, Betsy Hardinger, LeeAnn Pickrell, and all of the other empIOyees
`of OsbornechGraw Hill who worked to make this book possible.
`
`
`
`
`
`
`
`XVI" Acknowledgments
`
`Both Jessica Nelson and Blake Dournaee did an excellent job provid-
`ing technical reviewrthank you.
`I’d like to offer a special thanks to
`Mohan Atreya and Scott Maxwell of RSA Security; both were a source of
`excellent ideas and technical input.
`Thanks to my friends at RSA Security for being patient and under-
`standing while I worked long hours on the book.
`I especially want to thank Jerry Mansfield, a great friend who taught
`me to take life as it comes. Finally, I would like to thank my family for
`
`their support.
`
`-—St€phen Paine
`
`
`
`Preface
`
`Application developers never used to add security to their products
`because the buying public didn’t care. To add security meant spending
`
`money to include features that did not help sales. Today, customers
`
`demand security for many applications. The Federal Bureau of Investi—
`gation published the following Congressional Statement on February 16,
`2000:
`
`“There were over 100 million Internet users in the United States in 1999.
`
`That number is projected to reach 177 million in United States and 502 mil-
`
`lion worldwide by the end of 2003. Electronic commerce has emerged as a
`
`new sector of the American economy, accounting for over it 100 billion in sales
`
`during 1999; by 2003 electronic commerce is projected to exceed $1 trillion.”
`
`At the same time, the Computer Security Institute (CSI) reported an
`
`increase in cybercrime, “55% of the respondents to our survey reported
`
`malicious activity by insiders.” Knowing this, you can be sure growing cor-
`
`porations need security products.
`The most important seCurity tool is cryptography. Developers and engi-
`neers need to understand crypto in order to effectively build it into their
`
`products. Sales and marketing people need to understand crypto in order
`to prove the products they are selling are secure. The customers buying
`those products, whether end users or corporate purchasing agents, need
`to understand crypto in order to make well-informed choices and then to
`
`use those products correctly. IT professionals need to understand crypto
`in order to deploy it properly in their systems. Even lawyers need to
`understand crypto because governments at the local, state, and national
`
`level are enacting new laws defining the responsibilities of entities hold-
`
`ing the public’s private information.
`This book is an introduction to crypto. It is not about the history of
`crypto (although you will find some historical stories). It is not a guide to
`writing code, nor a math book listing all the theorems and proofs of the
`underpinnings of crypto. It does not describe everything there is to know
`about crypto; rather, it describes the basic concepts of the most widely
`
`used crypto in the world today. After reading this book, you will know
`
`
`
`
`
`XX
`Preface
`
`
`what computer cryptography does and how it’s used today For example,
`you will
`
`I Understand the difference between a block cipher and a stream
`cipher and know when to use each (if someone tries to sell you an
`application that reuses a stream cipher’s key, you will know why you
`shouldn’t buy it).
`
`I Know why you should not implement key recovery on a signing-only
`
`key.
`
`I Understand what SSL does and why it is not the security magic
`bullet solving all problems, which some e-ccmmerce sites seem to
`
`imply.
`
`I Learn how some companies have effectively implemented crypts in
`
`their products.
`
`I Learn how some companies have used crypto poorly (smart people
`learn from their own mistakes; brilliant people learn from other
`
`people’s mistakes).
`
`There are, of course, many more things you will learn in this book.
`Chapter 1 delves into why cryptography is needed today; Chapters 2
`through 5 describe the basic building blocks of crypto, such as symmetric
`keys and public keys, password-based encryption, and digital signatures.
`In Chapters 6 through 8, you will see how these building blocks are used
`to create an infrastructure through certificates and protocols. In Chapter
`9, you will learn how specialized hardware devices can enhance your secu-
`rity. Chapter 10 explores the legal
`issues around digital signatures.
`Finally, Chapters 11 and 12 show you some real-world examples of com-
`panies doing it wrong and doing it right.
`Throughout this book we use some standard computer hexadecimal
`notation. For instance, we might show a cryptographic key such as the fol-
`lowing:
`
`'
`
`0x14060839 623179086
`
`Many of you probably know what that means, but if you don’t, read
`Appendix A. It’s all about how the computer industry displays bits and
`bytes in hexadecimal. It also describes ASCII, the standard way letters,
`numerals, and symbols are expressed in computers.
`
`
`
`
`
`
`
`Preface XXI
`
`In Chapter 6, you’ll find a brief description of ASN.1 and BERIDER
`encoding. If you want
`to drill down further into this topic, read
`Appendix B.
`In Appendix C, you will find further detailed information about many
`of the topics discussed in the book. These details are not crucial to under—
`
`standing the concepts presented in the main body of the book; but for
`
`those who wish to learn more about the way crypto is used today, this
`appendix will offer interesting reading.
`Finally, the accompanying CD contains the RSA Labs Frequently
`Asked Questions (FAQ) about cryptography. The FAQ contains more
`
`detailed information about many of the concepts presented in this book.
`For instance, the FAQ describes much of the underlying math of crypto
`and the political issues surrounding export, and it offers a glossary and
`
`bibliography. Our goal in writing this book was to explain the crypto that
`
`the vast majority of you need to know. If you want more detail, start with
`
`the FAQ.
`
`
`
`About the Authors
`
`lege campuses.
`
`Stephen Paine Stephen Paine has worked in the security field
`throughout most of his career—formerly for the United States Marine
`Corps and SUN Microsystems. He is currently a systems engineer for
`RSA Security, where he explains security concepts to corporations and
`developers worldwide and provides training to customers and RSA
`employees.
`
`About the Reviewers
`
`Steve Burnett With degrees in math from Grinnell College in Iowa
`and The Claremont Graduate School in California, Steve Burnett has
`spent most of his career converting math into computer programs, first
`at Intergraph Corporation and now with RSA Security. He is currently
`the lead crypto engineer for RSA’s BSAFE Crypto-C and Crypto-J prod—
`ucts. which are general purpose crypto software development kits in C
`and Java. Burnett is also a frequent speaker at industry events and col-
`
`nical sales lead in the western division of a European security company.
`
`Blake Dournaee Blake Dournaee joined RSA Security’s developer sup-
`port team in 1999, specializing in Support and training for the BSAFE
`cryptography toolkits. Prior to joining RSA Security, he worked at NASA-
`Ames Research Center in their security development group. He has a 3.8.
`in Computer Science from California Polytechnic State University in San
`Luis Obispo and is currently a graduate student at the University of
`Massachusetts.
`'
`
`Jessica Nelson Jessica Nelson cemes from a strong background in com-
`
`puter security. As an officer in the United States Air Force, she spear-
`headed the 12 Air Force/Southern Command Defensive Information
`
`Warfare division. She built programs that integrated computer and com—
`munications security into the DoD’s Information Warfare. She graduated
`from UCSD with a degree in physics and has worked with such astro-
`physicists as Dr. Kim Griest and Dr. Sally Ride. She currently acts as tech-
`
`
`
`
`
`‘illccording to the afiidavit in support of the criminal complaint, the Secret
`Service began investigating this matter when it learned that there had
`been unauthorized access to [online brokerage] accounts ofseveral [anony-
`mous company] employees. One [anonymous company] employee told
`authorities that approximately $285, 000 had been drained from his
`[online brokerage] account when an unknown person was able to access his
`
`account by calling the online broker and providing a name and social secu«
`
`rity number. It was later determined that at least eight [anonymous com-
`pany] employees had been victimized this past spring, and that these eight
`had lost a total of$700, 000 from their stock accounts .
`.
`. [anonymous com~
`pany] officials revealed that while working in the financial department,
`[the accomplice] had access to confidential employee information such as
`social security numbers and home addresses. ”""
`
`If someone tells you, “I don’t need security. I have no secrets, nothing
`
`to hide,” respond by saying, “OK, let me see your medical files. How
`
`about your paycheck, bank statements, investment portfolio, and credit
`card Hills? Will you let me write down your Social Security number,
`
`
`
`
`
`*Source: US. Department ofJustice, July 20, 2000
`
`
`
`2
`
`Chapter 1
`
`credit card numbers, and bank account numbers? What’s the PIN for
`your ATM, credit card, or phone card? What’s your password to log on to
`the network at work? Where do you keep your spare house key?”
`The point is that we all have information we want kept private. Some-
`times the reason is simply our natural desire for privacy; we would feel
`uncomfortable if the whole world knew our medical history or financial
`details. Another good reason is self-protection—thieves could use some
`kinds of information to rob us. In other words, the motives for keeping a
`
`secret are not automatically nefarious.
`Corporations also have secrets—strategy reports, sales forecasts, tech-
`nical product details, research results, personnel
`files, and so on.
`Although dishonest companies might try to hide villainous activities from
`the public, most firms simply want to hide valuable information from dis-
`honest people. These people may be working for competitors, they might
`be larcenous employees, or they could be hackers and. crackers: people who
`break into computer networks to steal information, commit vandalism,
`disrupt service, or simply to show what they can do.
`
`Security Provided by Computer
`Operating Systems
`
`In the past, security was simply a matter of locking the door or storing
`files in a locked filing cabinet or safe. Today, paper is no longer the only
`medium of choice for housing information. Files are stored in computer
`databases as well as file cabinets. Hard drives and floppy disks hold many
`
`of our secrets. How do you lock a hard drive?
`
`How Operating Systems Work
`
`Before we talk about how computer data is protected, let‘s take a brief
`look at how computers get and store information. The usual way to access
`data on a computer or network is to go through the operating system (OS),
`such as DOS, Windows, Windows 95, Windows NT, MacOS, UNIX, Linux,
`Solaris, or HP/UX. The OS works like an application, taking input, per-
`forming operations based on the input, and returning output. Whereas, for
`
`
`
`
`
`Why Cryptography? 3
`
`example, a spreadsheet application takes the numbers you type into it,
`inserts them into cells, and possibly performs calculations such as adding
`columns, an OS takes your commands in the form of mouse clicks, joy-
`sticks, touch screens, or keyboard input-commands such as “Show a listing
`of the files in this directory”—and performs the request, such as printing
`to the screen a list of files. You can also ask the OS to launch a particular
`applicationwsay, a text editor. You then tell the text editor to Open a file.
`Behind the scenes, the editor actually asks the OS to find the file and
`make its contents available to the editor.
`
`Virtually all computers built today include some form of protection
`courtesy of the OS. Let’s take a look at how such protection works.
`
`Default OS Security: Permissions
`
`Virtually all operating systems have some built-in permissions, which
`
`allow only certain people access to the computer (its hard drive, memory,
`disk space, and network connection). Such access is implemented via a
`
`login procedure. If the user does not present the appropriate credentials
`
`(perhaps a user name and password), the US will not allow that individ-
`
`ual to use the computer. But even after a user is logged in, certain files
`may still be off-limits. If someone asks to see a file, the OS checks to see
`
`whether that requester is on the list of approved users; if not, the OS does
`
`not disclose the contents (see Figure 1-1).
`
`Access to most business computers and networks is controlled by some-
`
`one known as a superuser or system administrator (often shortened to sys
`admin). This system administrator is the person charged with creating
`
`and closing user accounts and maintaining the systems and network. A
`typical task of this superuser account is to override protections. Someone
`forgot a password? A file is read-protected (meaning that it cannot be
`opened and read)? The superuser has permission to circumvent the OS
`
`permissions to respond to these problems. (This is where the name “super-
`
`user” comes from; this individual can do anything.)
`
`How does the OS know that the person requesting such system over—
`
`rides is the superuser? The OS grants this access by user name and pass-
`word. The superuser user name is usually “so” or “me ” or “administrator.”
`
`Unfortunately, techniques for circumventing these default defenses are
`
`widely known.
`
`
`
`4
`
`Chapter 1
`
`
`
`Figure 1—1
`
`(a) In Windows
`NT, a file’s
`permission is
`given in its
`Properties screen.
`(b) In UNIX, you
`type ls -l to see a
`file’s permission
`
`
`
`
`
`mmaavltw
`
`car-9% ls -1
`total 216
`1 humans Bug
`-ruI-r--—r--
`1 hurnctts any
`-ru—r—Ar--
`1 hurnetts any
`-ru-r~-r“
`can-y: ell-ad 66h rthxt
`carryt 15 *1
`total 916
`we're-r"
`~ru—r—fir--
`~ra-r—-r--
`teary? I
`
`1 hurnetts eng
`1 burnttts tug
`1 hurnetts any
`
`93392 Feb 13 1mm rooms:
`2508 Feb 1a 10:!? rtflnpt.txt
`12321 rel: 13 1t“? rcflpwhtxt
`
`93392 Feb 13 1am rn-fi.txt
`25in Feb 13 1|:h7 ccoupt.tst
`12721 Feb 13 1mm refines-tht
`
`
`
`
`
`
`
`
`
`Attacks on Passwords
`
`Many computers or operating systems come with a preset superuser
`account and password. In many cases, several passwords are used for var-
`ious superuser functions. The superuser may have a password to create
`accounts, a different password to control network functionality, another to
`conduct or access nightly backups, and so on.
`
`
`
`
`
`
`
`Why Cryptography? 5m
`
`For a cracker, logging on to a system as the superuser is possibly the
`best way to collect data or do damage. If the superuser has not changed an
`operating system’s preprogrammed passwords, the network is vulnerable
`to attack. Most crackers know these passwords, and thei