ML22101A253

From kanterella
Jump to navigation Jump to search
CSO-GUID-2009 Cryptographic Control ESA Guidance v1.0
ML22101A253
Person / Time
Issue date: 09/15/2021
From: Jonathan Feibus
NRC/OCIO/CISD
To:
Shared Package
ML22101A241 List:
References
CSO-GUID-2009
Download: ML22101A253 (30)
v • d • e


Text

Nuclear Regulatory Commission Office of the Chief Information Officer Computer Security Guidance Office Instruction:

CSO-GUID-2009 Office Instruction

Title:

Cryptographic Control Enterprise Security Architecture Guidance Version Number:

1.0 Effective Date:

September 15, 2021 Primary Contacts:

Jonathan Feibus Responsible Organization:

OCIO/CSO

==

Description:==

CSO-GUID-2009, Cryptographic Control Enterprise Security Architecture Guidance, provides additional information in complying with the cryptographic control security requirements specified in CSO-STD-2009, Cryptographic Control Enterprise Security Architecture Standard.

Training:

As requested Approvals Primary Office Owner Office of the Chief Information Officer (OCIO) /

Computer Security Organization (CSO)

Signature Date SWG Chair Bill Bauer

/RA/

8/26/2021 CISO (Acting)

Garo Nalabandian

/RA/

9/8/2021

CSO-GUID-2009 Page i TABLE OF CONTENTS 1

PURPOSE............................................................................................................................................. 1 2

GENERAL GUIDANCE......................................................................................................................... 1 2.1 CRYPTOGRAPHY USE CASES............................................................................................................ 1 2.2 OVERVIEW OF CRYPTOGRAPHY AND CRYPTOGRAPHIC SYSTEMS........................................................ 2 2.3 CRYPTOGRAPHIC ALGORITHMS......................................................................................................... 3 2.3.1 Types of Cryptographic Algorithms.......................................................................................... 4 2.3.1.1 Symmetric-Key Algorithms................................................................................................ 4 2.3.1.2 Asymmetric-Key Algorithms.............................................................................................. 5 2.3.1.3 Hash Functions.................................................................................................................. 5 2.3.2 Message Authentication Code................................................................................................. 6 2.3.3 Hash-Based Message Authentication Code............................................................................ 6 2.3.4 Digital Signatures..................................................................................................................... 7 2.4 CRYPTOGRAPHIC MODULES.............................................................................................................. 7 2.5 CRYPTOGRAPHIC KEY MANAGEMENT................................................................................................. 8 2.5.1 Cryptographic Key Establishment............................................................................................ 8 2.5.2 Cryptographic Key Usage........................................................................................................ 9 2.6 CRYPTOGRAPHIC ALGORITHMS AND SECURITY STRENGTH............................................................... 10 2.6.1 Projected Security Strength Time Frames............................................................................. 10 2.6.2 Security Strength of Symmetric Block Cipher and Asymmetric-key Algorithms.................... 11 2.6.3 Security Strength of Hash Functions and Hash-based Functions......................................... 12 2.7 CRYPTOPERIOD.............................................................................................................................. 13 2.8 CRYPTOGRAPHIC KEY MANAGEMENT SYSTEM................................................................................. 14 2.9 PUBLIC KEY INFRASTRUCTURE........................................................................................................ 15 3

SPECIFIC GUIDANCE........................................................................................................................ 15 3.1 TRANSPORT LAYER SECURITY......................................................................................................... 15 3.1.1 TLS 1.3................................................................................................................................... 16 3.1.2 TLS 1.2................................................................................................................................... 17 3.1.3 TLS 1.1 and 1.0..................................................................................................................... 18 3.2 COMMERCIAL NATIONAL SECURITY ALGORITHM SUITE..................................................................... 18 3.3 NSA COMMERCIAL SOLUTIONS FOR CLASSIFIED PROGRAM.............................................................. 18 3.4 CRYPTOGRAPHIC CONTROLS FOR DATA IN TRANSIT AND AT REST..................................................... 19 3.4.1 Data in Transit........................................................................................................................ 19 3.4.2 Data at Rest........................................................................................................................... 19 APPENDIX A.

ACRONYMS................................................................................................................... 21 APPENDIX B.

GLOSSARY.................................................................................................................... 23 APPENDIX C.

REFERENCES................................................................................................................ 27 List of Tables Table 2.1-1: Cryptographic Use Cases........................................................................................................ 2 Table 2.6-1: Security Strength Time Frames............................................................................................. 11 Table 2.6-2: Security Strengths of Symmetric Block Cipher and Asymmetric-key Algorithms.................. 12 Table 2.6-3: Maximum Security Strength of Hash Functions and Hash-based Functions........................ 12

Computer Security Guidance CSO-GUID-2009 Cryptographic Control Enterprise Security Architecture Guidance 1 PURPOSE CSO-GUID-2009, Cryptographic Control Enterprise Security Architecture Guidance, provides additional information in complying with the cryptographic control security requirements specified in CSO-STD-2009, Cryptographic Control Enterprise Security Architecture Standard, for the Nuclear Regulatory Commission (NRC) network-computing environment.

This document is intended for system owners, system administrators, system and solution architects, information technology (IT) system managers (operational and project-related), and Information System Security Officers (ISSOs) to ensure compliance with CSO-STD-2009.

The following National Institute of Standards and Technology (NIST) Special Publications (SPs) provide details on cryptographic key management, best practices for key management organization and application-specific key management:

NIST SP 800-57, Part 1, Recommendation for Key Management: Part 1: General; NIST SP 800-57, Part 2, Recommendation for Key Management: Part 2: Best Practices for Key Management Organization; and NIST SP 800-57, Part 3, Recommendation for Key Management: Part 3: Application-Specific Key Management Guidance.

These documents provide additional guidance to facilitate compliance with CSO-STD-2009.

2 GENERAL GUIDANCE The security requirements specified in CSO-STD-2009 relate to cryptographic modules, algorithms, and key management systems that are used in the NRC systems environment. The requirements in CSO-STD-2009 are derived from the high-level concepts and terminology associated with the NRC enterprise security architecture (ESA), as described in the following subsections.

2.1 Cryptography Use Cases Cryptography is used to secure all transmitted information in the internet-connected world, to authenticate users and devices, and a device to other devices. Cryptography is an essential part of securing information and communications by using a set of rules that allow only the intended recipients to receive and process the information. Table 2.1-1, Cryptographic Use Cases, provides examples of when cryptography may be necessary for NRC systems and applications.

CSO-GUID-2009 Page 2 Table 2.1-1: Cryptographic Use Cases Use Case Cryptography Purpose Information with a confidentiality sensitivity of moderate or above Confidentiality of data at rest and data in transit Information with an integrity sensitivity of moderate or above Integrity of data at rest and data in transit Cryptographic key management Confidentiality and integrity protection of cryptographic keys Remote system/data access Protection of remote user, system, and device access to a system which includes use of digital certificates to ensure user access can validate that the connection is with a valid NRC computer (e.g., NRC websites)

Wireless access to system/data Protection of authentication information and information transmission Authenticator management Protection of individual and device authentication information Electronic signatures Creation of all types of electronic signatures and verification of signature authenticity Secure name and address resolution Secure Domain Name System (DNS)

