This post is mainly for the military otakus who like Tom Clancy games (or perhaps even his writings). Just a summary of "cool spy type stuff" I've discovered at my job (NIST provided us with a test suit of 450 COBOL programs that we have to be able to parse to be considered a compliant compiler). I've essentially taken all the juicy bits out of the document and posted them here for your perusal.

Source: Federal Information Processing Standards Publication 140-2, AKA FIPS PUB 140-2 AKA Security Requirements for Cryptographic Modules, by the National Institute of Standards and Technology (NIST).

FIPS PUB 140-2 defines 4 security levels, with 1 being the least secure, and 4 being the most secure. To attain level 1, you must use an approve cryptographic algorithm. No physical security (e.g. locks) are required. The cryptographic algorithm can run on a general purpose computing system using an unevaluated operating system. The operating system shall be restricted to a single operator mode of operation (i.e., conccurrent operators are explicitly excluded). The cryptographic module shall prevent access by other processes to plaintext private and secret keys, CSP, and intermediate key generation values during the time the cryptographic module is executing or operational. Non-cryptographic processes shall not interrupt a cryptographic module during execution. All cryptographic software and firmware shall bei nstalled in a form that protects the software nad firmware source and executable code from unauthorized disclosure and modification. A cryptographic mechanism using an approved integrity technique (e.g. digital signatures) shall be applied to all cryptographic software and firmware components within the cryptographic module.

For level 2 security, there needs to be a tamper evidence mechanism. Tamper-evident coatings or seals should be applied to the case of the cryptographic module so that if the case is opened, this becomes evident by the seal. It should not be possible to obtains keys, or other Critical Security Parameters (CSPs) without breaking the seal. Pick resistent locks should also be placed on the door or covers to protect against unauthorized access. Security level 2 security requires at a minimum role based authentication. That means if you have the administrator password, then you have all the priviliges that the administrator has. The cryptographic algorithms can run on a general purpose computer provided that the operating system is evaluated at level EAL 2 or higher.

As a digression, here's a quote from IBM's site:

• EAL-1 examines the product and its documentation for conformity, establishing that the product does what its documentation claims.
• EAL-2 tests the structure of the product through an evaluation, which includes the product's design history and testing.
• EAL-3 evaluates a product in design stage, with independent verification of the developer's testing results, and evaluates the developer's checks for vulnerabilities, the development environmental controls, and the product's configuration management.
• EAL-4 is an even greater in-depth analysis of the development and implementation of the product and may require more significant security engineering costs.
• EALs 5-7 require even more formality in the design process and implementation, analysis of the product's ability to handle attacks and prevent covert channels, specifically for high-risk environments. In the United States, evaluation to EALs 5-7 must be done by the National Security Agency (NSA) for the U.S. Government.

To protect plaintext data, cryptographic software and firmware, cryptographic keys and CSPs, and authentication data, the discretionary access control mechanisms of the operating system shall be configured to: Specify the set of roles that can execute stored cryptographic software and firmware; Specify the set of roles that can modify (i.e., write, replace, and delete) the following cryptographic module software or firmware components stored within the cryptographic boundary: cryptographic programs, cryptographic data (e.g., cryptographic keys and audit data), CSPs, and plaintext data; Specify the set of roles that can read the following cryptographic software components stored within the cryptographic boundary: cryptographic data (e.g., cryptographic keys and audit data), CSPs, and plaintext data; Specify the set of roles that can enter cryptographic keys and CSPs. The operating system shall prevent all operators and executing processes from modifying executing cryptographic processes (i.e., loaded and executing cryptographic program images). In this case, executing processes refer to all non-operating system processes (i.e., operator-initiated), cryptographic or not. The operating system shall prevent operators and executing processes from reading cryptographic software stored within the cryptographic boundary. The operating system shall provide an audit mechanism to record modifications, accesses, deletions, and additions of cryptographic data and CSPs. The following events shall be recorded by the audit mechanism: Attempts to provide invalid input for crypto officer functions, and the addition or deletion of an operator to/from a crypto officer role. The audit mechanism shall be capable of auditing the following events: operations to process audit data stored in the audit trail, requests to use authentication data management mechanisms, use of a security-relevant crypto officer function, requests to access user authentication data associated with the cryptographic module, use of an authentication mechanism (e.g., login) associated with the cryptographic module, explicit requests to assume a crypto officer role, and the allocation of a function to a crypto officer role.

