By Arleen Thukral, MS, CCE
In this month’s installment of Networking, we explore the Federal Information Processing Standard (FIPS) Publication 140-2. This standard establishes the Cryptographic Module Validation Program (CMVP) as a joint effort by the National Institute of Standards and Technology (NIST) and the Communications Security Establishment for the government of Canada as defined in section 5131 of the Information Technology Management Reform Act of 1996.
Validation against the FIPS 140-2 standard is required for all U.S. federal agencies that use a cryptographic module to protect sensitive but unclassified information stored digitally. So what’s a cryptographic module? In a phrase, it’s a set of hardware, software, firmware, or some combination thereof, that implements cryptographic logic or cryptographic processes.
Further, the NIST publishes a list of vendors and their cyrptographic modules validated for FIPS 140-2, which you can find at goo.gl/xwzXVM. Note: Rather than validating individual components and products, corporations certify the underlying cryptographic modules used in the products. In fact, numerous vendors, including Microsoft, have maintained a FIPS 140 validation program since the inception of the standard.
What’s more, some Windows components that rely on FIPS 140-validated cryptographic modules include Remote Desktop Protocol Client, some Microsoft .NET Framework applications, and IPsec settings of Windows Firewall.
The goal is to work with the government and industry to establish more secure systems and networks by developing, managing, and promoting security assessment tools, techniques, services, and supporting programs for examination, evaluation, and validation. Moreover, the security requirements cover areas such as cryptographic module specification; cryptographic module ports and interfaces; roles, services, and authentication; a finite-state model; physical security; the operational environment; cryptographic key management; electromagnetic interference/electromagnetic compatibility; self-tests; design assurance; and mitigation of other attacks.
FIPS by the Level
FIPS 140-2 defines four levels of security:
- Level 1: Security Level 1 provides the lowest level of security. An example of a security Level 1 cryptographic module is a personal computer encryption board. Most software, including Microsoft products, are tested against Level 1 security requirements. All plaintext, private keys, and other unprotected critical security parameters (CSPs) contained in the cryptographic module should be zeroized.
- Level 2: Security Level 2 improves upon the physical security mechanisms by requiring features that show evidence of tampering, including tamper-evident coatings or seals that must be broken to attain physical access to the plaintext cryptographic keys and critical security parameters within the module. A cryptographic module must employ role-based authentication to control access to the module.
- Level 3: Security Level 3 attempts to prevent the intruder from gaining access to CSPs held within the cryptographic module. Further, the physical port(s) used for the input and output of plaintext cryptographic key components, authentication data, and CSPs is physically separated from all other ports of the cryptographic module. Otherwise, the logical interfaces used for input and output of plaintext cryptographic key components must be logically separated from all other interfaces using the trusted path.
- Level 4: Security Level 4 provides the highest level of security. Penetration of the cryptographic module enclosure from any direction has a very high probability of being detected, resulting in the immediate deletion of all plaintext CSPs. At this level, a cryptographic module is required to either include special environmental protection features designed to detect fluctuations and delete CSPs, or to undergo rigorous environmental failure testing to provide a reasonable assurance that the module will not be affected by fluctuations outside the normal operating range in a manner that can compromise the security of the module. This security level is useful for operating in physically unprotected environments, such as hospitals.
Levels 3 and 4 must employ identity-based authentication mechanisms to control access to the module—in other words, such levels require operation to be individually identified. Further, the strength of the authentication mechanism must abide by the following specifications:
- For each attempt to use the authentication mechanism, the probability must be less than 1 in 1 million that a random attempt will succeed.
- For multiple attempts to use the authentication mechanism during a one-minute period, the probability must be less than 1 in 1 million that a random attempt will succeed.
- Feedback of authentication data to an operator must be obscured during authentication—aka: no visible display of characters when entering a password.
- Feedback provided to an operator during an attempted authentication must not weaken the strength of the authentication mechanism.
Finally, a cryptographic module performs power-up self-tests and a conditional self-test to ensure that the module is functioning properly. A failed self-test should result in an error state and output an error indicator via the status output interface. (Note: The cryptographic module cannot perform any operation while in an error state.)
Also, a cryptographic module may enter bypass—after all, services are provided without cryptographic processing. However, requiring two, independent internal actions to prevent inadvertent bypass—and show whether bypass is activated or not in the module—mitigates risk.
To sum it up, in the days of WannaCry incidents, medical device security needs to be included in pre-procurement assessment. Therefore, it’s important to ask vendors for a FIPS 140-2 certificate for networked medical devices. For starters, does the device use its own cryptography? Remember: The wireless driver should use a FIPS 140-2 validated cryptographic module and support authorized roles for operators and corresponding services within each role and bypass capabilities. Such actions matter since choosing a FIPS 140-2 medical device will help healthcare organizations enjoy securer systems and networks.
Arleen Thukral, MS, CCE, is a VISN 20 biomedical engineer at VA NorthWest Healthcare Network in Seattle. Questions and comments can be directed to firstname.lastname@example.org.
What is the security record of FIPS 140-2 certified systems?
On a related note, a bill has been introduced in the Senate that would require a cybersecurity report card for every new connected device. The specified content does not explicitly reference FIPS.