SECURITY PARAMETERSCritical security parameter (CSP). Security level.

CONTENTS

1. Critical security parameter (CSP)
2. Security level 1
3. Security level 2
4. Security level 3
5. Security level 4
6. Cryptographic module specification
7. Roles
8. Services
9. Operator authentication

CRITICAL SECURITY PARAMETER (CSP)

A critical security parameter (CSP) is data using a cryptography module to process encryption functions. Data includes passwords, security codes, cryptographic keys, personal identification numbers (PIN) and any other unprotected security information.

Established information security rules protect CSPs, which are only accessible from authorized computer systems. CSPs obtained by unauthorized users pose security threats.

The Federal Information Processing Standards (FIPS) 140 series are computer security specifications and requirements for cryptography modules. In May 2001, the most recent version was issued as FIPS 140-2.

FIPS 140-2 is comprised of four security levels, as follows:

• Level 1 - Has limited cryptographic module security requirements but no physical security.


• Level 2 - Dictates physical security, e.g., tamper-resistant measures and plain text evidence for cryptographic keys and CSPs.


• Level 3 - Adds physical security to prevent CSP access within the cryptographic module, as well as CSP zeroization after opening the module.


• Level 4 - Provides the most robust cryptographic module security.

SECURITY LEVEL 1

(FIPS 140-2)

Security Level 1 provides the lowest level of security. Basic security requirements are specified for acryptographic module (e.g., at least one Approved algorithm or Approved security function shall be used).

No specific physical security mechanisms are required in a Security Level 1 cryptographic module beyond the basic requirement for production-grade components. An example of a Security Level 1 cryptographicmodule is a personal computer (PC) encryption board.

Security Level 1 allows the software and firmware components of a cryptographic module to be executed on a general purpose computing system using an unevaluated operating system. Such implementations may be appropriate for some low-level security applications when other controls, such as physical security, network security, and administrative procedures are limited or nonexistent. The implementation ofcryptographic software may be more cost-effective than corresponding hardware-based mechanisms, enabling organizations to select from alternative cryptographic solutions to meet lower-level security requirements.

SECURITY LEVEL 2

(FIPS 140-2)

Security Level 2 enhances the physical security mechanisms of a Security Level 1 cryptographic module by adding the requirement for tamper-evidence, which includes the use of tamper-evident coatings or seals or for pick-resistant locks on removable covers or doors of the module.

Tamper-evident coatings or seals are placed on a cryptographic module so that the coating or seal must be broken to attain physical access to the plaintext cryptographic keys and critical security parameters (CSPs) within the module. Tamper-evident seals or pick-resistant locks are placed on covers or doors to protect against unauthorized physical access.

Security Level 2 requires, at a minimum, role-based authentication in which a cryptographic module authenticates the authorization of an operator to assume a specific role and perform a corresponding set of services.

Security Level 2 allows the software and firmware components of a cryptographic module to be executed on a general purpose computing system using an operating system that

• meets the functional requirements specified in the Common Criteria (CC) Protection Profiles (PPs) listed in Annex B

and


• is evaluated at the CC evaluation assurance level EAL2 (or higher). An equivalent evaluated trusted operating system may be used. A trusted operating system provides a level of trust so that cryptographic modules executing on general purpose computing platforms are comparable to cryptographic modules implemented using dedicated hardware systems.

An equivalent evaluated trusted operating system may be used. The implementation of a trusted path protects plaintext CSPs and the software and firmware components of the cryptographic module from other untrusted software or firmware that may be executing on the system.

SECURITY LEVEL 3

(FIPS 140-2)

In addition to the tamper-evident physical security mechanisms required at Security Level 2, Security Level 3 attempts to prevent the intruder from gaining access to CSPs held within the cryptographic module.

Physical security mechanisms required at Security Level 3 are intended to have a high probability of detecting and responding to attempts at physical access, use or modification of the cryptographic module.

The physical security mechanisms may include the use of strong enclosures and tamper detection/response circuitry that zeroizes all plaintext CSPs when the removable covers/doors of the cryptographic module are opened.

Security Level 3 requires identity-based authentication mechanisms, enhancing the security provided by the role-based authentication mechanisms specified for Security Level 2. A cryptographic module authenticates the identity of an operator and verifies that the identified operator is authorized to assume a specific role and perform a corresponding set of services.

Security Level 3 requires the entry or output of plaintext CSPs (including the entry or output of plaintext CSPs using split knowledge procedures) be performed using ports that are physically separated from other ports, or interfaces that are logically separated using a trusted path from other interfaces. Plaintext CSPs may be entered into or output from the cryptographic module in encrypted form (in which case they may travel through enclosing or intervening systems).