For security level 3, the cryptographic should be reside in a strong enclosure and tamper detection/responce circuitry should zero out all CSPs upon detecting the removable cover/doors are opened. The air vents through which cooling is usually employed needs to be secured as well (e.g. require at least one 90 degree bend or obstruction with a substantial blocking material). Instead of role-based security, level 3 requires identification-based security. That is to say, you must specify which particular person you are, not just what your job or role is, and then a check is made in a database whether the person you claim to be is allowed access to whatever module you're trying to access. The operating system of a level 3 system must be evaluated at level EAL-3 or higher. When a key is entered into the system, it must be entered using split knowledge procedures. I.e., two or more personnel are given a fragment of the key, and each person inputs the fragment that they are aware of. The crypogrpahic module must separately authenticate each operating entering each key component. The split knowledge procedure's documentation must contain a proof showing that if knowledge of n key components is required to reconstruct the original key, the knowledge of any of n-1 key components provide no information about the original key other than length.

For security level 4, no physical access to the cryptographic module is allowed, authorized or not. Upon detecting any physical tampering, the CSPs are immediately zeroed out. A level 4 system should also monitor environmental conditions or fluctuations outside normal operating ranges. An attacker may use intentional excursions outside normal operating ranges to thwart a cryptographic module's defense (e.g. temperature, voltage, etc.) Upon detecting any such changes, the module should zero out all CSPs, or undergo rigorous environmental failure testing to provide reasonable assurance that the module will not be affected by fluctuations outside the normal operating range in a manner that can compromise the security of the module. Level 4 systems can operate on a general computer device running an operating system evaluate at level EAL-4 or higher.

At all security levels, the cryptographic module should perform a self test upon initial power up, and every time a security function is invoked. If the self-test fails, the module shall enter an error state and output an error indicator via the status output interface. The cryptographic module shall not perform any cryptographic operations while in an error state. All data output via the data output interface shall be inhibited when an error state exists. All data output via the data output interface shall be inhibited when the power-up tests are performed. In addition to performing the power-up tests when powered up, a cryptographic module shall permit operators to initiate the tests on demand for periodic testing of the module. Resetting, rebooting, and power cycling are acceptable means for the on-demand initiation of power-up tests.

A cryptographic module shall perform the following power-up tests: cryptographic algorithm test, software/firmware integrity test, and critical functions test.

Cryptographic algorithm test. A cryptographic algorithm test using a known answer shall be conducted for all cryptographic functions (e.g., encryption, decryption, authentication, and random number generation) of each Approved cryptographic algorithm implemented by a cryptographic module. A known-answer test involves operating the cryptographic algorithm on data for which the correct output is already known and comparing the calculated output with the previously generated output (the known answer). If the calculated output does not equal the known answer, the known-answer test shall fail.

Cryptographic algorithms whose outputs vary for a given set of inputs (e.g., the Digital Signature Algorithm) shall be tested using a known-answer test or shall be tested using a pair-wise consistency test (specified below). Message digest algorithms shall have an independent known-answer test or the known-answer test shall be included with the associated cryptographic algorithm test (e.g., the Digital Signature Standard).

If a cryptographic module includes two independent implementations of the same cryptographic algorithm, then: the known-answer test may be omitted, the outputs of two implementations shall be continuously compared, and if the outputs of two implementations are not equal, the cryptographic algorithm test shall fail.

Software/firmware integrity test. A software/firmware integrity test using an error detection code (EDC) or Approved authentication technique (e.g., an Approved message authentication code or digital signature algorithm) shall be applied to all validated software and firmware components within a cryptographic module when the module is powered up. If the calculated result does not equal the previously generated result, the software/firmware test shall fail. If an EDC is used, the EDC shall be at least 16 bits in length.

Critical functions test. Other security functions critical to the secure operation of a cryptographic module shall be tested when the module is powered up as part of the power-up tests. Other critical security functions performed under specific conditions shall be tested as conditional tests.

Conditional tests shall be performed by a cryptographic module when the conditions specified for the following tests occur: pair-wise consistency test, software/firmware load test, manual key entry test, continuous random number generator test, and bypass test.

Pair-wise consistency test (for public and private keys). If a cryptographic module generates public or private keys, then the following pair-wise consistency tests for public and private keys shall be performed:

