_........
`
`. lie-airs ,.;'"'-II;-'_ .-.:'I
`
`.:
`
`.
`
`__
`
`_
`
`I
`
`_-.:.__
`
`.
`
`_
`
`.
`
`.Jr
`
`.._
`
`._
`
`.
`
`.
`
`:
`
`.L:I:~ :
`
`.1
`
`I.
`
`!_
`
`..
`
`l_ _.
`
`_
`
`It]
`
`
`
`Learn how secure data-encryption
`techniques work
`
`Protect cantidemlal information
`on yum netwark
`
`Get official current cryptography
`standards an enclosed CD-RDM
`
`Apple 1123
`Apple v. USR
`|PR2018—OO813
`
`Apple 1123
`Apple v. USR
`IPR2018-00813
`
`

`

`RSA Security’s
`Official Guide to
`Cryptography
`
`Steve Burnett and Stephen Paine
`
`Osborne/McGraW-Hill
`
`New York Chicago San Francisco
`Lisbon London Madrid Mexico City
`Milan New Delhi San Juan
`
`Seoul Singapore Sydney Toronto
`
`

`

`McGraw-Hill
`A Division olethcGraw-HillCompanies
`
`Z?
`
`Copyright © 200] by The McGraW—-I-Iill Companies. All rights reserved. Manufactured in the United States ofAmen'ca. Except as per-
`mitted under the United States 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 pn'or written permission of the publisher.
`
`()—()7—2 I 9225—9
`
`The material in this eBook also appears in the print version of this title10-07—213139-X.
`
`All trademarks are trademarks of their respective owners. Rather than put a trademark symbol after every occurrence of a trade-
`marked name. we use names in an editorial fashion only, and to the benefit of the trademark owner, with no intention of infringe—
`ment of the trademark. Where such designations appear in this book. they have been printed with initial caps.
`
`McGraw—Hill eBooks are available at special quantity discounts to use as premiums and sales promotions. or for use in corporate
`training programs. For more information. please contact George Hoare. Special Sales. at george_hoare@megraw—hillcom or (312)
`904-4069.
`
`TERMS OF USE
`
`This is a copyrighted w ork and The McGraw—l—Iill Companies. Inc. (“McGraw—Hill") and its licensors reserve all rights in and to the
`work. Use of this work is subject to these terms. Except as permitted under the Copyright Act of I976 and the right to store and
`retrieve one copy of the work. you may not decompile. disassemble. reverse engineer. reproduce, modify. create derivative works
`based upon. transmit, distnbute. disseminate. sell. publish or sublicense the work or any part of it without McGraw-Hill‘s prior con—
`sent. You may use the work for your own noncommercial and personal use; any other use of the work is strictly prohibited. Your
`right to use the work may be terminated if you fail to comply with these tenns.
`
`THE WORK IS PROVIDED “AS IS". McGRAW-HILL AND ITS LICENSORS MAKE NO GUARANTEES OR WARRANTIES
`AS TO THE ACCURACY. ADEQUACY OR COMPLETENESS OF ()R RESULTS TO BE OBTAINED FROM USING THE
`WORK, INCLUDING ANY INFORMATION THAT CAN BE ACCESSED THROUGH THE WORK VIA HYPERLINK OR
`OTHERWISE. AND EXPRESSLY DISCLAIM ANY WARRANTY. EXPRESS OR IMPLIED. INCLUDING BUT NOT LIMITED
`TO IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. McGraw-Hill and its
`licensors do not warrant or guarantee that the functions contained in the work will meet your requirements or that its operation will
`be uninterrupted or error free. Neither McGraw-I—Iill nor its licensors shall be liable to you or anyone else for any inaccuracy. error
`or omission, regardless of cause. in the work or for any damages resulting therefrom, McGraW-Hill has no responsibility for the con-
`tent of any information accessed through the work. Under no circumstances shall McGraw-l-Iill and/or its licensors be liable for any
`indirect, incidental. special. punitive. consequential or similar damages that result from the use of or inability to use the work, even
`if any of them has been advised ofthe possibility of such damages. This limitation ofliability shall apply to any claim or cause what-
`soever whether such claim or cause arises in contract. tort or otherwise.
`
`DOI: 10.1036/0072192259
`
`

`

`To Pao-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
`
`

`

