Vinnie's Views
PGPsdk and FIPS-140
Monday, September 15th, 2008
What is FIPS-140-2?
FIPS 140-2 is the Security Requirements for Cryptographic Modules standard from the National Institute of Standards and Technology (NIST). It applies to the protection of valuable and sensitive but unclassified information throughout the government and DoD. FIPS-140 is not a security guarantee but rather a set of best practices for implementing the cryptographic algorithms as well as handling the secret key material.
The primary objective of FIPS-140-2 is:
- Protection from unauthorized use.
- Protection of Critical Security Parameters (eg. Secret Key material)
- Protection from undetected modifications
- Use of approved security methods
- Indication of module operational standards
- Detection and indication of errors.
What is often misunderstood is that FIPS-140-2 only pertains to cryptographic modules (PGPsdk), not the products that use them. Further within the module is a subset of functions delineated in the Cryptographic Module Security Policy (CMSP) that excludes the non-cryptographic functions. Only the code within this cryptographic boundary is eligible for validation. So while we can put portions of the PGPsdk through validation we can’t validate PGP Desktop or PGP Universal Server.
What makes FIPS-140-2 so important is that compliance is mandatory for all US Federal Agencies, DoD, financial institutions, the Canadian government, and many private sector agencies when a Federal agency determines that cryptography is necessary for protecting sensitive information.
Levels and Sections
FIPS-140-2 has a number of security areas that must be addressed at the various levels. For each of these areas a module can receive a rating of 4 security levels and, in addition, the entire module will receive an overall level equal to the lowest level of all the areas. These levels are defined as follows:
- Basic security requirements
- Tamper evidence, role base authentication
- Enhanced physical security, identity based authentication
- Envelope and environmental protection
Only Level 1 and possibly Level 2 (in specific hw/sw combinations) are actually applicable to software modules such as the PGPsdk. Level 1 allows the module to be run on a general purpose computing system using an unevaluated operating system while Level 2 requires that the OS meets the requirements of Common Criteria EAL-2 and that it maintain a controlled access profile (TCSEC, C2, ITSEC, C2/E2, etc).
Level 2 further goes on to attempt to map the concept of tamper evidence and role-based authentication to a software module. In effect, it requires that the module maintain an audit log of all cryptographic operations, although it doesn’t require that this data be stored securely. There is also a requirement that the user authenticate itself to the crypto module before using it, in effect they would have to log in to the module.
For FIPS-140-2 we have opted to forgo Level 2 for, among other reasons, the belief that maintaining this log might open the user to a traffic analysis attack in addition to potential performance implications.
As mentioned earlier, the FIPS-140-2 specification is divided into 11 security areas that each module must address. Some of these areas are nothing more than documentation tasks, some are usage policies, and others require specific software functionality. These areas are defined as follows:
- Cryptographic Module Specifications
- Cryptographic Module Ports and Interfaces
- Roles, Services and Authentication
- Finite State Model
- Physical Security (N/A)
- Operational Environment
- Cryptographic Key Management
- EMI/EMC (N/A)
- Self-Tests
- Design Assurance
- Mitigation of other attacks
Documentation and Software Requirements
The first four sections are mostly documentation tasks. The module specifications and ports and interfaces (aka API) are defined in the Cryptographic Module Security Policy (CMSP). The CMSP covers, among other things, the cryptographic boundary, the approved modes of operation including all hardware, software and firmware components, which library binaries contain the PGPsdk, what algorithms it supports, as well as what the Application Programming Interface (API) looks like.
The security policy for each version of the PGPsdk can be found in the developer package as well as the NIST website.
For Level 1, the Roles, Services and Authentication section is a documentation issue, covered in the CMSP, but for Level 2 this requires the operator to authenticate himself to the module before doing FIPS operations (ie key generation) that modifies, discloses or substitutes a CSP. or uses a FIPS approved security function. In effect, the operator would have to log into the PGPsdk.
The Finite State Model (FSM) is a rather large document that specifies all the required states and optional states, state transition and inputs of the components within the Cryptographic boundary. It includes a state transition diagram and/or a state transition table for every API call that is crypto related.
Some areas such as the Physical Security and EMI/EMC are not applicable to software only modules.
The Operational Environment section details the conditions and systems on which the module will be deployed. For Level 1 validation, the crypto module must use a commercially available general purpose Operating System and the module be installed as executable only code. A FIPS approved authentication technique must be applied to the software; in our case we sign the module binary with RSA or DSA key. The module must protect CSPs from other processes and users. And best of all, the OS must be restricted to single operator mode; more on this later.
For Level 2 validation, however, it is required that all cryptographic software/firmware, keys, and CSPs must be under control of an Operating System rated to EAL-2 to an approved product profile, or an equivalent trusted OS, and that it maintains a controlled access profile (TCSEC, C2, ITSEC, C2/E2, etc).
The Cryptographic Key Management section details how keys are created, accessed, modified, and destroyed. The standard requires that key generation must use a FIPS approved random number generation method such as X9.31 and that all secret key material (CSP) be zeroed as part of the deletion process.
FIPS-140-2 also requires that when establishing a symmetric key, an appropriate size public key and hash algorithm must be used. For example, when wrapping an OpenPGP message encoded with an AES-128 key, you must use an RSA key of least a 3073 bits. This requirement isn’t always practical when using larger keys like AES-256, since that would need a RSA 15360 bit key.
The documentation process also requires detailing design assurance items, such as the software development process, configuration management, distribution, and installation.
FIPS Mode and Self-Tests
While the FIPS-140-2 allows a module to include non-approved algorithms or functionality such as CAST-5 or BlowFish, it can only be invoked outside the FIPS approved mode of operation. The PGPsdk module provides a special FIPS approved mode of operation. The module is defined as powering-up into FIPS mode when the PGPEnableFIPSMode() call is made by the client application. In addition to restrictions set forth by the Security Policy, entering FIPS mode has a number of effects on PGPsdk operations.
The module must perform a series of self-tests upon entering FIPS mode. These tests can also be run on demand. Typically these tests involve running each symmetric crypto algorithm and mode against a series of known answer tests. Non-deterministic public keys algorithms are also tested for pairwise consistency by encrypting a plain-text value with the public key, checking that the cipher-text is not the same as the original plaintext, and then decrypting with the private-key and checking against original plain-text.
While in FIPS mode there are also a few tests which are performed under certain conditions, such as when new public keys are generated or when random numbers are created. Failure of any self test puts the module in error state, and disables all further crypto operations.
One other test is against the module integrity using a built in public key to verify a detached signature of the library binary itself.
The Validation Process
Module validation and testing is facilitated by a Cryptographic Module Testing (CMT) Laboratory. The CMT labs themselves must be accredited by NIST’s Cryptographic Module Validation Program (CMVP). The primary role of the CMT lab is to test the cryptographic module against all applicable requirements specified in FIPS 140-2 and record the results. The module and its documentation undergoes extensive scrutiny by the CMT. For example, one of the tests is known as the “operational test” or “optest,” in which every module API is exercised against a series of procedures known as “Test Evidence.”
In addition to validating the crypto module, the FIPS approved algorithms within it must be also tested for compliance by the Cryptographic Algorithm Validation Program (CMVP). The algorithms are run through a battery of random test vectors by the CMT which must be passed before the enclosing module can be validated.
Once a test report is compiled, the test lab submits a report to NIST for review. At some point NIST assigns the report to a reviewer who could issue questions or comments on the certification report back to the CMT. When all questions are resolved and resubmitted a certificate is issued by NIST. Certificates and validation status are posted on the CMVP website. The time from when the report is submitted to NIST until the certificate is issued varies but is typically anywhere from 3-6 months.
The validation process can be extensive and make take on the order of several months, and validations do need to be updated when the module version number changes. However, if module updates do not involve changes to crypto sections, or are not security relevant changes, the update can be an easy process (approximately 1-2 weeks). If less than 30% of testable requirements change, NIST looks only at the changes.
FIPS-140-2 Practicality
It could be argued that the FIPS-140-2 standard is far from perfect. Functions such as module integrity testing could be better provided by the most modern operating systems. The tamper evidence and role-based authentication requirements of Level 2 are the result of trying to shoehorn guidelines for cryptographic telecommunication equipment and postage meter machines into a software-only crypto library environment. The symmetric key wrapping requirements in some ways weakens message encryption. But the biggest offender is that to properly comply with the standard, a Level 1 module would have to run in single user mode. Is this even possible with modern OS implementations?
One has to keep in mind that the standard is several years old and that it was originally drafted around the PC-AT. But the FIPS process is rigorous and does add a number of useful considerations to the design of crypto modules.