F2009VE 03

SECTION 3: ROLES, SERVICES, AND AUTHENTICATION

AS.03.01The cryptographic module shall support authorized roles for operators

and corresponding services within each role.

Note: This assertion is not separately tested.

Assessment:

AS.03.02If the cryptographic module supports concurrent operators, then the

module shall internally maintain the separation of the roles assumed by

each operator and the corresponding services.

Assessment:

VE.03.02.01

VE.03.02.01The vendor documentation shall specify whether multiple concurrent

operators are allowed. The vendor shall describe the method by which

separation of the authorized roles and services performed by each

operator is achieved. The vendor documentation shall also describe

any restrictions on concurrent operators (e.g., one operator in a

maintenance role and another in a user role simultaneously is not allowed).

Assessment:

AS.03.03The cryptographic module shall support the following authorized roles

for operators:

User Role. The role assumed to perform general security services,

including cryptographic operations and other Approved security

functions.

Crypto Officer Role: The role assumed to perform a set of

cryptographic initialization or management functions (e.g., module

Assessment:

VE.03.03.01

VE.03.03.01In the documentation required to satisfy VE03.06.01, the vendor shall

include at least one user role and one crypto-officer role.

Assessment:

AS.03.04If the cryptographic module allows operators to perform maintenance

services, then the module shall support the following authorized role:

* Maintenance Role: The role assumed to perform physical maintenance and/or logical maintenance services (e.g., hardware/software diagnostics).

Assessment:

VE.03.04.01

VE.03.04.01If the module has a maintenance interface, the vendor documentation

shall explicitly state a maintenance role is supported. The

documentation shall completely specify the role by name and allowed services.

Assessment:

AS.03.05All plaintext secret and private keys and unprotected CSPs shall be

zeroized when entering or exiting the maintenance role.

Assessment:

VE.03.05.01

VE.03.05.01The vendor documentation shall specify how the module's plaintext

secret and private keys and other unprotected critical security

parameters, as defined in Section 2.1 of FIPS PUB 140-2, are actively

zeroized when the maintenance role is entered or exited.

Assessment:

AS.03.06Documentation shall specify all authorized roles supported by the

cryptographic module.

Assessment:

VE.03.06.01

VE.03.06.01Vendor documentation shall specify each distinct authorized role,

including its name and the services that are performed in the role.

Assessment:

AS.03.07Services shall refer to all of the services, operations, or functions that

can be performed by the cryptographic module.

Note: This assertion is not separately tested.

Assessment:

AS.03.08Service inputs shall consist of all data or control inputs to the

cryptographic module that initiate or obtain specific services,

operations, or functions.

Assessment:

AS.03.09Service outputs shall consist of all data and status outputs that result

from services, operations, or functions initiated or obtained by service

inputs.

Assessment:

AS.03.10Each service input shall result in a service output.

Note: This assertion is not separately tested.

Assessment:

AS.03.11The cryptographic module shall provide the following services to

operators:

Show Status. Output the current status of the cryptographic module.

Perform Self-Tests. Initiate and run the self-tests as specified in

Section 4.9.

Perform Approved Security Function. Perform at least one Approved

Assessment:

VE.03.11.01

VE.03.11.01The vendor documentation shall describe the output of the current

status of the module and the initiation and running of user callable

self-tests, along with other services as specified by VE03.14.01 and VE03.15.01.

Assessment:

AS.03.12If a cryptographic module implements a bypass capability, where

services are provided without cryptographic processing (e.g.,

transferring plaintext through the module without encryption), then two

independent internal actions shall be required to activate the capability

to prevent the inadvertent bypass of plaintext data due to a single error

(e.g., two different software or hardware flags are set, one of which

Assessment:

VE.03.12.01

VE.03.12.01If the module implements a bypass capability, the vendor

documentation shall describe the bypass service as specified in

AS03.12.

Assessment:

VE.03.12.02

VE.03.12.02The finite state model and other vendor documentation shall indicate,

for all transitions into an exclusive or alternating bypass state, two

independent internal actions that are required to transition into each bypass state.

Assessment:

AS.03.13If the cryptographic module implements a bypass capability, where

services are provided without cryptographic processing (e.g.,

transferring plaintext through the module without encryption), then the

module shall show status to indicate whether

1) the bypass capability is not activated, and the module is exclusively

providing services with cryptographic processing (e.g., the plaintext is

encrypted),

2) the bypass capability is activated and the module is exclusively providing services without cryptographic processing (e.g., plaintext data is not encrypted), or

3) the bypass capability is alternately activated and deactivated and the

module is providing some services with cryptographic processing and

some services without cryptographic processing (e.g., for modules with

multiple communication channels, plaintext data is or is not encrypted

depending on each channel configuration).

Assessment:

VE.03.13.01

VE.03.13.01The vendor documentation for the "Show Status" service shall indicate

bypass status.

Assessment:

AS.03.14Documentation shall specify:

* the services, operations, or functions provided by the cryptographic

module, both Approved and non-Approved, and

* for each service provided by the module, the service inputs,

corresponding service outputs, and the authorized role(s) in which the

service can be performed.

Assessment:

VE.03.14.01

VE.03.14.01The vendor documentation shall describe each service including

purpose and function.

Assessment:

VE.03.14.02

VE.03.14.02The vendor documentation shall specify for each service, the service

inputs, corresponding service outputs, and the authorized role or roles

in which the service can be performed. Service inputs shall consist of

