RSA BSAFE Security Concepts 1.6 - EMC Community Network

RSA BSAFE ® Security Concepts1.6

Copyright and TrademarkNotice and TrademarksCopyright © 2010 EMC Corporation. All rights reserved. EMC, RSA, the RSA logo, and BSAFE are registered trademarksof EMC Corporation in the United States and/or other countries. All other products and services mentioned are trademarks oftheir respective companies. For the most up-to-date listing of EMC trademarks, go to www.emc.com/legal/emc-corporation-trademarks.htm.License agreementThis software and the associated documentation are proprietary and confidential to EMC, are furnished under license, andmay be used and copied only in accordance with the terms of such license and with the inclusion of the copyright noticeabove. This software and the documentation, and any copies thereof, may not be provided or otherwise made available to anyother person.No title to or ownership of the software or documentation or any intellectual property rights thereto is hereby transferred. Anyunauthorized use or reproduction of this software and the documentation may be subject to civil and/or criminal liability.This software is subject to change without notice and should not be construed as a commitment by EMC.Note on encryption technologiesThis product may contain encryption technology. Many countries prohibit or restrict the use, import, or export of encryptiontechnologies, and current use, import, and export regulations should be followed when using, importing or exporting thisproduct.DisclaimerEMC believes the information in this publication is accurate as of its publication date. The information is subject to changewithout notice. THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” EMC CORPORATION MAKESNO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THISPUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESSFOR A PARTICULAR PURPOSE.DistributionLimit distribution of this document to trusted personnel.Part Number8.10.10

RSA BSAFE Security ConceptsContentsPreface.................................................................................................................................... 7Document Organization ...................................................................................................... 8RSA Support and Service ................................................................................................... 8Chapter 1: Introduction to Cryptography................................................................ 9Uses of Cryptography ....................................................................................................... 10Access Control........................................................................................................... 10Authentication............................................................................................................ 10Non-repudiation..........................................................................................................11Data Confidentiality....................................................................................................11Data Integrity ..............................................................................................................11Cryptographic Terminology...............................................................................................11Chapter 2: Symmetric Key Cryptography ............................................................. 13About Symmetric Key Cryptography ............................................................................... 14Block Ciphers.................................................................................................................... 14Modes of Operation ................................................................................................... 15Data Encryption Standard.......................................................................................... 20Triple DES ................................................................................................................. 21Advanced Encryption Standard ................................................................................. 21RC2 ............................................................................................................................ 22RC5 ............................................................................................................................ 22Stream Ciphers..................................................................................................................23RC4 ............................................................................................................................ 24Password-based Encryption .............................................................................................. 25Chapter 3: Asymmetric Key Cryptography .......................................................... 27Encryption and Decryption ............................................................................................... 28Signing and Verifying....................................................................................................... 29The RSA Algorithm.......................................................................................................... 30Encryption Using the RSA Algorithm....................................................................... 30Signing Using the RSA Algorithm ............................................................................ 30Selecting Parameters.................................................................................................. 31Digital Envelopes....................................................................................................... 31Contents 3

RSA BSAFE Security ConceptsDigital Signature Algorithm.............................................................................................. 32RSA Algorithm and DSA Compared......................................................................... 32Elliptic Curve Cryptography............................................................................................. 33Elliptic Curve Digital Signature Algorithm............................................................... 33Elliptic Curve Integrated Encryption Scheme ........................................................... 33Elliptic Curve Cryptography Standards..................................................................... 34Chapter 4: Key Operations .......................................................................................... 35Diffie-Hellman Key Exchange.......................................................................................... 36Parameter Generation ................................................................................................ 36Phase 1 ....................................................................................................................... 36Phase 2 ....................................................................................................................... 36Security ...................................................................................................................... 37Multiple Party Key Exchange.................................................................................... 37Elliptic Curve Diffie-Hellman ................................................................................... 38Key Wrapping................................................................................................................... 38AES Key Wrapping ................................................................................................... 38Chapter 5: Digests, Digital Signatures and MACs ............................................ 41Message Digests................................................................................................................ 42Message Digest Algorithms....................................................................................... 42Digital Signatures..............................................................................................................43Message Authentication Codes......................................................................................... 44Chapter 6: Random Number Generation ............................................................... 47Seeding.............................................................................................................................. 48Dual EC DRBG................................................................................................................. 49HMAC DRBG................................................................................................................... 49FIPS 186-2 RNG............................................................................................................... 50Chapter 7: Base64 Encoding ...................................................................................... 51Converting Binary Data to Base64 ................................................................................... 52Base 64 Encoding Example ....................................................................................... 53Base64 Decoding ....................................................................................................... 54Base64 Variations ...................................................................................................... 54Chapter 8: Public Key Infrastructure and Certificates .................................... 57Trusted Authorities ........................................................................................................... 58Digital Certificates ............................................................................................................58X.509 Certificates ...................................................................................................... 58Extended Validation Certificates ............................................................................... 594 Contents

RSA BSAFE Security ConceptsWTLS Certificates ..................................................................................................... 60Attribute Certificates.................................................................................................. 60Certification Authorities ................................................................................................... 60Registration Authority ............................................................................................... 60Certificate Server ....................................................................................................... 61Certificate Repository ................................................................................................ 61Certificate Revocation....................................................................................................... 61Certificate Revocation Lists....................................................................................... 61Online Certificate Status Protocol ............................................................................. 62Certificate Chains..............................................................................................................62Self-signed Certificates.............................................................................................. 63Certificate Validation........................................................................................................ 64Certificate Chain Validation Example....................................................................... 64Certificate Store ......................................................................................................... 65Certificate Extensions ....................................................................................................... 66Key and Policy Information Extensions .................................................................... 67Subject and Issuer Information Extensions ............................................................... 67Certification Path Constraints Extensions ................................................................. 67Certificate Requests .......................................................................................................... 68Chapter 9: Transport Layer Security....................................................................... 69SSL and TLS Development .............................................................................................. 70TLS Protocols ...................................................................................................................70Handshake Protocol ................................................................................................... 71Record Protocol ......................................................................................................... 74Alert Protocol............................................................................................................. 75Change Cipher Spec Protocol .................................................................................... 76TLS Renegotiation Vulnerability...................................................................................... 76Insecure Connections and Renegotiations ................................................................. 77Chapter 10: NSA Suite B Cryptography................................................................. 79Security Strength...............................................................................................................80Specified Cryptographic Algorithms ................................................................................ 81Certificate Chain Validation ............................................................................................. 82Transport Layer Security and Cipher Suites ..................................................................... 83Appendix A: Public Key Cryptography Standards ........................................... 85PKCS #1............................................................................................................................ 86PKCS #3............................................................................................................................ 86PKCS #5............................................................................................................................ 87PKCS #6............................................................................................................................ 87Contents 5

RSA BSAFE Security ConceptsPKCS #7............................................................................................................................ 87Digital Envelope ........................................................................................................ 88Streaming/Standard Implementations........................................................................ 88Attributes ................................................................................................................... 89PKCS #8............................................................................................................................ 90PKCS #9............................................................................................................................ 90PKCS #10.......................................................................................................................... 90PKCS #11.......................................................................................................................... 90General Model ........................................................................................................... 91Session Operations..................................................................................................... 91PKCS #12.......................................................................................................................... 92Exchange Modes........................................................................................................ 92PKCS #13.......................................................................................................................... 93PKCS #14.......................................................................................................................... 93PKCS #15.......................................................................................................................... 93Appendix B: Recommended Reading..................................................................... 95Glossary ............................................................................................................................. 101Index .....................................................................................................................................1196 Contents

RSA BSAFE Security ConceptsPrefaceThis document describes the security concepts involved with cryptography, includingterminology, cryptographic algorithms, certificates, and Public Key CryptographyStandards (PKCS). The guide is intended for those with little or no cryptographicexperience.Topics:• Document Organization• RSA Support and ServicePreface 7

RSA BSAFE Security ConceptsDocument OrganizationThis guide is organized into the following chapters and appendixes:• Chapter 1 Introduction to Cryptography. Explains some prerequisitecryptographic concepts and terms.• Chapter 2 Symmetric Key Cryptography. Describes symmetric key cryptography,where the same secret key is used for an encryption and decryption operation.• Chapter 3 Asymmetric Key Cryptography. Describes asymmetric keycryptography, where a public/private key pair is used for an encryption anddecryption operation.• Chapter 4 Key Operations. Describes Diffie-Hellman key exchange and keywrapping.• Chapter 5 Digests, Digital Signatures and MACs. Describes message digests,digital signatures and Message Authentication Codes (MACs), which can provideauthentication, data integrity, or non-repudiation.• Chapter 8 Public Key Infrastructure and Certificates. Describes the role of aPublic Key Infrastructure (PKI) and how certificates are managed.• Chapter 6 Random Number Generation. Describes seeding a Pseudo-RandomNumber Generator (PRNG), and outlines three PRNGs.• Chapter 9 Transport Layer Security. Describes the Transport Layer Security(TLS) and Secure Socket Layer (SSL) protocols to provide secure datacommunications across open networks.• Appendix A Public Key Cryptography Standards. Lists and describes the PublicKey Cryptography Standards.• Appendix B Recommended Reading. Lists sources of recommended reading on avariety of cryptographic topics.RSA Support and ServiceAccess these locations for help with your RSA product.RSA SecurCare OnlineCustomer Support InformationRSA Secured Partner Solutions Directoryhttps://knowledge.rsasecurity.comwww.rsa.com/supportwww.rsasecured.com8 Preface

RSA BSAFE Security Concepts1 Introductionto CryptographyThe field of cryptography uses many terms, abbreviations, concepts that might beconfusing for newcomers. This chapter explains some of these prerequisitecryptographic terms, abbreviations, and concepts, which are then used throughout therest of the guide.Topics:• Uses of Cryptography• Cryptographic TerminologyChapter 1: Introduction to Cryptography 9

RSA BSAFE Security ConceptsUses of CryptographyAccess ControlAuthenticationCryptography is a mechanism for securing data, specifically data that is transmittedacross an open channel. Historically, privacy was the main use of cryptography.Messages were concealed or altered in some way before delivery, with the recipient ofthe message knowing how to decipher the concealed message.Today, cryptography is a critical technology ensuring data privacy in business andgovernment applications. The different cryptographic methods available provide thefollowing functionality:• Access control• Authentication• Non-repudiation• Data confidentiality• Data integrity.To help understand this functionality, consider the example of a bank that provideson-line Internet access for its customers.Access control ensures only authorized personnel or devices are allowed access toresources. Role-based access control provides different levels of access so authorizedusers can only perform operations on resources for which they are authorized.In the banking example, access control allows a bank customer to access the bank’sWeb site to perform banking operations such as bill payments, transfers betweenaccounts, and balance enquiries. However, the customer cannot modify the Web sitebecause their access role is user, not administrator.Authentication is about confirming the identity of communicating entities. That is, itensures the communicating entities are who they say they are. Authentication providesassurance that an entity is not masquerading as another replaying a previouscommunication.In the banking example, authentication ensures the entity logged on to the bankingsystem really is the customer they are purporting to be.10 Chapter 1: Introduction to Cryptography

RSA BSAFE Security ConceptsNon-repudiationData ConfidentialityData IntegrityNon-repudiation prevents an entity from denying having performed an action. Itprovides proof of network-related actions, such as proof of obligation, intent,commitment, data origin, ownership, or resource use. Non-repudiation ensuresevidence can be presented to third-parties to prove an event took place.In the banking example, non-repudiation commits a banking customer to thetransactions they perform on the bank’s Web site.Data confidentiality protects data from unauthorized disclosure. It ensures datacontent cannot be accessed or understood by unauthorized entities. Encryption, accesscontrol lists, and file permissions are example methods of providing dataconfidentiality.In the banking example, data confidentiality ensures encrypted communicationsbetween a bank and a customer remains confidential, even if the communications areintercepted by other entities.Data integrity ensures the correctness or accuracy of data. Data is protected againstunauthorized modification, deletion, creation, and replication and provides anindication of these unauthorized activities.In the banking example, data integrity ensures transactions remain unaltered.Cryptographic TerminologyThere are many terms used in cryptography. The following is a list of some of themajor ones, which are discussed in more detail throughout the rest of the document:• Plaintext. The data or message to be concealed. Also known as cleartext.• Ciphertext. The concealed data or message.• Encryption. The transformation of plaintext into ciphertext.• Decryption. The transformation of ciphertext into plaintext.• Algorithm. A named mathematical procedure to encrypt or decrypt data. Differentalgorithms have different characteristics, and are used in different situations. Alsoknown as a cipher.• Key. A modifier used in conjunction with an algorithm to encrypt or decrypt data.Different kinds of keys are used depending on the algorithm.The following diagram illustrates using an encryption algorithm with a key toencrypt plaintext into ciphertext.Chapter 1: Introduction to Cryptography 11

RSA BSAFE Security ConceptsFigure 1EncryptionKeyDear Bob,Thank you for youre-mail regarding RSAsoftware. Enclosed arethe brochures asrequested.Regards,EncryptionAlgorithm101010011001101001101010101100010100110101010101011010101011110101101100101101100110101101101101101001011110001011010101101010101010111000101101110110100100001110011010100PlaintextCiphertext• Cryptographic strength. The amount of security provided by an algorithm with aspecific key. Generally, the larger the key size, the greater the cryptographicstrength. Also, some types of algorithms have greater cryptographic strength thanothers.• Attacker. A malicious entity whose aim is to break a part or all of a cryptographicsystem, including data confidentiality, authentication, access control, integrity,non-repudiation, or availability of data.• Attack. A method by which an attacker attempts to compromise an algorithm. Forexample, a brute force attack is where an attacker systematically tries all possiblekeys in an attempt to decrypt a message.• Vulnerability. A weakness in an algorithm attackers can potentially exploit.• Pseudo-random number generator (PRNG). An algorithm that produces a seriesof numbers that appear to be random, based on a number input to the algorithm(the seed). The numbers are not truly random because the same seed produces thesame series of pseudo-random numbers. Pseudo-random numbers are used togenerate keys and Initialization Vectors (IVs, which are inputs to some kinds ofalgorithms).• Entropy. The degree of disorder or randomness in a system. Entropy from asystem is used to seed PRNGs. The greater the entropy, the more random theoutput from a PRNG. Poor entropy is the weak link in many cryptographicapplications.For a complete list of terms and concepts used in cryptography, see the Glossary.12 Chapter 1: Introduction to Cryptography

RSA BSAFE Security Concepts2 SymmetricKey CryptographyIt is called symmetric key cryptography because the same key must be used incorresponding encryption and decryption operations.This chapter provides an overview of symmetric key cryptography, including the twotypes of symmetric key algorithms (block ciphers and stream ciphers) andpassword-based encryption (a method of deriving a symmetric key from a suppliedpassword, and then optionally performing an encryption operation with that key).Topics:• About Symmetric Key Cryptography• Block Ciphers• Stream Ciphers• Password-based EncryptionChapter 2: Symmetric Key Cryptography 13

RSA BSAFE Security ConceptsAbout Symmetric Key CryptographyIn symmetric key cryptography, the key used for an encryption operation must be usedfor the corresponding decryption operation. Using any other key to decrypt theciphertext produces incorrect results. Symmetric key cryptography is also calledsecret key cryptography because the key used for the encryption and decryptionoperations must be kept secret for the operations to remain secure.The following diagram illustrates the symmetric key encryption and decryptionprocess.Figure 2Symmetric Key CryptographySecret KeyDear Bob,Thank you for youre-mail regarding RSAsoftware. Enclosed arethe brochures asrequested.Regards,Encryption101010011001101001101010101100010100110101010101011010101011110101101100101101100110101101101101101001011110001011010101101010101010111000101101110110100100001110011010100DecryptionDear Bob,Thank you for youre-mail regarding RSAsoftware. Enclosed arethe brochures asrequested.Regards,Symmetric key cryptography is relatively less complicated than other types ofcryptography, so it is usually the least computationally intensive, and fastest methodof encrypting or decrypting data.Block CiphersBlock ciphers encrypt fixed-length blocks of plaintext into blocks of ciphertext using asecret key. This is usually performed by iterating a function, called a round, apre-determined number of times.The round function provides security in two ways. Confusion, or non-linearity,ensures output bits appear unrelated to input bits, and diffusion ensures input bitsaffect a maximal number of output bits. To decrypt the ciphertext block, the blockcipher applies a reverse transformation to the ciphertext, using the same secret key.The fixed length of the plaintext block is called the block size. Typical block sizesvary from 64 to 128 bits. Plaintext is partitioned into sections that match the cipherblock size. When encrypting a message using a block cipher, the message length is nottypically a multiple of the block size. Some block cipher modes operate with variablesize blocks, while others require the message be a multiple of the block size.14 Chapter 2: Symmetric Key Cryptography

Modes of OperationRSA BSAFE Security ConceptsWhere a message must be a multiple of the block size, padding is used. Padding addsa regular pattern of bytes to the end of the last block to make it a complete block. Withpadding, the actual number of bytes encrypted can be as much as one block more thanthe original data.Common block ciphers include:• Data Encryption Standard (DES)• Triple DES• Advanced Encryption Standard (AES)• RC2• RC5.Encrypting the same plaintext using the same block cipher and the same key alwaysproduces the same ciphertext. To overcome this, block ciphers work in conjunctionwith modes of operation.A mode of operation takes the output from each round of the block cipher and uses itto alter the input to the next round. The input to the first round is altered using arandom value called an Initialization Vector (IV). Using a random IV ensures the firstblock of encrypted data is unpredictable, thereby ensuring the same plaintext isencrypted to a different cipher text each time.The start of the decryption process requires the same IV used in the encryptionprocess.Common modes of operation include:• Electronic Code Book (ECB)• Cipher Block Chaining (CBC)• Cipher Feedback (CFB)• Output Feedback (OFB)• Galois/Counter Mode (GCM)• Counter mode (CTR)• Counter with CBC-MAC (CCM)• Ciphertext stealing (CTS)• XEX-based Tweaked CodeBook mode with CipherText Stealing (XTS).Chapter 2: Symmetric Key Cryptography 15

RSA BSAFE Security ConceptsElectronic Code BookElectronic Code Book (ECB) mode is a simple mode in which plaintext blocks areindependently encrypted to ciphertext blocks and ciphertext blocks are independentlydecrypted to plaintext blocks. This is the default behavior of a block cipher whereeach identical block of plaintext yields an identical block of ciphertext. The speed ofeach encryption operation is identical to that of the block cipher.Unlike other modes of operation where the output from one round is feed into the nextround, transmission errors in a ciphertext block do not affect decryption of subsequentciphertext blocks. Furthermore, ECB mode is the only mode that offers random accessto ciphertext blocks.ECB mode is not very secure. It is susceptible to codebook attacks where an attackerstores known plaintexts with the corresponding ciphertexts. If the attacker identifiesciphertext that is present in the codebook, it is not difficult to recover thecorresponding plaintext. Also, plaintext can be easily manipulated by removing,repeating, or interchanging blocks.The following diagram illustrates the ECB mode encryption process where successiveblocks of plaintext are encrypted, using the same key, into successive blocks ofciphertext.Figure 3ECB Mode Encryptionplaintext block 1plaintext block 2plaintext block nkeyBlock cipherkeyBlock cipherkeyBlock cipherciphertext block 1ciphertext block 2ciphertext block nCipher Block ChainingCipher Block Chaining (CBC) mode creates dependencies between successiveciphertext blocks. Each ciphertext block depends upon all plaintexts previouslyencrypted within a session. The first block of plaintext in an encryption session iscombined with an IV using an XOR operation and is then encrypted. The resultingciphertext is combined with the next plaintext, again using XOR, and encrypted. Thisprocess is repeated until all the plaintext blocks have been encrypted.In CBC mode, identical plaintext blocks encrypted with the same key do not producethe same ciphertext blocks (unless all previous plaintexts are also identical). Patternsin the plaintext are concealed by the XORing of the previous ciphertext block with the16 Chapter 2: Symmetric Key Cryptography

