In general terms, Cryptography is the practice of securing information which has actually been around for hundreds of years. In today’s technology-focused world, cryptography is widespread and is used to protect sensitive and classified information. While cryptography, in its original form, was very basic, today’s cryptography is very complex, mathematical, and can be virtually unbreakable if implemented properly. This is why the Federal Government and DoD community apply a cryptography standard known as FIPS 140-2 to their IT systems.
What is FIPS 140-2?
The Federal Government spares no expense in the area of Cyber security, which is why the National Institute of Standards & Technology (NIST) created Federal Information Processing Standard (FIPS) 140-2 – Security Requirements for Cryptographic Modules. FIPS publications are mandatory for Federal Government agencies as required by FISMA law passed in 2002. FIPS 140-2 covers the design, development, and implementation of cryptographic modules, and underlying algorithms, in hardware or software. So what exactly is a cryptographic module? According to FIPS 140-2, a crypto module can be hardware, software, firmware, or a combination of the three that implements some form of cryptographic function (encryption, hashing, message authentication, or key management). Do you run a Windows environment? There are crypto modules in use at the software layer that may or may not be FIPS 140-2 compliant. What about Linux? What about any IA enabled software (web servers, database servers)? Bottom line, if your hardware, software, or firmware performs cryptographic functions, it’s done via a cryptographic module.
FIPS 140-2 Requirements
So what are the requirements of FIPS 140-2? I won’t go into detail about the specific requirement areas, but a FIPS 140-2 compliant crypto module must satisfy the following:
- Cryptographic Module Ports & Interfaces
- Roles, Services, & Authentication
- Finite State Model
- Physical Security
- General
- Single Chip Crypto Modules
- Multi Chip Crypto Modules
- Multi Chip Standalone Crypto Modules
- Environmental Failure Protection/Testing
- Operational Environment
- Operating System Requirements
- Crypto Key Management
- Random Number Generators (RNGs)
- Key Generation
- Key Establishment
- Key Entry & Output
- Key Storage
- Key Zeroization
- EMI/EMC Compatibility
- Self-Tests
- Design Assurance
- Configuration Management
- Mitigation of other Attacks
Additionally, FIPS 140-2 defines 4 qualitative levels of security that a cryptographic module can fall under, with level 1 being the least restrictive to layer 4, most restrictive (or secure). Again, this is just an overview of FIPS 140-2. If you’d like to review the FIPS 140-2 publication in detail or other NIST publications for that matter (highly recommend), you will find them here.
FIPS 140-2 Crypto Algorithms
The FIPS 140-2 standard also specifies the underlying algorithms contained within the cryptographic modules. In addition to meeting the requirements above, FIPS 140-2 also covers the specific algorithms that can be used for symmetric, asymmetric, message authentication, and hashing cryptographic functions. Please note that the algorithms contained in the table below must also be implemented according to FIPS 140-2 vs. merely just being used by the module. The approved cryptographic algorithms according to FIPS 140-2 are:
| Symmetric | Asymmetric | Message Authentication | Hashing |
| AES | DSS | TDES | SHA1 |
| TDES | SHS | AES | SHA-256 |
| EES | RNG | HMAC | SHA-512 |
- AES= Advanced Encryption Standard
- TDES= Triple Data Encryption Standard
- EES= Escrowed Encryption Standard
- DSS= Digital Signature Standard
- SHS= Secure Hash Standard
- RNG= Random Number Generators
- HMAC= Hash Message Authentication Code
Verification
So if cryptographic modules exist as hardware, software, or firmware, how can you go about identifying and verifying if they are FIPS 140-2 compliant? First, I should mention that most of the cryptographic modules that exist today were designed by the private sector or open source community, so it’s really up to the vendor, sponsor, or group if they decided to submit their module for FIPS validation. If the module does have FIPS 140-2 certification, it means the module in question has been sent to a NIST approved lab (Cryptographic Module Testing Lab) as part of the Cryptographic Module Validation Program (CMVP). As stated earlier, if your IT system (hardware, software, firmware) operates in the Federal Government, the underlying crypto modules should be FIPS 140-2 compliant and you can review the latest FIPS certified cryptographic modules here:
https://csrc.nist.gov/publications/detail/fips/140/2/final
This site allows you to get a listing via vendor or by specific cryptographic module. I would recommend searching by vendor (Symantec, Windows, Oracle, etc.) which will then allow you to drill down to the cryptographic module used and whether it has a FIPS certificate.
Cryptography and its practice will continue to be used, updated, and improved upon as long as information needs to be protected. NIST FIPS publications are a great resource to learn more about the Information Technology standards and requirements applied at the Federal Government level. While this blog focused on FIPS 140-2 standard, be advised that FIPS 140-3 is in draft which undoubtedly takes into account the ever changing threat landscape.