The SafeLogic Blog

In the past, we featured a "How To" for reading a FIPS validation listing, and it's time to update, since the CMVP changed the format of their website. The information displayed is mostly unchanged, just organized differently, with several new items which will be called out below.

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.)

1. The unique FIPS validation listing number assigned to this cryptographic module. This is the number that a vendor should reference when asked about FIPS 140-2. In this example, FinalCode would announce, “Our products use FIPS 140-2 validated cryptography, see certificate #2717.”
2. Every FIPS validation listing has a name. They are usually pretty generic, just for simplicity. We advise our customers to differentiate between modules with descriptors, like "for Mobile", when applicable.
3. This is a new field added by CMVP as a placeholder for future revisions to the standard. One day, this may specify "FIPS 140-3". We'll see.
4. Another new field, marking the distinction between "Active", "Historical", and "Revoked" modules. This status can be searched from the homepage and is a far better system than before, as modules used to simply disappear from the active list without clear tracking. Only "Active" validations meet mandates.
5. In 2017, CMVP began moving certificates to "Historical" status if they had not been validated or updated in the preceding five years. In the new website format, this is represented as a "Sunset Date" and establishes clear expectations of when the validation will expire, if not maintained and updated. SafeLogic handles this as part of our support and ensures that RapidCerts will not reach their expiration.
6. This is the completion date of the validation. If multiple dates are listed, those represent approved updates. Not as important as the "Sunset Date", but this provides insight into how often and how recently the validation has been updated.
7. 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. See #9 for more on the exceptions.
8. The caveat section contains information required by the CMVP for the cryptographic module. Common caveats describe operational requirements for “FIPS mode” and entropy. CMVP also includes a reference, if another validated module has provided a basis for this certificate.
9. This is an area for Security Levels that differ from the Overall Level (see #7) 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
10. This FIPS validation listing example features a Software validation, but CMVP also validates Hardware, Firmware and Hybrid modules.
11. 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.
12. 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.
13. The Operational Environment is a crucial section for procurement. 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, but this "vendor affirmation" that the module did not require modification for the unlisted environment must still be documented in the Security Policy. We can help strategize whether this would be valuable for your validation.
14. 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.
15. Other algorithms are included on the FIPS 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.
16. Federal agencies must verify that the specific version information matches the module version implemented by the product(s) that they are using. This used to be located at the top of the listing, alongside the name of the module.
17. 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.
18. Every FIPS 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.
19. 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 and saves our customers literally months of work.
20. A link to the consolidated validation certificate. To expedite the process, CMVP publishes 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 and Security Policy includes more information specific to each particular validation.
21. 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. Information on all the accredited labs can be found here: http://csrc.nist.gov/groups/STM/testing_labs/. CMVP recently began including the name of the lab, not just the unique NVLAP number, to give more visibility into this element of the process. This particular example was tested by Acumen Security, which has done a fantastic job on many SafeLogic’s RapidCert efforts, and it should be noted that our customers do not have to contract separately for a lab, we take care of all that!

If you have any questions about reading FIPS validation listings, please don't hesitate to ask. The SafeLogic team is ready to accelerate the process for your FIPS 140-2 validation!