NIAP: View Technical Decision Details
NIAP/CCEVS
  NIAP  »»  Protection Profiles  »»  Technical Decisions  »»  View Details  
Archived TD0119:  FCS_STO_EXT.1.1 in PP_APP_v1.2

Publication Date
2016.10.26

Protection Profiles
PP_APP_v1.2

Other References
FCS_STO_EXT.1.1

Issue Description

FCS_STO_EXT.1.1 seems to require AES encryption [FCS_COP.1(1)] if 'implement functionality' is selected, however, the application note also appears to allow for other cryptographic operations to securely store credentials. It is not clear if the application note allows for the selection of FCS_COP.1(2) in lieu of FCS_COP.1(1).

Resolution

The PP is revised as such:

FCS_STO_EXT.1.1

The application shall [selection:

     not store any credentials,
     invoke the functionality provided by the platform to securely store [assignment: list of credentials] ,
     implement functionality to securely store [assignment: list of credentials]
] to non-volatile memory.

Application Note: This requirement ensures that persistent credentials (secret keys, PKI private keys, or passwords) are stored securely.
The assurance activity implicitly restricts which selections can be made, on per-platform basis. For example, if a platform provides hardware-backed protection for credential storage, then the third selection cannot be indicated.
If implement functionality to securely store credentials is selected, then the following components must be included in theST: FCS_COP.1(1)or [FCS_CKM.1.1(A) and FCS_CKM.1.2(A)]. If other cryptographic operations are used to implement the secure storage of credentials, the corresponding requirements must be included in the ST.

Assurance Activity

The evaluator shall check the TSS to ensure that it lists all persistent credentials (secret keys, PKI private keys, or passwords) needed to meet the requirements in the ST. For each of these items, the evaluator shall confirm that the TSS lists for what purpose it is used, and how it is stored.

For all credentials for which the application implements functionality, the evaluator shall verify credentials are encrypted according to FCS_COP.1(1) or conditioned according to FCS_CKM_1.1(A) and FCS_CKM.1.2(A).

For all credentials for which the application invokes platform-provided functionality, the evaluator shall perform the following actions which vary per platform.

For BlackBerry: The evaluator shall verify that the application uses the BlackBerry KeyStore and Security Builder APIs to store credentials.

For Android: The evaluator shall verify that the application uses the Android KeyStore or the Android KeyChain to store certificates.

For Windows: The evaluator shall verify that all certificates are stored in the Windows Certificate Store. The evaluator shall verify that other credentials, like passwords, are stored in the Windows Credential Manager or stored using the Data Protection API (DPAPI). For Windows Universal Applications, the evaluator shall verify that the application is using the ProtectData class and storing credentials in IsolatedStorage.

For iOS: The evaluator shall verify that all credentials are stored within a Keychain.

For Linux: The evaluator shall verify that all keys are stored using Linux keyrings.

For Solaris: The evaluator shall verify that all keys are stored using Solaris Key Management Framework (KMF).

For Mac OS X: The evaluator shall verify that all credentials are stored within Keychain.


FCS_CKM.1.1(A)

Refinement: A password/passphrase shall perform [Password-based Key Derivation Functions] in accordance with a specified cryptographic algorithm as specified in FCS_COP.1(4) , with [assignment: positive integer of 1,000 or more] iterations, and output cryptographic key sizes [selection: 128, 256] that meet the following: [NIST SP 800-132].

FCS_CKM.1.2(A)

The TSF shall generate all salts using a RBG that meets FCS_RBG_EXT.1 (from the AS PP) and with entropy corresponding to the security strength selected for PBKDF in FCS_CKM.1.1(A).

Application Note:

Conditioning can be performed using one of the identified hash functions or the process described in NIST SP 800-132; the method used is selected by the ST Author. SP 800-132 requires the use of a pseudo-random function (PRF) consisting of HMAC with an approved hash function. The ST author selects the hash function used, also includes the appropriate requirements for HMAC and the hash function.

Appendix A of SP 800-132 recommends setting the iteration count in order to increase the computation needed to derive a key from a password and, therefore, increase the workload of performing a password recovery attack. A significantly higher value is recommended to ensure optimal security. This value is expected to increase to a minimum of 10,000 in a future iteration based on SP800-63.

Assurance Activity
TSS
Support for PBKDF: The evaluator shall examine the password hierarchy TSS to ensure that the formation of all password based derived keys is described and that the key sizes match that described by the ST author.

The evaluator shall check that the TSS describes the method by which the password/passphrase is first encoded and then fed to the SHA algorithm. The settings for the algorithm (padding, blocking, etc.) shall be described, and the evaluator shall verify that these are supported by the selections in this component as well as the selections concerning the hash function itself. The evaluator shall verify that the TSS contains a description of how the output of the hash function is used to form the submask that will be input into the function.

For the NIST SP 800-132-based conditioning of the password/passphrase, the required assurance activities will be performed when doing the assurance activities for the appropriate requirements (FCS_COP.1.1(4)).

No explicit testing of the formation of the submask from the input password is required.

FCS_CKM_1.2(A): The ST author shall provide a description in the TSS regarding the salt generation. The evaluator shall confirm that the salt is generated using an RBG described in FCS_RBG_EXT.1.


Guidance
There is no associated guidance with this activity.


Tests
Conditioning: No explicit testing of the formation of the authorization factor from the input password/passphrase is required.

Iteration count: The evaluator shall verify that the iteration count for PBKDFs performed by the TOE comply with NIST SP 800-132 by ensuring that the TSS contains a description of the estimated time required to derive key material from passwords and how the TOE increases the computation time for password-based key derivation (including but not limited to increasing the iteration count).

Justification

See issue description

 
 
Site Map              Contact Us              Home