This article is the first in a series of articles to review the next generation of Federal Information Processing Standards (FIPS) . This first of a two part article looks at the essential components of the cryptographic module standard best known as FIPS 140 whose third generation, FIPS 140-3 is currently in draft form and is expected to become standard in 2010/2011.
The Federal Information Processing Standard FIPS 140 is developed and maintained by the National Institute of Standards and Technology, NIST, in response to section 5131 of the Information Technology Management Reform Act of 1996 and the Federal Information Security Management Act of 2002. The first edition FIPS 140-1 was released in 1994, the second in 2001 and the third edition is currently under development in draft form, FIPS 140-3 draft.
The draft specifies five levels of security with level 1 providing the least assurance and level 5 the most and each level building on its predecessor. The security levels are in many ways akin to the assurance levels described in common criteria levels.
The standard specifies 11 security requirement areas for which the security levels are defined. The requirements include cryptographic module specification; cryptographic module ports and interfaces; roles, services and authentication; software security; operational environment; physical security; physical security-non invasive attacks; sensitive security parameter (ssp) management; self-tests; life-cycle assurance and; mitigation of attacks.
1. The Cryptographic module specification; a set of software, hardware or some combination thereof that implements cryptographic processes including algorithms, and optionally key generation and random number generator; and is contained within a defined cryptographic boundary. The module can also be specified to be working in an approved mode, meaning that it has implemented at least one approved security function. Approved security functions for FIPS 140-2 and released in draft format in late 2008 include symmetric encryption functions (AES, 3DES and Skipjack) and asymmetric signature functions (DSA, RSA and ECDSA), message authentication (3DES MAC, HMAC, CCM and CMAC), hashing functions (SHA-1, SHA -224, SHA -384, SHA-512) and random number generators. While no 140-3 specific functions have been defined, it is expected that the various functions in draft, defined for 140-2 will be automatically adopted, once the drafts are finalized and approved for 140-3. Additional functions may yet be added to the list above in due course.
2. Cryptographic module ports and interfaces; defines the physical or logical entry and exit points to a cryptographic module. The standard addresses requirements for data and information flow through the ports and interfaces, interface sharing, data access operational controls, visual verification of inputs as well as electric power requirements. The standard defines four interfaces; data output, data input, control input and status output interfaces. It is required that control input and data input interfaces be distinguished and that status and data output interfaces be distinguished as well.
3. Roles, Authentication, and Services describes the roles , authentication requirements and essential services of a cryptographic module. Defined roles include cryptographic officer, user and any additional roles specific to the module. While the standard supports multiple roles by a single operator defined in the module, it also requires that each role is separated for each corresponding service. The standard, both role based and identity based authentication of the security officers defined in the cryptographic modules. The standard also specified the requirement for authentication strength. Several cores services are required for compliance at the appropriate levels of the FIPS 140-3 standards in cryptographic module implementation and these include; show status, show module version, perform self test, perform approved security function, and zeroize (setting data to all zeros). The standard supports other services that may be implemented by the module for both approved and non-approved functions. Bypass capability, and external software loading services requirements are also defined in the draft and should be retained, potentially updated, in the final document.
4. Software security describes essential protection for software component of the security module including requirements for code obfuscation, software integrity, and module software interfaces. At a minimum, module software is required to be in executable form and supported with approved cryptographic integrity check.
5. Operational environment specifies requirements for cryptographic modules containing software in modifiable operational environment; example being some cryptographic modules that operate in operating system user mode. Modifiable operational environment introduce elevated vulnerability since some non-validated codes may be loaded at run time. This condition is not applicable for hardware only cryptographic modules with non-programmable memorable (post implementation). However, most software environment will likely require this control to be compliant beyond the original release (although its essential to note that compliance test for operating systems and most updateable software provide an assurance level for a snapshot state of the software, and increasingly for even many hardware modules as corporations hardly apply for certification for sub-versions of their systems. For example while Microsoft .NET Framework 3.1 maybe FIPS 140-2 level 1 certified, there are no guarantees that .NET Framework 3.1 service pack 1 will be compliant and thus certifiable.)
6. Physical Security specifies requirements for physical security of the cryptographic modules and does not apply to software –only-modules that rely completely on the physical housing of the overall system (such as .NET framework described above). The requirement applies to hardware and hybrid (software-hardware) cryptographic modules and defines requirements for module isolation, tamper proofing and aims to provide assurance of detectability in the event of tempering. Requirements for maintenance access interfaces are specified for modules with maintenance roles as well as requirements for basic documentation that specify the physical embodiment and security level for which the security mechanisms are implemented. Requirements for single-chip, multiple chip embedded, and multiple chip standalone cryptographic modules are specified in the standard as is environmental failure prevention and testing requirements. Power and temperature specification for the protection of critical security parameters (CSP), and public security parameter (PSP) are specified as are the testing procedures to mitigate vulnerabilities resulting from these failures.
7. Physical security – Non-Invasive Attacks; addresses external, non invasive exploitable vulnerabilities associated with the physical environment of the cryptographic module including but not limited to power analysis (simple and differential), electromagnetic emanation, and timing analysis.
8. Sensitive security parameter management sensitive security parameters (SSP) include both critical and public security parameters. Critical security parameters are parameters whose public disclosure will compromise the security of a cryptographic module and include PIN, passwords, and private cryptographic key. Public security parameters include security related public data or information whose modification can compromise the security of the cryptographic module, for examples the random seed for random number generator. The SSP requirement covers the SSP management lifecycle from random bit generation to SSP generation, SSP establishment, SSP entry/output, storage and zeroization.
9. Self-tests includes pre-operational, conditional, and where applicable; critical function tests to ensure that the cryptographic module is functioning properly, provide documented guidance as to what error state a cryptographic module enters on test failure as well as the necessary actions required to exit the error states. Pre-operational test are required to be performed between power on and performance of a cryptographic function where power on could be from a power off state or a quiescent state.