NOTE: Further information on use of cryptography is provided in NIST SP 800-57 (all parts).

2.2 Overview of Cryptography and Cryptographic Systems Cryptography is an art or science concerning the principles, means, and methods for rendering plain information unintelligible and for restoring encrypted information to intelligible form.1 Encryption is the cryptographic transformation of data to produce ciphertext.2 In order to encrypt plaintext and produce ciphertext, encryption uses a defined algorithm (also known as a cipher) to make information unintelligible and generate the ciphertext. In simpler terms, encryption is a method of converting data into an undecipherable format so that only the authorized parties can access the information.

A cryptographic system (cryptosystem) refers to the associated information security (INFOSEC) items interacting to provide a single means of encryption or decryption3 used to produce ciphertext via encryption or to obtain plaintext from ciphertext via decryption. A cryptographic system requires three components:

Plaintext data/information to encrypt; Method to encrypt the data using a cryptographic algorithm; and Encryption (cryptographic) keys to use in conjunction with the data and the algorithm.

Most modern programming languages provide libraries with a wide range of available cryptographic algorithms, such as the Advanced Encryption Standard (AES). Choosing the right 1 NISTIR 7298, Glossary of Key Information Security Terms, https://doi.org/10.6028/NIST.IR.7298r3.

2 Ibid.

3 Ibid.

CSO-GUID-2009 Page 3 algorithm involves evaluating security, performance, and compliance requirements specific to any particular application.

Just as the selection of an encryption algorithm is important, protecting the keys from unauthorized access is also critical. Often, a Key Management Infrastructure (KMI) is used to manage the security of encryption keys. A KMI is the framework and services that provide the generation, production, storage, protection, distribution, control, tracking, and destruction for all cryptographic keying material, symmetric keys as well as public keys and public key certificates.4 A KMI is comprised of the following functional elements or nodes for the generation, distribution, and management of cryptographic keys:

1. A central oversight authority
2. Key processing facility(ies)
3. Service agents, and
4. Client nodes.

Additional information on KMIs is provided in NIST SP 800-57, Part 2.

A common way to protect keys in a KMI is to use a cryptographic module. A cryptographic module is the set of hardware, software, and/or firmware that implements approved security functions (including cryptographic algorithms and key generation) and is contained within the cryptographic boundary.5 With respect to KMI, a cryptographic module typically provides tamper evidence or resistance to protect keys from unauthorized use.

Cryptography algorithms, modules, and key management systems are used to protect sensitive data.

2.3 Cryptographic Algorithms A cryptographic algorithm is a well-defined computational procedure that takes variable inputs, including a cryptographic key, and produces an output.6 Federal Information Processing Standards (FIPS)-validated cryptographic algorithms are used to secure data and communication services.

NIST has established a Cryptographic Algorithm Validation Program (CAVP) in which cryptographic algorithm testing is conducted to ensure that a specific algorithm is implemented and functions correctly. An algorithm implementation has to meet all the requirements of its associated FIPS Publication (PUB), such as FIPS PUB 197, Advanced Encryption Standard (AES), before it can be listed as Approved on the NIST validation certificate.

4 NISTIR 7298, Glossary of Key Information Security Terms, https://doi.org/10.6028/NIST.IR.7298r3.

5 FIPS PUB 140-3, Security Requirements for Cryptographic Modules, https://doi.org/10.6028/NIST.FIPS.140-3.

6 NISTIR 7298, Glossary of Key Information Security Terms, https://doi.org/10.6028/NIST.IR.7298r3.

CSO-GUID-2009 Page 4 2.3.1 Types of Cryptographic Algorithms There are three common types of cryptographic algorithms:

Symmetric-Key Algorithms Asymmetric-Key Algorithms Hash Functions 2.3.1.1 Symmetric-Key Algorithms Symmetric-key algorithms (also known as secret-key algorithms) encrypts data in a way that is difficult to unencrypt without knowledge of a secret key. Secret key cryptography uses symmetric-key algorithms where a single secret key is used for both encryption and decryption.

Symmetric-key algorithms are used, for example, to:

Provide data confidentiality the same key is used to encrypt and decrypt the data; Provide source and integrity authentication services in the form of Message Authentication Codes (MACs) the same key is used to generate the MAC and to validate it; Derive keying material from a pre-shared key using a key-derivation method; Derive a key from a shared secret during the use of an asymmetric key-agreement scheme; Wrap keys using a key-wrapping algorithm; and Generate random numbers.

One of the approved symmetric-key algorithms is the AES. AES is a block-cipher algorithm, which operates on blocks of data during encryption/decryption operations. The AES algorithm encrypts and decrypts information in 128-bit blocks while using 128, 196, or 256-bit keys, which are specified within FIPS PUB 197.

The block-cipher algorithm is used in conjunction with block cipher modes-of-operation to safeguard against unauthorized data interception. The most commonly used block cipher modes are:

Galois/Counter Mode (GCM)

Cipher Block Chaining (CBC) Mode Electronic Codebook (ECB) Mode Cipher Feedback (CFB) Mode Counter (CTR) Mode Output Feedback (OFB) Mode Further details of approved block cipher modes are provided in NIST SP 800-38A, Recommendation for Block Cipher Modes of Operation and NIST SP 800-38D, Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC.

CSO-GUID-2009 Page 5 Symmetric keys are most often known by more than one entity; however, the key should not be disclosed to entities not authorized to access the data protected by that algorithm and key.

2.3.1.2 Asymmetric-Key Algorithms Asymmetric-key algorithms (also known as public-key algorithms) use a key pair or two related keys, a public key and private key. The two keys are such that deriving the private key from the public key is computationally not feasible. The public key may be known by many, whereas, the private key is under the sole control of the key pair owner. Even though the public and private keys of a key pair are related, knowledge of the public key does not reveal the private key. The examples of current FIPS-approved asymmetric-key algorithms are:

Digital Signature Algorithm (DSA);

Rivest-Shamir-Adleman (RSA) Algorithm, Edwards-Curve Digital Signature Algorithm (EdDSA); and Elliptic Curve Digital Signature Algorithm (ECDSA).

The Elliptic Curve Cryptography (ECC) is a newer choice for the asymmetric-key cryptography that offers much higher performance over traditional public-key cryptography. With an asymmetric-key algorithm, one of the two keys are used to apply cryptographic protection and the other key is used to remove or verify that protection. Asymmetric-key algorithms are used for:

Confidentiality: Ensuring that only the owner of the key pair can see the information when the owners public key is used to encrypt the data.

Integrity: Addressing the unauthorized or accidental modification of information, which includes insertion, deletion, and modification. To ensure data integrity, the system has to detect any unauthorized modification. The goal is to verify that the information has not been altered at the receiving end.

Authentication: Establishing the validity of a transmission, message, or an originator.

Therefore, this service applies to both individuals and the information itself. The goal is for the receiver of the information to determine its origin.

Non-repudiation: Preventing an individual from denying that previous actions have been performed. The goal is to ensure that the recipient of the information is assured of the sender's identity.

2.3.1.3 Hash Functions A hash function takes an input of arbitrary length and outputs a fixed-length value, often known as a hash value, hash, message digest, and digital fingerprint. Cryptographic hash functions do not require keys.

