This is the first article of in our comprehensive series introducing Hardware Security Modules (HSM). We understand that some of these concepts can be difficult to grasp all in one read. So for this introduction, we don’t quite intend to break the ice, but only aim to scratch the surface on the topic of cryptographic module security standards.
Mainly, we aim to answer 3 essential questions in this regard:
- What is the current security standard of testing and certifying cryptographic modules?
- Why is it important to comply with these standards?
- And lastly, how to comply?
First of all, we offer a simplified introduction to FIPS 140-2. Further, we show you the essential purpose behind FIPS and why it is so important. Finally, we summarize the procedure to have your HSM tested and certified as a FIPS compliant module, and also we break down the legal requirements you will need to follow when implementing an HSM or any cryptographic module used to handle sensitive information. So let’s take a quick look at what it means, and how to become, “FIPS 140-2 Tested and Certified”
What is FIPS 140-2?
The requirements specified in the Federal Information Processing Standard (FIPS) PUB 140- 2 outline a total of 11 areas of design and implementation of products in applied cryptography. These areas include:
- cryptographic module specification
- roles, services, and authentication
- ports and interfaces
- operational environment
- physical security
- EMI / EMC
- key management
- design assurance
To boot, every certified cryptographic module is categorized into 4 levels of security:
Based on security requirements in the above areas, FIPS 140-2 defines 4 levels of security
- Level 1 - The lowest security that can be applied to a cryptographic module. The sole basis of its security is the fact that it uses a cryptographic function.
- Level 2 - These modules have temper evidence as an additional security feature. This cryptographic device will allow authorized operators to open the seals and access the keys, but only after successfully authenticating.
- Level 3 - This level of security is measured by tamper detection and response, enhanced protection of private key pairs, and identity-based authentication.
- Level 4 - This is the highest level of security. To be certified a level 4 device, the module must be tamper resistant and provide environmental (voltage or temperature) failure protection.
An example of a level 4 certified HSM is Utimaco’s Hardware security modules. Every Utimaco HSMs has been laboratory-tested and certified against FIPS 140-2 standards to help you comply with the standards you need to meet.
Reasons to use a FIPS-certified HSM
- To bar unauthorized users from accessing sensitive information
- To protect from any unauthorized activity in private systems
- To prevent changes from being made without your knowledge or permission
- To detect errors immediately, before sensitive information has been damaged or compromised
Why is FIPS Compliance important?
The FIPS 140-2 standard is applicable to all Federal departments and agencies operate or are operated for them under contract and use cryptographic-based security systems to protect sensitive information in computer and telecommunication systems (including voice systems). Additionally, FIPS compliance is required in any regulated industry that collects, stores, transfers, shares or disseminates sensitive information. This includes products in regulated industries such as Banking, Health-care institutions, and National Defense. If you want to sell into these industries and cryptography is a central component of your product, you'll need to prove FIPS compliance.To certify a cryptographic module such as an HSM, Private vendors must first undergo a series of FIPS testing by an independent, accredited Cryptographic and Security Testing (CST) laboratory, such as the National Voluntary Lab Accreditation Program. First, the CST laboratory uses the Derived Test Requirements (DTR) and Implementation Guidance (IG) to test cryptographic modules. Then they must validate the test results before issuing a certificate.
What are the requirements of FIPS 140-2?
An FIPS 140-2 compliant cryptographic 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
The NIST specifies certain crypto algorithms as FIPS 140-2 compliant, and also identifies which algorithms can be used for symmetric, asymmetric, message authentication, and hashing cryptographic functions. The following is a list of approved cryptographic algorithms:
Symmetric |
Asymmetric |
Message |
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
The FIPS 140-2 standard is applicable to all Federal departments and any regulated industry that collects, stores, transfers, shares or disseminates sensitive information. More importantly, a cryptographic device with high security is necessary to maintain the privacy and integrity of the sensitive information protected by the module. Now that you have a general idea on the importance of FIPS 140-2 and how to comply, take some time to reflect on what you’ve learned and written down any ideas that come to mind. Then when you’re ready, let’s continue on to Part 2 of the Comprehensive Guide to Hardware Security Modules.
References
-
FIPS PUB 140-2 - Security Requirements for Cryptographic Modules (2001), by Information Technology Laboratory, National Institute of Standards and Technology (NIST)
Blog post by Dawn Turner