all data or control inputs to the module that initiate or obtain specific

services, operations, or functions. Service outputs shall consist of all

data and status outputs that result from services, operations or functions

initiated or obtained by service inputs.

Assessment:

AS.03.15Documentation shall specify any services provided by the cryptographic

module for which the operator is not required to assume an authorized

role, and how these services do not modify, disclose, or substitute

cryptographic keys and CSPs, or otherwise affect the security of the

Assessment:

VE.03.15.01

VE.03.15.01The vendor documentation shall describe each service, including its

purpose and function.

Assessment:

VE.03.15.02

VE.03.15.02The vendor documentation shall specify, for each service, the service

inputs and corresponding service outputs. Service inputs shall consist

of all data or control inputs to the module that initiate or obtain specific

services, operations, or functions. Service outputs shall consist of all

data and status outputs that result from the services, operations, or

functions initiated or obtained by service inputs.

Assessment:

AS.03.16 (Level 2) Depending on the security level, the cryptographic module shall perform at least one of the following mechanisms to control access to the module: role-based authentication or identity-based authentication.

Note: This assertion is not separately tested.

AS.03.17 (Level 2) If role-based authentication mechanisms are supported by the cryptographic module, the module shall require that one or more roles either be implicitly or explicitly selected by the operator and shall authenticate the assumption of the selected role (or set of roles).

VE.03.17.01

VE.03.17.01 (Level 2) The vendor shall document the type of authentication performed for the module. The vendor shall document the mechanisms used to perform the implicit or explicit selection of a role or set of roles and the authentication of the operator to assume the role(s).

Assessment:

AS.03.18 (Level 2) If the cryptographic module permits an operator to change roles, then the module shall authenticate the assumption of any role that was not previously authenticated.

VE.03.18.01

VE.03.18.01 (Level 2) The vendor documentation shall describe the ability of an operator to change roles and shall state that verification of an operator to assume a new role is required.

Assessment:

AS.03.21When the cryptographic module is powered off and subsequently

powered on, the results of previous authentications shall not be retained

and the module shall require the operator to be re-authenticated.

Assessment:

VE.03.21.01

VE.03.21.01The vendor documentation shall describe how the results of previous

authentications are cleared when the module is powered off.

Assessment:

AS.03.22 (Level 2) Authentication data within the cryptographic module shall be protected against unauthorized disclosure, modification, and substitution.

Assessment:

VE.03.22.01

VE.03.22.01 The vendor documentation shall describe the protection of all authentication data to the module. Protection shall include the implementation of mechanisms that protect against unauthorized disclosure, modification, and substitution.

Assessment:

AS.03.23If the cryptographic module does not contain the authentication data

required to authenticate the operator for the first time the module is

accessed, then other authorized methods (e.g., procedural controls or

use of factory-set or default authentication data) shall be used to control

access to the module and initialize the authentication mechanisms.

Assessment:

VE.03.23.01

VE.03.23.01The vendor documentation shall specify means to control access to the

module before it is initialized.

Assessment:

AS.03.25 (Level 2) For each attempt to use the authentication mechanism, the probability shall be less than one in 1,000,000 that a random attempt will succeed or a false acceptance will occur (e.g., guessing a password or PIN, false acceptance error rate of a biometric device, or some combination of authentication methods).

VE.03.25.01

VE.03.25.01 (Level 2) The vendor documentation shall specify each authentication method and the associated false acceptance rate or probability that a random access will succeed.

Assessment:

AS.03.26 (Level 2) For multiple attempts to use the authentication mechanism during a one-minute period, the probability shall be less than one in 100,000 that a random attempt will succeed or a false acceptance will occur.

VE.03.26.01

VE.03.26.01 (Level 2) The vendor documentation shall specify each authentication method and the associated probability of a successful random attempt during a one-minute period.

Assessment:

AS.03.27 (Level 2) Feedback of authentication data to an operator shall be obscured during authentication (e.g., no visible display of characters when entering a password).

VE.03.27.01

VE.03.27.01 (Level 2) The vendor documentation shall specify the method used to obscure feedback of the authentication data to an operator during entry of the authentication data.

Assessment:

AS.03.28 (Level 2) Feedback provided to an operator during an attempted authentication shall not weaken the strength of the authentication mechanism.

VE.03.28.01

VE.03.28.01 (Level 2) The vendor documentation shall specify the feedback mechanism that is used when the operator is entering authentication data.

Assessment:

AS.03.29Documentation shall specify:

* the authentication mechanisms supported by the cryptographic

module,

* the types of authentication data required by the module to

implement the supported authentication mechanisms,

* the authorized methods used to control access to the module for the

first time and initialize the authentication mechanisms, and

* the strength of the authentication mechanisms supported by the

module.

Assessment:

AS.03.30If authentication mechanisms are not supported by the cryptographic

module, the module shall require that one or more roles either be

implicitly or explicitly selected by the operator.

Assessment:

VE.03.30.01

VE.03.30.01The vendor shall document the type of authentication performed for the

module. The vendor shall document the mechanisms used to perform

the implicit or explicit selection of a role or set of roles and the

authentication of the operator to assume the role(s).

Assessment:

VE.03.30.02

VE.03.30.02The vendor provided nonproprietary security policy shall provide a

description of the roles, either implicit or explicit, that the operator can

assume.

Assessment:

VE.03.30.03

VE.03.30.03The vendor provided non-proprietary security policy shall provide

instructions for the operator to assume either the implicit or explicit

roles.