`This page intentionally left blank.
`
`

`

`Contents
`
`Credlts
`Foreword
`
`Acknowledgments
`Preface
`About the Authors
`
`Chapter 1 Why Cryptography?
`
`Securlty Provrded by Computer Operatlng Systems
`How Operating Systems Work
`Default OS Security. Permrssrons
`Attacks on Passwords
`
`Attacks That Bypass Operatlng Systems
`Data Recovery Attack
`Memory Reconstructron Attack
`Added Protection Through Cryptography
`The Role of Cryptography in Data Security
`
`Chapter 2
`
`Symmetrlchey Cryptography
`
`Some Crypto Jargon
`What ls a Key?
`Why ls a Key Necessary?
`Generating a Key
`A Random Number Generator
`A PseudorRandom Number Generator
`
`Attacks on Encrypted Data
`A:tacklng the Key
`B eaking the Algorithm
`easunng the Tlme lt Takes to Break Your Message
`Symmetrlc Algorlthms: The Key Table
`
`Symmetrlc Algorlthms: Block Versus Stream Clphers
`B ock Crphers
`S ream Clphers
`Block Versus Stream: Whlch ls Better?
`
`
`
`Dlgl al Encryption Standard
`Triple DES
`Corrmercral DES Replacements
`
`Advanced Encryption Standard
`
`Copyright 2001 The McGraw-Hill Companies, Inc. Click Here for Terms of Use.
`
`Xlll
`xv
`
`XVlI
`XlX
`XXI]
`
`M~©OC>bLUMN
`
`U‘I
`
`l8
`20
`22
`22
`27
`
`28
`30
`30
`
`36
`37
`37
`
`38
`38
`4l
`
`45
`46
`47
`4C)
`
`

`

`Vl
`
`Contents
`
`Summary
`Real—World Example: Oracle Databases
`
`Chapter 3
`
`Symmetric—Key Management
`
`Password-Based Encryption
`Programming Convenience
`Breaking PBE
`Slowing Down an Attack on a Password
`Good Passwords
`Password Generators
`
`l'lardwareiBased Key Storage
`Tokens
`
`Crypto Accelerators
`Hardware Devices and Random Numbers
`Biometrics
`
`Summary
`RealeWorld Examples
`
`Keon Desktop
`Other Products
`
`El
`El
`
`53
`
`54
`
`59
`63
`64
`
`65
`67
`69
`69
`
`73
`75
`
`75
`76
`76
`77
`79
`
`Chapter 4
`
`The Key Distribution Problem and Public—Key Cryptography 8i
`
`Sharing Keys in Advance
`Problems With This Scheme
`
`Using a Trusted Third Party
`Problems With This Scheme
`
`Public—Key Cryptography and the Digital Envelope
`Security lssues
`Breaking a Publichey Algorithm
`Some History of Public-Key Cryptography
`How PubliceKey Cryptography Works
`The RSA Algorithm
`"he DH Algorithm
`"he ECDl—l Algorithm
`Comparing the Algorithms
`Security
`Key Sizes
`Performance
`TransmisSion Size
`
`
`
`Interoperability
`
`83
`84
`
`85
`86
`88
`9l
`92
`93
`94
`
`98
`lOS
`ill
`
`H7
`
`H7
`H9
`l2O
`l2?
`lZZ
`
`

`

`
`
`Contents V”
`
`122
`123
`124
`I26
`127
`130
`
`I32
`133
`
`I37
`
`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 Threshold Schemes
`How a Threshold Scheme Works
`
`Summary
`RealrWorId Example
`
`Chapter 5
`
`The Digital Signature
`
`The Uniqueness ofa Digital Signature
`Message Digests
`Collisions
`
`The Three Important Digest Algorithms
`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
`
`38
`4I
`45
`
`48
`49
`53
`54
`56
`59
`159
`6O
`61
`63
`
`63
`63
`64
`
`65
`
`65
`166
`66
`
`69
`69
`70
`
`
`
`Chapter 6
`
`PuinCrKey Infrastructures and the X509 Standard
`
`Publichey Certificates
`Unique Identifiers
`Standard Version 3 Certificate Extensions
`
`Entity Names
`
`171
`
`172
`174
`175
`
`177
`
`