Many algorithms and schemes that provide a security service use a hash function as a component of the algorithm. Hash functions can be found in digital signature algorithms, Hash-based Message Authentication Code (HMAC), and random number generators.

The algorithms with hash functions are used to determine the integrity of a message and protect against unauthorized modification. If there is any change in the message during data

CSO-GUID-2009 Page 6 transmission, it is highly probable that the resulting hash value will be different. The maximum number of input and output bits is determined by the design of the hash function.

There are three FIPS-approved Secure Hash Algorithm (SHA) families:

SHA-1 (limited usage, see details below)

SHA-2 SHA-3 These families specify one-way hash functions that can process a message to produce a condensed representation called a hash value:

SHA-1 is disallowed by NIST for digital signature generation that requires collision resistance for federal applications due to inherent vulnerabilities.7 SHA-2 and SHA-3 provide a higher level of security and can be used as alternatives.

FIPS PUB 180-4, Secure Hash Standard, and FIPS PUB 202, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions, provide further details about the approved hash functions.

2.3.2 Message Authentication Code MAC is a cryptographic checksum on data that uses a symmetric key to detect both accidental and intentional modifications of the data.8 Use of a MAC enables detection of modification of the data and ensures the recipient that only someone who knows the secret key could have sent the message. The MAC normally employs either a symmetric-key algorithm or a cryptographic hash function as the cryptographic primitive.

2.3.3 Hash-Based Message Authentication Code An HMAC is a message authentication code that uses a cryptographic key in conjunction with a hash function.9 HMACs use an approved hash function, a secret key, and the information to be hashed. Keyed-hash functions are also used in challenge-response identification protocols for computing responses, which are a function of both a secret key and a challenge message. MAC and HMAC SHA-1 and HMAC SHA-2 use keyed-hashing algorithms.

For example:

The message sender uses an HMAC function to produce a value formed by condensing the secret key and the challenge message input. The resulting MAC is sent to the message receiver along with the message. The receiver computes the MAC on the received message, using the same secret key and HMAC function. If both values match, the 7 NIST Hash Functions website, http://csrc.nist.gov/groups/ST/hash/policy.html.

8 NISTIR 7298, Glossary of Key Information Security Terms, https://doi.org/10.6028/NIST.IR.7298r3.

9 Ibid.

CSO-GUID-2009 Page 7 message has been correctly received, and the receiver is assured that the sender is a member of the authorized user group that shares the key.

A variety of key sizes are allowed for HMAC, where the key size depends on the level of security and the choice of hash function. FIPS PUB 198-1, The Keyed-Hash Message Authentication Code (HMAC), defines all HMAC implementations and key size requirements.

2.3.4 Digital Signatures A digital signature is a type of electronic signature. A digital signature is a result of a cryptographic transformation of data that, when properly implemented, provides the services of:

1. Origin Authentication
2. Data Integrity
3. Signer Non-repudiation10 The digital signature is used to prove to the recipient, or a third party, that the originator signed the message that was received. Verification of a digital signature also verifies that the information was not modified since the signature was generated.

Digital signatures may also be generated for data at rest so that the integrity of the data may be verified at a later time. Digital signatures authenticate the integrity of the signed data and the identity of the signatory. Signature generation uses a private key to generate a digital signature, and signature verification uses a public key that corresponds to the private key to verify the signature. The signatory owns both the public and private keys used in the process.

A hash function is used in the signature generation process to obtain a hash value. The resulting hash value is used with the digital signature algorithm to generate the digital signature.

The digital signature is sent with the signed data to the recipient. The recipient verifies the message and signature by using the signatory's public key. The same hash function and digital signature algorithm is used in the verification process.

Similar procedures generate and verify signatures for encrypted data in transit, as well as data at rest. FIPS PUB 186-4, Digital Signature Standard (DSS), provides detailed information related to digital signature applications.

2.4 Cryptographic Modules A cryptographic module is the set of hardware, software, and/or firmware that implements approved security functions (including cryptographic algorithms and key generation) and is contained within the cryptographic boundary. A cryptographic boundary is explicitly defined by the physical bounds of a cryptographic module that contains all the hardware, software, and/or firmware components of a cryptographic module.

FIPS PUB 140-3, Security Requirements for Cryptographic Modules, specifies the security requirements for a cryptographic module used to protect sensitive information within information 10 NISTIR 7298, Glossary of Key Information Security Terms, https://doi.org/10.6028/NIST.IR.7298r3.

CSO-GUID-2009 Page 8 technology systems. A FIPS PUB 140-3 compliant cryptographic module is used to implement at least one approved security function in an approved mode of operation.

FIPS PUB 140-3 was approved on March 22, 2019, with a grace period of 6 months for the testing labs to develop and implement FIPS 140-3 compliance testing..

There are four security levels specified for the cryptographic modules. Each level offers increased security over the preceding level. FIPS PUB 140-3 validations are determined at these security levels individually, with Level 1 being the lowest and Level 4 being the highest.

The main difference in making this determination is the way physical and logical access to the cryptographic module is limited to ensure its integrity at each level.

NIST established the Cryptographic Module Validation Program (CMVP) that validates cryptographic modules to FIPS PUB 140-3 and other FIPS cryptography-based standards.

Cryptographic module vendors use independent, accredited Cryptographic and Security Testing (CST) laboratories to test their modules and obtain validation certificates. The CMVP certificate indicates the security level provided by each cryptographic module depending on their physical and logical access; however, the strength and functionality of the cryptography is the same.

The Computer Security Division at NIST serves as the Validation Authority for the program, validating the test results. Validated cryptographic module listings are placed at the CMVP website11 that provides federal agencies with a security metric to use in procuring equipment containing validated cryptographic modules.

A cryptographic module used to secure classified information has to be validated to comply with National Security Agency (NSA) specific requirements, and systems that process Sensitive Compartmented Information (SCI) has to adhere to Director of National Intelligence (DNI) requirements.

2.5 Cryptographic Key Management Cryptographic key management encompasses the entire lifecycle of cryptographic keys used by a cryptographic module. This includes random number generation, key generation, key establishment (including key transport), key entry/output, key storage, key retirement (retaining keys for decryption of data after retirement), and key destruction.

Cryptographic key management is an essential part of the effective use of cryptography for security. Cryptographic keys can be envisioned as the combination on a safe. If the combination is weak and can be guessed by the adversaries, then the strongest safe can provide no protection against penetration. Similarly, poor key management may easily compromise strong algorithms. All keys need to be protected against unauthorized substitution and modification. Key management provides the foundation for protecting cryptographic keys from unauthorized disclosure, modification, and substitution.

2.5.1 Cryptographic Key Establishment Cryptographic key establishment is the process through which two or more entities share a key.

This process can be based on a manual transport method (key loaders) or by using automated 11 NIST Cryptographic Module Validation Program website, http://www.nist.gov/cmvp.

CSO-GUID-2009 Page 9 methods (key-transport and/or key agreement protocols). The key derivation can also be used from a pre-shared key between the entities. Key establishment processes include the creation of a key for cryptography functions between the entities.

Cryptographic keying material can be established between two or more entities by using a key-establishment scheme, that is, by using either a key-agreement scheme or a key-transport scheme:

