September 2016 | SafeLogic

Archive for September, 2016

13 Sep 2016

Format Change for Modules In Process List at CMVP

Modules In Process ListThere has been a fairly significant change in the way that the NIST website displays the status of encryption modules that are undergoing FIPS 140-2 testing and validation. The NIST Modules in Process List website now contains two separate reports, drawing a clear distinction between Implementation Under Test (IUT) and Modules in Process (MIP).

The FIPS 140-2 Implementation Under Test List (IUT List) contains cryptographic modules that are in the testing process with a FIPS Laboratory. The IUT Date indicates when the cryptographic module was first added to the list.

Sample IUT List entries:

CMVP Modules In Process List

Once a report package has been submitted to the CMVP by the FIPS Laboratory, a cryptographic module will be removed from the IUT List and then added to the MIP List.

The FIPS 140-2 Modules In Process List (MIP List) contains the cryptographic modules that are stepping through the following milestones:

  • Review Pending – The CMVP received a complete report package
  • In Review – Report Reviewers assigned at the CMVP
  • Coordination – CMVP comments returned to the FIPS Laboratory
  • Finalization – Administrative processing to post the certificate

Sample MIP List entries:

CMVP Modules In Process List

Both lists are updated daily and available as PDFs from the NIST website. Note that participation is optional, and a vendor may elect to not be listed on one or either list.

What does this mean for my FIPS 140-2 strategy?

Essentially, the IUT status loses its luster. By drawing a clear differentiation between IUT and MIP, the former becomes simply a voluntary “We’re working on it!” claim while the latter signifies actual progress. Federal procurement officers used to check the In Process List and would be encouraged by any company appearing there, but the IUT list will become less important, especially for module entries that are months old and their progress has stagnated.

For SafeLogic customers, IUT status was never relevant in the first place. RapidCert catapults clients directly to MIP status because there is no delay between initiating the process and delivering documentation to CMVP. With our project management team and the processes already arranged with our preferred testing laboratories, SafeLogic customers will appear only on the MIP List during their brief waiting period for validation. Unless, of course, you prefer stealth mode. Imagine the looks on your rivals’ faces when you appear on the Validated List before they even make it off the IUT List!

As always, feel free to contact me with any questions. We’re ready when you are.

7 Sep 2016

How to Read a FIPS 140-2 Validation Listing

I’m pleased to provide a breakdown of exactly what you will find on the NIST website when reviewing a FIPS 140-2 validation listing. Whether you are a federal procurement officer, a technical consultant, a vendor representative, an end user, or really any role that may deal with FIPS 140-2, you should be able to interpret and verify the information on these certificates after reading this post. Bookmark this page for future reference, in fact. If you have any further questions, please don’t hesitate to contact me directly at I’m here to help.

Here is a screen-captured example of a FIPS 140-2 validation listing, as shown on the NIST website. I will note where other validated modules may differ, but this is a good sample of a typical Software Level 1 certificate, the specialty of SafeLogic’s RapidCert program. (If you click here or anywhere on the image below, it will open full-size in a new tab.)

How to Read a FIPS 140-2 Validation Listing

  1. The unique FIPS 140-2 validation listing number assigned to this cryptographic module. This is the number that a vendor should reference when relevant. In this example, FinalCode would announce, “Our products use FIPS 140-2 validated cryptography, see certificate #2717.”
  2. This is the validation owner. Company names include an embedded link to their website, and the physical address is provided by the vendor. It may not always be headquarters – sometimes it is a development office or similar.
  3. Every validation listing includes contact information. Often it is the product manager, CTO or another development stakeholder. In this example, it is a general mailbox and central phone number, which is also acceptable. Note the embedded link for direct email.
  4. This is the independent third party testing laboratory. Every validation has one, and it’s not possible to earn your FIPS 140-2 without an accredited lab. This particular example was tested by Acumen Security, which has done a fantastic job on many SafeLogic’s RapidCert efforts. Information on all the accredited labs can be found here: and you can cross-reference the unique NVLAP (National Voluntary Laboratory Accreditation Program) code if you like.
  5. Every FIPS 140-2 validation listing has a name. They are usually pretty generic, just for simplicity, but federal agencies must verify that the specific version information matches the module version implemented by the product(s) that they are using.
  6. The caveat section contains information required by the CMVP for the cryptographic module. Common caveats describe “FIPS mode” and entropy, a hot button issue of late. CMVP also recently added a new reference, if another validated module has provided a basis for this certificate.
  7. A link to the consolidated validation certificate. CMVP realized that it was a real time suck to create individual certificates (and send them via snail mail), so instead, they publish a single certificate each calendar month, which lists the validations completed during that period. The PDF certificate includes signatures from both NIST and CSE and it looks pretty, but they are rarely referenced because the public website listing includes more information.
  8. Each validation includes a required Security Policy, which is linked via PDF. This documentation includes technical parameters for the cryptographic operations in FIPS mode and represents a significant portion of the time and effort wasted by vendors who insist on handling their validation in-house. With RapidCert, this documentation is already prepared for CryptoComply modules and is updated for client needs. Much more simple than starting from scratch.
  9. This FIPS 140-2 validation listing example features a Software validation, but CMVP also validates Hardware, Firmware and Hybrid modules.
  10. This is the completion date of the validation. If multiple dates are listed, those represent approved updates. Note that beginning in 2017, CMVP will be removing validations that are not dated within the preceding 5 years. This is an important step to ensure that all validated crypto modules are being maintained for compliance with current standards and requirements.
  11. FIPS 140-2 validations can be completed for Level 1, 2, 3, or 4. While Level 1 is appropriate for Software, the advanced levels feature increasing amounts of physical security, including tamper-evident seals and tamper response. These are key facets for Hardware validations, in particular.
  12. This is an area for Security Levels that differ from the Overall Level (see 11) or additional information. These may include notes in the following categories:

– Roles, Services, and Authentication
– Physical Security
– Cryptographic Module Specification
– EMI/EMC (electromagnetic interference/electromagnetic compatibility)
– Design Assurance
– Mitigation of Other Attacks

  1. The Operational Environment is a crucial section for Software validations. This is where it becomes explicit which platforms were tested within the scope of the validation. This example includes both Android and Apple iOS mobile operating systems. Note that it may be permissible to operate FIPS mode on other operating environments that are not listed here (by vendor affirmation that the module did not require modification for the unlisted environment).
  2. The FIPS Approved algorithms section lists the specific cryptographic algorithms Approved for use in the FIPS mode of operation, as well as references (but not embedded hyperlinks, unfortunately) to the CAVP certificates for each. This is the evidence that each algorithm was successfully tested by the lab as a prerequisite for the module testing.
  3. Other algorithms are included on the FIPS 140-2 validation listing if they are implemented in the module but are not specifically listed as FIPS Approved algorithms (#14). This list includes algorithms allowed for use in the FIPS mode of operation as well as any algorithms contained in the module that are not to be used in the FIPS mode of operation. The latter category may be algorithms that have been phased out or are included for other strategic reasons.
  4. This is a categorization of the module. Multi-Chip Stand Alone, Multi-Chip Embedded, or Single Chip. Software modules are classified as Multi-Chip Stand Alone since they run in a general purpose computer or mobile device.
  5. This is a brief summary of the role of the cryptographic module. Some are extremely brief, while zealous marketing folks have written others, but the vendor always provides it to offer some context.