The following diagram illustrates the OFB encryption process.RSA BSAFE Security ConceptsFigure 6OFB Encryption ProcessInitializationVector (IV)keyBlock cipherkeyBlock cipherkeyBlock cipherplaintextXORplaintextXORplaintextXORciphertextciphertextciphertextCounter ModeCounter Mode (CTR), used with the AES algorithm, is similar to OFB, except insteadof re-encrypting each successive block of output, successive blocks of a counter areencrypted instead. The counter can be any simple function that produces a sequenceguaranteed not to repeat for a long time, although an actual counter is the simplest andmost popular method. The IV and the counter can be concatenated, added, or XORedtogether to produce the actual unique counter block for encryption.The following diagram illustrates the CTR encryption process.Figure 7CTR Encryption ProcessInitializationVector (IV)+ CounterInitializationVector (IV)+ CounterInitializationVector (IV)+ CounterkeyBlock cipherkeyBlock cipherkeyBlock cipherplaintextXORplaintextXORplaintextXORciphertextciphertextciphertextGalois/Counter ModeGalois/Counter Mode (GCM), used with the AES algorithm, combines CTRencryption with Galois mode authentication (based on finite fields, or Galois fields, inabstract algebra).Chapter 2: Symmetric Key Cryptography 19

RSA BSAFE Security ConceptsCounter with CBC-MACCounter with CBC-MAC (CCM), used with AES algorithm, combines CTRencryption with CBC-MAC authentication.Ciphertext StealingCiphertext stealing (CTS) enables block ciphers to be used to process data that is notevenly divisible into blocks, without increasing the length of the resulting ciphertext.CTS works by changing the processing of the last two blocks of plaintext.It pads the final block of plaintext with bits from the second-to-last ciphertext block(hence, stealing the ciphertext). The final block is then encrypted and exchanged withthe second-to-last ciphertext block, which is shortened to the length of the lastplaintext block, removing the bits that were stolen. This results in ciphertext that is thesame length as the original size of the data.Ciphertext stealing is most commonly used in conjunction with the ECB and CBCmodes of operation. In CBC mode, the IV can be used as the second-to-last block ofciphertext.XEX-based Tweaked CodeBook Mode with CiphertextStealingXEX-based Tweaked CodeBook Mode with Ciphertext Stealing (XTS) mode, usedwith the AES algorithm, is typically used for encrypting data on block storage devices,such as disk drives. It uses two keys, one for the encryption key, the second for thetweak key, which incorporates the logical position of the data block into theencryption.Data Encryption StandardThe Data Encryption Standard (DES) was defined by IBM and endorsed by theNational Bureau of Standards (NBS) as an official standard in 1977. It is documentedin FIPS 46-3 (http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf). It is a widely used symmetric key algorithm.The block size is eight bytes. The input must be a multiple of eight bytes, or padded tobe a multiple of eight bytes for DES to operate in CBC or ECB modes properly. Thekey consists of 56 random bits and 8 parity bits, forming a 64-bit (8-byte) key.DES is now considered to be insecure for most applications, because of the small56-bit key size.20 Chapter 2: Symmetric Key Cryptography

RSA BSAFE Security ConceptsTriple DESThe Triple DES algorithm executes DES three times, which triples the number of bitsin any encryption key. Triple DES is documented in FIPS 46-3(http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf).Triple DES can be used in any of the following modes:• DES-EEE3, which performs three consecutive DES encryptions, each with adifferent key.• DES-EEE2, like DES-EEE3, but with the same key for the first and thirdencryption operations.• DES-EDE3, which performs three consecutive DES operations in the sequenceencrypt-decrypt-encrypt, each with different key.• DES-EDE2, like DES-EDE3, but using the same key for the encryptionoperations.Note: DES-EDE3, when used with one key, is equivalent to a single DESencryption. This is useful for interoperability with applications that havesingle DES capability only.Of all the Triple DES variants, DES-EDE3 provides the most security, although itdoes have vulnerabilities. All other Triple DES variants should not be used.For this reason, and because Triple DES is slow in comparison to other ciphers, theAES algorithm is replacing Triple DES as the preferred symmetric key algorithm. See“Advanced Encryption Standard” below.The following diagram illustrates DES-EDE3 encryption.Figure 8DES-EDE3 Encryption24-byte Triple DES key(including parity bits)First 8 bytesof the keyMiddle 8 bytesof the keyLast 8 bytesof the key8-byteplaintext blockDES encryption DES decryption DES encryption8-byteciphertext blockAdvanced Encryption StandardThe Advanced Encryption Standard (AES) is the replacement for DES. Also known asRijndael, AES was developed by Joan Daemen and Vincent Rijmen in 1997 andentered as a candidate in the National Institute of Standards and Technology's (NIST)AES development effort.Chapter 2: Symmetric Key Cryptography 21

RSA BSAFE Security ConceptsRC2RC5AES has a block size of 128 bits and a variable key size ranging from 128 to 256 bits,in multiples of 32 bits. The large block size makes it more secure than both DES andTriple DES. This protects the cipher from dictionary attacks (where a codebook ofplaintexts and ciphertexts is built) and reduces the incidence of collisions when thecipher is used in chaining modes of operation or as a hash function. The large key sizemakes brute-force attacks (where an attacker systematically tries all possible keys inan attempt to decrypt a message) infeasible.AES is extremely fast because of its economical use of simple but effective operations.The RC2 ® cipher was developed by Ronald Rivest as an alternative to DES. RC2 usesan eight byte block size, meaning the length of the plaintext input must be a multipleof eight bytes. If not, it is padded to be a multiple of eight bytes enabling operation inCBC and ECB modes.RC2 accepts a key of between 8 and 1024 bits in length, and an effective keyparameter that determines how much of the key is used. This also specifies a rangebetween 8 and 1024 bits. If the effective key exceeds the length of the supplied key,new key material is created but the amount of key entropy remains the same. For mostapplications, a key size of 80 to 128 bits is used. RC2 is optimized for 16-bitprocessors. It treats the 64-bit block as four sub-blocks.While RC2 is faster than DES on most machines, RC5 is as a more efficient andsecure alternative. RC2 should not be used in new applications.The RC5 ® cipher was developed by Ronald Rivest as an alternative to DESencryption. The block can contain 4, 8, or 16 bytes, depending on the word size. Tooperate properly, the input must be a multiple of the block size, or it must be padded toa multiple of the block size.The design of the RC5 cipher differs from other block ciphers in that it relies uponvariable rotations and modular addition in place of substitution boxes (S-boxes). Useof these components, in place of large look-up tables used to implement S-boxes,minimizes code and the memory required for the RC5 cipher.22 Chapter 2: Symmetric Key Cryptography

RSA BSAFE Security ConceptsSpeed and security of the RC5 cipher depends on the following user-determined inputparameters:• Word size.The size of the hardware register. For hardware implementations of the RC5cipher, developers can take advantage of larger registers to increase speed. Onchips with smaller registers, the word size can be emulated in software. Version1.0 of the RC5 cipher accepts word sizes of 16, 32, or 64 bits. The block size istwice the word size. For a word size of 32 bits, the block size is 64 bits, or 8 bytes,the same as for the DES and RC2 ciphers. For a word size of 64 bits, the blocksize is 128 bits, or 16 bytes.• Rounds.The number of times the operation employs the inner encryption function. Varyingthe number of rounds allows developers to make a trade-off between speed andsecurity. The greater the number of rounds, the greater the security, but the slowerthe execution. The number of rounds can be anywhere from zero to 255, but it istypical for an RC5 cipher with a 32-bit word size to use 16 rounds. While nopractical attacks are known for 12-round RC5-32, recent cryptanalytic worksuggests that a more secure option is to use 16 rounds. It is typical for an RC5cipher with a 64-bit word size to use at least 20 rounds.• Key size, in bytes.The key size can be 1 to 255 bytes. The RC5 cipher uses the secret key bits togenerate an expanded key table during the initialization phase. The key table isthen used during encryption or decryption. Therefore, key length has noappreciable effect on algorithm speed.The RC5 cipher is more formally described as RC5 w/r/b (word/rounds/byte). Forexample, an RC5 cipher with a 32-bit word, 16 rounds, and a 10-byte key would bedescribed as RC5 32/16/10.Stream CiphersStream ciphers take in a variable length stream of plaintext, combine it with apseudo-random bit stream (the keystream), and output a stream of ciphertext the samelength as the input. The algorithm does not have to wait for a specified amount of datato be input before processing, nor does it have to append and encrypt extra data likeblock ciphers.Stream ciphers are ideal in scenarios where:• Throughput must be maximized. Stream ciphers are faster than block ciphers.• Delays must be removed. The time delay between the encryption of smallplaintext units is usually less than that of larger data blocks.• Buffering space is limited. Small plaintext units have low memory (down to onebit) requirements.Chapter 2: Symmetric Key Cryptography 23

RSA BSAFE Security ConceptsRC4• Transmission is unreliable. Error propagation in the ciphertext is restricted to thesize of the plaintext unit. That is, down to one bit.Care is required when using stream ciphers, because they produce identical ciphertextif used with the same key and input data over successive operations. If the plaintext isa high redundancy language, such as English, the plaintext can easily be extractedfrom the ciphertext without knowledge of the key.The RC4 ® stream cipher was developed by Ronald Rivest. RC4 generates apseudo-random stream of bits (the keystream) that is combined with the plaintextusing the exclusive-or (XOR) operation to produce the ciphertext. The encryption anddecryption operations are identical.RC4 is much faster than any other popular block cipher algorithm. It uses a key with alength of between 8 and 2048 bits. Key lengths less than 128 bits are consideredinsecure. Government laws concerning the use of cryptography might dictate amaximum key length.RC4 is vulnerable to attack if the keystream used for the encryption is not discarded,or if the same key is used twice. A new key is required for each new encryption.The following diagram illustrates the RC4 encryption process.Figure 9RC4 EncryptionKeyKeystreamGeneratorPseudo-random keystreamplaintext bytestreamXORciphertext bytestreamRC4 with Message Authentication CodeThe RC4-with-MAC algorithm is an extension of the RC4 cipher. It provides dataintegrity by using a Message Authentication Code (MAC) with the RC4 encryptionalgorithm. The authentication code does not provide cryptographic authentication, butprovides the equivalent of a checksum that can be used to determine if any errors wereintroduced within the cipher bytes. The MAC guards against transmission or retrievalerrors, but it might not detect deliberate tampering with the data.For information about MACs, see “Message Authentication Codes” on page 44.24 Chapter 2: Symmetric Key Cryptography

RSA BSAFE Security Concepts26 Chapter 2: Symmetric Key Cryptography

RSA BSAFE Security Concepts3 AsymmetricKey CryptographyThere are two issues with symmetric key cryptography. The first issue is about thesecurity of the symmetric key. How do two parties exchange a symmetric key in asecure way? The second issue is about the number of secret keys required. Becauseeach pair of communicators requires a unique secret key, as the number of partiesgrows, so does the number of unique keys required. This creates key generation andkey management problems.Asymmetric key cryptography (also called public key cryptography) solves these twoissues. Each entity generates a pair of keys; a public key, which is published and freelyavailable to anyone, and a private key, which is held by the entity and kept secret.This chapter describes asymmetric key cryptography and the different kinds ofasymmetric key algorithms.Topics:• Encryption and Decryption• Signing and Verifying• The RSA Algorithm• Digital Signature Algorithm• Elliptic Curve CryptographyChapter 3: Asymmetric Key Cryptography 27

RSA BSAFE Security ConceptsEncryption and DecryptionSuppose Alice wants to send an encrypted message to Bob. Using asymmetric keycryptography, Alice finds Bob’s public key and encrypts her message using that key.Unlike symmetric key cryptography, the key used to encrypt the message cannotdecrypt the message, so knowledge of Bob’s public key does not help an attacker.To decrypt Alice’s message, Bob uses his private key. If Bob wants to respond to Alicewith his own encrypted message, he find Alice’s public key and encrypts his messageusing that key. Alice then decrypts the response using her private key.The following diagram illustrates asymmetric key encryption and decryption.Figure 11Asymmetric Key Encryption and DecryptionBob’s Public KeyBob’s Private KeyDear Bob,Thank you for youre-mail regarding RSAsoftware. Enclosed arethe brochures asrequested.Regards,Encryption101010011001101001101010101100010100110101010101011010101011110101101100101101100110101101101101101001011110001011010101101010101010111000101101110110100100001110011010100DecryptionDear Bob,Thank you for youre-mail regarding RSAsoftware. Enclosed arethe brochures asrequested.Regards,Asymmetric key cryptography is slower than symmetric key cryptography (because ofthe more complex public key/private key algorithms involved) so is generally not usedto encrypt entire messages.28 Chapter 3: Asymmetric Key Cryptography

RSA BSAFE Security ConceptsSigning and VerifyingAsymmetric key cryptography is also used to provide authentication via signatures.With signatures, the sender of a message uses their own private key to sign a message,which can then be verified by anyone using the sender’s public key.For example, Alice signs her message to Bob using her private key and sends thesigned message to Bob. Bob verifies Alice’s message using her public key. Becauseonly Alice has the private key used to sign the message, Bob knows Alice sent themessage.Note: Signatures using asymmetric key cryptography do not provide dataconfidentiality. Because the public key required to verify a message is freelyavailable to anyone, signed messages are not secure.The following diagram illustrates asymmetric key signing and verifying.Figure 12Asymmetric Key Signing and VerifyingAlice’s Private KeyAlice’s Public KeyDear Bob,Thank you for youre-mail regarding RSAsoftware. Enclosed arethe brochures asrequested.Regards,Signing101010011001101001101010101100010100110101010101011010101011110101101100101101100110101101101101101001011110001011010101101010101010111000101101110110100100001110011010100VerifyingDear Bob,Thank you for youre-mail regarding RSAsoftware. Enclosed arethe brochures asrequested.Regards,Chapter 3: Asymmetric Key Cryptography 29