Key Transport: A key-establishment procedure whereby one entity (the sender) selects a value for secret keying material and then securely distributes that value to one or more other entities (the receivers).12 Key Agreement: A (pair-wise) key-establishment procedure in which the resultant secret keying material is a function of information contributed by both participants so that neither party can predetermine the value of the secret keying material independently from the contributions of the other party.13 If an asymmetric-key algorithm is used, each entity has either a static key pair or an ephemeral key pair, or both. If a symmetric-key algorithm is used, each entity shares the same key-wrapping key.

Key-establishment protocols use key-establishment schemes to ensure that:

Each entity in the key distribution process knows the identifier of other entities; The keying material is correctly associated with entities; and The keying material has been correctly received.

There are several different types of cryptographic keys that can be used. Further information related to key types and their use is provided in NIST SP 800-57, Part 1.

References to the NIST guidance documents for approved pair-wise key-establishment schemes are provided in Appendix C, References.

2.5.2 Cryptographic Key Usage Cryptographic keys are used in many processes, such as encryption, authentication, random number generation, or digital signatures. If the same key is used for more than one purpose, it may result in an undesirable outcome if the key is compromised. The following should be kept in mind when selecting cryptographic key usage in multiple applications:

The use of the same key for two different cryptographic processes may weaken the security provided by one or both of the processes.

Limiting the use of a key limits the damage that could be done if the key is compromised.

Some uses of keys interfere with each other:

For example:

12 NISTIR 7298, Glossary of Key Information Security Terms, https://doi.org/10.6028/NIST.IR.7298r3.

13 Ibid.

CSO-GUID-2009 Page 10 The longevity requirements for the private key-transport key and for the private digital-signature key will contradict each other, due to the fact that the first has to be kept for encryption/decryption purposes beyond its cryptoperiod and the second has to be destroyed at the expiration of its cryptoperiod to prevent its compromise.

The need to escrow encryption keys to enable decryption of organization data if the owner of the key is not available. If the same key is used for authentication, then the escrow key could be used to impersonate the owner.

2.6 Cryptographic Algorithms and Security Strength Cryptographic algorithms have been developed and used in many different protocols and functions for a long time. However, advanced computing and art of cryptanalysis have made it necessary to adopt the newer and stronger algorithms and larger key sizes to attain the desired level of security strength.

Some older algorithms and key sizes no longer provide adequate protection from modern threats and need to be replaced. Therefore, it is critical that only NIST and FIPS approved algorithms are used for the protection of information. It is also recommended that larger key sizes should be used, in place of the minimum specified in CSO-STD-2009, for additional protection.

Cryptographic algorithms and associated key sizes may become vulnerable to successful attacks after a certain period of time. Therefore, projected time frame for applying cryptographic protection at minimum security strength are provided, as a guidance.

2.6.1 Projected Security Strength Time Frames The projected time frame guidance for applying cryptographic protection at minimum security strengths is illustrated in Table 2.6-1, Security Strength Time Frames. When selecting a key length or algorithms for desired security strength, these time frames should be kept in mind.

The following defines the information provided within the columns of Table 2.6-1:

1. Column 1, Security Strength, is divided into two sub-columns. The first sub-column (to the left) indicates the security strength to be provided; the second sub-column (to the right) indicates whether cryptographic protection is being applied to data (i.e.,

encrypted), or whether cryptographically protected data is being processed (i.e.,

decrypted).

2. Column 2, Through 2030, and Column 3, 2031 and Beyond, indicate the time frames during which the security strength is either Acceptable, okay for Legacy Use, or Disallowed.

Acceptable: Indicates that the algorithm or key length is currently considered to be secure.

Legacy Use: Indicates that an algorithm or key length may be used in legacy applications (i.e., the algorithm or key length can be used to process cryptographically protected data).

CSO-GUID-2009 Page 11 Disallowed: Indicates that an algorithm or key length should not be used for applying cryptographic protection.

Table 2.6-1: Security Strength Time Frames Security Strength (in Bits)

Through 2030 2031 and Beyond 112 Applying Acceptable Disallowed Processing Legacy Use 128 Applying/Processing Acceptable Acceptable 192 Acceptable Acceptable 256 Acceptable Acceptable 2.6.2 Security Strength of Symmetric Block Cipher and Asymmetric-key Algorithms Strong cryptographic algorithms mitigate security issues other than just brute force cryptographic attacks. However, some unintentional implementations of these algorithms may leak some information about the key. In this case, the larger key that provides a higher level of security strength may reduce the likelihood that this leaked information will eventually compromise the key.

When selecting a block-cipher cryptographic algorithm (e.g., AES), the block size is also an important factor, as the amount of security depends on the block size. If specific data is sensitive for a very long time, the security strength of the key used to protect that information should be much greater than if the data is only sensitive for a short period of time.

Cryptographic algorithms and key length requirements are determined based on the sensitivity of the information paired with the length of time the information will remain sensitive. Table 2.6-2, Security Strengths of Symmetric Block Cipher and Asymmetric-key Algorithms, provides estimated, comparable, maximum security strengths for approved symmetric block ciphers and asymmetric-key algorithms and key lengths for federal system applications.

The following defines the information contained within the columns of Table 2.6-2:

Maximum Security Strength: Indicates the estimated maximum-security strength, in number of bits, provided by the algorithm and key lengths given in that row.

Symmetric-Key Algorithm: Identifies the symmetric-key algorithms that provide the indicated level of security.

FFC: Indicates the minimum size of the parameters associated with the standards that use Finite-Field Cryptography (FFC) (e.g., algorithms such as DSA for digital signatures, Diffie-Hellman [DH] and Menezes-Qu-Vanstone [MQV]) key agreements, where the public key size is denoted by L and private key by N.

IFC: Indicates the value for k (the size of the modulus n) for algorithms (e.g., RSA) based on Integer-Factorization Cryptography (IFC).

ECC: Indicates the range of f for algorithms (e.g., ECDSA, EdDSA, DH, MQV) based on ECC that are specified for digital signatures and key establishment.

CSO-GUID-2009 Page 12 Table 2.6-2: Security Strengths of Symmetric Block Cipher and Asymmetric-key Algorithms Maximum Security Strength (in Bits)

Symmetric-Key Algorithm FFC (for DSA, DH, MQV)

IFC*

(for RSA)

ECC*

(for ECDSA, EdDSA, DH, MQV) 128 AES-128 L=3072 N=256 k=3072 f=256-383 192 AES-192 L=7680 N=384 k=7680 f=384-511 256 AES-256 L=15360 N=512 k=15360 f=512+

  • The security-strength estimates will be significantly affected when quantum computing becomes a practical consideration.

The estimated security strengths for the FCC, IFC, and ECC algorithms can be calculated using a formula provided in the Implementation Guidance for FIPS 140-2 and the Cryptographic Module Validation Program14. Further information on security strength, block cipher, and algorithms is provided in NIST SP 800-57, Part 1.

2.6.3 Security Strength of Hash Functions and Hash-based Functions The security strength of a hash function is determined by the properties required by the application in which it is used. Appropriate hash functions that can be employed are determined by the algorithm, scheme, or application in which the hash function is used and by the minimum security-strength required.

Table 2.6-3, Maximum Security Strength of Hash Functions and Hash-based Functions, lists the approved hash functions with the smallest output block length that can be used to provide the security strength for various hash-function applications: digital signatures, HMAC or Keccak-based Message Authentication Code (KMAC), key-derivation functions and random bit generation.

