FIPS Standard

1) the bypass capability is not activated, and the module is exclusively providing services with
cryptographic processing (e.g., plaintext data 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).
Documentation shall specify:
the services, operations, or functions provided by the cryptographic module, both Approved and
non-Approved,
•
•
•
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, and
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 module.
4.3.3 Operator Authentication
Authentication mechanisms may be required within a cryptographic module to authenticate an operator
accessing the module and to verify that the operator is authorized to assume the requested role and perform
services within that role. Depending on the security level, a cryptographic module shall support at least one
of the following mechanisms to control access to the module:
Role-Based Authentication: If role-based authentication mechanisms are supported by a 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). The cryptographic
module is not required to authenticate the individual identity of the operator. The selection of roles and
the authentication of the assumption of selected roles may be combined. If a cryptographic module
permits an operator to change roles, then the module shall authenticate the assumption of any role that
was not previously authenticated.
Identity-Based Authentication: If identity-based authentication mechanisms are supported by a
cryptographic module, the module shall require that the operator be individually identified, shall require
that one or more roles either be implicitly or explicitly selected by the operator, and shall authenticate
the identity of the operator and the authorization of the operator to assume the selected role (or set of
roles). The authentication of the identity of the operator, selection of roles, and the authorization of the
assumption of the selected roles may be combined. If a cryptographic module permits an operator to
change roles, then the module shall verify the authorization of the identified operator to assume any role
that was not previously authorized.
A cryptographic module may permit an authenticated operator to perform all of the services allowed within
an authorized role, or may require separate authentication for each service or for different sets of services.
When a 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.
Various types of authentication data may be required by a cryptographic module to implement the
supported authentication mechanisms, including (but not limited to) the knowledge or possession of a
password, PIN, cryptographic key, or equivalent; possession of a physical key, token, or equivalent; or
17