RSA BSAFE Security ConceptsThe RSA AlgorithmThe RSA algorithm is a widely used asymmetric key algorithm for encryption andsignatures. The algorithm is based upon a one-way trapdoor function. Such functionsare easy to calculate in one direction, but exponentially more difficult in the reversedirection unless the key is known. The RSA algorithm is based upon prime factoring(breaking down an integer into its prime factors).The keys for the RSA algorithm are created as follows:1. Choose two large random prime numbers, p and q. It is best that p and q are ofequal length.2. Compute the product of these two primes.n = pq3. Select the encryption key, e, such that e and (p - 1)(q - 1) are relatively prime.4. Compute the decryption key.d = e -1 mod [(p - 1)(q - 1)]Encryption Using the RSA AlgorithmTo encrypt data using the RSA algorithm, Alice retrieves Bob's public key,represented as the pair of integers e and n. The key is usually obtained as part of therecipient's (Bob's) X.509 certificate, which is available for public distribution.Alice translates the message for encryption into blocks of integers, each of which hasa value less than n. Each block M is encrypted into ciphertext C as C = M e mod n.Alice transmits the ciphertext blocks C to Bob who, using the private key d, decryptsthem into the message fragments M by calculating M = C d mod n. After reassemblingthe message fragments, Bob converts the message from integer blocks into its originalformat.Signing Using the RSA AlgorithmYou can sign messages in a similar way to encryption by applying the private keyrather than public key to the message. The signed text block S is created from themessage block M as S = M d mod n.Anyone can verify the originator of the message M by decrypting the signed text withthe signer's public key and comparing the result M = S e mod n. If it matches theoriginal message, the signer (the only holder of the private key) is the only one whocould have signed the text. This authenticates the message origin.30 Chapter 3: Asymmetric Key Cryptography

RSA BSAFE Security ConceptsSelecting ParametersDigital EnvelopesSelect parameters for use with the RSA algorithm appropriately, because differentfactoring algorithms work best with specific properties. For example, the primenumbers p and q should be about the same length to avoid vulnerabilities to theelliptic curve factoring attack.The public key e is usually chosen to be small, for reasons of implementationefficiency. A common value includes 65537 to reduce the effort of exponentiation ofthe plaintext message.RSA recommends using the RSA algorithm with a modulus of at least 2048 bits fornew applications.Using the RSA algorithm to encrypt entire messages is computationally expensive.Instead, encrypting a message using a symmetric key algorithm, such as AES, thenencrypting the symmetric key with the RSA algorithm, creates a digital envelope.The recipient of the digital envelope decrypts the symmetric key using their privatekey, then decrypts the message using the decrypted symmetric key.The following diagram illustrates the digital envelope.Figure 13Digital EnvelopesEncrypted MessageDear Bob,Thank you for youre-mail regarding RSAsoftware. Enclosed arethe brochures asrequested.Regards,Symmetric keyencryptionSecret Key101010011001101001101010101100010100110101010101011010101011110101101100101101100110101101101101101001011110001011010101101010101010111000101101110110100100001110011010100Symmetric keydecryptionSecret KeyDear Bob,Thank you for youre-mail regarding RSAsoftware. Enclosed arethe brochures asrequested.Regards,Encryption using therecipient’s public key1010100110011010011010101011000101001101010101010110101010111101011011001011Encrypted KeyDecryption using therecipient’s private keyChapter 3: Asymmetric Key Cryptography 31

RSA BSAFE Security ConceptsDigital Signature AlgorithmUnlike the RSA algorithm, the Digital Signature Algorithm (DSA) is used only forsigning and cannot be directly used to encrypt messages. DSA is a part of the DigitalSignature Standard (DSS), which was proposed by NIST and the National SecurityAgency (NSA) in 1991 and issued in 1994.The security of DSA relies on the difficulty of the discrete logarithm problem. That is,easy to compute in one direction, difficult to compute in the other direction. Typicalkey sizes for DSA range between 1024 and 2048 bits.RSA Algorithm and DSA ComparedToday, many standards specify both the RSA algorithm and DSA as signing tools.The RSA algorithm is much less complex than DSA and also more powerful in thatthe RSA algorithm can be used for signing and encryption. The RSA algorithm workswith a modulus of unlimited size, so it is preferred for strong signature generation.In terms of efficiency, both have strengths. DSA is faster for signature generationbecause of its ability to precompute some values within the algorithm. However, theRSA algorithm is much faster at verifying signatures. This can be useful if the samesignature needs to be verified many times.32 Chapter 3: Asymmetric Key Cryptography

RSA BSAFE Security ConceptsElliptic Curve CryptographyElliptic curves are mathematical constructs that have been studied by mathematiciansfor over 100 years. In 1985, Neal Koblitz and Victor Miller independently devised apublic key system using a group of points on an elliptic curve. The mathematicsinvolved with ECC-based algorithms is more complex than that used in non-ECCalgorithms like RSA or DSA, but key sizes can be smaller and still provide the samelevel of security.For example, a popular, recommended RSA key size for most applications is 2048bits. For equivalent security using ECC, a key of only 224 bits is required. Thedifference becomes more pronounced as security levels increase. A 384-bit ECC keymatches a 7680-bit RSA key for security.Smaller ECC keys mean that:• Cryptographic operations can be performed on smaller hardware.• Software applications can complete cryptographic operations with fewerprocessor cycles.• Operations can be performed faster, while still guaranteeing equivalent security.Several types of elliptic curves are available, but selection is made easier from a set ofnamed curves, such as P256, P384, and P521. NIST recommended curves include:• P-192, P-224, P-256, P-384, P-521• K-163, K-233, K-283, K-409, K-571• B-163, B-233, B-283, B-409, B-571.Elliptic Curve Digital Signature AlgorithmThe Elliptic Curve Digital Signature Algorithm (ECDSA) is a variation of DSA thatuses elliptic curve cryptography. As with elliptic curve cryptography in general,smaller key sizes used with ECDSA provide the same level of protection as larger keysizes used with DSA.Elliptic Curve Integrated Encryption SchemeThe Elliptic Curve Integrated Encryption Scheme (ECIES), also known as the EllipticCurve Augmented Encryption Scheme (ECAES) is a complex cryptographicalgorithm that combines asymmetric key cryptography, key exchange, messageauthentication codes (MACs), symmetric key cryptography, and message digests toperform asymmetric encryption and decryption.ECIES operations follow this sequence:• The recipient's public key object is obtained. The public key object contains curveparameters used when this key was generated.Chapter 3: Asymmetric Key Cryptography 33

RSA BSAFE Security Concepts• An ephemeral key pair is generated using the same curve parameters as therecipient's public key.• Using the recipient’s public key and the private ephemeral key just generated, ashared secret is generated using key agreement.• The shared secret output, and optionally some user-specified shared data(sharedData1), is passed to a key derivation function (KDF).• The output of the KDF is used to create two keys: a symmetric encryption key anda MAC key.• The symmetric encryption key is used to encrypt the plaintext using a symmetriccipher.• The MAC key is used to create a MAC on the plaintext, and optionally some otheruser-specified shared data (sharedData2).• The output contains the public ephemeral key, encrypted data, and MAC tagwhich is sent to the recipient.For more information about key exchange, see Chapter 4, “Diffie-Hellman KeyExchange” on page 36.For more information about message digests and MACs, see Chapter 5, “Digests,Digital Signatures and MACs” on page 41.Elliptic Curve Cryptography StandardsPKCS #13 Elliptic Curve Cryptography Standard is a new document being developedby RSA Laboratories as part of its PKCS series, covering public key techniques basedon elliptic curve cryptography.Current standards being developed for elliptic curve cryptography include:• X9.F.1, an ANSI-accredited standards committee for the financial servicesindustry, has developing two standards: ANSI X9.62 for digital signatures, andANSI X9.63 for key agreement and key transport.• IEEE P1363, a general reference for public key techniques from several families,including elliptic curves.• FIPS 186-3 Digital Signature Standard.34 Chapter 3: Asymmetric Key Cryptography

RSA BSAFE Security Concepts4 KeyOperationsIn cryptography, a key is a string of bits used in conjunction with an algorithm toperform an operation on data, such as encryption, decryption, or a digital signature.Keys must be able to be exchanged securely and protected during transmission.Symmetric key cryptography, for example, requires secret keys be securely exchangedbetween parties. This is further complicated because multiple parties require multiplesecret keys. Key exchange schemes such as Diffie-Hellman allow secret keys to benegotiated across an insecure channel.Another method of protecting keys is key wrapping. This is designed to protect keyswhile on an untrusted storage device, or during transmission over an untrustedcommunications network.This chapter discusses Diffie-Hellman key exchange, and different types of keywrapping.Topics:• Diffie-Hellman Key Exchange• Key WrappingChapter 4: Key Operations 35

RSA BSAFE Security ConceptsDiffie-Hellman Key ExchangeThe Diffie-Hellman public key exchange algorithm, invented by Whitfield Diffie andMartin Hellman in 1976, was the first true public key algorithm. Diffie-Hellman keyexchange enables two parties to agree on a key over an insecure channel. This key canthen be used with a symmetric key algorithm in a subsequent encryption session.Note: Diffie-Hellman key exchange does not provide encryption orauthentication.The Diffie-Hellman algorithm consists of three parts: parameter generation, phase 1,and phase 2.Parameter GenerationThe two parties agree on a prime number p of length k bytes, and an integer g greaterthan 0 but less than p, called the base. The two parties can optionally agree on aninteger l, the private value length in bits, that satisfies 2 l–1 ≤ p.Phase 1Each of the two parties executing the Diffie-Hellman protocol does the following:1. Each party, i, i = 1 or 2, randomly generates a private value, which is a number, x i ,greater than 0 but less than the prime. If the length l is specified, the private valuemust satisfy 2 l–1 ≤ x i < 2 l .2. Each party computes a public value y i = g x i mod p.3. The two parties exchange the public values.These private and public values correspond to the private and public key componentsof a key pair. The public value is generated in such a way that computing the privatevalue from the public number is computationally infeasible.Phase 2Each participant computes the agreed upon secret key, z, using the other participant’spublic value, y i , their own private value, x, and the prime, p.z = (y i ) x mod pEven with knowledge of the parameters and both public keys, an outside individualcannot determine the secret key because one of the private values must be known todetermine the secret key. This means secret information is never sent over insecurelines.36 Chapter 4: Key Operations

RSA BSAFE Security ConceptsThe following diagram illustrates two users, Alice and Bob, using the Diffie-Hellmankey exchange process.Figure 14Diffie-Hellman Key ExchangeParameterGenerationPhase 1AliceBobCompute PrivateValueCompute PrivateValueCompute PublicValueCompute PublicValuePhase 2AliceBobCompute AgreedUpon Key=Compute AgreedUpon KeySecurityDiffie-Hellman is vulnerable to a man-in-the-middle attack. A man-in-the-middleattack is where an attacker sits in the middle of a session between two parties makingindependent connections with each party and relaying messages between them. Thetwo parties believe they are communicating directly with each other over a privateconnection, but instead, the entire session is controlled by the attacker.To circumvent this type of attack, it is recommended communications between thetwo parties be authenticated using digital signatures. For more information aboutdigital signatures, see “Digital Signatures” on page 43.Multiple Party Key ExchangeDiffie-Hellman can be extended to more than two parties. For a multiple partyagreement, each individual chooses a private value, then uses the collection of publicvalues from other parties to generate a common secret key.Chapter 4: Key Operations 37

RSA BSAFE Security ConceptsElliptic Curve Diffie-HellmanElliptic Curve Diffie-Hellman (ECDH) combines elliptic curve cryptography withDiffie-Hellman. The agreed elliptic curve is a public parameter of the ECDHalgorithm.Key WrappingAES Key WrappingKey wrapping is a method of encrypting key data for protection on untrusted storagedevices or during transmission over insecure channels.There are three main types of key wrapping:• Symmetric key wrapping, which uses any standard symmetric key algorithm toencrypt or decrypt key data.• Asymmetric key wrapping, which uses any standard asymmetric key algorithm toencrypt or decrypt key data.This type of key wrapping is also known as digital enveloping. Application data isencrypted using a symmetric key, and then the symmetric key is encrypted usingthe recipient’s public key. For more information, see “Digital Envelopes” onpage 31.• AES key wrapping, which is based on the AES symmetric key algorithm. AESencryption and decryption operations are used in accordance with publishedRequest For Comments (RFCs).There are two RFCs that define how to perform AES key wrapping: the AES key wrapalgorithm, and the AES key wrap with padding algorithm.AES Key Wrap AlgorithmSpecified in RFC 3394, the AES key wrap algorithm uses a Key Encryption Key(KEK) with the AES symmetric key algorithm to wrap and unwrap. The length of theplaintext key must be a multiple of the AES block size (64 bits), and a minimum oftwo blocks. The AES key wrap algorithm implements all supported AES key sizes(128, 192, and 256-bit).For more information, see http://tools.ietf.org/html/rfc3394.AES Key Wrap with Padding AlgorithmSpecified in RFC 5649, the AES key wrap with padding algorithm also uses AES, butthere is no requirement that the key be a multiple of 64 bits. The plaintext key cantherefore be any length greater than zero.For more information, see http://tools.ietf.org/html/rfc5649.38 Chapter 4: Key Operations

RSA BSAFE Security ConceptsThe AES key wrap algorithm and the AES key wrap algorithm with padding differfrom the standard AES symmetric key algorithm in the following ways:• All plaintext key data or ciphertext key data must be available before thewrapping or unwrapping operations can be performed. This means all theplaintext or ciphertext must fit into memory.• The IV (the 64-bit initial value used during the wrapping process) is defined bythe RFC specification, not the application.• No feedback modes are applicable. The RFC specifications determine how theindividual blocks are processed (that is, the need for 64-bit blocks, and theaddition of padding).Chapter 4: Key Operations 39

RSA BSAFE Security Concepts40 Chapter 4: Key Operations

RSA BSAFE Security Concepts5 Digests,Digital Signatures and MACsApart from encryption and decryption, there are other cryptographic tools andprocedures available to provide data security.This chapter describes message digests, digital signatures and message authenticationcodes (MACs). Depending on which is used, these cryptographic tools can provideauthentication, data integrity, or non-repudiation.Topics:• Message Digests• Digital Signatures• Message Authentication CodesChapter 5: Digests, Digital Signatures and MACs 41

RSA BSAFE Security ConceptsMessage DigestsA message digest is a computationally unique, fixed-length transformation of avariable-length unit of data. Each unit of data (for example, a file, string, or buffer)maps to a specific message digest. It is not random. Digesting the same unit of datawith the same message digest algorithm always produces the same message digest.A good message digest algorithm possesses the following qualities:• The algorithm accepts any data length as input.• The algorithm produces a fixed length output for any input data.• The algorithm can provide multiple security levels.• It is computationally infeasible to find two sets of input data that produce the samemessage digest. This quality is known as collision resistance.• It is computationaly infeasible to produce data that has a specific message digest.That is, given a specific message digest of the proper size, it is virtuallyimpossible to determine input data that could be used to produce the messagedigest. This quality is known as the one-way property or preimage resistance.• It is computationally infeasible to produce two sets of input data that produce thesame digest. That is, given some data, it is virtually impossible to create differentdata that will transform to the same message digest as the first. This quality isknown as second preimage resistance.Message digests are used to ensure data integrity. For example, if you download asoftware file from the Internet, you might also be able to download a message digestof that file. Create your own message digest of the file you downloaded (using thesame message digest algorithm) and compare the two. If the message digests aredifferent, then the file (or the message digest) is corrupt.Although other sets of data exist that will digest to the original message digest, it isvirtually impossible to find them. Minor changes in data will produce very differentmessage digests.Message Digest AlgorithmsCommon message digest algorithms include:• MD2• MD4• MD5• SHA-1• SHA-2• RIPEMD160.42 Chapter 5: Digests, Digital Signatures and MACs

RSA BSAFE Security ConceptsMD2, MD4, and MD5 are old message digest algorithms, producing 128-bit messagedigests. They have known vulnerabilities and should not be used.Secure Hash Algorithm-1 (SHA-1) produces a 160-bit message digest. Vulnerabilitieswith regards to collision resistance have recently been identified, so SHA-1 should notbe used in new applications. SHA-1 is NIST-approved for use until the end of 2010.After 2010, SHA-1 is only approved for:• Message Authentication Codes (MACs)• Key Derivation Functions (KDFs)• Pseudo Random Number Generators (PRNGs).The most recent SHA-2 family of message digest algorithms (SHA-224, SHA-256,SHA-384, and SHA-512) produce message digests of 224, 256, 384, and 512 bitsrespectively. The SHA-2 algorithms are considered to be much more secure thanSHA-1.RIPEMD160 is an enhanced version of the RIPEMD message digest algorithm andproduces a 160-bit message digest. It is primarily used in Europe.Digital SignaturesDigital signatures combine message digests and asymmetric key cryptography toprovide authentication, data integrity, and non-repudiation.Because messages can be arbitrarily long, it is more efficient and practical to sign themessage digest instead. The RSA algorithm, DSA, or ECDSA can be used to sign themessage digest.The process of creating a digital signature using the RSA algorithm is as follows:• The sender:a. Creates a message digest of the message to be sent.b. Signs the message digest using their private key.c. Sends the plaintext message and the signed message digest to the recipient.• The recipient:a. Creates their own message digest of the plaintext message.b. Verifies the received message digest using the sender’s public key.c. Compares the two message digests. If they are the same, the recipient knowsthe message could only have come from the sender (authentication andnon-repudiation) and the message was not tampered with or corrupted duringtransmission (data integrity).Chapter 5: Digests, Digital Signatures and MACs 43

RSA BSAFE Security ConceptsThe following diagram illustrates using digital signatures.Figure 15Digital SignaturesDear Bob,Dear Bob,Thank you for youre-mail regarding RSAsoftware. Enclosed arethe brochures asrequested.Thank you for youre-mail regarding RSAsoftware. Enclosed arethe brochures asrequested.Digest1010100110011010011010101011000101001101010101010110101010111101011011001011Regards,Send toBobRegards,DigestCompare1010100110011010011010101011000101001101010101010110101010111101011011001011Sign using RSAalgorithm andAlice’s private key1010100110011010011010101011000101001101010101010110101010111101011011001011Verify using RSAalgorithm andAlice’s public key1010100110011010011010101011000101001101010101010110101010111101011011001011Note: Digital signatures do not provide secrecy because the message is sent inplaintext. Only the message digest is signed.Message Authentication CodesLike message digests, Message Authentication Codes (MACs) are shorttransformations of a plaintext message. Unlike message digests, the MAC algorithmthat generates the MAC requires a symmetric key. Only someone with the samesymmetric key can verify the MAC. MACs are used to provide authentication anddata integrity.The process of using MACs is as follows:• The sender:a. Creates a MAC of the message to be sent using an agreed symmetric key.b. Sends the plaintext message and the MAC to the recipient.• The recipient:a. Creates their own MAC of the plaintext message using the same agreedsymmetric key.b. Compares the two MACs. If they are the same, the recipient knows themessage came from the sender (authentication) and the message has not beentampered with (data integrity).44 Chapter 5: Digests, Digital Signatures and MACs

RSA BSAFE Security ConceptsThe following diagram illustrates using MACs.Figure 16MACsDear Bob,Dear Bob,MACThank you for youre-mail regarding RSAsoftware. Enclosed arethe brochures asrequested.Thank you for youre-mail regarding RSAsoftware. Enclosed arethe brochures asrequested.MAC algorithmusing secret key1010100110011010011010101011000101001101010101010110101010111101011011001011Regards,Regards,MAC algorithmusing secret keySend toBobCompare1010100110011010011010101011000101001101010101010110101010111101011011001011MAC1010100110011010011010101011000101001101010101010110101010111101011011001011MACCommon MAC algorithms include:• HMAC-MD5• HMAC-SHA-1• HMAC-SHA-224• HMAC-SHA-256• HMAC-SHA-384• HMAC-SHA-512.Chapter 5: Digests, Digital Signatures and MACs 45

RSA BSAFE Security Concepts46 Chapter 5: Digests, Digital Signatures and MACs

RSA BSAFE Security Concepts6 RandomNumber GenerationSome inputs into a cryptographic system are required to be unpredictable, particularlythose that are kept secret. Random numbers are generally required in conjunction withthe following cryptographic operations:• Generating a symmetric key• Generating an Initialization Vector (IV) or salt• Performing PKCS #1 Block 02 and Optimal Asymmetric Encryption Padding(OAEP) padding (as part of asymmetric encryption)• Generating RSA, DSA, or Diffie-Hellman key pairs• Creating DSA and ECDSA signatures.Good sources of randomness include air turbulence within a disk drive, thermal noisefrom a transistor, or the times associated with radioactive decay. Unfortunately,obtaining randomness from such sources is not practical for a software-basedapplication.A practical alternative involves the use of a Pseudo-Random Number Generator(PRNG). A PRNG is an algorithm that uses a seed to produce a series of numbers thatappear to be random.Note: Within this document, references to random numbers are references topseudo-random numbers.This chapter discusses seeding a PRNG and outlines three PRNGs.Topics:• Seeding• Dual EC DRBG• HMAC DRBG• FIPS 186-2 RNG.Chapter 6: Random Number Generation 47

RSA BSAFE Security ConceptsSeedingTrue random numbers derive from events that are physically impossible to predict orreproduce, such as radioactive decay or electronic static. Pseudo-random numbers arevalues that look random but are obtained from a deterministic source, such as acomputer program, and can be regenerated.Two of the requirements of a good PRNG are:• On average, it generates as many 1 bits as 0 bits.• There are no preferred strings. It does not generate a repeating sequence (such as010101... or 0011001100110011...).Also, when examining the output of a good PRNG, even when the values of previouslygenerated bits are known, nothing about subsequently generated bits is revealed.The effectiveness of the PRNG depends on the unpredictability of the seed. While atruly random source can be used to provide the seed, it is usually easier to initialize thePRNG using many pseudo random “seedlings”. Such seedlings include:• An in built random pool (for example, /dev/urandom)• The system clock• Network access times• Keyboard and mouse events• User input.Note that none of these elements should be used in isolation.The security issue with seeding is to ensure an attacker cannot determine the seed, asthese techniques illustrate:• Using the current date/time string (partial seed). This method uses the current datestring as a random number seed. This is an easy way to generate something thatlooks random, however, it lacks an adequate level of entropy (the amount ofrandomness). If the precision of the time is in milliseconds an attacker couldeasily guess when the program was run, and then try every date string for severaldays or weeks before or after that date. If the attacker knew that an applicationgenerates a DES key based on such a seeded PRNG, it would probably take only afew hours to generate trial DES keys based on a date-seeded PRNG. Clearly, thisalone is not a good method for seeding a PRNG.48 Chapter 6: Random Number Generation

RSA BSAFE Security Concepts• Typing a series of random key strokes. A more secure method for generating someuser-based entropy would be to have the user type a series of random key strokes.Although each key stroke is probably reported as a byte, it does not contain 8 bitsof entropy for each keystroke. Users are more likely to press keys in the centerrow of the keyboard than the function keys on the top row. To compensate for this,the application programmer could take more key strokes so that an attacker cannoteasily replicate the sequence used as the seed.For more information on seeding PRNGs, seehttp://tools.ietf.org/html/rfc1750.Dual EC DRBGDual EC DRBG is the implementation of the Dual Elliptic Curve DeterministicRandom Bit Generator based on the NIST SP 800-90 standard. For more information,see http://csrc.nist.gov/publications/nistpubs/800-90/SP800-90revised_March2007.pdf.It is based on the following hard problem, sometimes known as the “elliptic curvediscrete logarithm problem” (ECDLP). This is given points P and Q on an ellipticcurve of order n, find a such that Q=aP.The instantiation of this DRBG requires the selection of an appropriate elliptic curvefor a desired security strength. The possible security strengths are 128, 192, and 256bits. It also uses a message digest. Dual EC DRBG uses a seed that is approximatelythe bit length of the field size of the elliptic curve group to initiate the generation ofrandom bytes.HMAC DRBGHMAC Deterministic Random Bit Generator (HMAC-DRBG) is the implementationof the HMAC Deterministic Random Bit Generator based on the NIST SP 800-90standard.It uses the HMAC operation with SHA digests as the internal operations forgenerating pseudo random bytes. Each instantiated HMAC-DRBG is associated witha security strength and a digest. The supported strengths are 128, 192, and 256 bits.For more information, see http://csrc.nist.gov/publications/nistpubs/800-90/SP800-90revised_March2007.pdf.Chapter 6: Random Number Generation 49

RSA BSAFE Security ConceptsFIPS 186-2 RNGFIPS 186-2 describes a general purpose RNG. For more information, seehttp://csrc.nist.gov/publications/fips/archive/fips186-2/fips186-2.pdf.50 Chapter 6: Random Number Generation

RSA BSAFE Security Concepts7 Base64EncodingBase64 encoding is a method of converting, or encoding, binary data into a textualequivalent that can be stored or transferred using applications designed to deal withtext data only. For example, binary attachments to e-mail messages, such as images,are base64 encoded prior to transfer and base64 decoded after transfer.This chapter describes the process of base64 encoding and decoding, and somespecific base64 variations.Topics:• Converting Binary Data to Base64Chapter 7: Base64 Encoding 51

RSA BSAFE Security ConceptsConverting Binary Data to Base64The process of converting binary data to base64 is as follows:1. Each three-byte block of data (24 bits) is split into four six-bit values.2. Each six-bit value (maximum 64 possible values) is represented as a characterfrom the US-ASCII character set.3. Where the length of the unencoded data is not a multiple of three (and fewer than24 bits are available at the end of the unencoded data), a padding character (=) isused to complete the encoded data.The following table lists the possible six-bit values and the corresponding US-ASCIIcharacter equivalentsTable 1Base64 Index TableValue Character Value Character Value Character Value Character0 A 16 Q 32 g 48 w1 B 17 R 33 h 49 x2 C 18 S 34 i 50 y3 D 19 T 35 j 51 z4 E 20 U 36 k 52 05 F 21 V 37 l 53 16 G 22 W 38 m 54 27 H 23 X 39 n 55 38 I 24 Y 40 o 56 49 J 25 Z 41 p 57 510 K 26 a 42 q 58 611 L 27 b 43 r 59 712 M 28 c 44 s 60 813 N 29 d 45 t 61 914 O 30 e 46 u 62 +15 P 31 f 47 v 63 /padding =52 Chapter 7: Base64 Encoding

RSA BSAFE Security ConceptsBase 64 Encoding ExampleConsider the following text to be converted to base64:The quick brown fox jumped over the lazy dog.The base64 encoding of this text results in the following:VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wZWQgb3ZlciB0aGUgbGF6eSBkb2cuIn the above example, the word The is encoded as VGhl. As ASCII characters, T, h,and e are stored as bytes 84, 104, and 101, which are 01010100, 01101000, and01100101 as binary. The following table illustrates the base64 encoding of the wordThe.Table 2Base64 Encoding of “The”Text T h eASCII 84 104 101Bit Pattern 0 1 0 1 0 1 0 0 0 1 1 0 1 0 0 0 0 1 1 0 0 1 0 1Value 22 6 33 37Base64 V G h lAlternatively, the following text:The quick brown fox jumped over the lazyConverts to:VGhlIHF1aWNrIGJyb3duIGZveCBqdW1wZWQgb3ZlciB0aGUgbGF6eQ==Because the length of the unencoded text is not a multiple of three, which results infewer than 24 bits on the end of the data to be encoded, padding characters are addedto the end of the base64 encoded output.Note: While base64 encoding visually hides easily recognized information,such as passwords, it does not provide any encryption or compression of data.For more detailed information about base64 encoding, see RFC 4648(http://tools.ietf.org/html/rfc4648).Chapter 7: Base64 Encoding 53

RSA BSAFE Security ConceptsBase64 DecodingBase64 VariationsThe process of base64 decoding is the opposite of encoding:1. Each base64 character is converted back to its six-bit equivalent.2. Padding characters are replaced with zeros.3. Each 24-bit block of data is split into three bytes.Invalid Characters in Base64 Encoded DataAs outlined previously, base64 encoding uses a specific character set to encode binarydata. However, other invalid characters might exist in base64 encoded data, eitherbecause of data corruption or a specific attack.For invalid characters in base64 encoded data, the recommended implementation is tocompletely reject the entire encoded string. However, some implementations mightjust ignore the invalid characters.There are some variations to the base64 encoding outline above, specifically regardingthe maximum line length of the encode data, the characters used in positions 62 and 63of the index table, and whether a padding character is used.Privacy Enhanced MailThe first standardized use of base64 encoding was in the Privacy Enhanced Mail(PEM) protocol. The maximum line length of encoded data was 64 characters, with aCR/LF character as a line separator.Multipurpose Internet Mail ExtensionsFor Multipurpose Internet Mail Extensions (MIME), the maximum line length ofencoded data is 76 characters, with a CR/LF character as a line separator.Base64 with URL and Filename-safe CharactersThe +, /, and = characters in URL applications are represented as percent encodedhexadecimal sequences (for example, + = %2B), which makes the encoded stringlonger than necessary. Also, the / character cannot be used in filenames on someoperating systems.54 Chapter 7: Base64 Encoding

RSA BSAFE Security Conceptsbase64url is base64 encoding that is identical to the encoding described previously,except for the following:• The - (minus) and _ (underscore) characters replace the + and / characters in the62nd and 63rd position of the index table.• The padding character (=) can be omitted if the length of the unencoded data isknown.• There is no maximum line length for the encoded data.Chapter 7: Base64 Encoding 55

RSA BSAFE Security Concepts56 Chapter 7: Base64 Encoding

RSA BSAFE Security Concepts8 PublicKey Infrastructure andCertificatesChapter 3 Asymmetric Key Cryptography describes how public/private key pairs areused to encrypt data and create signatures. For example, a message digest algorithm inconjunction with the RSA algorithm is used to create a digital signature of a message.To create a digital signature the sender of a message creates a message digest of themessage, signs it using their private key, and sends the message and the messagedigest to the recipient.The recipient creates a message digest of the sent message, verifies the message digestusing the sender’s public key, and compares the two message digests. If they are thesame, the recipient knows the message could only have come from the sender and themessage has not been tampered with.But how does the recipient trust the key pair used to encrypt the message digest, andthen decrypt the message digest, actually belongs to the person or organization theybelieved signed the message? Perhaps an attacker switched public keys and then usedtheir own private key to sign the message. In this case, the recipient incorrectly truststhe content of the message.The role of a Public Key Infrastructure (PKI) is to create digital identities that can betrusted.This chapter describes the components of a PKI, including Certification Authoritiesand digital certificates.Topics:• Trusted Authorities• Digital Certificates• Certification Authorities• Certificate Revocation• Certificate Chains• Certificate Validation• Certificate Extensions• Certificate RequestsChapter 8: Public Key Infrastructure and Certificates 57

RSA BSAFE Security ConceptsTrusted AuthoritiesThere are many real world cases of trusted authorities that have the right or the abilityto establish a person’s identity. For example, a motor vehicle registry office issuesdriver’s licenses, which identify people and authorize them to drive a motor vehicle.And a passport office issues passports enabling people to be recognized by othercountries.We accept that motor vehicle registry offices, passport offices, and other types oforganizations have the authority to issue these documents and authorize identities.Within a PKI, the Certification Authority (CA) is the trusted authority responsible forcreating and certifying identities. And the level of trust we have in a CA depends onthe security of their policies and procedures.Digital CertificatesX.509 CertificatesA CA issues digital certificates, which are the link between an entity’s identity and thepublic key (and hence private key) belonging to the entity. In the same way a passportproves your identity when trying to enter another country, a digital certificate provesyour identity in electronic transactions.Certificates include information such as the:• Identity’s name• Certificate issuer• Not before and not after dates (the validity period)• Public key• Valid uses for the certificate• Digital signature of the issuer across the certificate content. This ensures thedetails of the certificate have not been tampered with.The most widely accepted certificate format is X.509. It is described by the ITU-TX.509 certificate standard (http://www.itu.int/rec/T-REC-X.509/en) andformatted according to the Abstract Syntax Notation One (ASN.1) specification(http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf).58 Chapter 8: Public Key Infrastructure and Certificates

X.509 certificates contain the following information:RSA BSAFE Security Concepts• Version. The X.509 certificate format version number to which the certificateconforms. The latest is version 3.• Serial number. An identifier unique among the certificates created by its issuer.Although certificates with the same serial number can be issued by different CAs,the combination of the CA and the serial number uniquely identifies anycertificate.• Certificate signature algorithm. The message digest algorithm used to create themessage digest of the certificate, and the asymmetric key algorithm used toencrypt the message digest.• Issuer. The issuer of the certificate. The trusted authority that generated andsigned the certificate.• Not before validity date. The earliest time the certificate is valid and can be used.• Not after validity date. The latest time the certificate is valid and can be used.• Subject. The individual or entity identified by the certificate. Additionalinformation about the subject might also be included in the field.• Public key. The subject’s public key. It corresponds to the private key held by thesubject.• Subject public key algorithm. The asymmetric key algorithm corresponding to thesubject’s public key.• Extensions. X.509 certificates (version 3 only) can have an arbitrary number ofextensions, each of which is marked as critical or non-critical.• Signature. The digital signature of the issuer across all of the above fields.Extended Validation CertificatesThe use of certificates in on-line Web transactions provides a level of trust that a Website is legitimate. However, over time, CAs started issuing certificates for whichminimal verification was performed. Because most browser software did notdistinguish between low-validation and high-validation certificates, most users wouldbe unaware of whether a Web site owner was properly validated or not. This led tofraudsters using certificates to add credibility to their Web sites.Extended Validation (EV) certificates were introduced to address this problem. Theyare a special type of X.509 certificate. Certificates issued under the EV scheme requirethe CA to perform more extensive validation of the requesting entity before issuingthe certificate. These certificates must ultimately be signed by a trusted EV rootcertificate.Because of stricter issuing criteria consistently applied by all participating CAs, EVcertificates provide a higher level of trust that a Web site operator is a legallyestablished entity with a verifiable identity. Modern browsers which support EV alsoprovide greater information about the verification employed when a Web site using anEV certificate is accessed.Chapter 8: Public Key Infrastructure and Certificates 59

RSA BSAFE Security ConceptsWTLS CertificatesAttribute CertificatesWireless Transport Layer Security (WTLS) certificates are compliant with theWireless Application Protocol Wireless Transport Layer Security Specificationversion 1.1. WTLS certificates have similar characteristics to X.509 certificates, butare formatted differently and optimized for size because they are normally used inwireless communications where bandwidth is limited.Attribute certificates have the same structure and are similar to X.509 certificates, butbind an identity to authorization information. Attribute certificates do not contain akey. Attribute certificates contain attributes that specify group membership, role,security clearance, or other authorization information associated with the certificateholder.Certification AuthoritiesA CA is responsible for creating and issuing digital certificates. The CA is the trustedthird party that vouches for the identity of the individuals and organizations to whomthey issue certificates.A CA consists of different components or services, the most important of which arethe:• Registration Authority (RA)• Certificate server• Certificate repository.Registration AuthorityThe RA is responsible for registration and initial authentication of those wanting acertificate.To acquire a certificate, the subject sends a certificate request to the RA, along withproof of identity. This might be an automated process, or it could be a manual process(similar to a passport application) where the user submits documents, varying innumber and strength, according to the level of authentication required. The processdepends on rules imposed by the CA and impacts upon the perception of trust of thatCA by others.60 Chapter 8: Public Key Infrastructure and Certificates

RSA BSAFE Security ConceptsCertificate ServerThe certificate server is the machine or service responsible for issuing certificatesbased on the information provided during the registration process. If the informationsupplied by the subject is satisfactory, the certificate server generates the certificate,creates a message digest of the certificate body, signs the message digest, and appendsthe digest to the certificate body.Certificate RepositoryCertificates and the corresponding public keys need to be publicly available.Certificates ready for distribution are placed into the certificate repository, usually anX.500 or Lightweight Directory Access Protocol (LDAP) directory, from which thecertificate can be retrieved by those who want to communicate with the certificateowner.Certificate RevocationCertificates are issued with a limited lifespan and are only valid during the periodspecified by the NotBefore and NotAfter fields in the certificate. If the currentdate and time is earlier than the NotBefore value the certificate is not yet valid foruse. If the current date and time is later than the NotAfter value, the certificate isexpired. Neither of these types of certificates can be validated and should not be used.Certificates that are not expired, but for some other specific reason should not be used,are considered to be revoked. For example, if an entity no longer works for theorganization that requested the certificate, or if the private key related to thecertificate's public key is compromised, the CA will revoke the certificate.Usually, the entity that requests the certificate also instigates the revocation of thecertificate, but a CA can revoke a certificate if the entity uses the certificate in a waythat violates CA policy.Certificate Revocation ListsRevoked certificates are listed on a Certificate Revocation List (CRL). CRLs areadministered by CAs and are available for distribution in the same way as certificates.Certificates listed on the CRL are invalid and should not be used.Chapter 8: Public Key Infrastructure and Certificates 61

RSA BSAFE Security ConceptsOnline Certificate Status ProtocolAs an alternative to CRLs, the Online Certificate Status Protocol (OCSP) is anInternet protocol used to obtain the revocation status of a certificate.Instead of parsing a CRL to check the revocation status of a certificate, an entity sendsan OCSP request to the issuing CA, who then looks up the certificate details and sendsback an OCSP response indicating the certificate revocation status.Certificate ChainsIf one party wants to communicate with another, the sender retrieves the recipient’scertificate and extracts the public key. The sender trusts the CA and trusts the publickey belongs to the recipient because the CA says it does. But what if the senderdoesn’t know or trust the CA? What reason does the sender have to trust thecertificate?Somewhere in the system there must be a single point of trust. With millions ofcertificates issued every year, it is infeasible to have a handful of prominent CAsauthenticating the originator of every single certificate request and issuing a certificatein return.To solve this problem, PKI uses a hierarchy of CAs that issue certificates. The CA atthe top of the hierarchy is called the Root CA and is the entity mutually trusted by allusers of the PKI. The Root CA generates and signs the certificates of the Primary CAsit trusts to generate valid certificates. The Primary CAs generate and sign thecertificates of the Secondary CAs, and so on, until the CAs at the bottom of thehierarchy sign the end-user certificates. As long as one CA in the hierarchy is trusted,the end-user certificate can be trusted. The certificates issued by the CAs in a CAhierarchy form a certificate chain.62 Chapter 8: Public Key Infrastructure and Certificates

RSA BSAFE Security ConceptsThe following diagram illustrates a CA hierarchy.Figure 17CA HierarchyRoot CACertificatesPrimary CAsCertificatesCertificatesSecondary CAsCertificatesCertificatesWhen end-users exchange certificates, they also exchange the certificates in theircertificate chain, all linked by the certificate issuer and subject fields. The firstcertificate in the chain belongs to the end-user and the last belongs to the Root CA. Anend-user might not trust the issuer of a certificate, but if they trust the issuer’s issuer(or other issuers up the chain), then the end-user can trust the association between thepublic key and the owner of the certificate they are trying to communicate with.Self-signed CertificatesWho signs the Root CA’s certificate? Root CA certificates are signed by the Root CA.These are known as self-signed certificates, meaning the Root CA’s certificatevouches for itself. This is an acceptable solution because all users of the CA hierarchyagree the Root CA is trustworthy.Chapter 8: Public Key Infrastructure and Certificates 63

RSA BSAFE Security ConceptsCertificate ValidationBefore an end-user uses another’s public key, the end-user must verify the certificateis valid and is fit for the intended purpose. To achieve this, a number of validationsteps must occur, including:• Signature verification. The recipient of the certificate obtains the public key of thecertificate issuer, and uses it to verify the certificate signature. A verificationfailure indicates that the certificate information was not signed by the issuer andshould not be trusted. For example, some of the fields in the certificate might havebeen altered since the certificate was signed.• The certificate is current. That is, the certificate is not being used prematurely or isnot expired.• All certificate extensions marked as critical are supported and contain valid data.• The certificate is being used for the purpose for which it was created. Forexample, signing, encryption, or both.• The certificate is not revoked, determined either by OCSP with the issuing CA, orchecking that the certificate is not listed on the CRL published by the CA.These certificate validation steps must occur for all certificates in the certificate chain.Certificate Chain Validation ExampleBob sends his certificate to Alice, as well as the certificate chain that includesCharlie’s and Dave’s certificates. In this example, Dave is acting as the Root CA andself-signed his own and Charlie’s certificate. Because Dave is the Root CA, Alicetrusts the certificate from Dave. Alice needs to validate all certificates in the certificatechain.The following diagram illustrates the certificate chain.Figure 18Certificate ChainDave’s Certificate(signed by Dave)Charlie’s Certificate(signed by Dave)Bob’s Certificate(signed by Charlie)64 Chapter 8: Public Key Infrastructure and Certificates

Certificate StoreAlice does the following:RSA BSAFE Security Concepts1. Validate Bob’s certificate signature:a. Obtain the public key from Charlie’s certificate.b. Use Charlie’s public key to perform a signature verification on Bob’scertificate signature.2. Check the remaining characteristics of Bob’s certificate (it is current, its criticalextensions, the certificate purpose, and that it is not revoked).3. Validate Charlie’s certificate signature:a. Obtain the public key from Dave’s certificate.b. Use Dave’s public key to perform a signature verification on Charlie’scertificate signature.4. Check the remaining characteristics of Charlie’s certificate (it is current, itscritical extensions, the certificate purpose, and it is not revoked).5. Validate Dave’s certificate signature:a. Using Dave’s public key already retrieved, perform a signature verification onDave’s certificate signature.6. Check the remaining characteristics of Dave’s certificate (it is current, its criticalextensions, the certificate purpose, and that it is not revoked).Because Dave is a trusted authority, who signed Charlie’s certificate, who signedBob’s certificate, and Alice has validated all certificates in the certificate chain, Alicetrusts Bob’s certificate and can confidently use Bob’s public key.A certificate store contains the certificates of trusted entities (and in some cases,non-trusted entities). When a certificate is received from a sender, the recipientcompares it to the certificates held in the store. If a match is found in the list of trustedentities (or non-trusted entities), the sender is trusted (or not trusted). Provided thecertificate is trusted, and after certificate validation, transactions can proceed.Certificate stores are used to expedite the certificate validation process.Chapter 8: Public Key Infrastructure and Certificates 65

RSA BSAFE Security ConceptsThe following diagram illustrates a certificate store.Figure 19Certificate StoreReceivedCertificateCCertificate StoreA B CCompareDEFCertificate ExtensionsX.509 version 3 certificates includes support for optional extensions, enablingadditional fields to be included in the certificate without changing the certificatedefinition.Extension fields provide a way to associate additional information with the user’sidentity and public key. Some of the fields can provide additional information aboutthe user. Other fields can contain information on the intended use of the public key(for example, the key pair used for authentication or digital envelopes). Additionalfields can be used to locate other related certificates and certificate status information.An extension field is made up of an extension type, extension criticality, and anextension value.The extension criticality instructs a certificate-using application on whether it canignore an extension or not. If an extension is critical and the extension is notrecognized by an application, the application should reject the certificate. If anextension is noncritical and the application does not recognize the extension, it is safefor the application to ignore the extension and use the certificate.Extensions for X.509 certificates can be grouped into three categories:• Key and policy information extensions• Subject and issuer information extensions• Certification path constraints extensions.66 Chapter 8: Public Key Infrastructure and Certificates

RSA BSAFE Security ConceptsKey and Policy Information ExtensionsThe following are common key and policy information extensions:• Authority Key Identifier (AKI). Uniquely identifies the correct CA certificate incases where a CA might have multiple signing keys stored in multiple certificates.The AKI might be a unique octet string identifier for the CA certificate, thecombination of the CA issuer name and serial number, or both.• Subject Key Identifier (SKI). A unique octet string that identifies which public keyis being verified. Subjects can have multiple public keys, especially if keys arerenewed because of compromise or expiration.• Key Usage. Defines how the certificate’s public key can be used. Keys can only bevalid for certain kinds of operations. For example, a key can be valid forparticipation in key exchange mechanisms, but not for signing certificate requests.The key usage extension is a bit string, where multiple usage types are defined fora single key by combining bits.• Extended Key Usage. A similar concept to key usage except this option allowscustom usage definitions above those defined in the X.509 standard.• Private Key Usage. The private halves of asymmetric keys might need to havedifferent validity periods than those of the corresponding public keys. The validityperiod specified in certificates relates to the public key only. However, it might benecessary to terminate the use of the private key (for example, for signing), while thepublic key remains valid (for example, for verification). Private key usage allowsnotBefore and notAfter times to be defined for the private part of the key.Subject and Issuer Information ExtensionsDepending on the application, it might be convenient for the name of the subject orissuer of certificates to be defined differently from the standard X.500 format. Forexample, it might be useful when communicating via the Internet to have access to theDNS name or IP address of the owner/signer of the certificate. The alternate namefields enable this information to be included in the certificate.Certification Path Constraints ExtensionsBasic Constraints is a common certification path constraints extension that protectsagainst entities establishing themselves as CAs without authorization, and limits thechain length that can result from authorizing intermediate CAs. The extensioncontains two fields:• A Boolean value, indicating whether the entity is a CA or not.• An integer value, indicating the maximum certificate chain length that can bederived from this CA.For example, if a CA has a path length of 1, then it can create valid sub-CAs, but thesein turn can only issue valid end entity certificates, not valid CA certificates. The pathlength constraint is optional, but if it exists it can override the Boolean CA value inanother certificate in the chain.Chapter 8: Public Key Infrastructure and Certificates 67

RSA BSAFE Security ConceptsCertificate RequestsA certificate request is usually required after an entity generates a new public andprivate key pair. A certificate request can also be required after a change to the subjectname. The request contains the information that is required to appear in the certificate,including the subject name and public key, and, optionally, certain attributes. Thisinformation is ASN.1 Distinguished Encoding Rules (DER)-encoded and signed bythe subject.When the CA receives the entity’s certificate request, it validates the certificaterequest by generating and comparing its own digest of the certificate information (theentity’s public key, subject name and attributes) against the digest provided by theentity. The CA obtains the signature algorithm identifier from the request along withthe entity’s public key. It uses this information to decrypt the request signature andcompare the result to its own hash value.If the digests match, the CA can transform the request to a certificate. It returns thiscertificate, possibly along with a certification path to itself or, in the case of X.509certificates, a CRL.Certificate requests can be created using either PKCS #10 or Certificate RequestMessage Format (CRMF). CRMF is used in conjunction with the CertificateManagement Protocol (CMP), an Internet protocol for obtaining certificates from aCA.For more information about the PKCS#10 standard, see “PKCS #10” on page 90. Formore information about CRMF, see RFC 4211, Certificate Request Message Format(CRMF) ( http://tools.ietf.org/html/rfc4211). For more informationabout CMP, see RFC 4210, Certificate Management Protocol (CMP)(http://tools.ietf.org/html/rfc4210).Note: PKCS #10 or CRMF does not prescribe methods for passing the requestto the CA and returning the certificate to the client, or indicate how the CAshould authenticate the client.68 Chapter 8: Public Key Infrastructure and Certificates

RSA BSAFE Security Concepts9 TransportLayer SecurityThe Transport Layer Security (TLS) protocol, and its predecessor, Secure SocketsLayer (SSL) protocol, is a set of rules governing secure data communications overTCP/IP networks. TLS and SSL are the most widely used protocols for transmittingdata across the Internet in applications where confidentiality, authentication, and dataintegrity are required.This chapter provides a brief overview of development of SSL and TLS, and describesthe protocols making up TLS.Topics:• SSL and TLS Development• TLS Protocols• TLS Renegotiation VulnerabilityChapter 9: Transport Layer Security 69

RSA BSAFE Security ConceptsSSL and TLS DevelopmentThe SSL protocol was originally developed by Netscape for use in its web browser.SSLv1 was never publicly released.SSLv2, released in 1995, contained a number of security flaws.SSLv3, released in 1996, solved the security problems of SSLv2, as well as addingsupport for more algorithms and certificate chains.TLS 1.0 (RFC 2246, http://tools.ietf.org/html/rfc2246), released in1999, was based on SSLv3 and developed by the Internet Engineering Task Force(IETF).TLS 1.1 (RFC 4346, http://tools.ietf.org/html/rfc4346), released in2006, contained some minor security improvements, such as changes to InitializationVector (IV) usage and the handling of padding errors.TLS 1.2 (RFC 5246, http://tools.ietf.org/html/rfc5246), released inAugust 2008, is the latest version of TLS and provides better flexibility in thenegotiation of cryptographic algorithms.TLS ProtocolsA TLS (and SSL) communication session between a client and a server is made up offour components:• Handshake protocol.At the beginning of the communication session, the handshake protocol is wherethe client and server negotiate the rules and parameters for the session. Ininformation technology terms, handshaking is an automated process ofnegotiation between two entities.During the handshake protocol, the client and server also exchange certificates,and exchange random numbers for the generation of keys for use in laterencryption and decryption operations.• Record Protocol.On successful completion of the handshake protocol, the record protocol specifieshow application data communicated between the client and server is packaged.Records can be compressed, padded, appended with a MAC, or encrypted,depending on the state of the communication session.• Alert Protocol.The alert protocol is used by the handshake and record protocols to alert the clientand server of aberrations or errors during a communication session.• Change Cipher Spec Protocol.70 Chapter 9: Transport Layer Security

Handshake ProtocolRSA BSAFE Security ConceptsThe change cipher spec protocol is used to indicate a change in the cipher suite.A client and server establish a secure communication session using the handshakeprotocol. The steps of the handshake protocol vary depending on the TLS or SSLversion, and whether server and the client are to be authenticated using certificates. Italso depends on whether the client and server are negotiating a new session orrenegotiating an old session.Cipher SuitesOne of the main things agreed upon in the handshake protocol is the cipher suite. Thecipher suite is the set of cryptographic algorithms to be used during thecommunication session to provide authentication, encryption, and data integrity.Generally, the client and server support a range of cipher suites to maximize thechances of finding a mutually supported cipher suite.The cipher suite agreed upon in the handshake protocol includes the:• Key exchange algorithm. For example, RSA, Diffie-Hellman (DH), or EllipticCurve DH (ECDH).• Signature algorithm. For example, RSA, DSA, or Elliptic Curve DSA (ECDSA).• Encryption algorithm, and key size and mode where appropriate. For example,AES 128 in GCM mode, Triple DES in CBC mode, or RC4.• Message digest algorithm. For example, SHA-1, SHA-256, or SHA-384.The agreed cipher suite is usually the strongest one supported by both the client andserver.Cipher suite names describe the cipher suites in terms of the algorithms included in thecipher suite. For example, the TLS_ECDHE_ECDSA_AES_128_GCM_SHA256 ciphersuite uses ephemeral ECDH as the key exchange, ECDSA as the signature algorithm,AES (with a 128-bit key, working in GCM mode) as the encryption algorithm, andSHA-256 as the message digest algorithm.Basic HandshakeThe following steps describe a basic handshake, with the client authenticated usingcertificates. Note that client authentication is optional and is requested by the server, ifrequired.1. A client wanting to communicate with a server sends a ClientHello message,specifying the highest TLS or SSL version it supports, a random number, a list ofsuggested cipher suites and compression methods.2. The server responds with a ServerHello message, containing the chosenprotocol version, a random number, and cipher suite and compression methodfrom the choices offered by the client.Chapter 9: Transport Layer Security 71

RSA BSAFE Security Concepts3. The server sends a Certificate message, containing the server’s certificateand certificate chain.4. The server sends a CertificateRequest message, requesting a certificatefrom the client so the connection can be mutually authenticated.5. The server sends a ServerHelloDone message.6. The client sends a Certificate message, containing the client's certificate, ifrequested by the server. The client might not send a certificate because it does nothave one that is appropriate. The server can accept this and continue thehandshake, or fail.7. The client sends a ClientKeyExchange message. Depending on whether RSA,DH, or ECDH is specified as the key exchange algorithm in the agreed ciphersuite, the ClientKeyExchange message contains either a pre-master secretencrypted with the server’s public key (RSA key exchange algorithm) or publicparameters required for master key generation (DH or ECDH key exchangealgorithms).This message is empty if the server and client certificates contain compatiblefixed DH keys.8. The client sends a CertificateVerify message, which is a signature over theprevious handshake messages using the client's private key. This signature can beverified by the server using the public key from the client's certificate. Thisauthenticates the client to the server.This message is not sent if the server and client certificates contain compatiblefixed DH keys.9. The client and server use the random numbers from the Hello messages, and thepre-master secret from the ClientKeyExchange message, to compute acommon master secret. All other key data for this connection is derived from thismaster secret (and the client- and server-generated random values).10. The client sends a ChangeCipherSpec message, telling the server everythingfrom now on will be protected using the specified cipher suite. The client updatesits current cipher suite to be this new cipher suite.11. The client sends a Finished message, which is an encryption of the client’sprevious handshake messages using the algorithms of the new cipher suite.12. The server attempts to decrypt the client's Finished message to verify the clientmessages were not tampered with. If the decryption or verification fails, thehandshake is considered to have failed and the connection is closed.13. The server sends a ChangeCipherSpec message, telling the client everythingfrom now on will be protected using the specified cipher suite. The server updatesits current cipher suite to be this new cipher suite.14. The server sends a Finished message, which is an encryption of the server’sprevious handshake messages using the algorithms of the new cipher suite.15. The client attempts to decrypt the server’s Finished message to verify the servermessages were not tampered with. If the decryption or verification fails, thehandshake is considered to have failed and the connection is closed.72 Chapter 9: Transport Layer Security

RSA BSAFE Security ConceptsThe handshake is complete and the client and server can exchange encrypted andintegrity-protected application data using the algorithms specified in the agreed ciphersuite.The following diagram illustrates the steps in the basic handshake protocol.Figure 20Basic Handshake ProtocolClientServer1. ClientHello 2. ServerHello3. Certificate4. CertificateRequest5. ServerHelloDone6. Certificate7. ClientKeyExchange8. CertificateVerfify9. Compute master secret10. ChangeCipherSpec11. Finished15. Verify server’s Finished message9. Compute master secret12. Verify client’s Finished message13. ChangeCipherSpec14. FinishedHandshake CompleteEncrypted Application DataEncrypted Application DataSession Reuse HandshakeRather than negotiate a new session, the server can decide to resume an old sessionusing a session reuse handshake. A session reuse handshake is a shortened version ofthe basic handshake, which saves time and bandwidth. If the server determines that theold session is no longer valid (for example, the session is expired), then a fullhandshake is requested by the server.The following steps describe a session reuse handshake:1. A client wanting to resume an old session with a server sends a ClientHellomessage. The message contains the session ID of the session.2. If the server can locate the session ID and associated parameters in its sessioncache, and if the server is willing to resume the session, the server responds with aServerHello message with the same session ID.3. The server sends a ChangeCipherSpec message, telling the client everythingfrom now on will be protected using the algorithms specified by the cipher suiteand keys generated using the master secret of the old session and the randomvalues exchanged in the latest Hello messages. The server updates its currentcipher suite to be this new cipher suite.4. The server sends a Finished message, which is an encryption of the server’sprevious handshake messages using the algorithms of the new cipher suite.Chapter 9: Transport Layer Security 73

RSA BSAFE Security Concepts5. The client attempts to decrypt the server’s Finished message to verify the servermessages were not tampered with. If the decryption or verification fails, thehandshake is considered to have failed and the connection is closed.6. The client sends a ChangeCipherSpec message, telling the server everythingfrom now on will be protected using the specified cipher suite. The client updatesits current cipher suite to be this new cipher suite.7. The client sends a Finished message, which is an encryption of the client’sprevious handshake messages using the algorithms of the new cipher suite.8. The server attempts to decrypt the client's Finished message to verify the clientmessages were not tampered with. If the decryption or verification fails, thehandshake is considered to have failed and the connection is closed.The session reuse handshake is complete and the client and server can exchangeapplication data encrypted using the algorithm specified in the agreed cipher suite.The following diagram illustrates the steps in the session reuse handshake protocol.Figure 21Session Reuse Handshake ProtocolClientServer1. ClientHello5. Verify server’s Finished message6. ChangeCipherSpec7. Finished2. ServerHello3. ChangeCipherSpec4. Finished12. Verify client’s Finished messageHandshake CompleteEncrypted Application DataEncrypted Application DataRecord ProtocolThe record protocol receives data from the higher layers (including the handshakeprotocol), and it is here data is encrypted, decrypted and authenticated. The followingsteps occur in transmitting data between entities:1. Fragmentation. Data to be transmitted is fragmented into blocks(TLSPlaintext) of 16 KB or less. Each TLSPlaintext block can containmore than one unit of data of the same type. For example, application data,handshake data, or alert data.2. Compression. If compression is supported by the application, theTLSPlaintext blocks are then compressed using the compression methodagreed upon during the handshake. The output of the compression process isTLSCompressed data.74 Chapter 9: Transport Layer Security

Alert ProtocolRSA BSAFE Security Concepts3. Authentication Encoding. A MAC of the TLSCompressed data, using the MACalgorithm specified in the agreed cipher suite, is appended to TLSCompresseddata.4. Encryption. The combined TLSCompressed data and MAC are encrypted usingthe encryption algorithm specified in the agreed cipher suite, and the key derivedfrom the handshake master secret, to produce TLSCiphertext data.5. Header Addition. Each record is prefixed with a header comprised of fieldsdescribing the content type, TLS (or SSL) version details, and length of the record.The recipient of the data reconstructs it by reversing the process:1. Header Removal. Removal of the fields describing the content type, version, andlength of the record.2. Decryption. The recipient decrypts the data and strips off the MAC, but does notdiscard it.3. Integrity Calculation. The recipient calculates its own MAC of theTLSCompressed data using the MAC algorithm specified in the agreed ciphersuite. By comparing its own MAC with that received from the sender, the recipientcan determine whether the message was altered during transmission. If this is thecase, it discards the message and requests a resend, probably under a new session.4. Decompression. The recipient decompresses the data using the compressionmethod agreed upon during the handshake.5. Defragmentation. The recipient reassembles the received block of data with otherreceived blocks according to semantics imposed by the application it uses.Both the handshake and record protocols use the alert protocol to inform entities ofcommunication and security errors. Each alert message is associated with a severitylevel of either warning or fatal. Warning alerts are informational, while fatal alertsresult in the termination of the communication session.The following are some of the common alerts supported by TLS:• close_notify. A fatal or warning alert indicating the connection is beingclosed. Closure of a connection without this alert brings the session to a halt.• unexpected_message. A fatal alert indicating the order of operations in ahandshake was violated.• bad_record_mac. A fatal alert indicating an error in the MAC, possibly due toan illicit alteration of the message.• handshake_failure. A fatal alert indicating the client and server were unableto complete handshake negotiation successfully.• certificate_expired. A fatal or a warning alert indicating a certificate usedfor authentication during the handshake is not current and therefore cannot be used.Chapter 9: Transport Layer Security 75

RSA BSAFE Security ConceptsChange Cipher Spec ProtocolThe change cipher spec protocol is used by clients and servers to notify the receivingpeer that the following records are protected using a newly negotiated cipher suite.The protocol is sent during a handshake, but can also be sent any time after the initialhandshake.TLS Renegotiation VulnerabilitySSL and TLS renegotiations are vulnerable to man-in-the-middle attacks. Aman-in-the-middle attack is where an attacker makes independent connections with aserver and a client and can inject content, of their choice, into the datastream. Theserver believes that the initial data sent by the attacker and the subsequent client dataare from the same entity.Security for SSLv3 and TLS renegotiations is described in detail in RFC 5746(http://tools.ietf.org/html/rfc5746). The following summarizes TLSrenegotiation security, including steps for the initial handshake and for securerenegotiations.In the initial handshake:1. The client sends either an empty renegotiation extension or the renegotiationcipher suite in the ClientHello message to a server.2. The server checks the ClientHello message for either the renegotiation ciphersuite or a renegotiation extension. If either is included, secure renegotiation isenabled for the server. If neither is included, secure renegotiation is not enabled.Depending on how the server is configured, if secure renegotiation is not enabled,the server might terminate the handshake.3. If secure renegotiation is enabled on the server, the server includes an emptyrenegotiation extension in the ServerHello message back to the client.4. The client checks the ServerHello message for the renegotiation extension. If itis included, the client enables secure renegotiation. If it is not included, securerenegotiation is not enabled on the client. Depending on how the client isconfigured, if secure renegotiation is not enabled, the client might terminate thehandshake.5. When the initial handshake is complete, both the client and server saveverification data for later use.In a secure renegotiation:1. The client includes a renegotiation extension in the ClientHello message to theserver. The extension contains client verification data saved from the initialhandshake.2. The server checks that the ClientHello message does not include therenegotiation cipher suite. If it does, the server rejects the renegotiation.76 Chapter 9: Transport Layer Security

RSA BSAFE Security Concepts3. The server checks that the ClientHello message includes a renegotiationextension. If it does not, the server rejects the renegotiation.4. The server checks that the client verification data in the renegotiation extensionequals its own client verification data saved from the initial handshake. If it doesnot, the server rejects the renegotiation.5. The server includes a renegotiation extension in the ServerHello message tothe client. The extension contains client and server verification data saved fromthe initial handshake.6. The client checks that the ServerHello message includes a renegotiationextension. If it does not, the client rejects the renegotiation.7. The client checks that the client and server verification data in the renegotiationextension equals its own client and server verification data saved from the initialhandshake. If it does not, the client rejects the renegotiation.8. When the renegotiation handshake is complete, both the client and server saveverification data for later use.Insecure Connections and RenegotiationsUpgrades to public facing SSL and TLS servers to include the security featuresoutlined in RFC 5746 (http://tools.ietf.org/html/rfc5746) will occur overtime. Until all servers are upgraded, secure SSL and TLS clients should be ready toconnect and perform renegotiation with trusted, insecure servers. It is theresponsibility of the application to determine which servers are to be trusted or not.Likewise, upgrades to SSL and TLS clients to include the security features outlined inRFC 5746 will occur over time. Secure servers should allow renegotiations withinsecure clients only when it is required for the Web site to continue functioning. Inthese cases, steps need to be taken to ensure attacks cannot be made at the applicationdata level.Chapter 9: Transport Layer Security 77

RSA BSAFE Security Concepts78 Chapter 9: Transport Layer Security

RSA BSAFE Security Concepts10NSA Suite B CryptographyNational Security Agency (NSA) Suite B Cryptography specifies a set of FederalInformation Processing Standard (FIPS) 140-approved cryptographic algorithms forthe protection of classified and unclassified data.As part of the NSA cryptographic modernization program, the aim of Suite BCryptography is to ensure implementors use cryptographic components with the samesecurity strength. Suite B Cryptography is appropriate for use in US governmentapplications and where strong cryptography is required.Topics:• Security Strength• Specified Cryptographic Algorithms• Certificate Chain Validation• Transport Layer Security and Cipher SuitesChapter 10: NSA Suite B Cryptography 79

RSA BSAFE Security ConceptsSecurity StrengthSecurity strength is a measure of the strength offered by a cryptographic algorithmused with a specific key size. Essentially, security strength reflects how hard it is tobreak an algorithm.The following table compares the security strengths of some common cryptographicalgorithm and key size combinations.Table 3Cryptographic Algorithm Security StrengthSecurityStrength(bits)Symmetric KeyAlgorithmAsymmetric KeyAlgorithmElliptic CurveAsymmetric KeyAlgorithmMessage DigestAlgorithm80 (too weak by2010)Triple DES (2 key)RSA or DSA,1024-bit keyECDSA, 160-bit keySHA-1112 (too weakby 2030)Triple DES (3 key)RSA or DSA,2048-bit keyECDSA, 224-bit keySHA-224128 AES, 128-bit key RSA or DSA,3072-bit key192 AES, 192-bit key RSA or DSA,7060-bit key256 AES, 256-bit key RSA or DSA,15360-bit keyECDSA, 256-bit keyECDSA, 384-bit keyECDSA, 512-bit keySHA-256SHA-384SHA-512Note the following points about the information provided in the previous table:• A security strength of 80 is now considered to provide inadequate cryptographicprotection.• A security strength of 112 will be inadequate by the year 2030.• Asymmetric key algorithms require relatively large key sizes to provide adequatelevels of data protection.• Elliptic curve asymmetric key algorithms require relatively small key sizes toprovide the same level of data protection.Another important issue is combining cryptographic algorithms of different strengths.For example, an organization that uses AES with a 128-bit key and RSA with a1024-bit key, has an effective security strength of only 80 bits. That is, the effectivesecurity strength is only as strong as the weakest cryptographic algorithm used.80 Chapter 10: NSA Suite B Cryptography

RSA BSAFE Security ConceptsSpecified Cryptographic AlgorithmsSuite B Cryptography specifies the use of the following FIPS 140-approvedcryptographic algorithms:• AES for symmetric key encryption• ECDSA for digital signatures• ECDH for key exchange• SHA-2 (SHA-256 and SHA-384) for message digests.As well as specifying the algorithms to use, Suite B also specifies two categories ofsecurity strength:• Secret information (128-bit security strength):– AES, 128-bit key– ECDSA with the NIST P-256 elliptic curve– ECDH with the NIST P-256 elliptic curve– SHA-256• Top secret information (192-bit security strength):– AES, 256-bit key 1– ECDSA with the NIST P-384 elliptic curve– ECDH with the NIST P-384 elliptic curve– SHA-384.Note: Suite B Cryptography only specifies the algorithms to use and in whichsituations. Other factors to consider when implementing a cryptographic solutioninclude:• Implementation quality of the cryptographic algorithms, in software, firmware, orhardware.• Key and key management operational requirements.• Uniqueness of the information to be protected.• Interoperability requirements, domestically and internationally.1 For top secret information, AES with a 192-bit key was to be specified, but the processing requirementsbetween AES 192 and AES 256 is minimal, so the stronger AES 256 was specified.Chapter 10: NSA Suite B Cryptography 81

RSA BSAFE Security ConceptsCertificate Chain ValidationAs well as specifying the cryptographic algorithms to use and in which situations,Suite B Cryptography also affects certificate chain validation.Certificates are the link between an entity’s identity and the public key (and henceprivate key) belonging to the entity. Before an end-user uses another’s public key froma certificate, the end-user must verify the certificate is valid and is fit for the intendedpurpose. Part of this process is to verify the certificate digital signature.The recipient of a certificate obtains the public key of the certificate issuer, and uses itto verify the certificate signature. A verification failure indicates that the certificateinformation was not signed by the issuer and should not be trusted. For example, someof the fields in the certificate might have been altered since the certificate was signed.The certificate validation steps must occur for all certificates in a certificate chain.There are two levels of certificate chain validation compliance: Suite B and NSASuite B compliance. Whether a certificate chain is Suite B or NSA Suite B compliantis described in detail in RFC 5430 (Suite B compliance)(http://tools.ietf.org/html/rfc5430) and the NSA Suite B compliance(http://www.nsa.gov/ia/_files/industry/Suite_B_Certificate_and_CRL_Profile_20080528.pdf).Both Suite B and NSA Suite B compliance requires the following:• For end-user certificates, ECDSA is the signing algorithm, using either the P-256(128-bit security) or P-384 (192-bit security) curves.• For intermediate Certification Authority (CA) and root CA certificates in thecertificate chain, ECDSA is the signing algorithm, using the same or strongercurve than that used for the end-user certificate (restricted to P-256 or P-384curves).NSA Suite Bcompliance requires specific values for certain certificate extensions.Effectively, Suite B or NSA Suite B certificate validation ensures that no certificate ina certificate chain has a weaker security strength than a certificate further down thechain.82 Chapter 10: NSA Suite B Cryptography

RSA BSAFE Security ConceptsTransport Layer Security and Cipher SuitesTLS is a set of rules governing secure data communications over TCP/IP networksbetween a client and a server. During a TLS connection setup, the client and servernegotiate a cipher suite. The cipher suite is the set of cryptographic algorithms to beused during the communication session to provide authentication, encryption, and dataintegrity. The client and server usually support a range of cipher suites (a cipher suitelist) to maximize the chances of finding a mutually supported cipher suite.The Suite B Profile for TLS (RFC 5430) defines two cipher suite profiles:• Suite B compliant, for use with TLS 1.2 (RFC 5246)(http://tools.ietf.org/html/rfc5246) and elliptic curve cipher suitesthat include AES (in GCM mode) and SHA-256/384 (RFC 5289)(http://tools.ietf.org/html/rfc5289).• Suite B transitional, for use with TLS 1.0 or 1.1 and elliptic curve cipher suites(RFC 4492) (http://tools.ietf.org/html/rfc4492). This profile usesthe Suite B cryptographic algorithms to the greatest extent possible, and providesa transition path to Suite B compliance.The rules for whether a client or server is Suite B compliant or transitional aredescribed in detail in RFC 5430. In summary, the Suite B compliant profile requires:• TLS 1.2.• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (128-bit security) orTLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (192-bit security) be thepreferred cipher suites.• For maximum interoperability, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (128-bit security) or TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (192-bit security) can be the second choice cipher suites.• For backward interoperability, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(128-bit security) or TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (192-bitsecurity) can be the third choice cipher suites.• Finally, other cipher suites can be offered after the cipher suites listed above.Note: Only connections negotiated usingTLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, orTLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 are Suite B compliant.Chapter 10: NSA Suite B Cryptography 83

RSA BSAFE Security ConceptsThe Suite B transitional profile requires:• TLS 1.1 or 1.0.• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (128-bit security) orTLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (192-bit security) be thepreferred cipher suites.• For interoperability, other cipher suites can be offered after the cipher suites listedabove.84 Chapter 10: NSA Suite B Cryptography

RSA BSAFE Security ConceptsA Public Key Cryptography StandardsThe Public Key Cryptography Standards (PKCS) are a series of specificationsproduced by RSA Laboratories in co-operation with developers of secure systemsthroughout the world. They were developed to promote and accelerate the deploymentof public key cryptography.The PKCS specifications are continually enhanced and provide an industry-acceptedreference and implementation for public key cryptography. Selected sections of thePKCS series have become part of many formal and de facto standards, includingANSI X9 documents, PKIX, SET, S/MIME and SSL.All of the current PKCS standards are accessible on the RSA Web site, athttp://www.rsa.com/rsalabs/node.asp?id=2124.The PKCS series of standards are listed in the following table.Table 4PKCS StandardsStandardPKCS #1DescriptionRSA Cryptography Standard.PKCS #2 Incorporated into PKCS #1.PKCS #3Diffie-Hellman Key Agreement Standard.PKCS #4 Incorporated into PKCS #1.PKCS #5PKCS #6PKCS #7PKCS #8PKCS #9PKCS #10PKCS #11PKCS #12Password-Based Cryptography Standard.Extended-Certificate Syntax Standard.Cryptographic Message Syntax Standard.Private Key Information Syntax Standard.Selected Attribute Types.Certification Request Syntax Standard.Cryptographic Token Interface Standard.Personal Information Exchange Syntax Standard.Appendix A: Public Key Cryptography Standards 85

RSA BSAFE Security ConceptsTable 4PKCS Standards (continued)StandardPKCS #13PKCS #14PKCS #15DescriptionElliptic Curve Cryptography Standard.Pseudo-random Number Generation.Cryptographic Token Information Format Standard.PKCS #1PKCS #1 is the RSA Cryptographic Standard. It recommends techniques forimplementing public key schemes based upon the RSA algorithm. PKCS #1 schemesinclude:• Encryption schemes, each consisting of an encryption and decryption operation.• Signature schemes with appendix, including signature generation and verification.The encryption schemes are Optional Asymmetric Encryption Padding(RSAES-OAEP) and PKCS #1 v1.5 (RSAES-PKCS1-v1_5). Use of OAEP ispreferred for new systems because of its stronger security properties.The signature schemes include RSASSA-PKCS1-v1_5 and the probabilistic schemeRSASSA-PSS, which includes a randomly generated salt. Use of RSASSA-PSS ispreferred, again due to its stronger security properties.The standard also describes a series of cryptographic and encoding primitives for usein the asymmetric key schemes. The cryptographic primitives are encryption,decryption, signing and verification. The encoding primitives convert integers to octetstrings and vice versa.These primitives use RSA public and private key pairs and include support forMultiPrime key generation. The format of the keys are described, but methods forgenerating them are not.The PKCS #1 standard also describes the Abstract Syntax Notation (ASN.1)representation of keys and Object Identifiers (OIDs) for its schemes.PKCS #3PKCS #3 is the Diffie-Hellman Key Agreement Standard. It describes a method forimplementing Diffie-Hellman key exchange, whereby two parties, without any priorarrangements, can agree upon a secret key known only to them (and, in particular, isnot known to an eavesdropper listening to the dialogue by which the parties agree onthe key). This secret key can then be used to encrypt further communications betweenthe parties.86 Appendix A: Public Key Cryptography Standards

RSA BSAFE Security ConceptsPKCS #5PKCS #5 is the Password-based Cryptography Standard. It describes a method togenerate a secret key based on a password, and covers the implementation ofpassword-based cryptography, including key derivation functions, encryptionschemes, message authentication schemes and ASN.1 syntax identificationtechniques.PKCS #6PKCS #6 is the Extended-Certificate Syntax Standard. It describes the syntax forextended certificates, consisting of a certificate and a set of attributes, collectivelysigned by the issuer of the certificate. The intended application of this standard is toextend the certification process beyond just the public key to certify other informationabout the given entity. This is currently being phased out in favour of X.509 v3.PKCS #7PKCS #7 is the Cryptographic Message Syntax Standard. It describes the syntax fordigital envelopes and signatures. It includes facilities for envelope nesting. Thestandard defines six content types including:• Data. Arbitrary octet strings without an imposed internal structure.• Digested data. Data of any content type combined with a message digest of thatdata.• Encrypted data. Data of any content type encrypted under an external key.• Signed data. Data of any content type combined with a signed message digest ofthat data.• Enveloped data. Encrypted data combined with the encrypting key, which is itselfencrypted using the public key of the recipient.• Signed-and-enveloped data. Enveloped data combined with a signed messagedigest encrypted using the public key of the recipient.PKCS #7 is designed to process data in a single pass using indefinite length BasicEncoding Rules (BER) encoding. Some content types require Distinguished EncodingRules (DER) which is difficult to process in a single pass, as variable lengths may notbe known in advance. This might necessitate an extra pass.A digital signature verifies message details such as the origin, time and date of adocument, the identity of the sender and the identity of a computer or user. It is basedon both the document and the signer's private key, and is typically created through theuse of a message digest algorithm.Appendix A: Public Key Cryptography Standards 87

RSA BSAFE Security ConceptsDigital EnvelopeA digital envelope is a way to send a message privately from sender to recipient, whilealso providing authentication of the sender.With a digital envelope, the sender encrypts a message using a symmetric keyencryption algorithm, and then encrypts the symmetric key using the recipient’s publickey. The recipient then decrypts the symmetric key using their own private key anddecrypts the message with the symmetric key. This combines the advantages ofsymmetric key and asymmetric key cryptography. It is a fast encryption method thatcan process large amounts of data, yet secret information is never transmittedunencrypted.Streaming/Standard ImplementationsThere are two PKCS #7 implementations, standard and streaming. The standardinterface processes cryptographic messages as single blocks of data. It requiresmemory for the entire message to be available prior to processing. Streamed messagescan be progressively constructed/parsed into memory buffers of fixed length. If thereis a large amount of data, such as a streaming video, it might be impracticable from amemory standpoint to construct the complete message. By streaming the data, themessage can be partitioned into smaller blocks without compromising the securityprovided by PKCS #7.The streaming implementation supports the following features from PKCS #7:• Creation of indefinite length data, enveloped data and signed data messages.• Parsing of definite and indefinite length data, enveloped data and signed datamessages.• Creation of messages with multiple recipients (enveloped) and signers (signed).• Creation of nested messages.• Messages in binary format only (DER).Alternatively an application can implement the standard or non-streamingimplementation, whereby the entire message is processed in a single block. Thestandard interface supports the following features from PKCS #7:• Creation of definite length data, enveloped data and signed data messages.• Parsing of definite and indefinite length data, enveloped data and signed datamessages.• Creation of definite length detached data messages (enveloped and signed) wherethe data is stored in a separate file.• Creation of definite length detached data messages (enveloped and signed) wherethe data is appended to the message.• Creation of messages with multiple recipients (enveloped) and signers (signed).• Creation of nested messages.88 Appendix A: Public Key Cryptography Standards

RSA BSAFE Security Concepts• Messages in Privacy Enhanced Mail (PEM) and binary (DER) formats.Standard messages must have enough memory allocated to accommodate the entiremessage before being written or read.Streamed MessageIndefinite length messages are designed for applications where only part of themessage may be constructed, or delivered, at a time (and so the full length is unknownuntil the end of the message is received).End of Content (EOC) markers identify the end of different parts of these messages.Non-Streamed MessageThe length of definite length encoded messages is known in advance and stored as partof the sequence header information.AttributesSigned data messages allow additional information, in the form of PKCS #9 attributes,to be stored as part of the message. Attributes may be authenticated (signed by thesigner of the message) or unauthenticated (unsigned). Attributes can be used in boththe streaming and non-streaming implementation. The following are some commonattribute types:• Content Type.Specifies the type of content being signed. This is usually data, however PKCS #7enables the nesting of messages, so it could also be a data type such as signed orenveloped. This attribute type must be included if there are any otherauthenticated attributes in the message.• Message Digest.When this attribute is included it contains the message digest of the contentsection of the message. This attribute must be included if there are any otherauthenticated attributes in the message.• Signing Time.Specifies the time the signer performed the signing operation. The signing timemay be expressed in Coordinated Universal Time (UTC) or Generalized timeformat.• Counter Signatures.An unauthenticated attribute enabling external parties to add their signature to theencrypted message digest part of the PKCS #7 signed message. The countersignature attribute cannot be authenticated as it is added after the signer signs themessage.Appendix A: Public Key Cryptography Standards 89

RSA BSAFE Security ConceptsPKCS #8PKCS #8 is the Private Key Information Syntax Standard. It describes the syntax forprivate keys and encrypted private keys.The private key syntax includes an identifier for the private key, the private key itselfand a series of X.501 attributes. The encrypted private key syntax includes the privatekey information once encrypted and an identifier for the encryption algorithm used.PKCS #9PKCS #9 is the Selected Attribute Types Standard. It defines selected attribute typesfor use in PKCS #6, PKCS #7, PKCS #8 and PKCS #10.PKCS #10PKCS #10 is the Certificate Request Syntax Standard. It describes the syntax for acertificate request and is used primarily to support PKCS #7 cryptographic messages.A certificate request is typically sent after generating a public key/private key pair. Itmay also be sent after a modification to an entity’s Distinguished Name (DN). Theinformation in a request contains the version number of the certificate requested, thesubject’s DN and public key and optionally some attributes. This information isencoded into octet strings using DER and signed by the subject.Once the subject is authenticated, the CA builds a X.509 certificate. It returns thiscertificate, possibly along with a certification path to itself or a Certificate RevocationList.PKCS #11PKCS #11 is the Cryptographic Token Interface Standard. It specifies the CryptokiApplication Programming Interface (API) for devices holding cryptographicinformation and perform cryptographic functions. Cryptoki isolates an applicationfrom the details of the cryptographic device. The application does not have to changeto interface to a different type of device or to run in a different environment; thus, theapplication is portable.PKCS #11 addresses the goals of technology independence (any kind of device) andresource sharing (multiple applications accessing multiple devices), presenting toapplications a common, logical view of the device called a cryptographic token.90 Appendix A: Public Key Cryptography Standards

General ModelSession OperationsRSA BSAFE Security ConceptsA number of cryptographic mechanisms (algorithms) are supported in the latestversion. Cryptoki v2.1 is intended for cryptographic devices associated with a singleuser, so some features that might be included in a general purpose interface areomitted. For example, Cryptoki v2.1 does not have a means of distinguishing multipleusers. The focus is on a single user’s keys and perhaps a small number of certificatesrelated to them.Smart cards and other portable computing devices provide a means to store the privatekey component of a public/private key pair securely under the control of a single user.Cryptographic applications utilize the device to perform cryptographic operationsrather than performing the operations within the application itself. This meansinformation such as private keys need never be revealed. A standard programminginterface for these devices is required as more applications are developed for publickey cryptography. PKCS #11 addresses this need.Cryptoki provides an interface to active devices through slots. Each slot correspondsto a physical reader or device interface that might contain a token. A token isconsidered to be present in the slot when a cryptographic device is present in thereader. Cryptoki provides only a logical view of slots and tokens.Cryptographic operations are passed through standard device drivers and Cryptokimakes each cryptographic device look logically the same regardless of theimplementation technology. Because Cryptoki hides the device driver details, theunderlying device may be implemented entirely in software with no special hardwarenecessary. To Cryptoki, an application consists of a single address space and all thethreads of control running in it.Session operations are specific tasks that can be performed by an open session for atoken. There are three broad categories:• Administrative operations. For example, logging in.• Object management operations. For example, creating an object on a token.• Cryptographic operations. For example, computing a message digest.Usually a single session can only perform one operation at a time, so it is preferable anapplication opens multiple sessions with a single token. A single session on sometokens can perform the following pairs of operation types simultaneously:• Decrypting and verifying signatures or creating Message Authentication Codes(MACs).• Decrypting and message digesting.• Message digesting and encryption.• Signing or creating MACs, and encryption.Appendix A: Public Key Cryptography Standards 91

RSA BSAFE Security ConceptsThe consequence of single operations is an application should never make multiplesimultaneous function calls to Cryptoki, which use a common session. Cryptoki doesnot define what will happen if multiple threads of an application attempt to use acommon session concurrently.PKCS #12Exchange ModesPKCS #12 is the Personal Information Exchange Syntax Standard. It describes thesyntax for transfer of personal identification information including private keys andcertificates. Applications supporting this standard allow the import, export, andexercise of a single set of personal identity information.Privacy and integrity modes are supported under this standard. The most secure modesrequire both source and destination platforms to have trusted public/private key pairsfor use by digital signatures and encryption. Lower security such as password-basedmodes are also supported for platforms where trusted key pairs are not available.PKCS #12 builds on PKCS #8 by including identity information along withasymmetric keys and by utilizing higher security through asymmetric key privacy andintegrity modes.Exchange modes are modes of operation designed to protect the privacy and integrityof information as it is transferred from a source or to a destination.PKCS #12 supports two types of exchange mode:• Privacy modes. Prevent exposure of personal information by using encryption.• Integrity modes. Protect personal information from tampering.Any combination of exchange modes is permitted under this standard. Theasymmetric key mode for both privacy and integrity is preferable to password modes.However, if the destination platform is not known then asymmetric key privacy modeis precluded.Privacy ModesPKCS #12 supports two privacy modes:• Public key. Personal information is enveloped using trusted asymmetric keyencryption on the source platform. The envelope is opened with a correspondingprivate key.• Password. Personal information is encrypted with a symmetric key which isderived from a username and privacy password.92 Appendix A: Public Key Cryptography Standards

RSA BSAFE Security ConceptsIntegrity ModesPKCS #12 supports two integrity modes:• Public key. Integrity is guaranteed via a digital signature on the contents of the toplevel exchange Protocol Data Unit (PFX PDU) produced using private signaturekey of the source platform. The corresponding public key verifies the signature onthe destination platform.• Password. A MAC derived from a secret integrity password guarantees integrity.Asymmetric key pairs are supported under this standard and can be used in twomodes:• Public key privacy mode. An encryption key pair is required and the private keyfrom the encryption pair is stored on the destination platform.• Public key integrity mode. A signature key pair is required and the private keyfrom the signature pair is stored on the source platform.For both modes of key pairs the public key is transported to the other platform suchthat it is trusted to have originated from the correct platform. The method used todetermine if the public key is trusted is determined by the user.PKCS #13PKCS #13 is the Elliptic Curve Cryptography Standard and is currently underdevelopment. It will address aspects of elliptic curve cryptography, includingparameter and key generation and validation, digital signatures, public key encryption,key exchange, and the ASN.1 syntax.PKCS #14PKCS #14 is the Pseudo-random Number Generation Standard and is currently underdevelopment.PKCS #15PKCS #15 is the Cryptographic Token Information Format Standard. It describes theformat of cryptographic credentials stored on cryptographic tokens.Appendix A: Public Key Cryptography Standards 93

RSA BSAFE Security Concepts94 Appendix A: Public Key Cryptography Standards

RSA BSAFE Security ConceptsB Recommended ReadingThe following table lists sources of recommended reading on a variety ofcryptographic topics.Table 5TopicRecommended ReadingDescriptionASN.1, BERand DERFIPSFIPS 46-3FIPS 81FIPS 113FIPS 140-2FIPS 180-1FIPS 186-3FIPS 197FIPS 198aIEEE P1363A Layman’s Guide to a Subset of ASN.1, BER and DERRSA Laboratories, November, 1993.ftp://ftp.rsasecurity.com/pub/pkcs/ascii/layman.ascFederal Information Processing Standards.http://www.itl.nist.gov/fipspubs/Data Encryption Standard.http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdfDES Modes of Operation.http://csrc.nist.gov/publications/fips/fips81/fips81.htmComputer Data Authentication.http://www.itl.nist.gov/fipspubs/fip113.htmSecurity Requirements for Cryptographic Modules.http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdfSecure Hash Standard (SHA).http://www.itl.nist.gov/fipspubs/fip180-1.htmDigital Signature Standard.http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdfAdvanced Encryption Standard.http://csrc.nist.gov/publications/fips/fips197/fips-197.pdfKeyed-Hash Message Authentication Code.http://csrc.nist.gov/publications/fips/fips198/fips-198a.pdfWorking group developing standards for public-key cryptography based onRSA, Diffie-Hellman and related algorithms.http://grouper.ieee.org/groups/1363/Appendix B: Recommended Reading 95

RSA BSAFE Security ConceptsTable 5TopicISO/IEC9979ISO/IEC10116ISO/IEC10118PKCS #1PKCS #3PKCS #5PKCS #6PKCS #7PKCS #8PKCS #9Recommended Reading (continued)DescriptionInformation technology - Security techniques - Encryption algorithms- Part 1: General.http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=37970Modes of operation for an n-bit block cipher algorithm.http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=38761Information technology - Security techniques - Hash functions - Part 3:Dedicated hash functions.http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=39876RSA Cryptography Standard.http://www.rsa.com/rsalabs/node.asp?id=2125Diffie-Hellman Key Agreement Standard.http://www.rsa.com/rsalabs/node.asp?id=2126Password-based Cryptography Standard.http://www.rsa.com/rsalabs/node.asp?id=2127Extended-Certificate Syntax Standard.http://www.rsa.com/rsalabs/node.asp?id=2128Cryptographic Message Syntax Standard.http://www.rsa.com/rsalabs/node.asp?id=2129Private Key Information Syntax Standard.http://www.rsa.com/rsalabs/node.asp?id=2130Selected Attribute Types.http://www.rsa.com/rsalabs/node.asp?id=2131PKCS #10PKCS #11PKCS #12PKCS #13PKCS #15RFC 822Certification Request Syntax Standard.http://www.rsa.com/rsalabs/node.asp?id=2132Cryptographic Token Interface Standard.http://www.rsa.com/rsalabs/node.asp?id=2133Personal Information Exchange Syntax Standard.http://www.rsa.com/rsalabs/node.asp?id=2138Elliptic Curve Cryptography Standard.http://www.rsa.com/rsalabs/node.asp?id=2139Cryptographic Token Information Format Standard.http://www.rsa.com/rsalabs/node.asp?id=2141Standard for the Format Of ARPA Internet Text Messages.http://www.faqs.org/rfcs/rfc822.html96 Appendix B: Recommended Reading

RSA BSAFE Security ConceptsTable 5TopicRFC 1319RFC 1321Recommended Reading (continued)DescriptionMD2 Message-Digest Algorithm.http://tools.ietf.org/html/rfc1319MD5 Message-Digest Algorithm.http://tools.ietf.org/html/rfc1321RFC1421-1424RFC 1750RFC 1777RFC 2003RFC 2040RFC 2104PEM (Privacy Enhanced Mail):• Part I: Message Encryption and Authentication Procedures.http://tools.ietf.org/html/rfc1421• Part II: Certificate-based Key Management.http://tools.ietf.org/html/rfc1422• Part III: Algorithms, Modes, and Identifiers.http://tools.ietf.org/html/rfc1423• Part IV: Key Certification and Related Services.http://tools.ietf.org/html/rfc1424Randomness Recommendations for Security.http://tools.ietf.org/html/rfc1750Lightweight Directory Access Protocol.http://tools.ietf.org/html/rfc1777IP Encapsulation within IP.http://tools.ietf.org/html/rfc2003The RC5, RC5-CBC, RC5-CBC-Pad, and RC5-CTS Algorithms.http://tools.ietf.org/html/rfc2040HMAC: Keyed-Hashing for Message Authentication.http://tools.ietf.org/html/rfc2104RFC 2246 The TLS Protocol Version 1.0.http://tools.ietf.org/html/rfc2246RFC 2251RFC 2392RFC 2402RFC 2560RFC 2612RFC 2986Lightweight Directory Access Protocol (v3).http://tools.ietf.org/html/rfc2251Content-ID and Message-ID Uniform Resource Locators.http://tools.ietf.org/html/rfc2392IP Authentication Header.http://tools.ietf.org/html/rfc2402X.509 Internet Public Key Infrastructure Online Certificate Status Protocol(OCSP).http://tools.ietf.org/html/rfc2560The CAST-256 Encryption Algorithm.http://tools.ietf.org/html/rfc2612PKCS #10: Certification Request Syntax.http://tools.ietf.org/html/rfc2986Appendix B: Recommended Reading 97

RSA BSAFE Security ConceptsTable 5TopicRFC 3394RFC 3986RFC 4086RFC 4210RFC 4211Recommended Reading (continued)DescriptionAES Key Wrap Algorithm.http://tools.ietf.org/html/rfc3394Uniform Resource Identifier (URI): Generic Syntax.http://tools.ietf.org/html/rfc3986Randomness Requirements for Security.http://tools.ietf.org/html/rfc4086Certificate Management Protocol (CMP).http://tools.ietf.org/html/rfc4210Certificate Request Message Format (CRMF).http://tools.ietf.org/html/rfc4211RFC 4346 The Transport Layer Security (TLS) Protocol Version 1.1.http://tools.ietf.org/html/rfc4346RFC 4492RFC 4510RFC 4648Elliptic Curve Cryptography (ECC) Cipher Suites for Transport LayerSecurity (TLS).http://tools.ietf.org/html/rfc4492Lightweight Directory Access Protocol (LDAP):Technical Specification Road Map.http://tools.ietf.org/html/rfc4510The Base16, Base32, and Base64 Data Encodings.http://tools.ietf.org/html/rfc4648RFC 5246 Transport Layer Security (TLS) version 1.2.http://tools.ietf.org/html/rfc5246RFC 5280RFC 5289RFC 5430RFC 5649RFC 5746SCEPInternet X.509 Public Key Infrastructure Certificate and CertificateRevocation List (CRL) Profile.http://tools.ietf.org/html/rfc5280TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES GaloisCounter Mode (GCM).http://tools.ietf.org/html/rfc5289Suite B Profile for Transport Layer Security (TLS).http://tools.ietf.org/html/rfc5430AES Key Wrap with Padding Algorithm.http://tools.ietf.org/html/rfc5649Transport Layer Security (TLS) Renegotiation Indication Extension.http://tools.ietf.org/html/rfc5746Simple Certificate Enrollment Protocol.http://tools.ietf.org/html/draft-nourse-scep-1898 Appendix B: Recommended Reading

RSA BSAFE Security ConceptsTable 5TopicWTLSRecommended Reading (continued)DescriptionWAP- Wireless Transport Layer Security Specification.http://www.openmobilealliance.org/tech/affiliates/LicenseAgreement.asp?DocName=/wap/wap-261-wtls-20010406-a.pdfX.400 Message Handling System and Service Overview.http://www.itu.int/rec/T-REC-F.400-199906-I/enX.500 The Directory - Overview of Concepts, Models and Services.http://www.itu.int/rec/T-REC-X.500/enX.509 The Directory - Public-key and Attribute Certificate Frameworks.http://www.itu.int/rec/T-REC-X.509/enX.690 Basic Encoding Rules (BER) Specification.http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdfAppendix B: Recommended Reading 99

RSA BSAFE Security Concepts100 Appendix B: Recommended Reading

RSA BSAFE Security ConceptsGlossaryThe following table lists terms and abbreviations used in the field of cryptography.Table 6TermAESAHAlgorithmAliceANSIAPIARPASN.1Terms and AbbreviationsDescriptionAdvanced Encryption Standard. A fast symmetric key algorithm with a128-bit block, and keys of lengths 128, 192, and 256 bits. This willreplace the Data Encryption Standard (DES) as the US symmetricencryption standard.Authentication Header. An IPSec header (as defined in RFC 2402) usedto ensure integrity and data authentication of the entire IP packet towhich it is applied.In cryptography, a named mathematical procedure to encrypt or decryptdata. Different algorithms have different characteristics, and are used indifferent situations. Also called a cipher.The name traditionally used for the first user of cryptography in asystem; Bob's friend.American National Standards Institute.Application Programming Interface.Address Resolution Protocol.Abstract Syntax Notation One. An ISO OSI standard for describingarbitrary data structures.Asymmetric keyalgorithmAsymmetric keycryptographyAttackAuthenticationA cryptographic algorithm that uses two keys, one public and oneprivate, for encryption and decryption operations.Cryptography involving an asymmetric key algorithm and two keys; oneis widely available (the public key) and used to encrypt or verify theorigin of a message, the other is kept secret by its owner (the privatekey) and is used to decrypt or sign messages. Also called public keycryptography.Asymmetric key cryptography provides data confidentiality, and/orguarantee of origin.Either a successful or unsuccessful attempt at breaking part or all of acryptosystem. Various attack types include an algebraic attack, birthdayattack, brute force attack, chosen ciphertext attack, chosen plaintextattack, differential cryptanalysis, known plaintext attack, linearcryptanalysis, and middleperson attack.The action of verifying information such as identity, ownership orauthorization.Glossary 101

RSA BSAFE Security ConceptsTable 6TermBERBitTerms and Abbreviations (continued)DescriptionBasic Encoding Rules. A set of rules for representing ASN.1 objects asstrings of ones and zeros. DER is a subset of BER.A binary digit, either one or zero.Block cipherBlowfishBNBobBPIBPI+Brute force attackBXACACAPICASTCBCCertificateCFBChecksumA symmetric key algorithm that encrypts a message by breaking it downinto fixed size blocks and encrypting each block.A symmetric key algorithm designed in 1993 by Bruce Schneier as afast, free alternative to existing encryption algorithms.Big Number. A large integer library which supports normal arithmeticoperations. There are no limits on the size of the numbers beingmanipulated.The name traditionally used for the second user of cryptography in asystem; Alice's friend.Baseline Privacy Interface specification.Baseline Privacy Interface Plus specification.An attack on a cryptosystem executed by methodically guessing keys,and by decrypting ciphertext with those keys, until the resultingplaintext appears to be non-random. The effort involved in launching abrute force attack grows exponentially with the key size.Bureau of Export Administration.Certification Authority. It signs and verifies the certificates ofsubordinates in a certificate hierarchy.Cryptographic Application Programming Interface.A family of substitution-permutation network ciphers. IPSec includessupport for the CAST-256 algorithm, which is defined in RFC 2612.Cipher Block Chaining. An encryption mode of operation where eachciphertext depends upon all previous ciphertexts. Changing anInitialization Vector (IV) alters the ciphertext produced by successiveencryptions of an identical plaintext.In cryptography, an electronic document binding some pieces ofinformation together, such as a user's identity and a public key.Certification Authorities (CAs) provide certificates.Cipher Feedback. An encryption mode of operation producing a streamof ciphertext bits rather than a succession of blocks. In other respects, ithas similar properties to the CBC mode of operation.Used in error detection, a checksum is a computation done on themessage and transmitted with the message; similar to using parity bits.102 Glossary

RSA BSAFE Security ConceptsTable 6TermCipherTerms and Abbreviations (continued)DescriptionAn encryption-decryption algorithm.Cipher suiteCiphertextCleartextCMPCMSCollisionCRLCRMFCRSCSRCTRCTSCyclic finitegroupData compressionData whiteningDecryptionA collection of cryptographic algorithm, typically including a keyexchange algorithm, a symmetric encryption algorithm, and a hashingalgorithm.Encrypted data.Transmitted data without any cryptographic protection. See also,plaintext.Certificate Management Protocol. An Internet protocol for obtaining acertificate from a Certification Authority.Cryptographic Message Syntax.Two different messages that produce the same message digest. Seemessage digest algorithm.Certificate Revocation List. A list of expired or invalid certificates usedby a Certification Authority.Certificate Request Message Format. A message syntax to conveycertificate requests to a Certification Authority.Certificate Revocation Status. Indicates the validity of a certificate.Certificate Signing Request.Counter mode. An encryption mode of operation used with the AESalgorithm where successive blocks of a counter are encrypted andXORed with the plaintext.Ciphertext stealing. An encryption mode of operation that enables blockciphers to be used to process data that is not evenly divisible into blocks,without the length of the ciphertext increasing.A discrete set of numbers, under which an operation is closed andassociative. The group has an identity and an inverse element, and canbe generated by repeated application of the operation to any of itsgenerator elements. This is the setting for the Discrete LogarithmProblem.Removes redundancy from a file, typically reducing its length. Thisspeeds up the processes of encryption, decryption, and transmission. Theremoval of redundancy also complicates some cryptanalytic attacks.Transformation of data in order to make it computationallyindistinguishable from random data.The transformation of ciphertext back into the original plaintext. Seealso encryption.Glossary 103

RSA BSAFE Security ConceptsTable 6TermDERDESDHCPTerms and Abbreviations (continued)DescriptionDistinguished Encoding Rules. A subset of BER which gives a uniqueencoding to each ASN.1 value.Data Encryption Standard. A symmetric encryption algorithm with a56-bit key. See also Triple DES.Dynamic Host Configuration Protocol. A protocol for assigningdynamic IP addresses to devices on a network.Dictionary attackDiffie-HellmanDigestDigital signatureDistributed keyDLPDNDNSDOCSISDOIDSADSDDSSECAESA brute force attack that tries passwords and/or keys from a precompiledlist of values. This is often done as a pre-computation attack.The Diffie-Hellman asymmetric key exchange algorithm. There aremany variants, but typically two entities exchange some publicinformation (for example, public keys or random values) and thencombine them with their own private keys to generate a shared sessionkey. Because private keys are not transmitted, eavesdroppers are notprivy to all of the information that composes the session key.Diffie-Hellman does not provide encryption or authentication.See message digest.Application of an asymmetric key algorithm with a private key to amessage digest of a message to provide authentication, data integrity,and non-repudiation.A key split into many parts and shared amongst different participants.Discrete Logarithm Problem. Where finding the logarithm of an elementin a cyclic finite group becomes exponentially more difficult as the sizeof the group linearly increases.Distinguished Name.Dynamic Name Server/Service.Data-Over-Cable Service Interface Specifications.Domain of Interpretation. Defines the security parameters to negotiatewith respect to a security association.Digital Signature Algorithm. An asymmetric key algorithm for creatingdigital signatures. DSA cannot be used directly for encryption.Defence Signals Directorate.Digital Signature Standard. A US Government standard combining DSAand SHA-1 for specifying a format for signing data.Elliptic Curve Augmented Encryption Scheme. See ECIES.104 Glossary

RSA BSAFE Security ConceptsTable 6TermECBECCECDHECDLECDSAECIESEDEEDIEIOTerms and Abbreviations (continued)DescriptionElectronic Code Book. An encryption mode of operation where plaintextblocks are independently encrypted to ciphertext blocks.Elliptic Curve Cryptography. An asymmetric key encryption systembased on elliptic curve parameters.Elliptic Curve Diffie-Hellman. Combines Elliptic Curve Cryptographywith Diffie-Hellman key exchange.Elliptic Curve Discrete Logarithm. The problem of finding m such thatm·P=Q, where P and Q are two points on an elliptic curve.Elliptic Curve Digital Signature Algorithm. Combines Elliptic CurveCryptography with DSA.Elliptic Curve Integrated Encryption Scheme. A complex encryptionalgorithm that combines elliptic curve parameters, asymmetric keyencryption, key exchange, message authentication codes (MACs),symmetric key encryption, and message digests.Encrypt-Decrypt-Encrypt. A mode of encryption in which plaintext isencrypted with one key, decrypted with a second key, and encryptedagain with a third key.Electric Data Interchange (X.435).Event Input/Output methods.Elliptic curveMathematical constructs, which in recent years has found numerousapplications in cryptography. The set of points (x, y) satisfying anequation of the form for variables x, y, and constants a:y 2 +a 1 xy+a 3 y=x 3 +a 2 x 2 +a 4 x+a 6Elliptic curvefactoring methodEncryptionEntropyEOFEPOCHA special-purpose factoring algorithm that attempts to find a primefactor p of an integer n by finding an elliptic curve whose number ofpoints modulo p is divisible by only small primes.The reversable transformation of data (plaintext) into an apparently lessreadable form (ciphertext) as a mechanism for protecting itsconfidentiality, integrity, and sometimes its authenticity. Encryption usesan encryption algorithm and a key. See also decryption.The degree of disorder or randomness in a system. Entropy from asystem is used to seed pseudo-random number generators (PRNGs). Thegreater the entropy, the more random the output from a PRNG. Poorentropy is the weak link in many cryptographic applications.End-of-File.The basis of date and time calculation on computers. Epoch Time is thetime elapsed since 1 January 1970 00:00:00. This is usually expressed inseconds.Glossary 105

RSA BSAFE Security ConceptsTable 6TermESPFactorFactoringFactoringmethodsTerms and Abbreviations (continued)DescriptionEncapsulating Security Payload.Given an integer n, any number that divides it is called a factor of n. Forexample, 7 is a factor of 91, because 91/7 is an integer.The breaking down of an integer into its prime factors.The method used to break down an integer into its prime factors. Seeelliptic curve method, multiple polynomial quadratic sieve, number fieldsieve, Pollard p-1 and Pollard p+1 method, Pollard rho method, andquadratic sieve.FingerprintFIPSForward secrecyFTPFTPSFull-strengthGCMGMTGSS-APIHackerHash functionHMACHTTPHTTPSI/OICDSee message digest.Federal Information Processing Standards. Publicly announcedstandards developed by the United States Federal government for use byall non-military government agencies and by government contractors.The property that ensures that a session key derived from a set oflong-term public and private keys is not compromised if one of thelong-term private keys is compromised.File Transfer Protocol.File Transfer Protocol with SSL.Due to US export regulations, previously only 40-bit keys could beexported from the US. This restriction allowed the stronger 128-bit keysto only be used within the US.Galois/Counter Mode. An encryption mode of operation used with theAES algorithm. Combines CTR mode of operation with Galois modeauthentication (based on finite fields, or Galois fields, in abstractalgebra).Greenwich Mean Time.Generic Security Service Application Programming Interface.A person who tries to defeat computer security measures.See message digest algorithm.Keyed-Hashing for Message Authentication Code.Hypertext Transfer Protocol.Hypertext Transfer Protocol with SSL.Input/Output.Interface Control Document.106 Glossary

RSA BSAFE Security ConceptsTable 6TermICMPIDEATerms and Abbreviations (continued)DescriptionInternet Control Message Protocol. The protocol transmits errormessages pertaining to IP packets.International Data Encryption Algorithm.IdentificationIEEEIETFInitializationVectorInvolutionIPIPCOMPIPIPIPv4IPv6IPXISOIVKDCKeyKey agreementKey escrowA process through which one entity ascertains the identity of anotherentity.Institute of Electrical and Electronics Engineers. A body that createssome cryptography standards.Internet Engineering Task Force. The group responsible for developingInternet standards.An initial block of data used with some encryption modes of operation.An operation where two successive applications maps an input back toitself.Internet Protocol.IP Compression Header. Used to indicate the attributes of an IP packetcompressed using the IP Payload Compression Protocol (IPPCP).Tunneling protocol that encapsulates IP packets within AH or ESPheaders. This is defined in RFC 2003.Current version of the IP protocol which supports IPSec but does notmandate IPSec.New version of the IP protocol, supporting 128-bit addresses andmandating IPSec as its security mechanism.Internetwork Packet Exchange.International Standards Organization.Initialization Vector.Key Distribution Center.A string of bits used in conjunction with a cryptographic algorithm toperform a cryptographic operation (such as encryption, decryption,message digest, or digital signature) on data. Types of keys includedistributed keys, private keys, public keys, secret keys, session keys,shared keys, subkeys, symmetric keys, and weak keys.A process used by two or more parties to agree upon a secret symmetrickey. See also Diffie-Hellman.The process of having a third party hold onto encryption keys.Glossary 107

RSA BSAFE Security ConceptsTable 6TermTerms and Abbreviations (continued)DescriptionKey exchangeKey expansionKey generationKey managementKey pairKey recoveryKey revocationKey scheduleKey spaceL2TPLACLDAPLDAPSLeaf certificateLNSLRUMACA process used by two more parties to exchange keys in cryptosystems.A process that creates a larger key from the original key.A process used to create a key.The various processes dealing with the creation, distribution,authentication, and storage of keys.The public and private key of an asymmetric key cryptosystem.A special feature of a key management scheme allowing messages to bedecrypted even if the original key is lost.A process for making keys invalid for use. For example, keys that arecompromised, or irretrievably lost, should be revoked.An algorithm generating the subkeys in a block cipher key space.The collection of all possible keys for a given cryptosystem. Varioustypes of key space include flat key space, linear key space, nonlinear keyspace, and reduced key space.Layer 2 Tunneling Protocol. A link-to-link protocol encapsulating trafficon PPP connections. It does not provide any security.L2TP Access Concentrator.Lightweight Directory Access Protocol. Supports X.500 directorymodels without much of the latter’s overhead. It is defined in RFC 1777and RFC 2251.Lightweight Directory Access Protocol with SSL.The last certificate in a certificate chain. Also known as an End Entity.L2TP Network Server.Least Recently Used.Message Authentication Code. A short transformation of a plaintextmessage using a MAC algorithm and a symmetric key.MACs are used to provide authentication and data integrity.108 Glossary

RSA BSAFE Security ConceptsTable 6TermTerms and Abbreviations (continued)DescriptionMAC algorithmMan-in-themiddleattackMD2MD5Message digestMessage digestalgorithmMICMIMEMIPSMTAA cryptographic algorithm that produces a MAC. Common MACalgorithms include:• HMAC-MD5• HMAC-SHA-1• HMAC-SHA-224• HMAC-SHA-256• HMAC-SHA-384• HMAC-SHA-512.An attack on a cryptosystem where an attacker sits in the middle of asession between two parties and recovers all communications withoutdetection.Message digest function used to create digital signatures. It produces adigest of 128 bits. It was designed by Ronald Rivest in 1988 and istargeted at 8-bit machines. See RFC 1319.A secure hash algorithm created by Ronald Rivest. MD5 hashes anarbitrary-length input into a 16-Byte digest.A computationally unique, fixed-length transformation of avariable-length unit of data. Each unit of data (for example, a file, string,or buffer) maps to a specific message digest. It is not random. Digestingthe same unit of data with the same message digest algorithm alwaysproduces the same message digest.Message digests are used to provide data integrity.A cryptographic algorithm that produces a message digests. Commonmessage digest algorithms include:• MD2• MD4• MD5• SHA-1• SHA-2• RIPEMD160.Message Integrity Check.Multipurpose Internet Mail Extensions.Millions of Instructions Per Second. A measurement of computingspeed.Media Terminal Adaptor. Contains an interface to a voice device, anetwork adapter, CODECs and all signaling and encapsulationfunctions.Glossary 109

RSA BSAFE Security ConceptsTable 6TermMTUTerms and Abbreviations (continued)DescriptionMaximum Transfer Unit. An upper bound on the size of IP packets thatcan passed through the router dictating the MTU. This influencesfragmentation policies for IP packets.MultiPrimeNDISNETBEUINETBIOSNISTNNTPNNTPSNonceNSANull cipher specOAEPOCSPOctetOFBOIDOne-time padNew technology that greatly increases the throughput of some RSAoperations without sacrificing security. This is due to the construction ofthe RSA modulus using multiple primes of smaller than usual size.Network Driver Interface Specification.NETBIOS Extended User Interface.Network Basic Input/Output System.National Institute of Standards and Technology. A division of the USDepartment of Commerce (formerly known as the NBS) which producessecurity and cryptography-related standards.Network News Transfer Protocol.Network News Transfer Protocol with SSL.Number used once. A random number applied to a packet to instill itwith freshness, hence avoiding replay attacks.National Security Agency. A US government agency which monitorsand deciphers foreign communications.If a message is to be sent using the null cipher spec then no compression,MAC protection or encryption will be used by the record layer whenconstructing the encapsulating record.Optimal Asymmetric Encryption Padding. A padding scheme often usedin conjunction with RSA encryption.Online Certificate Status Protocol. A protocol allowing applications toeasily determine the revocation status of a specific certificate, as well asadditional information not normally supplied via CRLs.A group of eight bits. Also known as a byte.Output Feedback. An encryption mode of operation where the blockcipher is separated from its ciphertext.Object Identifier. OIDs serve to name almost every object type in anX.509 certificate.A secret-key cipher in which the key is a truly random sequence of bitsthat is as long as the message itself, and encryption is performed byXORing the message with the key. This is theoretically unbreakable.110 Glossary

RSA BSAFE Security ConceptsTable 6TermTerms and Abbreviations (continued)DescriptionOne-way functionOne-way hashfunctionOSIOSSPacketCablePaddingPasswordPBEPCMCIAPCPPCTPDUPeerPEMPFSPGPPKCSPKCS #1PKCS #10A mathematical function significantly easier to perform in one direction(the forward direction) than in the opposite direction (the inversedirection).A one-way function that takes a variable sized input and creates a fixedsize output.Open Systems Integration.Operational Support System. This is back office software used forconfiguration, performance, fault, accounting and security management.A set of protocols and associated element functional requirementsdeveloped to deliver quality of service enhanced secure communicationsservices using packetized data transmission technology to a consumer’shome over the cable television hybrid fiber coax data network.Extra bits concatenated with a key, password or plaintext.A character string used as a key to control access to file or encrypt them.Password-Based Encryption. Generates a symmetric key from apassword, and encrypts data using that generated key.Personal Computer Memory Card International Association.Payload Compression Protocol.Private Communication Technology. A protocol developed by Microsoftand Visa International for secure Internet communication.Protocol Data Unit.Complementary side of the connection (that is, the client is the server’speer; the server is the client’s peer).Privacy Enhanced Mail. Draft Internet standard which has not yet beenofficially adopted.Perfect Forward Secrecy. Guarantees session keys of previous sessionsremain secure if long-term keys are compromised.Pretty Good Privacy. Software package originally developed by PhilZimmerman providing cryptographic routines for e-mail and file storageapplications.Public Key Cryptography Standards. A specification suite created byRSA for standardizing cryptographic formats and operations.Public key standard describing the use of the RSA cryptographic systemfor encryption and digital signatures.Public key standard describing the format of certification requests.Glossary 111

RSA BSAFE Security ConceptsTable 6TermTerms and Abbreviations (continued)DescriptionPKCS #11PKCS #12PKCS #7PKCS #8PKCS #9PKIPlaintextPMTUPPPPPTPPrime factorPrime numberPrivacyPrivate exponentPrivate keyPRNGPseudo-randomnumberPseudo-randomsequencePublic key standard describing the Cryptoki API for devices holdingcryptographic information and perform cryptographic functions.Public key standard describing the syntax for personal informationexchange.Public key standard describing the syntax for data to be protected bycryptography.Public key standard describing the syntax for private keys and encryptedprivate keys.Public key standard describing selected object classes and attributetypes.Public Key Infrastructure. The set of applications policies, practices,standards and laws emerging from public key technology.Unencrypted data. See also, cleartext.Path MTU. The MTU associated with the source and destinationaddresses of an IP packet.Point-to-Point Protocol. A full duplex protocol using the IP protocol toconnect two computers. It is a de facto standard for dialup connections.Point-to-Point Tunneling Protocol. Sponsored by Microsoft, it is analternative to IPSec in that it creates private tunnels over a publicnetwork.A prime number that is a factor of another number.Any integer greater than 1 that is divisible only by 1 and itself. The firsttwelve primes are 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, and 37.The state or quality of being secluded from the view and/or presence ofothers.The private key in the RSA public key cryptosystem.The secret key in asymmetric key cryptography. Primarily used fordecryption but also used for encryption with digital signatures.Pseudo-random Number Generator.Numbers that appear to be random, but the sequence of number isdeterministic. That is, given a specific function and seed value, the samesequence of numbers are generated by the function.A deterministic function producing a sequence of bits with qualitiessimilar to that of a truly random sequence.112 Glossary

RSA BSAFE Security ConceptsTable 6TermTerms and Abbreviations (continued)DescriptionPublic keyPublic keycryptographyQoSRARandom numberRC2RC4RC5Relatively primerenegotiationcipher suiterenegotiationextensionRFCRKSRNGThe public key used in asymmetric key cryptography. Primarily used forencryption, but also used for signature verification.Cryptography based on methods involving a public key and a privatekey.Quality of Service. Defines a series of parameters, including guaranteesof security, that must be met during the transmission of IP packets.Registration Authority. An organization performing registration forinformation objects and devices.As opposed to a pseudo-random number, a truly random number is anumber produced independently of its generating criteria. Forcryptographic purposes, numbers based on physical measurements, suchas times associated with radioactive decay, are considered truly random.A symmetric key algorithm developed by Ronald Rivest as analternative to DES. It has a block size of 64 bits and a variable key size.It is a legacy algorithm and RC5 should be used in preference.A symmetric key algorithm developed by Ronald Rivest using variablelength keys (usually 40 bit or 128 bit).A symmetric key algorithm developed by Ronald Rivest. Its word size,key length, and number of rounds are parameters that can be customized.Typical use involves a block size of 64 bits, a key size of 128 bits, andeither 16 or 20 iterations of its round function.Two integers are relatively prime if they have no common factors. Forexample, 14 and 25 are relatively prime, while 14 and 91 are not because7 is a common factor.A special signalling cipher suite sent by a client in the ClientHellomessage in a TLS initial handshake to request secure TLSrenegotiations. Used to secure against man-in-the-middle attacks onTLS renegotiations.A TLS extension that allows clients and servers to include verificationdata about previous handshakes in any renegotiation handshake, andthereby verify the identity of the client or server on the other end of theconnection. Used to secure against man-in-the-middle attacks on TLSrenegotiations.Request for Comments. An IETF document typically intended as anInternet standard.Records Keeping Server. Collects and correlates event messages.Random Number Generator.Glossary 113

RSA BSAFE Security ConceptsTable 6TermRSAS/MIMES/WANSASADBSAFERSaltTerms and Abbreviations (continued)DescriptionAsymmetric key algorithm providing the ability to encrypt data andcreate and verify digital signatures. RSA stands for Ronald Rivest, AdiShamir, and Leonard Adleman, the developers of the RSA public keycryptographic system.Secure/Multipurpose Internet Mail Extensions. A protocol that addsdigital signatures and encryption to Internet MIME messages.Secure Wide Area Network.Security Association. A series of parameters dictating how IPSecprotocols transform IP packets on a unidirectional connection.Security Association Database. Stores security associations.Secure And Fast Encryption Routine. Non-proprietary block cipherdeveloped by Massey in 1993 for Cylink Corporation.A string of random (or pseudo-random) bits concatenated with a key orpassword to complicate attacks.SatisfiabilityproblemSCEPSDKSDUSEALSecret keySecret sharingSeedSEPPSession keySETSGGiven a Boolean expression, determine if there is an assignment of onesand zeros such that the expression evaluates to one.Simple Certificate Enrolment Protocol. Protocol jointly designed byCisco Systems and VeriSign for certificate management.Software Development Kit.Service Data Unit.Software-optimized Encryption Algorithm.In secret key cryptography, this is the key used both for encryption anddecryption.Splitting a secret (for example, a private key) into many pieces such thatany specified subset of k pieces can be combined to form the secret, butk-1 pieces are not enough.A typically random bit sequence used to generate another, usually longerpseudo-random bit sequence.Secure Electronic Payment Protocol.A key for symmetric key cryptosystems which is used for the duration ofone message or communication session.Secure Electronic Transactions. Protocol jointly developed by Visa andMasterCard as a method for secure, cost-effective bankcard transactionsover open networks.Signaling Gateway.114 Glossary

RSA BSAFE Security ConceptsTable 6TermSHASHA-1SHA-2Terms and Abbreviations (continued)DescriptionSecure Hash Algorithm. A message digest algorithm that creates aunique hash value for each possible input. There are two variations ofSHA, SHA-1 and SHA-2.Produces a 160-bit message digest. Vulnerabilities with regards tocollision resistance have recently been identified, so SHA-1 should notbe used in new applications.The NIST-mandated successor to SHA-1, to complement the AdvancedEncryption Standard. It is a family of hash algorithms (SHA-224,SHA-256, SHA-384 and SHA-512), which produce digests of 224, 256,384 and 512 bits respectively.Shared keyS-HTTPSkipjackSmart cardSMTPSMTPSSPDSPISSLThe secret key two (or more) users share in symmetric keycryptography.Secure HyperText Transfer Protocol. A secure way of transferringinformation over the World Wide Web.Encryption algorithm contained in the Clipper chip.A card, not much bigger than a credit card, containing a computer chipthat is used to store or process information.Simple Mail Transfer Protocol.Simple Mail Transfer Protocol with SSL.Security Policy Database. Determines the actions to be effected on eachIP packet. These actions include whether the packet is to be discarded,bypassed with respect to security, or to have security policy applied.Security Parameters Index. Used in conjunction with a destination IPaddress and security protocol to uniquely identify a security association.Secure Sockets Layer. Protocol providing an encrypted andauthenticated communications stream over a network. This allows theclient and the server to establish a secure connection free fromeavesdropping, tampering and forgery. See TLS.SSLv2 Secure Sockets Layer version 2.SSLv3 Secure Sockets Layer version 3.Stream cipherStream cipherbased MACStrong primeA symmetric key algorithm processing data in a stream of arbitrarylength one a bit at a time.A MAC that uses linear feedback shift registers (LFSRs) to reduce thesize of the data it processes.A prime number with certain properties chosen to defend againstspecific factoring techniques.Glossary 115

RSA BSAFE Security ConceptsTable 6TermTerms and Abbreviations (continued)DescriptionSubstitutionboxesSymmetric keyalgorithmSymmetric keycryptographySynchronousTamper resistantTCPTCP/IPTCSECTFTPTLSTrap-doorone-way functionTriple DESUCSUDPUTCIn symmetric key cryptography, substitution boxes (or S-boxes)substitute a number of bits of input with a number of other bits.A cryptographic algorithm that uses the same secret key for bothencryption and decryption.Cryptography involving a symmetric key algorithm and one secret keyfor both encryption and decryption. Also called secret key cryptographybecause the key used for encryption and decryption must be kept secretfor the operations to remain secure.Symmetric key cryptography provides data confidentiality.A property of a stream cipher, stating that the keystream is generatedindependently of the plaintext and ciphertext.In cryptographic terms, this refers to a hardware device that is eitherimpossible or extremely difficult to reverse engineer or extractinformation from.Transmission Control Protocol. One of the main protocols in TCP/IPnetworks. TCP enables two hosts to establish a connection and exchangedata. It guarantees both the delivery of data and that the packets aredelivered in the same order they were sent.Transmission Control Protocol/Internet Protocol.Trusted Computer System Evaluation Criteria.Trivial File Transfer Protocol.Transport Layer Security. The successor to SSL to provide an encryptedand authenticated communications stream over a network.A one-way function where the inverse direction is easy, given a certainpiece of information (called the trap door), but difficult otherwise.DES with three 56-bit keys. See also EDE.Universal Character Set.User Datagram Protocol.Coordinated Universal Time.UTF-8 Universal Character Set Transfer Format 8.VerificationVPNThe act of recognizing that a person or entity is who or what it claims tobe.Virtual Private Network. An inexpensive mechanism for securingsimulated private lines across a public network (such as the Internet).The enabling mechanism is typically IPSec.116 Glossary

RSA BSAFE Security ConceptsTable 6TermWAEWAPWDPWIMWirelessWMLWSPWTAWTAIWTLSWTPTerms and Abbreviations (continued)DescriptionWireless Application Environment.Wireless Application Protocol.Wireless Datagram Protocol.Wireless Identification Module.An alternative environment to wired communications, allowingenhanced mobility under a tight series of constraints including reducedbandwidth and memory available to applications.Wireless Markup Language.Wireless Session Protocol.Wireless Telephony Application.Wireless Telephony Application Interface.Wireless Transport Layer Security.Wireless Transaction Protocol.X.509 A standard dictating the format of certificates and Certificate RevocationLists.XORExclusive-OR. A binary bitwise operator yielding the result one if thetwo values are different and zero otherwise.Glossary 117

RSA BSAFE Security Concepts118 Glossary

RSA BSAFE Security ConceptsIndexAAbstract Syntax Notation One, 58, 101access control, 10Advanced Encryption Standard, 21key wrapping 38AES, see Advanced Encryption StandardAH, see authentication headeralert protocol, 75algorithm, 11Alice (see also Bob), 101ASN.1, see Abstract Syntax Notation Oneasymmetric ciphers, and key wrapping 38asymmetric key cryptography, 27attack, 12brute force, 12dictionary, 104man-in-the-middle, 37attacker, 12authentication header, 101authentication, 10Bbase64 encoding, 51base64url, 55Basic Encoding Rules, 102basic handshake, 71BER, See Basic Encoding Rulesblock cipher, 14Advanced Encryption Standard, 21Data Encryption Standard, 20modes of operation, 15padding, 15RC2, 22RC5, 22Triple DES, 21Bob (see also Alice), 102brute force attack, 12CCA, see Certification AuthorityCBC, see Cipher Block ChainingCCM, see Counter with CBC-MACCertificate Request Syntax Standard (PKCS #10), 90Certificate Revocation List, 61certificate server, 61certificate/digital certificate, 58certificate chain, 62certificate extension, 66certificate repository, 61certificate request, 60certificate store, 65certificate validation, 64Extended Validation certificate, 59revoked certificate, 61self-signed certificate, 63Suite B certificate validation, 82WTLS certificate, 60X509 certificate, 58Certification Authority, 58, 60CA hierarchy, 63certificate repository, 61certificate server, 61primary CA, 62Registration Authority, 60root CA, 62secondary CA, 62CFB, see Cipher Feedbackchange cipher spec protocol, 76Cipher Block Chaining, 16Cipher Feedback, 17cipher suites, 71cipher, see algorithmCiphertext stealing 20ciphertext, 11cleartext, see plaintextcollision resistance, 42Counter Mode, 19Index 119

RSA BSAFE Security ConceptsCounter with CBC-MAC, 20CRL, see Certificate Revocation ListCryptographic Message Syntax Standard (PKCS#7), 87cryptographic strength, 12Cryptographic Token Information Format Standard(PKCS #15), 93Cryptographic Token Interface Standard (PKCS#11), 90cryptography, 10CTR, see Counter ModeCTS, see Ciphertext stealingDdata confidentiality, 11Data Encryption Standard, 20data integrity, 11decryption, 11DER, See Distinguished Encoding RulesDES, see Data Encryption StandardDH, see Diffie-Hellmandictionary attacks, 25Diffie-Hellman Key Agreement Standard (PKCS#3), 86Diffie-Hellman, 36man-in-the-middle attack, 37random number generation, 47digital envelope 38digital envelope, 31Digital Signature Algorithm, 32random number generation, 47digital signature, 43Distinguished Encoding Rules, 104DSA, see Digital Signature AlgorithmDual EC DRBG, 49EECB, see Electronic Code BookECC, see Elliptic Curve CryptographyECDH, see Elliptic Curve Diffie-HellmanECDSA, see Elliptic Curve Digital SignatureAlgorithmECIES, see Elliptic Curve Integrated EncryptionSchemeElectronic Code Book, 16Elliptic Curve Cryptography, 33Elliptic Curve Diffie-Hellman, 38Elliptic Curve Digital Signature Algorithm, 33random number generation, 47Elliptic Curve Integrated Encryption Scheme, 33elliptic curve, 33encryption, 11entropy, 12EV, see Extended Validation certificateExtended-Certificate Syntax Standard (PKCS #6), 87FFIPS 186-2 RNG, 50GGalois/Counter Mode, 19GCM, see Galois/Counter ModeHhandshake protocol, 71HMAC-DRBG, 49HMAC-MD5, 45HMAC-SHA-1, 45HMAC-SHA-224, 45HMAC-SHA-256, 45HMAC-SHA384, 45HMAC-SHA-512, 45IIEEE, see Institute of Electrical and ElectronicsEngineersIETF, see Internet Engineering Task ForceInitialization Vector, 12random number generation, 47Institute of Electrical and Electronics Engineers, 107Internet Engineering Task Force, 70, 107IV, see Initialization VectorKkey, 11distributed key, 104Key Encryption Key (KEK) 38private key, 27public key, 27wrapping 38keystream, 24Koblitz, Neal, 33MMAC algorithm, 45MAC, see Message Authentication Codeman-in-the-middle attack, 37, 76120 Index

RSA BSAFE Security ConceptsMD2, see message digest algorithmMD4, see message digest algorithmMD5, see message digest algorithmMessage Authentication Code, 44message digest algorithm, 42message digest, 42collision resistance, 42one-way property, 42preimage resistance, 42second preimage resistance, 42Miller, Victor, 33modes of operation, 15Cipher Block Chaining, 16Cipher Feedback, 17Counter Mode, 19Counter with CBC-MAC, 20Electronic Code Book, 16Galois/Counter Mode, 19Output Feedback, 18XEX-based Tweaked CodeBook Mode withCiphertext Stealing, 20NNational Bureau of Standards, 20NBS, see National Bureau of Standardsnon-repudiation, 11OOAEP, see Optional Asymmetric Encryption PaddingOFB, see Output Feedbackone-way property, 42Optional Asymmetric Encryption Padding, 86random number generation, 47Output Feedback, 18Ppadding, 15with key wrapping 38Password-based Cryptography Standard (PKCS#5), 87Password-based Encryption, 25PBE, see Password-based EncryptionPersonal Information Exchange Syntax Standard(PKCS #12), 92PKCS #1,random number generation, 47PKCS, see Public Key Cryptography StandardsPKI, see Public Key Infrastructureplaintext, 11preimage resistance, 42primary CA, 62prime factor, 112prime number, 112prime, relatively, 113Private Key Information Syntax Standard (PKCS#8), 90private key, 27PRNG, see pseudo-random number generatorPseudo-random Number Generation Standard (PKCS#14), 93pseudo-random number generator, 12, 47Dual EC DRBG, 49FIPS 186-2 RNG, 50HMAC-DRBG 49seeding 48Public Key Cryptography Standards, 85PKCS #1, 86PKCS #10, 90PKCS #11, 90PKCS #12, 92PKCS #13, 93PKCS #14, 93PKCS #15, 93PKCS #3, 86PKCS #5, 87PKCS #6, 87PKCS #7, 87PKCS #8, 90PKCS #9, 90public key cryptography, see asymmetric keycryptographyPublic Key Infrastructure, 57public key, 27RRA, see Registration Authorityrandom number generation (see also pseudo-randomnumber generator), 47RC2, 22RC4, 24RC4-with-MAC, 24RC5, 22record protocol, 74Registration Authority,renegotiation cipher suite, 76renegotiation extension, 76Request For Comments (RFC),2246 70Index 121

RSA BSAFE Security Concepts3394 384210 684211 684346 704492 835246 70, 835289 835430 82, 835649 385746 76, 77RIPEMD160, see message digest algorithmRivest, Ronald, 24root CA, 62RSA algorithm, 30digital envelope, 31encryption using, 30random number generation, 47signing using, 30RSA Cryptographic Standard (PKCS #1), 86RSA Cryptographic Standard (PKCS #13), 93Ssalt, 25second preimage resistance, 42secondary CA, 62secret key cryptography, see also symmetric keycryptographySecure Sockets Layer,security dimensions,access control, 10authentication, 10data confidentiality, 11data integrity, 11non-repudiation, 11security strength, 80categories, 81seed, 12seeding 48seedlings, 48Selected Attribute Types Standard (PKCS #9), 90session reuse handshake, 73SHA-1, see message digest algorithmSHA-2, see message digest algorithmsignature, 29SSL, see Secure Sockets Layerstream cipher, 23RC4, 24Suite B Cryptography, 79certificate validation, 82cipher suite profiles, 83Transport Layer Security, 83symmetric ciphers, and key wrapping 38symmetric key cryptography, 14random number generation, 47TTLS, see Transport Layer SecurityTransport Layer Security, 69alert protocol, 75basic handshake, 71change cipher spec protocol, 76cipher suites, 71handshake protocol, 71record protocol, 74renegotiation vulnerability, 76session reuse handshake, 73Suite B cipher suite profiles, 83Triple DES, 21Vverification, 29vulnerability, 12WWrapping, of keys 38XXEX-based Tweaked CodeBook Mode withCiphertext Stealing, 20XOR, 24, 117XTS, see XEX-based Tweaked CodeBook Mode withCiphertext Stealing122 Index