Table 2.6-3: Maximum Security Strength of Hash Functions and Hash-based Functions Security Strength (in Bits)

Digital Signatures and Other Applications Requiring Collision Resistance HMAC1 / KMAC2 Key Derivation Functions3 Random Bit Generation4 128 SHA-256 SHA-512/256 SHA3-256 SHA-1, KMAC128 SHA-1, KMAC128 SHA-1, KMAC128 192 SHA-384 SHA3-384 SHA-224 SHA-512/224 SHA3-224 SHA-224 SHA-512/224 SHA3-224 SHA-224 SHA-512/224 SHA3-224 256 or more SHA-512 SHA3-512 SHA-256 SHA-512/256 SHA-384 SHA-512 SHA-256 SHA-512/256 SHA-384 SHA-512 SHA-256 SHA-512/256 SHA-384 SHA-512 14 Implementation Guidance for FIPS 140-2 and the Cryptographic Module Validation Program, Section 7.5, Strength of Key Establishment Methods: Implementation Guidance for FIPS 140-2 (nist.gov)

CSO-GUID-2009 Page 13 Security Strength (in Bits)

Digital Signatures and Other Applications Requiring Collision Resistance HMAC1 / KMAC2 Key Derivation Functions3 Random Bit Generation4 SHA3-512 KMAC256 SHA3-512 KMAC256 SHA3-512 KMAC256 NOTES:

1 Assumes that preimage resistance is required rather than collision resistance.

2 Based on functions specified in FIPS 202.

3 Security strength for key-derivation assumes that the shared secret or key used contains sufficient entropy to support desired security strength.

4 Security strength for random bit generation assumes that the random bit generator has been provided with adequate entropy to support the desired security strength.

SHA-1 may only be used for digital signature generation where it is specifically allowed by the NIST protocol-specific guidance. For all other applications, SHA-1 is disallowed for digital signature generation.

2.7 Cryptoperiod A cryptoperiod is the time span during which a specific key is authorized for use or in which the keys for a given system or application may remain in effect. A suitably defined cryptoperiod:

1. Limits the amount of information protected by a given key that is available for cryptanalysis;
2. Limits the amount of exposure if a single key is compromised;
3. Limits the use of a particular algorithm (e.g., to its estimated effective lifetime);
4. Limits the time available for attempts to penetrate physical, procedural, and logical access mechanisms that protect a key from unauthorized disclosure;
5. Limits the period within which information may be compromised by inadvertent disclosure of keying material to unauthorized entities; and
6. Limits the time available for computationally intensive cryptanalytic.

Cryptoperiods, sometimes, are defined by an arbitrary time period or maximum amount of data protected by the key. However, cryptoperiods should be selected based on the risk and consequences of exposure. The following risk factors should be considered when defining a cryptoperiod:

1. The strength of the cryptographic mechanisms (e.g., the algorithm, key length, block size, and mode of operation);
2. The embodiment of the mechanisms (e.g., a FIPS 140 Level 4 implementation or a software implementation on a personal computer);
3. The operating environment (e.g., a secure limited-access facility, open office environment, or publicly accessible terminal);
4. The volume of data flow or the number of transactions;
5. The security life of the data;

CSO-GUID-2009 Page 14

6. The security function (e.g., data encryption, digital signature, key derivation, or key protection);
7. The re-keying method (e.g., keyboard entry, re-keying using a key loading device where humans have no direct access to keys, or remote re-keying within a Public Key Infrastructure [PKI]);
8. The re-keying or key-derivation process used;
9. The number of nodes in a network that share a common key;
10. The number of copies of a key and the distribution of those copies;
11. Personnel turnover (e.g., of system administrators and certification systems personnel);
12. The threat to the information from adversaries (e.g., perceived technical capabilities and financial resources to mount an attack); and
13. The threat to the information from new and disruptive technologies (e.g., quantum computers).

A key uses an algorithm to create ciphertext from plaintext and to decipher it on the receiving end. Once the cryptoperiod ends, the key is no longer available for either encryption or decryption. A properly defined cryptoperiod limits the amount of exposure if a single key is compromised or an attempt is made for cryptanalysis. If specific data is sensitive for a very long time, the strength of the key used to protect that information should be much greater than if the data is only sensitive for a short period of time.

In general, short cryptoperiods enhance security. For example, a cryptographic algorithm may be less vulnerable to cryptanalysis if the adversary has only a limited amount of data encrypted under a single key.

Cryptoperiods associated with different keys vary in time depending on the key types. Further details about cryptoperiod recommendations for various key types are provided in NIST SP 800-57, Part 1.

2.8 Cryptographic Key Management System The Cryptographic Key Management System (CKMS) provides administrators with the ability to centrally manage the lifecycle of all cryptographic keys across a range of encryption platforms.

The term CKMS refers to the framework and services that are utilized for the generation, establishment, control, accounting, and destruction of cryptographic keys and associated management information. Cryptography is used to protect sensitive data. This protection is provided by using specifically designed algorithms and cryptographic keys, which are managed by the CKMS. The cryptographic algorithm and various size keys provide the level of protection or security strength. The keys are either static or ephemeral, where static keys are regarded as long-term, multi-use keys and ephemeral keys are short-term, single use keys generated when needed. Physical protection of a CKMS is equally important to ensure authorized user access and used only by the designated system operators.

Recommendations for CKMS design and implementation are provided in NIST SP 800-152, A Profile for U.S. Federal Cryptographic Key Management System.

Key management policy and best practices guidance is provided in NIST SP 800-57 (all parts).

CSO-GUID-2009 Page 15 2.9 Public Key Infrastructure A PKI enables users to exchange information securely and privately via a public and private cryptographic key pair that is obtained and shared through a trusted authority. The PKI binds public keys to an entity via a digital certificate that is digitally signed by a trusted entity and provides the capability for others to verify those bindings. A PKI also provides services that can store, access, add, and revoke certificates.

A PKI is an enabler of trust that provides strong user and other entity identification, confidential communication, data integrity, and evidence for non-repudiation among individuals and entities that may or may not have had prior knowledge of each other. The trust that PKI facilitates is enterprise-wide through distinct, yet integrated policies and technology components. These policies and components explicitly identify and determine the roles, responsibilities, constraints, range of use, and services available.

A Certification Authority (CA) represents the people, processes, and tools to create digital certificates that securely bind a users identity to the users public key. The following parties rely on the appropriate level of trust with respect to the creation and use of public key certificates:

Individual subscriber or entity identified by the certificate; CA who issues the certificate; Registration or Validation Authority that provides identity verification and validation services in certain implementations; and Relying Party (company, agency, or individual) relying on the certificate.

As long as users trust a CA and the CAs policies for issuing and managing certificates, the users can trust certificates issued by the CA. The CA investigates individuals and verifies their identity, binding that identity to the public key, and verifying that the individual has the private key. The CA maintains and provides certificate status information for the life of the binding.

Levels of trust are placed on the level of identification and verification required by the certificate level (i.e., Low, Moderate, High).

3 SPECIFIC GUIDANCE The following guidance relates to specific topics in cryptographic control.

