NIAP: View Technical Decision Details
  NIAP  »»  Protection Profiles  »»  Technical Decisions  »»  View Details  
TD0288:  Support for Single-User File Encryption

Publication Date

Protection Profiles

Other References

Issue Description

FIA_FCT_EXT.1(2) requires the TOE to support multiple users and it has been determined that it is acceptable if it only supported one user.


A “single-user” FIA_FCT_EXT.1(3) is added to the EP.

Appendix C.3 is modified as follows:

C.3 User Authorization

Because the actions of the TSF are fairly different depending on whether password/passphrase or external entity authorization factors are used (see Section 1.1.2, Authorization), different user authorization components are needed for each type of authorization factor supported by the TOE. The ST author will include FIA_FCT_EXT.1(1) in the ST if the TOE supports external entity authorization factors and will include FIA_FCT_EXT.1(2) or FIA_FCT_EXT.1(3) in the ST if the TOE supports password/passphrase authorization factors.

C.3.1 – no changes.

C.3.2 – no changes.

C.3.3 is added as follows:

C.3.3 Extended: Single User Authorization with Password/Passphrase Authorization Factors

FIA_FCT_EXT.1(3)            Extended: Single User Authorization with Password/Passphrase Authorization Factors

FIA_FCT_EXT.1.1(3)        The TSF shall provide a mechanism as defined in FCS_CKM_EXT.1 and FCS_COP.1(4) to perform user authorization.

FIA_FCT_EXT.1.2(3)        The TSF shall perform user authorization using the mechanism provided in FIA_FCT_EXT.1.1(3) before allowing decryption of user data.

FIA_FCT_EXT.1.3(3)        The TSF shall verify that the user-entered authorization factors are valid before decrypting the user’s encrypted files.

FIA_FCT_EXT.1.4(3)        The TSF shall ensure that the method of validation for each authorization factor does not expose or reduce the effective strength of the KEK, FEK, or CSPs used to derive the KEK or FEK.

FIA_FCT_EXT.1.5(3)        The TSF shall perform user authorization using the mechanism provided in FIA_FCT_EXT.1.1(3) before allowing the user to change the passphrase-based authorization factor as specified in FMT_SMF.1(c).

Application Note:

If the TSF supports multiple authorization factors to produce multiple KEKs, this requirement does not apply and FIA_FCT_EXT.1(2) must be claimed.

The intent of this requirement is to specify the password and/or passphrase mechanisms by which a single user is authorized to decrypt the encrypted file (or set of files) and thus gain access to their data. It is fairly important to note that this is not considered authentication of an individual user. There is no requirement that the TSF even understand the concept of a “user” in the context of a file owner; it should merely be able to tell (FIA_FCT_EXT.1.3(3)) if the authorization factor presented is valid for the file being requested, and if so, perform the appropriate cryptographic operations on that file. User authorization only needs to be performed when a request to the TOE for decrypt/encrypt services is made, not on each individual read and write for that file.

Since the TSF is responsible for manipulating the password/passphrase authorization factor itself, in this case FIA_FCT_EXT.1.1(3) and FIA_FCT_EXT.1.2(3) mean that the TSF itself provides the mechanism to prompt the user for the authorization factors, verify that the authorization factors are valid, transform the authorization factor into a KEK, and then use the KEK to decrypt the FEK so that the data can be accessed.

Elements 1.3(3) and 1.4(3) deal with the validation of the authorization factors provided by the user prior to a user being able to access the information in the file (or set of files). If a password/passphrase authorization factor is not valid, it is undesirable to unmask the FEK and use it to decrypt the file (or set of files) and present gibberish to the user. However, checking that the authorization factor is valid should not be done in a way that allows an attacker to circumvent the other requirements; since this operation may be done on the host, it may be monitored/disassembled by an attacker and so must be designed with this threat in mind. In the case that the TOE supports external authorization factors, this provision means that the external entity must have a way of signaling to the TSF that the authorization factor was not valid (which means that the information provided to decrypt the secret key was invalid), rather than just pass back an incorrectly-derived KEK (as ECC CDH does) or decrypted FEK (as RSA decryption does) for the TSF to use.

FIA_FCT_EXT.1.5(3) covers the case that the user wishes to change their password- or passphrase-based authorization factor such that the user authorization functionality will have to be invoked prior to the change being completed.

Assurance Activities:


The evaluator shall check the TSS section to confirm that it describes how a request for each type of supported resource (file (or set of files)) to be encrypted/decrypted is captured by the TOE; how the user is prompted for an authorization factor, and how the KEK is formed.

The evaluator shall check that the TSS describes how the authorization factors are validated prior to allowing the user to access the data on a drive or change their passphrase. This description shall be in enough detail so that the evaluator can determine that the method or methods used do not expose the FEK, KEK, or other key material. 'Expose' also includes the notion of weakening the FEK or KEK. It is not required to have a separate method for checking each authorization factor if separate authorization factors are used to provide submasks to create the KEK. The evaluator shall document their analysis of the mechanism(s) used to authenticate the authorization factors in the test report (ATE_IND).

The evaluator shall ensure the TSS describes how updates to the current authorization factor are handled, to include verifying that a change to the authorization factor cannot occur prior to providing the original authorization factor and that once the update has transpired the original authorization factor would no longer be effective.

For the cryptographic functions implemented in the Operational Environment that are used by the TOE in implementing this component, the evaluator shall check the TSS to ensure it describes--for each platform identified in the ST—the interface(s) used by the TOE to invoke this functionality.


The evaluator shall check that the Operational Guidance contains information so that users understand how authorization factors are entered, and the resources that are protectable by the TOE in each platform listed in the ST. They shall also check to ensure it describes the method by which a user changes their password/passphrase authorization factor.


The evaluator shall perform the following tests (these tests may be conducted in concert with those specified for FDP_PRT_EXT.1 above):

Test 1: For each authorization factor and resource type supported by the TOE (file (or set of files)), ensure that the authorization factors are prompted for prior to allowing any access to the protected resource. This activity must be performed using all cryptographic FEK protection algorithms identified in the TSS for each external entity. This activity must also be performed for first-time encryption of a resource, as well as encryption and decryption of an existing resource.

Test 2: For each authorization factor and resource type supported by the TOE (file (or set of files)), ensure that incorrect entry of an authorization factor results in a notification from the TOE that an incorrect authorization has been provided.


The application note for FIA_AUT_EXT.1 is replaced as follows:

Application Note:

Requirements that pertain to the selection are contained in Appendix C. The ST author will include FIA_FCT_EXT.1(1) in the ST if the TOE supports RSA/ECC CDH authorization factors, and will include FIA_FCT_EXT.1(2) or FIA_FCT_EXT.1(3) in the ST if the TOE supports password/passphrase authorization factors. It is possible that the platform is providing the actual authorization functionality.


The first selection for FCS_CKM_EXT.1.1 is modified as follows:

derive a KEK using a password-based authorization factor conditioned as defined in FCS_CKM.1(A) and in accordance with FIA_FCT_EXT.1(2) or FIA_FCT_EXT.1(3);

The fist bullet in the Application Note for FMT_SMF.1 is replaced as follows:

·         If password or passphrase authorization factors are implemented by the TOE, then the appropriate “change” selection must be included, along with FIA_FCT_EXT.1(2) or FIA_FCT_EXT.1(3) from Appendix C.


See issue description.

Site Map              Contact Us              Home