`

`Vlll
`
`Contents
`
`79
`79
`8O
`80
`81
`82
`
`82
`84
`84
`
`H35
`86
`9O
`l90
`91
`
`92
`
`93
`
`95
`
`96
`97
`
`97
`98
`99
`200
`20l
`20l
`
`20l
`203
`204
`206
`206
`207
`207
`
`209
`
`209
`210
`2H
`2H
`2l2
`
`
`
`ASNl Notation and Encoding
`The Components of a PKl
`
`Certification Authority
`Registration Authority
`Certificate Directory
`Key Recovery Server
`Management Protocols
`Operational Protocols
`Registering and issuing Certificates
`Revoking a Certificate
`Certificate Revocation LISLS
`
`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
`
`Certificate PolICIes and Certification Practice Statements
`
`Summary
`Real~World Examples
`Keon Certificate Server
`Keon Web PassPort
`
`Chapter 7
`
`Network and Transport Security Protocols
`
`lnternet Protocol Security
`IP Security Architecture
`IPSec Services
`
`The Authentication Header Protocol
`
`Integrity Check Value Calculation
`
`

`

`
`
`Contents IX
`
`Transport and Tunnel Modes
`The Encapsulating Security Payload Protocol
`Encryption Algorithms
`ESP in Transport and Tunnel Modes
`
`Security Associations
`Combining Security Assooations
`Security Databases
`Security Policy Database
`Security Association Database
`Key Management
`Internet Key Exchange
`Secure Sockets Layer
`The History of SSL
`Session and Connection States
`
`"he Record Layer Protocol
`"he Change Cipher Spec Protocol
`“he Alert Protocol
`"he Handshake Protocol
`
`
`
`
`
`The Client Hello Message
`"he Server Hello Message
`"he Server Certificate Message
`The Server Key Exchange Message
`"he Certificate Request Message
`"he Server Hello Done Message
`"he Client Certificate Message
`The Client Key Exchange Message
`"he Certificate Verify Message
`"he Finished Message
`Ending a Session and Connection
`Resuming Sessions
`Cryptographic Computations
`Encryption and Authentication Algorithms
`Summary
`PealrWorld Examples
`
`Chapter 8
`
`Applicatioanayer Security Protocols
`
`S/MIME
`OverVievv
`
`S/MIME Functionality
`Cryptographic Algorithms
`
`2 l 3
`2 l 5
`2 l 6
`2 l 7
`
`2 l 8
`2 l 9
`220
`222
`222
`223
`224
`227
`227
`228
`
`230
`23l
`232
`233
`
`234
`235
`236
`236
`237
`237
`237
`238
`238
`2339
`239
`240
`240
`240
`24l
`242
`
`243
`
`243
`244
`
`245
`245
`
`

`

`Contents
`
`S/MlME Messages
`Enhanced Security Servrces
`interoperability
`Secure Electronic Transaction (SET)
`Business Requirements
`SE" Features
`
`247
`252
`253
`253
`254
`255
`
`256
`
`257
`258
`
`260
`264
`265
`
`
`
`SE“ Participants
`
`Dual Signatures
`SE‘ Certificates
`
`Payment Processing
`Sumrrary
`Real-World Examples
`
`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 Terminals
`
`JavaCards
`
`History and Standards
`JavaCard Operations
`Other Java Tokens
`
`Biometrics
`
`Biometric Systems Overview
`Recognition Methods
`Biometric Accuracy
`Combining Authentication Methods
`Summary
`Vendors
`
`Chapter 10 Digital Signatures: Beyond Security
`
`Legislative Approaches
`legal Guidelines from the American Bar Association
`Legal Concepts Related to Digital Signatures
`
`267
`269
`270
`
`270
`275
`275
`276
`
`276
`278
`
`279
`
`279
`280
`28i
`
`282
`
`282
`285
`288
`289
`291
`29l
`
`2933
`
`295
`295
`296
`
`

`