3.1 Transport Layer Security Transport Layer Security (TLS) and Secure Sockets Layer (SSL) were developed as protocols to create private, secure channels between a server and clients using encryption and authentication. While the standards and most products have been updated, some implementations have fallen behind in keeping up with the latest standards. Network connections employing obsolete protocols are most vulnerable to the attacks by adversaries.

Using obsolete encryption provides a false sense of security because it seems that sensitive data is protected, where it actually is not. Over time, new versions of the TLS protocols are developed, and some previous versions became obsolete due to technical reasons and vulnerabilities. NIST SP 800-52, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementation and the Committee on National Security

CSO-GUID-2009 Page 16 Systems (CNSS) Policy (CNSSP) 15, Use of Public Standards for Secure Information Sharing, prohibit U.S. Government and National Security Systems (NSS) from using obsolete protocols.

The CNSSP 15 requirements for TLS are identified in the Commercial National Security Algorithm (CNSA) Suite15.

Many TLS implementations in non-government environments (e.g., external IT services, public cloud services) support cipher suites that are not composed of only NIST-approved algorithms.

Therefore, it is very important to configure NRC systems to only permit use of NIST-approved algorithms/ciphers for all applications. NIST-approved algorithms/cipher suites are provided in NIST SP 800-52.

For example:

If NRC uses a Federal Risk and Authorization Management Program (FedRAMP)-

authorized public cloud service, the agency may not be able to make any configuration changes to the cryptographic algorithms/ciphers used by the cloud service provider. In that case, it would be the responsibility of the agency to make certain that NRC systems are configured to only permit the use of NIST-approved algorithms in order to enforce their use.

The TLS security model uses certificates to provide authenticity. These certificates are cryptographically signed by a trusted CA. A part of the signature process is computing a hash of the data included in the certificate, which is accomplished by using a standard hashing algorithm.

TLS is a protocol that provides for authentication, confidentiality, and data integrity between two communicating applications. TLS establishes an encrypted connection to an authenticated peer and uses a handshake protocol to negotiate session parameters. The TLS handshake protocol initializes both the client and server to use optional cryptographic capabilities by negotiating a cipher suite of algorithms and functions, including key establishment, digital signature, confidentiality, and integrity algorithms. The server selects a cipher suite from the list sent by the client to start the session. The handshake protocol is also used for configuration of security services, such as:

Confidentiality: Provides assurance that data is kept secret.

Message Integrity: Provides detection of unauthorized data modification, to ensure that undetected deletion, addition, or modification of data did not take place.

Authentication: Provides assurance of the sender or receivers identity.

Replay Protection: Provides assurance that an unauthorized user does not capture and successfully replay previous data.

3.1.1 TLS 1.3 TLS 1.3 is the most secure version of the current TLS protocol family. It was finalized in 2018, ten years after the previous TLS 1.2. Here are some differentiating factors in TLS 1.3:

Eliminated vulnerable algorithms and ciphers, (e.g., Rivest Cipher 4 [RC4] stream cipher, RSA key exchange, SHA-1 hash function, CBC block mode cipher, Message-15 NSA/CSS Commercial National Security Algorithm Suite, https://apps.nsa.gov/iad/programs/iad-initiatives/cnsa-suite.cfm.

CSO-GUID-2009 Page 17 Digest5 [MD5], Data Encryption Standard [DES], 3DES, various non-ephemeral DH groups)

Simplified key exchange, (e.g., RSA is out due to lack of ephemeral key mode support, DH is in due to ephemeral key support)

Faster due to refined handshake Authenticated Encryption with Additional Data (AEAD) symmetric encryption (that uses stream ciphers; block ciphers are out)

Simplified cipher suite format The TLS 1.3 cipher suites are defined differently. These cipher suites do not specify the key exchange algorithm. The following is an example of a TLS 1.3 cipher format:

TLS_AEAD_HASH AEAD: Indicates the algorithm is used for confidentiality, integrity, and message authentication.

HASH: Indicates the hashing algorithm is used with the HMAC-based Extract-and-Expand Key Derivation Function (HKDF).

The following is an example of a cipher suite supported by TLS 1.3 servers:

TLS_AES_256_GCM_SHA384 TLS: Denotes TLS is used for the cipher suite.

AES_256_GCM: Denotes AES encryption algorithm is used with a 256-bit AES key in GCM mode for confidentiality, integrity, and message authentication.

SHA384: Denotes SHA-384 is used for hashing algorithm.

In TLS 1.3,the cipher suite no longer includes the key exchange and signature algorithms; it just includes a symmetric cipher and hashing algorithm (as shown in the example above). All federal agencies are to support TLS 1.3 by January 1, 2024, as per NIST SP 800-52.

3.1.2 TLS 1.2 TLS 1.2 is the most used version, which made several improvements in security compared to TLS 1.1 to address vulnerabilities. NIST SP 800-52 requires that TLS 1.2 be configured with cipher suites using NIST-approved schemes and algorithms as the minimum appropriate secure transport protocol. The following are the key improvements in TLS 1.2 (compared with TLS 1.1):

MD5/SHA-1 replaced with SHA-256 MD5/SHA-1 digitally-signed elements replaced with single hash - negotiated during handshake Client/Servers ability to specify the accepted hash and signature algorithms Support for authenticated encryption for additional data modes TLS extensions and AES cipher suites

CSO-GUID-2009 Page 18 The enhancements for encryption in TLS 1.2 allow the use of more secure hash algorithms such as SHA-256, as well as advanced cipher suites that support ECC:

TLS_KeyExchangeAlgorithm_WITH_EncryptionAlgorithm_MessageAuthenticationAlgorithm The following is an example of a cipher suite supported by TLS 1.2 servers for interoperability purposes:

TLS_DHE_WITH_AES_256_GCM_SHA384 The following explains each component in the cipher suite example above:

TLS: Denotes TLS is used for the cipher suite.

DHE: Denotes algorithm used for the key exchange in this cipher suite.

AES_256_GCM: Denotes that AES encryption algorithm is used with a 256-bit AES key in GCM mode.

SHA384: Denotes that SHA-384 is used as the message authentication algorithm.

It should be noted that there is no interoperability between TLS 1.2 and TLS 1.3. A TLS 1.3 cipher suite cannot be negotiated for TLS 1.2 connection and TLS 1.2 cipher suite cannot be negotiated for TLS 1.3.

NIST SP 800-52 provides further information on approved TLS cipher suites for use in federal system applications.

3.1.3 TLS 1.1 and 1.0 TLS versions 1.0 and 1.1 cannot be used in protection of government-only applications due to inherent vulnerabilities. However, when interoperability with non-government systems is required, TLS 1.1 and TLS 1.0 may be supported. In that case, such applications should be assessed for any potential risk and acceptance.

3.2 Commercial National Security Algorithm Suite The CNSA Suite will provide new algorithms for the applications where Suite B algorithms are being used. Currently, Suite B cryptographic algorithms are specified by NIST and are used by NSAs Information Assurance Directorate (IAD) for protecting classified and unclassified NSS.

IAD will transition to quantum resistant algorithms in the near future as they become available and replace Suite B. Until then, use of Suite B elliptic curve algorithms will continue.

NSA is increasing reliance on commercial cryptographic technologies for securing NSS and is moving toward more transparency. Cryptographic algorithms are specified by NIST and are used by NSA in solutions approved for protecting NSS. They include cryptographic algorithms for encryption, key exchange, digital signature, and hashing.