Security Level 3 allows the software and firmware components of a cryptographic module to be executed on a general purpose computing system using an operating system that

• meets the functional requirements specified in the PPs listed in Annex B with the additional functional requirement of a Trusted Path (FTP_TRP.1)

and


• is evaluated at the CC evaluation assurance level EAL3 (or higher) with the additional assurance requirement of an Informal Target of Evaluation (TOE) Security Policy Model (ADV_SPM.1).

SECURITY LEVEL 4

(FIPS 140-2)

Security Level 4 provides the highest level of security defined in this standard. At this security level, the physical security mechanisms provide a complete envelope of protection around the cryptographic module with the intent of detecting and responding to all unauthorized attempts at physical access.

Penetration of the cryptographic module enclosure from any direction has a very high probability of being detected, resulting in the immediate zeroization of all plaintext CSPs. Security Level 4 cryptographic modules are useful for operation in physically unprotected environments.

Security Level 4 also protects a cryptographic module against a security compromise due to environmental conditions or fluctuations outside of the module's normal operating ranges for voltage and temperature.

Intentional excursions beyond the normal operating ranges may be used by an attacker to thwart a cryptographic module's defenses. A cryptographic module is required to either include special environmental protection features designed to detect fluctuations and zeroize CSPs, or to undergo rigorous environmental failure testing to provide a reasonable assurance that the module will not be affected by fluctuations outside of the normal operating range in a manner that can compromise the security of the module.

Security Level 4 allows the software and firmware components of a cryptographic module to be executed on a general purpose computing system using an operating system that

• meets the functional requirements specified for Security Level 3

and


• is evaluated at the CC evaluation assurance level EAL4 (or higher).

An equivalent evaluated trusted operating system may be used.

CRYPTOGRAPHIC MODULE SPECIFICATION

(FIPS 140-2)

A cryptographic module shall be a set of hardware, software, firmware, or some combination thereof that implements cryptographic functions or processes, including cryptographic algorithms and, optionally, key generation, and is contained within a defined cryptographic boundary.

A cryptographic module shall implement at least one Approved security function used in an Approved mode of operation.

Non-Approved security functions may also be included for use in non-Approved modes of operation.

The operator shall be able to determine when an Approved mode of operation is selected.

For Security Levels 1 and 2, the cryptographic module security policy may specify when a cryptographic module is performing in an Approved mode of operation.

For Security Levels 3 and 4, a cryptographic module shall indicate when an Approved mode of operation is selected.

ROLES

(FIPS 140-2)

A cryptographic module shall support authorized roles for operators and corresponding services within each role.

A 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 cryptographic initialization or management functions (e.g., module initialization, input/output of cryptographic keys and CSPs, and audit functions).

If the cryptographic module allows operators to perform maintenance services, then the module shall support the Maintenance Role.

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

All plaintext secret and private keys and unprotected CSPs shall be zeroized when entering or exiting the maintenance role.

Note: A cryptographic module may support other roles or sub-roles in addition to the roles specified above. Documentation shall specify all authorized roles supported by the cryptographic module.

SERVICES

(FIPS 140-2)

Services shall refer to all of the services, operations, or functions that can be performed by a cryptographic module.

Service inputs shall consist of all data or control inputs to the cryptographic 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.

Each service input shall result in a service output.

A cryptographic module shall provide the following services to operators:

• Show Status;
• Perform Self-Tests;
• Perform Approved Security Function.

A cryptographic module may provide other services, operations, or functions, both Approved and non-Approved, in addition to the services specified above.

Specific services may be provided in more than one role (e.g., key entry services may be provided in the user role and the crypto officer role).

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;


• 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.

OPERATOR AUTHENTICATION

(FIPS 140-2)

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 verification of personal characteristics (e.g., biometrics).

Authentication data within a cryptographic module shall be protected against unauthorized disclosure, modification, and substitution.

The initialization of authentication mechanisms may warrant special treatment. If a 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.

For Security Level 1, a cryptographic module is not required to employ authentication mechanisms to control access to the module. If authentication mechanisms are not supported by a cryptographic module, the module shall require that one or more roles either be implicitly or explicitly selected by the operator.

For Security Level 2, a cryptographic module shall employ role-based authentication to control access to the module.

For Security Levels 3 and 4, a cryptographic module shall employ identity-based authentication mechanisms to control access to the module.

  Contents