Published: 2023-03-10
Impacted Documents
References
FCS_CKM.1/SK
Issue Description
The references to NIST SP 800-133 are unclear. A new revision was release just before the publication of cPP (during the final editing process), and it is not clear what version should be used. Additionally the sections being referred to are incorrect.
Resolution
As the original version of SP 800-133 has been withdrawn, the current version (SP 800-133r2) will be explicitly referenced within the SFR along with updating the section numbers correctly.
The changes are included in Table 15 and Application Note 48.
CPP_DSC_v1.0
The cPP is updated as follows (yellow highlights for additions, strikethrough for deletions) per section that is being updated:
Table 15. Supported Methods for Symmetric Encryption Key Generation
| Identifier | Key Type | Cryptographic Key Generation Algorithm | Key Sizes | List of Standards |
|---|---|---|---|---|
RSK |
[selection: symmetric key, submask, authorization value] |
Direct Generation froma Random Bit Generator as specified in FCS_RBG_EXT.1 |
[selection: 128, 192, 256, 512] bits |
NIST SP 800-133r2 (Section 7.1 6.1) with ISO 18031:2011 as an approved RBG in addition to those in NIST SP 800-133r2 (Section 5 4). |
DSK [selection: identifier from [KeyDerivation]] |
[selection: Key Type from [KeyDerivation]] |
Derived from a Key Derivation Function as specified in FCS_CKM_EXT.5 [selection: Key Derivation Algorithm from [KeyDerivation]] |
[selection: key sizes from [KeyDerivation]] |
[selection: List of Standards from [KeyDerivation]] |
PBK |
[selection: submask, authentication token, authorization value] |
Derived from a Password Based Key Derivation Function as specified in FCS_COP.1/PBKDF |
[selection: key sizes as specified in FCS_COP.1/PBKDF] |
[selection: standards as specified in FCS_COP.1/PBKDF] |
- Application Note 48
-
The intent of this requirement is to ensure that attackers cannot recover SKs with less than a full exhaust of the key space. This requirement explains SK generation regardless of how the DSC uses it or when it generates it. The encryption of user data that is not keying material, authentication tokens, or authorization values is outside the scope of this cPP. This cPP assumes that the DSC lacks the required resources to perform bulk encryption/decryption services at a suitable rate for users. The host may use the SK for encrypting user data outside the boundaries of the DSC. On the other hand, the DSC may use the SK on behalf of the user to perform keyed hashes. In this case, all the requirements for generating, controlling access and use, and destroying the key while under the protection of the DSC apply.
The selection of key size 512 bits is for the case of XTS-AES using AES-256. In the case of XTS-AES for both AES-128 and AES-256, the developer is expected to ensure that the full key is generated using direct generation from the RBG as specified in NIST SP 800-133r2 section (Section 6.1).
The ST author selects at least one algorithm from the RSK row if the ST supports creating keys directly from the output of the RBG without further conditioning, at least one algorithm from the DSK row should be selected if the ST supports key derivation functions which are usually seeded from RBG and then further conditioned to the appropriate key size, and at least one algorithm from the PBK row should be selected if the ST supports keys derived from passwords.
If DSK is selected, the selection-based SFR FCS_CKM_EXT.5 must be claimed by the TOE.
If PBK is selected, the selection-based SFR FCS_COP.1/PBKDF must be claimed by the TOE.
This requirement must be claimed by the TOE if at least one of FCS_CKM.1 or FCS_CKM.1/KEK chooses a selection related to generation of symmetric keys.