1. If the keys are used to perform an approved key transport method, then the public key shall encrypt a plaintext value. The resulting ciphertext value shall be compared to the original plaintext value. If the two values are equal, then the test shall fail. If the two values differ, then the private key shall be used to decrypt the ciphertext and the resulting value shall be compared to the original plaintext value. If the two values are not equal, the test shall fail.
2. If the keys are used to perform the calculation and verification of digital signatures, then the consistency of the keys shall be tested by the calculation and verification of a digital signature. If the digital signature cannot be verified, the test shall fail.

Continuous random number generator test. If a cryptographic module employs Approved or non-Approved RNGs in an Approved mode of operation, the module shall perform the following continuous random number generator test on each RNG that tests for failure to a constant value.

1. If each call to a RNG produces blocks of n bits (where n > 15), the first n-bit block generated after power-up, initialization, or reset shall not be used, but shall be saved for comparison with the next n-bit block to be generated. Each subsequent generation of an n-bit block shall be compared with the previously generated block. The test shall fail if any two compared n-bit blocks are equal.
2. If each call to a RNG produces fewer than 16 bits, the first n bits generated after power-up, initialization, or reset (for some n > 15) shall not be used, but shall be saved for comparison with the next n generated bits. Each subsequent generation of n bits shall be compared with the previously generated n bits. The test fails if any two compared n-bit sequences are equal.

Cryptographic modules may be susceptible to other attacks for which testable security requirements were not available at the time this version of the standard was issued (e.g., power analysis, timing analysis, and/or fault induction) or the attacks were outside of the scope of the standard (e.g., TEMPEST). Susceptibility of a cryptographic module to such attacks depends on module type, implementation, and implementation environment. Such attacks may be of particular concern for cryptographic modules implemented in hostile environments (e.g., where the attackers may be the authorized operators of the module). Such types of attacks generally rely on the analysis of information obtained from sources physically external to the module. In all cases, the attacks attempt to determine some knowledge about the cryptographic keys and CSPs within the cryptographic module. Brief summaries of currently known attacks are provided below.

Power Analysis: Attacks based on the analysis of power consumption can be divided into two general categories, Simple Power Analysis (SPA) and Differential Power Analysis (DPA). SPA involves a direct (primarily visual) analysis of electrical power consumption patterns and timings derived from the execution of individual instructions carried out by a cryptographic module during a cryptographic process. The patterns are obtained through monitoring the variations in electrical power consumption of a cryptographic module for the purpose of revealing the features and implementations of cryptographic algorithms and subsequently values of cryptographic keys. DPA has the same goals but utilizes advanced statistical methods and/or other techniques to analyze the variations of the electrical power consumption of a cryptographic module. Cryptographic modules that utilize external power (direct current) sources appear to be at greatest risk. Methods that may reduce the overall risk of Power Analysis attacks include the use of capacitors to level the power consumption, the use of internal power sources, and the manipulation of the individual operations of the algorithms or processes to level the rate of power consumption during cryptographic processing.

Timing Analysis: Timing Analysis attacks rely on precisely measuring the time required by a cryptographic module to perform specific mathematical operations associated with a cryptographic algorithm or process. The timing information collected is analyzed to determine the relationship between the inputs to the module and the cryptographic keys used by the underlying algorithms or processes. The analysis of the relationship may be used to exploit the timing measurements to reveal the cryptographic key or CSPs. Timing Analysis attacks assume that the attacker has knowledge of the design of the cryptographic module. Manipulation of the individual operations of the algorithms or processes to reduce timing fluctuations during processing is one method to reduce the risk of this attack.

Fault Induction: Fault Induction attacks utilize external forces such as microwaves, temperature extremes, and voltage manipulation to cause processing errors within the cryptographic module. An analysis of these errors and their patterns can be used in an attempt to reverse engineer the cryptographic module, revealing certain features and implementations of cryptographic algorithms and subsequently revealing the values of cryptographic keys. Cryptographic modules with limited physical security appear to be at greatest risk. Proper selection of physical security features may be used to reduce the risk of this attack.

TEMPEST: TEMPEST attacks involve the remote or external detection and collection of the electromagnetic signals emitted from a cryptographic module and associated equipment during processing. Such an attack can be used to obtain keystroke information, messages displayed on a video screen, and other forms of critical security information (e.g., cryptographic keys). Special shielding of all components, including network cabling, is the mechanism used to reduce the risk of such an attack. Shielding reduces and, in some cases, prevents the emission of electromagnetic signals.