3.3 NSA Commercial Solutions for Classified Program The Commercial Solutions for Classified (CSfC) Program was developed by NSA to enable commercial products to be used in layered solutions protecting classified NSS data. Although

CSO-GUID-2009 Page 19 NSA continues to employ both commercial-off-the-shelf (COTS) and government-off-the-shelf (GOTS) information solutions, the IAD first utilizes commercial technology to formulate solutions to protect classified information. NSA has developed and published solution-level specifications called Capability Packages (CPs) and works with industry leaders, governments, and academia to develop product-level requirements in U.S. Government Protection Profiles (PPs). Further information for the CSfC program is available on the NSA website16.

3.4 Cryptographic Controls for Data in Transit and at Rest Encryption provides both confidentiality and integrity of data in transit and at rest. Cryptography can provide data integrity either by using a hash of the data or by encrypting the data.

Confidentiality is provided when the data is encrypted in such a way that only authorized users, who have access to the key, can decrypt the data. Data encryption is provided by the use of different cryptographic key size that depends on the data category (i.e., High, Moderate, or Low).

3.4.1 Data in Transit Data in transit refers to data transmitted over an internal or external network, where it could be intercepted by an unauthorized person with access to the network. The internal or external networks could be either wired or wireless, or both, where an adversary could access the data by intercepting the data traffic by means of wiretapping or using sniffing tools. When clear text protocols (e.g. Hypertext Transfer Protocol [HTTP] or File Transfer Protocol [FTP]) are used for data transmission, the data traffic is in clear text and can be easily intercepted by someone using tools to access user emails, copy personal credentials, or copy sensitive files. Hence, to safeguard against unauthorized interception, data in transit is encrypted (e.g., using Hypertext Transfer Protocol Secure [HTTPS]).

The computational effort required to encrypt using symmetric keys is far less than that used to encrypt using asymmetric keys. As a result, asymmetric keys are generally used to securely exchange symmetric keys between the communicating parties, and the symmetric keys are used to encrypt the subsequent data transmissions.

The TLS protocol is commonly used to encrypt data in transit. TLS uses certificates to exchange public keys, and then the public keys are used to securely exchange private keys, making it very difficult for an adversary to intercept. Most encryption protocols include a hashing algorithm to ensure that data is not altered while in transit. This can also safeguard against man-in-the-middle attacks, because by decrypting and re-encrypting data, the attackers will alter the signature even if they do not change the data. When data in transit is encrypted, it can only be compromised if the session key is compromised.

3.4.2 Data at Rest Data at rest refers to data stored on media. Encryption of data at rest can protect sensitive data against unauthorized access.

16 NSA/CSS Commercial Solutions for Classified Program (CSfC), https://www.nsa.gov/Resources/Commercial-Solutions-for-Classified-Program/.

CSO-GUID-2009 Page 20 There are two types of encryption used for data at rest:

Hardware-based Encryption: Typically provided by a special internal or external (e.g.,

Universal Serial Bus [USB]) hard drive with built-in hardware encryption, which is most efficient and provides the least adverse performance impact.

Software-based Encryption: Provided on computer systems where performance is less of a concern; may be at the file system, file/folder, or other object (e.g., database) level.

If any adversary has physical access to a server or workstation, then file system permissions may not be effective in preventing unauthorized access to data. However, if data is encrypted at rest, the adversaries cannot access the data unless they obtain the decryption key. To quickly encrypt and decrypt data with minimal impact to system performance, most implementations use symmetric-key algorithms. For example, the AES encryption algorithm can be used to encrypt data at rest.

Hashing algorithms protect the integrity of data at rest, by means of calculating the hash value and comparing it later to detect any changes quickly and easily in the data.

CSO-GUID-2009 Page 21 APPENDIX A.

ACRONYMS AEAD Authenticated Encryption with Associated Data AES Advanced Encryption Standard CA Certification Authority CAVP Cryptographic Algorithm Validation Program CBC Cipher Block Chaining CFB Cipher Feedback CKMS Cryptographic Key Management System CMVP Cryptographic Module Validation Program CNSA Commercial National Security Algorithm CNSS Committee on National Security Systems CNSSP Committee for National Security Systems Policy COTS Commercial-off-the-Shelf CP Capability Package CSfC Commercial Solutions for Classified CSO Computer Security Organization CST Cryptographic and Security Testing CTR Counter DES Data Encryption Standard DH Diffie Hellman DNI Director of National Intelligence DNS Domain Name System DSA Digital Signature Algorithm DSS Digital Signature Standard ECB Electronic Codebook ECC Elliptic Curve Cryptography ECDSA Elliptic Curve Digital Signature Algorithm EdDSA Edwards-Curve Digital Signature Algorithm ESA Enterprise Security Architecture FIPS Federal Information Processing Standard FFC Finite-Field Cryptography FTP File Transfer Protocol GCM Galois/Counter Mode GOTS Government-off-the-Shelf GUID Guidance HKDF HMAC-based Extract-and-Expand Key Derivation Function

CSO-GUID-2009 Page 22 HMAC Hash-based Message Authentication Code HTTP Hypertext Transfer Protocol HTTPS Hypertext Transfer Protocol Secure IAD Information Assurance Directorate IFC Integer-Factorization Cryptography INFOSEC Information Security ISSO Information System Security Officer IT Information Technology KMAC Keccak-based Message Authentication Code KMI Key Management Infrastructure MAC Message Authentication Code MD5 Message-Digest5 Algorithm MQV Menezes-Qu-Vanstone NIST National Institute of Standards and Technology NRC Nuclear Regulatory Commission NSA National Security Agency NSS National Security Systems OCIO Office of the Chief Information Officer OFB Output Feedback PKI Public Key Infrastructure PP Protection Profile PUB Publication RC4 Rivest Cipher 4 RSA Rivest-Shamir-Adleman SCI Sensitive Compartmented Information SHA Secure Hash Algorithm SP Special Publication SSL Secure Sockets Layer STD Standard TLS Transport Layer Security USB Universal Serial Bus

CSO-GUID-2009 Page 23 APPENDIX B.

GLOSSARY Approved FIPS or NIST approved. An algorithm or technique that is either:

Specified in a FIPS PUB or NIST SP; or Adopted in a FIPS PUB or NIST SP Certificate A set of data that uniquely identifies a key pair and an owner that is authorized to use the key pair. The certificate contains the owners public key and possibly other information, and is digitally signed by a CA (i.e., a trusted party), thereby binding the public key to the owner.

Certification Authority The entity in a PKI that is responsible for issuing certificates and exacting compliance with a PKI policy.

Ciphertext Data in its encrypted form.

Collision Resistance An expected property of a hash function whereby it is computationally infeasible to find a collision.

Cryptanalysis

1. Operations performed in defeating cryptographic protection without an initial knowledge of the key employed in providing the protection.
2. The study of mathematical techniques for attempting to defeat cryptographic techniques and information system security. This includes the process of looking for errors or weaknesses in the implementation of an algorithm or in the algorithm itself.

Cryptographic Algorithm A well-defined computational procedure that takes variable inputs, including a cryptographic key, and produces an output.

