Welcome to the Acumen Security Blog

SP 800-52r1 and it’s impact on FIPS 140-2 certifications

Special Pub 800-52 revision 1 was published at the end of April (April 28th) and is a pretty good document to enhance the readers understanding of the Transport Layer Security (TLS) protocol, the various steps involved in TLS tunnel establishment, the cipher suites supported and best practices for certificate validation. I would highly recommend readers of this blog read also through the document to gain an understanding of TLS or to get a refresher.

The reason to write this blog post though is to point out a requirement in the document that can have a pretty significant impact on current and future FIPS 140-2 validations (and potentially Common Criteria evaluations within the US scheme).

Section 3.1 states that TLS 1.1 is the minimum TLS version that can be configured on servers deployed in Federal government networks (with some caveats). TLS 1.0 (which is the most prevalent version and allowed by FIPS 140-2, currently) is not allowed. Moreover starting January 1, 2015, TLS 1.2 is the only version that will be allowed. Below is the relevant snippet from the special pub:

Servers that support government-only applications shall be configured to support TLS 1.1, and should be configured to support TLS 1.2. These servers shall not support TLS 1.0, SSL 2.0, or SSL 3.0. TLS versions 1.1 and 1.2 are represented by major and minor number tuples (3, 2) and (3, 3), respectively7. Agencies shall develop migration plans to support TLS 1.2 by January 1, 2015.
Servers that support citizen or business-facing applications shall be configured to support version 1.1 and should be configured to support version 1.2. These servers may also be configured to support TLS version 1.0 in order to enable interaction with citizens and businesses. These servers shall not support SSL version 3.0 or earlier. If TLS 1.0 is supported, the use of TLS 1.1 and 1.2 shall be preferred over TLS 1.0.

This is a significant requirement should CMVP start enforcing this restriction as part of FIPS 140-2 validations. TLS 1.1 support is not very prevalent. The support for TLS 1.2 is even less and Jan 1st is not very far away.

Acumen is contacting CMVP to receive clarification on their stance regarding TLS versions allowed in FIPS mode of operation going forward. We will update this post once we receive any information from the CMVP. In the meantime our strong recommendation would be to put support of TLS 1.2 into your development plan. It will not only head off any sudden change in requirements from CMVP but also help in Common Criteria evaluation (TLS 1.2 is the only version that supports the Suite B class of crypto algorithms and something that NIAP also wants to move to ASAP).
Bottom Line: Don’t change any plans for in-flight evaluations however put TLS 1.2 on the immediate product roadmap as an insurance policy and for future proofing.

Update 6/18/14: We heard back from NIST and all is good. They have indicated that SP 800-52r1 is a recommendation for TLS deployment for Federal agencies however FIPS 140-2 will continue allowing TLS v1.0 as long as the implementation uses FIPS approved cryptographic algorithms/primitives. The reasoning given is that FIPS validation is for approved algorithms and not necessarily the protocols.

The above update not withstanding, Acumen’s recommendation in the original post still stands. Given where the security industry is going, and requirement for Suite B crypto in a number of national security accounts it would make imminent sense to start implementing TLS 1.2 in future product releases. Please feel free to leave a comment or send email to info(at)acumensecurity(dot)net if you have any questions.

Getting ready for an ISO 19790 based FIPS 140-Next

Recently, there has been a lot of talk about the next version of FIPS 140 being based on ISO 19790:2012.  The CMVP has even added a section to its website to address its consideration. At first glance, the differences between FIPS 140-2 and ISO 19790:2012 may not seem too bad. However, in doing a deep dive into the requirements, one finds that there are numerous changes that will directly affect every cryptographic module that has ever been validated. If vendors are caught off guard, it will be very painful to complete their next FIPS 140 validation after the transition.

For many vendors, it makes sense to consider getting a head start into integrating the new functionality required by ISP 19790:2012. However, the transition plan is not finalized (the CMVP could potentially even go a completely different direction) and it would not be prudent to completely overhaul code and design to meet the ISO requirements. There are, however, several requirements that could be considered not only because they will be required, but, they are also just good security practices. Here are a few suggestions a product vendor may wish to consider to get a head start on an ISO 19790:2012 based FIPS 140-Next.

  • Password Complexity Requirements: FIPS 140-2 allows any password complexity requirement to be enforced procedurally. This will NOT be the case moving forward. Now is the time to add minimum complexity rules to your software. At minimum, even if it does not become part of FIPS 140-Next, you will prevent the dreaded one-character password. As an added bonus, this may also help with other certifications you are interested in, such as, NIAP NDPP Common Criteria evaluation.
  • Default Authentication Data: If you provide default authentication data to initially access your product, ISO 19790:2012 requires that these credentials be changed after first usage. Default credentials are one of the more common ways a system in operation is compromised. Requiring the user to change these credentials will not only be necessary to validate against FIPS 140-Next but is a good security practice.
  • Automated Security Diagnostic Testing: ISO 19790:2012 requires that any software/firmware in a product be run through automated testing (such as, static analysis).  If you are not already performing that type of testing, now is a good time to start. Not only will you be meeting the new validation requirements, but, you may just identify and prevent a vulnerability from getting out into the field.

The list above only touches on a couple of the differences between FIPS 140-2 and ISO 19790:2012. There are a number of other differences that will directly affect product vendors’ development plans. Acumen Security has performed a detailed analysis between the two standard and put together an easily consumable white paper providing a high-level description of the differences between FIPS 140-2 and ISO 19790:2012 and some recommendations to help make the transition easier. Check out “FIPS 140-Next is coming: What does it mean and what are you going to do?,” give us a call, or drop us a note. We’d love to help you understand what this transition would mean to you and how you can minimize its impact.

Also, follow us on Twitter and like us on Facebook, we’ll keep you up-to-date on the ever changing world of government certifications.