Archived TD0146: FCS_STG_EXT.3.1 - Integrity
FCS_STG_EXT.3.1 requires that the KEK or DEK needs to be stored with integrity protected. This requirement is unchallenged. Yet, in addition to the possibilities listed there, there is another option which maintains the integrity equally and should therefore be allowed.
For example, a KEK wraps data which is stored encrypted together with some meta data like an identifier. That KEK is now stored encrypted. The KEK is decrypted when the cleartext KEK is needed to access the protected data. Thus, the KEK is decrypted and immediately used to decrypt the protected data. Before using the data, the decrypted data is checked that the meta data matches with a previously known value (e.g. that identifier). In this case, the decryption of the data was successful in the sense that the "correct" data was decrypted. This in turn means that the decrypted KEK was also properly decrypted with its integrity preserved.
The TSF shall protect the integrity of any encrypted DEKs and KEKs and [selection: long-term trusted channel key material, all software-based key storage, no other keys] by [selection:
• [selection: GCM, CCM, Key Wrap, Key Wrap with Padding] cipher mode for encryption according to FCS_STG_EXT.2;
Decryption of known plaintext is a method used in the FDE cPP in FCS_VAL_EXT.