FIPS Standard

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 of
cryptographic 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.
1.2 Security Level 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.
1.3 Security Level 3
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).
2