FIPS 140-3 (ISO/IEC 19790) - Testing of crypto modules and crypto algorithms

Hardware, software, firmware or hybrid-products - if there are cryptographic functions performed, getting a FIPS 140-3 certification shows compliance with a meanwhile worldwide accepted standard, originally demanded and required by public sector clients in North-America.

FIPS PUB 140-3 is the de facto standard for the testing of crypto modules. Products certified to this standard allow public authorities, as well as enterprise sector clients, of the United States and Canada to comply with requirements to use certified cryptographic products. This is driven by regulations to ensure that critical data must be cryptographically protected, and cryptographic mechanisms being used in IT products such as hardware security modules, storage media with hardware encryption, software modules, VPN solutions or smart cards are securely implemented and safe to use. The certification scope covers not only the security requirements for cryptographic algorithms, but also physical security, and entropy for random number generation.

The scheme entails 3 major programs, the cryptographic module verification program (CMVP), the "little" brother cryptographic algorithm validation program (CAVP) and entropy source validation (ESV), for more info check with https://csrc.nist.gov/publications/detail/fips/140/3/final

Which standard is it then?

FIPS 140-3 is the US version, which has an ISO/IEC pendant, which are [ISO/IEC 19790] (Requirements for Cryptographic Modules) and [ISO/IEC 24759] (Test requirements for cryptographic modules). FIPS 140-3 is basically a wrapper for [ISO/IEC 19790] and [ISO/IEC 24759]. The FIPS 140-3 consist of NIST Special Publication (SP) 800-140 and SP 800-140A to F, whereby the SP 800-140 is specifying the modifications of the Derived Test Requirements (DTR) of the test (TE) and vendor (VE) evidence requirements of the (ISO/IEC) 24759. The annexes A to F address documentation, security policy, approved security functions and others.

These documents contain instructions for the vendor on what has to be provided for testing, so called vendor evidence (“VE…”), and instructions for tester how to test e.g. the cryptographic module and its documentation tester evidence (“TE…”). It should be noted that both of these should be read by the vendor for full understanding of both VEs and TEs!

There are also FIPS 140-3 Implementation Guidance documents, which contain binding interpretations of the standard, the derived test requirements, and the referenced cryptographic standards (referenced to as IG X.Y). Relevant IGs about functional aspects have to be read and regarded by the vendor, too!

What products and security functions are tested in which program

The scheme defines 5 modules types (firmware, firmware hybrid, hardware, software, software hybrid) that can be implemented in 3 different physical security embodiments ("form-factors", single IC or smart card, multi-chip embedded module such as adapters and expansion boards or multi-chip standalone such as encrypting routers, secure radios or USB token) for products to be tested, in 4 different security levels.

The security functionality that is tested comprises of encryption, signatures, hashing, authentication, randon number generation (RNG) and key management.

The security levels are to be read and understood in ascending order, i.e. level 1 is the lowest and level 4 the most assuring security level.

• Security level 1 defines a basic level, and as such demands no specific physical security mechanisms and allows that software components of cryptographic modules can be executed on general purpose computer using an unevaluated operating system. Examples here are hardware encryption board in a PC, cryptographic toolkit in a handheld, cryptographic library.
• Security Level 2 introduces some physical protection or so called tamper evidence (coating, seals, or pick-resistant locks on removable covers or doors) as well as role-based or identity-based authentication. Examples here are software modules that executed in modifiable environment that implements role-based access control and audit mechanisms. This level is the highest attainable level for software modules!
• Security level 3 introduces further physical protection known as tamper evidence and response such as strong enclosure, tamper detection/response circuitry, prevention of probing through ventilation holes, and requires as well as trusted channel and protection against security compromises due to environmental conditions (voltage and temperature), plus life-cycle assurance such as automated configuration management, detailed design, etc.
• Finally security level 4 requires physical security mechanisms that provide complete protection around the cryptographic module with the aim to detect and respond to all unauthorized attempts at physical access, as well as authentication mechanisms (secret passwords, token, biometrics) for the operator of the module. Security Level 4 verified modules are typically used or operated in physically unprotected environments. Security Level 4 also requires protection of the cryptographic module against a security compromises commonly know as side channel attacks. due to environmental conditions or fluctuations outside of the module's normal operating ranges for voltage and temperature. A cryptographic module is required to either include special environmental protection features designed to detect fluctuations and zeroize CSPs, or to undergo rigorous environmental failure testing to provide a reasonable assurance that the module will not be affected by fluctuations outside of the normal operating range in a manner that can compromise the security of the module. Level 4 modules require the protection of CSPs against simple power analysis and differential power analysis attacks.?

SL 4 is essentially a design verification based on functional specification.

The validation or testing also considers the operational environment, which is understood as a set of all software and hardware consisting of an operating system and hardware platform required for the module to operate securely. This is important especially for software modules as by NIST definition "The type of environment in which the checklist is intended to be applied. Types of operational environments are Standalone, Managed, and Custom (including Specialized Security-Limited Functionality, Legacy, and United States Government)."?and it also impacts the efforts of testing.

Hardware and Software products are most commonly certified, whereby hardware typically is certified in higher levels. Following table shows the certifications issued by NIST as of end october 2022.

Ultimately the FIPS validation testing aims to test and certify that approved security functions have been deployed and are correctly implemented by the vendor.

TüV IT test laboratory is the only one in Germany (NVLAP Lab Code: 200636-0) that is approved by the National Institute of Standards and Technology (NIST, USA) for testing and validation according to FIPS PUB 140-3.

How can TüV IT assist with FIPS 140-3 certification

TüV IT as approved lab and evaluation body in the IT security domain for nearly 3 decades can assist vendors at every step towards certification:

• validation tests on implementations of cryptographic algorithms with the aim of certification with CAVP (Cryptographic Algorithm Validation Program)
• validation tests on crypto modules (hardware, firmware, software or hybrid) according to FIPS PUB 140-3 with the aim of certification with CMVP (Cryptographic Module Validation Program)
• pre-validation workshops to clarify the extent to which an existing or planned crypto module fulfills the requirements or what amendments need to be made
• project consulting and document creation
• creation of the Security Policy, Finite State Model, Guidance, etc. based on your documentation/input
• additionally, we offer side-channel analyses, since FIPS 140-3 does not provide for vulnerability analysis

TüViT has successfully implemented the following projects in the FIPS 140-3 environment, among others:

• Apollo OS by SCsquare (SC2), Israel, smart card operating system, firmware, security level 3
• banksys DEP/PCI by Atos Worldline, Belgium, hardware security module, hardware/firmware, security level 3
• Java Card Platform Implementation by ORACLE, USA, Java Card operating system, firmware, security level 3
• PSD-I by FRAMA, Switzerland, hardware security module, hardware/firmware, security level 3
• SAP Secure Login Library Crypto Kernel by SAP, Germany, crypto library for various operating systems, software, security level 1
• Secure Mobile by Digital Defence, UK, security extension for Windows Mobile, software, security level 1

#firmware #hardware #software #embeddedsystems #cryptography #informationsecurity #computersecurity #certification #SecurityAnalysis ?#HardwareSecurity ?#ProductSecurity ?#SideChannel ?#SCA #FaultInjection #SecurityCertifications ?#FIPS ?#InfoSec

For more information do not hesitate to connect

Alexander Schasse

Chia-Hung (Michael) Lin

Eric A. Behrendt

TüV Informationstechnik GmbH - TüVIT (TüV NORD GROUP)