`
`
`Contents XI
`
`Nonrepudiation
`Authentication
`
`Written Versus Digital Signatures
`Requirements for the Use of Digital Signatures
`Public Key Infrastructures
`Control of Key Revocation
`TimeeStamping
`Current and Pending Legislation
`The ErSlGN Act
`
`Dealing with Legal Uncertainties
`Summary
`RealrWorld Examples
`
`Chapter 11 Doing It Wrong: The Break—ins
`
`Measuring Losses
`Types of Security Threats
`Jnauthorized Disclosure of Data
`
`296
`298
`
`299
`299
`300
`300
`300
`302
`303
`
`306
`307
`307
`
`309
`
`309
`3 0
`3
`l
`
`
`
`Jnauthorized Modification of Data
`Unauthorized Access
`Disclosure of Network Traffic
`
`Spoofing of Network Traffic
`Identifying lntruders
`nsiders
`-lacl<ers
`
`Terrorists
`
`Foreign lntclligence SerVices
`4actIVIsts
`
`ntruder Knowledge
`Case Studies
`Data in Transit
`Data at Rest
`Authentication
`
`
`
`mplementation
`information Security: Law Enforcement
`Summary
`
`Chapter 12 Doing It Right: Following Standards
`
`Security Services and Mechanisms
`Authentication
`
`l
`3
`3 2
`3 3
`
`3 4
`3 4
`3 S
`3 S
`
`3 l 5
`
`
`
`3 6
`3 6
`
`3 7
`3 7
`3 7
`3 l 8
`3 9
`
`320
`32l
`322
`
`323
`
`324
`324
`
`

`

`Contents
`Xll
`
`Confidentiality
`integrity
`Nonrepudiation
`Standards, Guidelines, and Regulations
`The Internet Engineering Task Force
`ANSl X9
`
`National Institute of Standards and Technology
`Common Criteria
`
`The Health Insurance Portability Act
`DeveloperAssistance
`insurance
`
`Security Research
`Case Studies
`
`Implementation
`Authentication
`Data at Rest
`Data in TranSit
`
`Summary
`
`Appendix A Bits, Bytes,
`
`l-lex, and ABC”
`
`Appendix B A Layman’s Guide to a Subset ofASN. l, BER, and DER
`
`Appendix C Further Technical Details
`
`Index
`
`326
`326
`327
`
`327
`327
`328
`328
`330
`
`330
`33l
`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 CAB—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.
`
`Copyright 2001 The McGraw-Hill Companies, Inc. Click Here for Terms of Use.
`
`

`

`This page intentionally left blank.
`
`

`

`CHAPTER
`
`Symmetric-Key
`Management
`
`Symmetric-key encryption can keep your secrets safe, but because you need
`your keys to recover encrypted data, you must also keep them safe. The
`process ofkeeping all your keys safe and available for use is known as key
`management. This chapter is about managing symmetric keys.
`In Chapter 2, “Symmetric—Key Cryptography,” Pao-Chi generated a
`random or pseudo—random key, and used it to encrypt data. If he wants to
`decrypt the data, he must use the same key. This means he has to either
`memorize the key or store it somewhere. Memorizing it isn’t practical, so
`he must store it so that he can recall it when he wants to, but no one else
`
`can. Right now you’re probably asking, “If there’s some place Pao-Chi can
`keep his key safe, why doesn’t he just put his sensitive information there
`as well?” The answer is that it’s easier to protect a small key than many
`
`megabytes worth of information. In fact, some of the key storage solu—
`tions you’ll see in this chapter are small devices designed in part to pro-
`tect keys. So the idea is to use symmetric-key crypto to protect the
`megabytes of information and some other technique to protect the 16
`bytes (or so) of keys.
`
`Copyright 2001 The MCGraw-Hill Companies, Inc. Click Here for Terms of Use.
`
`

`

