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.

Resolution

FCS_STG_EXT.3.1

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;• a hash (FCS_COP.1(2)) of the stored key that is encrypted by a key protected by FCS_STG_EXT.2;• a keyed hash (FCS_COP.1(4)) using a key protected by a key protected by FCS_STG_EXT.2;• a digital signature of the stored key using an asymmetric key protected according to FCS_STG_EXT.2;• an immediate application of the key for decrypting the protected data followed by a successful verification of the decrypted data with previously known information].

Justification

Decryption of known plaintext is a method used in the FDE cPP in FCS_VAL_EXT.