Cryptographic Boundary An explicitly defined continuous perimeter that establishes the physical bounds of a cryptographic module and contains all hardware, software, and/or firmware components of a cryptographic module.

Cryptographic Key A parameter used in conjunction with a cryptographic algorithm that determines the specific operation of that algorithm.

Cryptographic Module The set of hardware, software, and/or firmware that implements at least one approved security function (including cryptographic algorithms and key generation) and is contained within the cryptographic boundary.

Cryptographic Primitive A low-level cryptographic algorithm used as a basic building block for higher-level cryptographic algorithms.

Cryptographic System Associated INFOSEC items interacting to provide a single means of encryption or decryption.

Cryptoperiod The time span during which a specific key is authorized for use or remains in effect for a given system or application.

CSO-GUID-2009 Page 24 Decryption The process of transforming ciphertext into plaintext using a cryptographic algorithm and key.

Digital Signature The result of a cryptographic transformation of data that, when properly implemented, provides a mechanism for verifying origin authentication, data integrity and signatory non-repudiation.

Encryption The cryptographic transformation of data to produce ciphertext.

Entity A person, organization, device, or process.

Entropy A measure of the amount of uncertainty an attacker faces to determine the value of a secret. Entropy is usually stated in bits. A value having n bits of entropy has the same degree of uncertainty as a uniformly distributed n-bit random value.

Ephemeral Key A cryptographic key that is generated for each execution of a key establishment process and meets other requirements of the key type.

Handshake Protocol An automated process that sets parameters for communication between two devices before normal communication takes place between the devices.

Hash Function A mathematical function that maps a string of arbitrary length (up to a predetermined maximum size) to a fixed-length bit string.

Hash Value The fixed-length bit string produced by a hash function.

Hash-based Message Authentication Code A MAC that utilizes a keyed hash.

Key A parameter used in conjunction with a cryptographic algorithm that determines its operation.

Key Agreement A key-establishment procedure where resultant keying material is a function of information contributed by two or more participants, so that no party can predetermine the value of the keying material independently of the other partys contribution.

Key Management The activities involving the handling of cryptographic keys and other related security parameters (e.g. passwords) during the entire life cycle of the keys, including their generation, storage, establishment, entry and output, and destruction.

Key Management Infrastructure The framework and services that provide the generation, production, storage, protection, distribution, control, tracking, and destruction for all cryptographic keying material, symmetric keys, as well as public keys and public key certificates.

Key Pair A public key and its corresponding private key.

Keyed-Hash Message Authentication Code A MAC that utilizes a cryptographic key in conjunction with a hash function.

Keying Material The data necessary to establish and maintain cryptographic keying relationships.

CSO-GUID-2009 Page 25 Key-Wrapping A method of encrypting keys (along with associated integrity information) that provides both confidentiality and integrity protection using a symmetric key.

Message The data that is signed (also known as signed data) during the signature verification and validation process.

Message Authentication Code A cryptographic checksum that results from passing data through a message authentication algorithm. In this standard, the message authentication algorithm is called HMAC, while the result of applying HMAC is called the MAC.

Message Digest The result of applying a hash function to a message. Also known as hash value.

Non-Repudiation A service that is used to provide assurance of the integrity and origin of data in such a way that the integrity and origin can be verified and validated by a third party as having originated from a specific entity in possession of the private key (i.e., the signatory).

Preimage Resistance An expected property of a hash function, such that given a randomly chosen message_digest it is computationally infeasible to find a preimage of the message_digest.

Private Key A cryptographic key that is used with an asymmetric cryptographic algorithm. For digital signatures, the private key is uniquely associated with the owner and is not made public. The private key is used to compute a digital signature that may be verified using the corresponding public key.

Public Key A cryptographic key that is used with an asymmetric cryptographic algorithm and is associated with a private key. The public key is associated with an owner and may be made public. In the case of digital signatures, the public key is used to verify a digital signature that was signed using the corresponding private key.

Public Key Infrastructure A framework that is established to issue, maintain, and revoke public key certificates.

Secret Key A cryptographic key that is uniquely associated with one or more entities. The use of the term "secret" in this context does not imply a classification level; rather the term implies the need to protect the key from disclosure or substitution.

Self-Signed Certificate A public-key certificate whose digital signature may be verified by the public key contained within the certificate.

The signature on a self-signed certificate protects the integrity of the data but does not guarantee the authenticity of the information. The trust of self-signed certificates is based on the secure procedures used to distribute them.

Signatory The entity that generates a digital signature on data using a private key.

CSO-GUID-2009 Page 26 Signed Data The data or message upon which a digital signature has been computed.

Static Key A key that is intended for use for a long period of time and is for use in many instances of cryptographic key-establishment schemes.

Symmetric-Key A cryptographic algorithm that uses the same secret key for an operation; such as encryption and decryption.

CSO-GUID-2009 Page 27 APPENDIX C.

REFERENCES CNSSP 15 Use of Public Standards for Secure Sharing of Information FIPS PUB 140-3 Security Requirements for Cryptographic Modules FIPS PUB 180-4 Secure Hash Standard (SHS)

FIPS PUB 186-4 Digital Signature Standard (DSS)

FIPS PUB 197 Advanced Encryption Standard (AES)

FIPS PUB 198-1 The Keyed-Hash Message Authentication Code (HMAC)

FIPS PUB 202 SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions NISTIR 7298 Glossary of Key Information Security Terms NIST SP 800-38A Recommendation for Block Cipher Modes of Operation NIST SP 800-52 Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations NIST SP 800-56A Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography NIST SP 800-56B Recommendation for Pair-Wise Key-Establishment Schemes Using Integer Factorization Cryptography NIST SP 800-57 (Parts 1-3)

Recommendation for Key Management:

Part 1 - General Part 2 - Best Practices for Key Management Organizations Part 3 - Application-Specific Key Management Guidance NIST SP 800-63-3 Digital Identity Guidelines NIST SP 800-63A Digital Identity Guidelines: Enrollment and Identity Proofing NIST SP 800-63B Digital Identity Guidelines: Authentication and Lifecycle Management NIST SP 800-63C Digital Identity Guidelines: Federation and Assertions NIST SP 800-131A Transitioning the Use of Cryptographic Algorithms and Key Lengths NIST SP 800-133 Recommendation for Cryptographic Key Generation NIST SP 800-140 FIPS 140-3 Derived Test Requirements (DTR): CMVP Validation Authority Updates to ISO/IEC 24759 NIST SP 800-140C CMVP Approved Security Functions: CMVP Validation Authority Updates to ISO/IEC 24759 NIST SP 800-140E CMVP Approved Authentication Mechanisms: CMVP Validation Authority Requirements for ISO/IEC 19790 Annex E and ISO/IEC 24579 Section 6.17 NIST SP 800-152 A Profile for U.S. Federal Cryptographic Key Management Systems (CKMS)

NIST SP 800-175B Guideline for Using Cryptographic Standards in Federal Government:

Cryptographic Mechanisms

CSO-GUID-2009 Page 28 CSO-GUID-2009 Change History Date Version Description of Changes Method Used to Announce &

Distribute Training 08-Sep-21 1.0 Initial release Post to OCIO/CSO SharePoint website As needed

Retrieved from "https://kanterella.com/w/index.php?title=ML22101A253&oldid=5471411"