`
`
`54 Chapter 3
`
`Password-Based Encryption
`
`The key used to encrypt the megabytes of information, or bulk data, is
`generally known as the session key. A session is simply an instance of
`encryption, possibly during an email exchange, a World Wide Web con-
`nection, or a database storage. In Pao-Chi’s case, a session involves
`
`encrypting a file before storing it on his hard drive. Some systems gener—
`ate a new key for each session; others use the same key from session to
`session. One way to store the session key securely is to encrypt it using a
`symmetric-key algorithm. Someone who finds the session key has really
`found the encrypted key. The attacker would have to break the encryption
`to get the key that protects the megabytes of information. Of course, the
`process of encrypting the session key itself needs a key. That is, the key
`needs a key. There’s the session key and then the key encryption key, as
`shown in Figure 3-1. In the crypto literature, not surprisingly, the latter is
`often known as the KEK.
`
`You may be thinking that if Pao—Chi uses a KEK, he now has to store
`and protect it as well. Actually, he does not store the KEK, and therefore
`does not need to protect it. When he needs a KEK to encrypt, Pao—Chi will
`generate it, use it, and then throw it away. When he needs to decrypt the
`data, he generates the KEK again, uses it, and throws it away. He is able
`to generate the KEK a second time and produce the same value as before
`
`because it is based on a password. Pao-Chi uses an RNG or PRNG to gen—
`
`
`
`Session key
`
`Figure 3-1
`
`A session key
`protects data, and
`a key encryption
`key (KEK)
`protects the
`session key
`
`
`
`Protected
`key
`
`
`
`
`
`
`
`
`Regular
`encrypt
`engine
`
`

`

`
`
`SymmetricKey Management 5 5
`
`erate a session key, he uses password-based encryption (PBE) to build the
`KEK. It usually works like this (see Figure 3-2).
`
`1. Enter the password.
`
`2. Use an RNG or PRNG to generate a salt.
`
`NOTE:
`What’s a salt? We describe the salt and its purpose in a few paragraphs.
`
`3. Using a mixing algorithm, blend the salt and password together. In
`most cases, the mixing algorithm is a message digest. And that’s the
`second time we’ve mentioned this tool—the message digest. The first
`time was in discussing PRNGs. Remember, a digest is a blender,
`
`taking recognizable data and mixing it up into an unrecognizable
`blob. We’ll talk more about message digests in Chapter 5.
`
`4. The result of step 3 is a bunch of bits that look random. Take as many
`of those bits as needed for the KEK and use it with a symmetric-key
`
`algorithm to encrypt the session key. When the session key has been
`encrypted, throw away the KEK and the password. Save the salt.
`
`5. When storing the now encrypted session key, be sure to store the salt
`along with it. It is necessary to decrypt.
`
`When it comes time to decrypt the data, here’s the process.
`
`1. Enter the password.
`
`2. Collect the salt. The same salt used to encrypt is required (that’s why
`
`you saved it with the encrypted session key).
`
`3. Using the same mixing algorithm used to encrypt, blend the salt and
`password together. If one or more of the salt, password, or mixing
`algorithm is different, the result will be a KEK; however, it will be the
`wrong KEK. If all three elements are the same, the result is the
`correct KEK.
`
`4. Use this KEK from step 3 along with the appropriate symmetric-key
`algorithm to decrypt the session key.
`
`You probably have four questions.
`
`

`

`
`
`56 Chapter 3
`
`Password
`rLI-l -'|‘|_ if 1",.
`
`salt
`
`Figure 3-2
`
`In password-
`based encryption
`(PBE), (1) blend
`the password and
`the salt to form a
`KEK and then (2)
`use it to encrypt
`the session key.
`To decrypt the
`data, use the
`same password
`and salt
`
`
`
`
`KEK: 3F08CD55...
`
`(7)
`
`r3 “F
`
`
`Session
`Encrypt
`Key
`engine
`
`Mixing Algorithms and KEK
`
`Why use a mixing algorithm? Why notjust use the password as the KEK?
`A password does not have much entropy. Recall from Chapter 2 that
`entropy is the measure of randomness. But a password is made up
`entirely of keystrokes (characters associated with the keys on a key-
`board), which are not sufficiently chaotic. Using a mixing algorithm on the
`password (and salt) ensures that the KEK looks random.
`
`

`

`
`Symmetric—Key Management 5 7
`
`
`The Necessity of Salt
`
`Why is a salt needed in the first place?
`The salt is there to prevent precomputations. If the password were the
`only thing used to generate the KEK, an attacker could create a dictionary
`of common passwords and their associated keys. Then a brute force attack
`would not be necessary; the attacker would try only the precornputed keys
`(logically enough, this is called a dictionary attack). With a salt, the
`attacker must wait until seeing the salt before finding the KEK any par-
`
`ticular password produces (see Figure 3—3).
`
`N0 Salt
`
`With Salt
`
`Figure 3-3
`
`Using a salt foils
`a dictionary
`
`attack
`
`
`
`The same passwords don't produce the same keys
`
`eagle—>273D1148F6
`Ogégdfgzggiiifi
`
`eagle + sah[l]—>3B442CEA1A
`eagle + salt[2]—->8702B45CD5
`
`eagle + salt! I .()00.()()()]—>SB l ()1 82CA4
`
`

