BaselineWatch
Desk
Your fleet and your work Fleetyour releases and the hardware they run onTriagewhat needs a decisionWatchlistthe products and platforms you runSaved searchesthe lists you come back to
This instance Sourceswhat is read, how often, under what termsDigestthe daily or weekly summary, and alerts
How it is drawn Appearancethe look and the colour schemeBrandingthe mark this instance wears
Owner sign-in

6.1 Protection and Assurance Requirements

NIST platform security: roots of trust, firmware and secure enclaves SP 800-57 Part 1 Rev. 4
All changes in this version
first version loaded 6 Training: If the new system requires that new or different tasks (e.g., key part of 6

Title

Protection and Assurance Requirements

Control

Keying material should be (operationally) available as long as the associated cryptographic service is required. Keys may be maintained within a cryptographic module while they are being actively used, or they may be stored externally (provided that proper protection is afforded) and recalled as needed. Some keys may need to be archived if required beyond the key’s originator-usage period (see Section 5.3.5 for a discussion of the originator-usage period). The following protections and assurances may be required for the keying material. Integrity protection shall be provided for all keying material. Integrity protection always involves checking the source and format of received keying material (see Section 5.4.1 ). When the key exists within a validated cryptographic module, appropriate integrity protection is provided when the cryptographic module conforms to [FIPS140] , at a security level that is consistent with the [ FIPS 199 ] impact level associated with the data to be protected by the key (see [ SP800-152 ]). When a key is available outside a cryptographic module, integrity protection shall be provided by appropriate cryptographic integrity mechanisms (e.g. cryptographic checksums, cryptographic hash functions, MACs, and digital signatures), non-cryptographic integrity mechanisms (e.g. CRCs, parity checks, etc.) (see Appendix A ), or physical protection mechanisms. Guidance for the selection of appropriate integrity mechanisms is given in Sections 6.2.1.2 and 6.2.2.2 . C onfidentiality protection for all symmetric and private keys shall be provided. Public keys generally do not require confidentiality protection. When the symmetric or private key exists within a validated cryptographic module, appropriate confidentiality protection is provided when the cryptographic module conforms to [FIPS140] , at a security level that is consistent with the [ FIPS199 ] impact level associated with the data to be protected by the key (see [ SP800-152 ]). When a symmetric or private key is available outside a cryptographic module, confidentiality protection shall be provided either by encryption (e.g., key wrapping) at an appropriate security strength (see [SP800-152]), by the use of separate key components (see Section 6.2.1.3 ) or by controlling access to the key via physical means (e.g. storing the keying material in a safe with limited access). The security and operational impact of specific confidentiality mechanisms varies. Guidance for the selection of appropriate confidentiality mechanisms is given in Sections 6.2.1.3 and 6.2.2.3 . Association protection shall be provided for a cryptographic security service by ensuring that the correct keying material is used with the correct data in the correct application or equipment. Guidance for the selection of appropriate association protection is given in Sections 6.2.1.4 and 6.2.2.4 . Assurance of domain-parameter and public-key validity provides confidence that the parameters and keys are arithmetically correct (see Sections 5.4.2 and 5.4.3 ). Guidance for the selection of appropriate assurance mechanisms is given in [SP800-56A] and [SP800- 89] , as well as in this document. Assurance of private key possession provides assurance that the owner of a public key actually possesses the corresponding private key (see Section 5.4.4 ). The period of protection for cryptographic keys, associated key information, and cryptographic parameters (e.g. initialization vectors) depends on the type of key, the associated cryptographic service, and the length of time for which the cryptographic service is required. The period of protection includes the cryptoperiod of the key (see Section 5.3 ). The period of protection is not necessarily the same for integrity as it is for confidentiality. Integrity protection may only be required until a key is no longer used (but not yet destroyed), but confidentiality protection may be required until the key is actually destroyed.