`

`58
`
`
`Chapter 3
`
`Storing Salt with Ciphertext
`
`If the salt is stored with the Ciphertext, then won’t the attacker be able to
`see it? Wouldn’t it be safer to keep the salt secret?
`As just explained, a salt’s only purpose is to prevent precomputations.
`That’s worth repeating: the salt does not add security; it only prevents a
`dictionary attack. Even though the salt is not secret, it achieves that goal.
`Besides, if the salt is secret, how is it recovered when needed?
`
`Reasons for Using Two Keys, a Session Key, and KEK
`
`Wouldn’t it be easier to simply use PBE to encrypt the bulk data? Why is
`it necessary to have two keys (the session key and the KEK)?
`
`There are a couple of reasons to use a session key and a KEK. First,
`suppose you need to share the data with other people and you want to
`keep it stored encrypted. In that case, you generate one session key, and
`everyone gets a copy of it. Then everyone protects his or her copy of the
`session key using PBE. So rather than share a password (something
`everyone would need for decrypting if you had used PBE to encrypt the
`bulk data), you share the key (see Figure 3-4).
`
`The second reason for using both keys is that it’s easier to break a pass—
`word than to break a key (more on this soon), and attackers might have
`easier access to the encrypted data than to the encrypted key. For
`instance, suppose Pao—Chi’s data is on the network and the encrypted ses-
`
`sion key (the value encrypted by PBE using the KEK) is on his own per—
`sonal computer (or other storage facility). Suppose Ray, an attacker,
`breaks into the network and steals the encrypted bulk data. To decrypt,
`Ray would have to break the session key or else perform a second break
`
`in (possibly into a more secure location) to find the encrypted session key
`and then break the password. Alternatively, if Pao—Chi used PBE to pro—
`tect the data, Ray can recover the information by breaking the password
`(see Figure 3-5).
`
`Of course, it is possible to use PBE to do the bulk encryption. In this
`book we don’t discuss that option. From a programming point of View, it’s
`not much more difficult to use a session key and then PBE to encrypt the
`session key, so you might as well because of the reasons given.
`
`

`

`
`
`Symmetric—Key Management 5 9
`
`Figure 3-4
`
`Using a session
`key for bulk data
`and protecting it
`with PBE means
`that users don’t
`have to share
`
`passwords
`
`
`
`Pao-Chi’s password
`
`F'I'l} :Ilyim:
`
`
`El
`lKl'K
`
`.
`
`3"-
`
`Gwcn‘s password
`
`1
`
`Programming Convenience
`
`A PBE program will do its work, even with the wrong password. Suppose
`the wrong password were entered, the program would have no way of
`knowing it was an incorrect password. It would simply mix the “bad” value
`with the salt and produce a KEK. It wouldn’t be the correct KEK, but the
`
`

`

`60
`
`Chapter 3
`
`Figure 3-5
`
`If Pao-Chi uses
`
` -\ p1
`
`Salt
`
`
`
` Session
`
`. Ray
`‘ allac ks
`password
`
`PBE to protect
`bulk data, Ray
`can recover it by
`breaking the
`password. If Pao-
`Chi uses PBE to
`
`protect the
`session key, Ray
`must find the
`
`encrypted key
`
`
`
`Ray has to find the PBE
`protected session key to
`attack the password
`
`
`
`
`
`t!
`
`Ray
`__ attacks
`session key
`
`engine
`
`Encrypt
`
`program wouldn’t know that; it just blindly follows instructions. It would
`
`then use that KEK to decrypt the session key. That would work; some
`value would come out as a result. It would be the wrong value, but there
`would be something there. Then the program would use this supposed ses—
`sion key to decrypt the ciphertext. The resulting data would be gibberish,
`but only then would it be possible to see that something went wrong.
`
`

`

`
`
`Symmetrichey Management 6 1
`
`For this reason, it would have been more convenient if, when entering
`the password, there were some way to know immediately whether it’s the
`correct password or not. That would be better than decrypting the entire
`bulk data before finding that out.
`
`One solution is to use the KEK to encrypt the session key along with
`something else, the “something else” being some recognizable value, such
`as the salt. Then when decrypting, the program checks this recognizable
`value first. If it’s correct, continue using the session key to decrypt the bulk
`data. If not, the password was wrong and the process should start over.
`The overall process looks like this. To encrypt bulk data:
`
`1. Generate a random or pseudo—random session key. Use this key to
`encrypt the data.
`
`2. Enter the password, generate a salt, and mix the two together to
`produce the KEK.
`
`3. Encrypt the salt and session key using the KEK. Store the encrypted
`data with the salt.
`
`4. Store the encrypted session key, which is actually the session key and
`the salt (see Figure 3-6).
`
`To decrypt the data, follow these steps.
`
`1. Collect the salt and password and mix the two together to produce
`what is presumably the KEK.
`
`2. Using this KEK, decrypt the session key. The result is really the
`session key and the salt.
`
`3. Check the decrypted salt. Is it correct?
`
`a.
`
`b.
`
`If it is not correct, don’t bother using the generated session key to
`decrypt the data; it’s not the correct value. The user probably
`entered the wrong password. Go back to step 1.
`lfit is correct, use the session key to decrypt the data.
`
`Instead of the salt, you can use a number of things as a check. For
`example, it could be an eight—byte number, the first four bytes being a ran-
`dom value and the second four, that random value plus 1. When decrypt—
`ing, check the first eight bytes; if the second four bytes is the first four plus
`1, it’s the correct password. This may be more palatable than the salt,
`since if the salt is the check, there is now some known plaintext. Presum-
`ably, the cipher is immune to a known—plaintext attack, but nonetheless,
`
`

`

`
`
`62 Chapter 3
`
`Figure 3-6
`
`Use a KEK to
`
`encrypt the
`session key along
`with a
`
`recognizable
`value such as the
`
`salt. Entering the
`wrong password
`produces the
`wrong KEK/salt
`combination
`
` PBE Encrypt engine
`
`1
`
`
`E;
`Session key
`
`engine
`
`Protected key
`and salt
`
`Protected key
`and salt
`
`engine
`
`'1
`'
`Sessmn key_
`
`some people might feel it is more secure without any known plaintext. Of
`course, it is possible to use the wrong password and get a KEK that
`decrypts the check into a different eight—byte value that by sheer coinci-
`dence passes the test. The chances of this happening are so small, it will
`probably never happen in a million years.
`
`Another check could be an algorithm identifier. This would be some
`sequence of bytes that represents the algorithm being used. Or it could be
`
`a combination of some of these values. In the real world, you’ll probably
`find that engineers come up with complex procedures that include mul-
`tiple checks. In these schemes, maybe one check accidentally passes, but
`not all of them.
`
`

`

`
`
` Symmetric—Key Management 63
`
`Breaking PBE
`
`Our attacker (who we’re calling Ray) has two ways to break PBE. First, he
`could break it like any symmetric—key encryption and use brute-force on
`the KEK. Second, he could figure out what the password is.
`Although the KEK is the result of mixing together the password and
`salt, Ray doesn’t have to bother with those things; he could simply perform
`a brute-force attack on the KEK, use it to decrypt the session key, and then
`
`decrypt the data. This might be plausible if the session key is larger than
`the KEK. In Chapter 2, though, we saw that if a key is large enough, that’s
`not going to happen. Hence, Ray will probably try the second way, which
`is to figure out what the password is. Once he has the password, he can
`reconstruct the key-generating process and have the KEK.
`How can Ray figure out what the password is? One way would be to try
`every possible keystroke combination. This would be another flavor of the
`brute-force attack. If Pao-Chi entered the password from the keyboard,
`
`Ray could try every possible one-character password. Then he would try
`every two—character combination (AA, AB, AC, AD,
`.
`.
`. ), then three-char-
`acter values, and so on. In this way, eight-character or less passwords (on
`a keyboard with 96 possible values) would be approximately equivalent to
`a 52-bit key. Ten-character passwords are equivalent to about 65-bit keys.
`Another attack is for Ray to build up a dictionary of likely passwords,
`such as every word in the English, German, French, and Spanish lan—
`guages, along with common names, easy-to-type letter combinations, such
`as “qwertyuiop.” He could add to that dictionary lists of common pass-
`words that are available from hacker sites and bulletin boards (if you’ve
`
`thought of a password, someone else probably thought of it also). When
`confronted with PBE, he runs through the dictionary. For each entry, he
`mixes it with the salt and generates an alleged KEK. He tries that KEK
`on the chunk of PB-encrypted data. Did it produce the session key?
`Because the original PBE probably has a check in it (such as the salt
`encrypted along with the session key), it’s probably easy to determine. If
`the check passes, that was the correct password and it produced the cor-
`rect KEK, which in turn will properly decrypt the session key, which will
`then decrypt the bulk data.
`This dictionary attack tries fewer passwords than does the brute force
`attack. Any password the dictionary attack tries, the brute force attack
`also tries, but the brute-force attack tries many additional passwords that
`the dictionary attack does not. As a result, the dictionary attack is faster
`than the brute force attack.
`
`

`

`
`
`64 Chapter 3
`
`Of course, if Pao—Chi comes up with a password not in Ray’s dictionary,
`it Will never succeed. If Ray is smart, he’ll probably start with a dictionary
`attack and if that fails, move on to a modified brute-force attack.
`
`Slowing Down an Attack on a Password
`
`To check a password, Ray has to mix the salt and password the same way
`Pao—Chi did. Pao-Chi can slow Ray down by making that a lengthy task.
`His goal will be to make the process quick enough that it doesn’t make his
`
`own encryption or decryption process too expensive, but slow enough to be
`a drain on Ray. He can do this by repeating the mixing over and over.
`First, mix the salt and password together. Then take the result of that
`and run it through the blender again. Then take the result of that and run
`it through the blender. And on and on, say 1,000 times.
`
`The blender is probably pretty fast, the mixing is almost certainly
`done with a message digest, and these algorithms are generally very fast,
`so for Pao—Chi to do 1,000 iterations of the mixing process won’t be too
`time-consuming. In fact entering a password is going to be far more time-
`consuming than 1,000 mixings. So relatively speaking, for Pao—Chi, the
`
`mixing takes up a very small portion of the total time. But Ray is going
`to have to do 1,000 mixings for every password he tries. That can add up.
`Let’s say Pao—Chi has an eight-character password. In an earlier section
`
`we said that an eight-character password is equivalent to a 52-bit key. But
`actually, Ray cannot try one password as quickly as one key. If he tries the
`brute-force attack on a key, here’s the process (BFK stands for “brute-force
`on the key”):
`
`BFK1 Get a candidate key.
`
`BFK2 Do key setup (recall the key table from Chapter 2).
`
`BFK3 Decrypt some ciphertext, yielding some purported
`plaintext.
`
`BFK4 Check the plaintext.
`
`But for each password Ray checks, on the other hand, here’s the process
`(BFP stands for “brute—force on the password”):
`
`BFPl Get a candidate password.
`
`BFP2
`
`Perform the mixing to build the candidate key.
`
`BFP3
`
`Do key setup.
`
`

`

`
`
`Symmetrichey Management 65
`
`BFB4 Decrypt the ciphertext, yielding the purported check and
`session key.
`
`BFB5
`
`Perform the check.
`
`How long it takes to do one BFK depends on four things. How long it
`takes to do one BFP depends on those same four things, plus one more. If
`step BFP2 is as long as the other four steps combined, that’s going to dou—
`ble the amount of time to check one password. That’s like adding one bit
`
`to your password. The eight—character password which was equivalent to
`a 52-bit key is now more like a 53—bit key.
`In our experiments, performing 1,000 iterations (doing step BFP2 1,000
`times) is about 136 times slower than the other steps combined (more or
`
`less, depending on the encryption algorithm; we used RC4, a very fast
`algorithm). On one Pentium-based PC, step BFP2 took 4.36 milliseconds,
`whereas checking one key took 0.032 milliseconds (a millisecond is “one
`one-thousandth” of a second; Pao-Chi is going to pay this 4 millisecond
`
`penalty when he encrypts or decrypts). Although Ray could check 31,000
`keys per second, he could check only 230 passwords per second. The eight-
`character password is now equivalent to a 59-bit key. The 10-character
`password is more like a 72-bit key.
`Incidentally, you may be thinking, “In a lot of places I’ve used pass-
`words, t