Mark Minnoch, Author at SafeLogic

All posts by author

22 Dec 2016

FIPS Module 3.0 for OpenSSL 1.1 Update

(L to R) Tony Busciglio (Acumen), Ashit Vora (Acumen), Mark Minnoch (SafeLogic), Steve Marquess (OpenSSL) Not pictured: Ryan Thomas (Acumen)

(L to R) Tony Busciglio (Acumen), Ashit Vora (Acumen), Mark Minnoch (SafeLogic), Steve Marquess (OpenSSL) Not pictured: Ryan Thomas (Acumen)

In December, Acumen Security hosted our kick-off meeting for the FIPS Module 3.0 validation effort. I was SafeLogic’s delegate, Steve Marquess represented OpenSSL, and Ashit Vora, Tony Busciglio, and Ryan Thomas attended for Acumen. With the expected adoption of TLS 1.3 and upcoming algorithm transition deadlines (outlined in NIST SP 800-131A), the OpenSSL-SafeLogic-Acumen Security partnership strives to deliver a FIPS module that works with OpenSSL 1.1 during the 2017 calendar year.

For this project to be successful, we will need additional Project Sponsors. Technology vendors that plan to deliver products using OpenSSL 1.1 in the future should consider sponsorship to support the effort. Financial contributions from Project Sponsors will help fund the engineers developing the code (OpenSSL) and the FIPS Laboratory (Acumen Security) for their validation testing services.

Here is the tentative schedule for the FIPS Module 3.0:

January 2017: Receive initial contributions from Project Sponsors
February 2017: Technical parameters locked in for development
March 2017: OpenSSL team begins development to meet FIPS requirements
May 2017: Development checkpoint
July 2017: SafeLogic reviews FIPS Module, finalizes FIPS 140-2 documentation
August 2017: Acumen submits FIPS 140-2 report to CMVP
October 2017: CMVP provides report comments to Acumen (2 month queue time expected)
November 2017: CMVP issues FIPS 140-2 certificate for FIPS Module 3.0 (for OpenSSL 1.1)

Important Notes:

1. Additional Project Sponsors are needed to make their initial contributions in January to begin the process on time.
2. All development and testing work is scheduled based upon sponsorship contributions being delivered as planned. Additional sponsors will mitigate risk of delays.
3. FIPS Module 3.0 Technical Objectives and Sponsorship information are available here: https://wiki.openssl.org/index.php/FIPS_module_3.0
4. Early releases of the FIPS code will be available from Github for public review and testing.
5. For a quick history of how the OpenSSL/SafeLogic/Acumen team came together, please see our July announcement.

How Can My Company Become a Sponsor?

Thank you for your interest! We welcome additional sponsors to support this crucial development for the community. Please contact me directly to discuss and stay tuned for additional updates here at the SafeLogic blog.

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 Mark@SafeLogic.com. 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: http://csrc.nist.gov/groups/STM/testing_labs/ 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.

 

BlogFooter_Mark

24 Aug 2016

How does the SWEET32 Issue (CVE-2016-2183) affect SafeLogic’s FIPS Modules?

Executive Summary:

SWEET32 issueA newly demonstrated attack, SWEET32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN, shows that a network attacker monitoring an HTTPS session secured by Triple-DES can recover sensitive information. The attack was performed in a lab setting in less than two days by capturing 785 GB of traffic over a single HTTPS connection.

Sounds scary at first.

The good news: No action is required by SafeLogic customers for the SWEET32 issue.

 

My FIPS 140-2 Module is not Broken?

Correct. Triple-DES [1] is a FIPS Approved algorithm and Triple-DES is expected to remain a FIPS Approved algorithm for the foreseeable future. Triple-DES uses 64-bit block sizes which makes it vulnerable to this attack. Cryptographers have long been aware of this type of vulnerability in ciphers designed with small block sizes.

The AES symmetric cipher (also a FIPS Approved algorithm) is not vulnerable to this attack.

[1] Two-key Triple-DES may only be used for decryption purposes in the FIPS mode of operation. Three-key Triple-DES may be used for encryption and decryption purposes in the FIPS mode of operation.

What Might NIST Do?

Since a considerable amount of ciphertext needs to be captured to make this attack possible, this is a low security concern for nearly every use of TLS. We anticipate that CMVP (NIST/CSE) may publish future guidance limiting the amount of plaintext that is encrypted using a single Triple-DES key, but we do not expect the CMVP to remove Triple-DES from the list of FIPS Approved algorithms due to this reported attack.

 

Should I Turn Off Triple-DES to be Safe?

That depends on your company’s security policy for addressing vulnerabilities. The SWEET32 issue does not make Triple-DES itself any less secure than it was yesterday and the method of attack is not new. You may need to continue supporting Triple-DES in order to allow TLS connections that are not able to negotiate use of the AES cipher. (Note that good security practices always negotiate AES at a higher priority than Triple-DES). In short, there is no need to turn off the use of Triple-DES in your application.

 

What If I Still Have Questions?

Please contact me. I am happy to be a resource to you.

BlogFooter_Mark

17 Jun 2016

Format-Preserving Encryption (FPE) in ‘FIPS Approved’ Mode

Vertical_Lock_ShortThe FIPS 140-2 Implementation Guidance (A.10) now includes vendor affirmation requirements for the format-preserving encryption schemes (FF1, FF3) specified in SP 800-38G.

As its name suggests, format-preserving encryption transforms plaintext to ciphertext of the same format and length. For example, format-preserving encryption may be used for a legacy application that needs to protect 16-digit credit card numbers and 9-digit social security numbers in a database without having to change their storage allocations. FPE has saved a lot of headaches in these use cases, as you can imagine.

For ‘FIPS Approved’ operation, until Cryptographic Algorithm Validation Program (CAVP) testing becomes available specifically for FPE, vendors will need to complete CAVP testing for the underlying AES algorithm, make documentation updates, and affirm compliance to SP 800-38G. Alternatively, SafeLogic can help you strategize and complete this process as easily as possible.

If you have a customer requirement to provide format-preserving encryption with FIPS 140-2 validation, then please contact us today.

BlogFooter_Mark

14 Jan 2016

The Transition Is Here: RNGs Disallowed in 2016

Question: I’m hearing rumors that my FIPS 140-2 cryptographic module will be moved to NIST’s Legacy Validation List on January 31, 2016.  Is this true?

Answer: The rumors are true for many organizations, unfortunately. If your cryptographic module contains any of the RNGs in FIPS 186-2, ANS X9.31, or ANS X.9.62-1998 on the “FIPS Approved algorithm” list, your certificate will be re-classified and moved to the Legacy Validation List unless it is reaffirmed otherwise.  In addition, certificates that have not been updated since 2011 or prior will be relegated to the Legacy List next year, as part of a five year rolling expiration.  More on that soon.

The bad news: Federal agencies have been instructed to strictly avoid products that have been moved to this Legacy Validation List. We know that DISA has already contacted technology vendors that are in danger of having their certificates moved to the Legacy Validation List. This is a demonstration of DISA’s attention to this issue – they plan to be extremely proactive and solutions that fall out of compliance will not be able to slide under the radar.  Every vendor with an RNG included on their FIPS certificate should immediately take action to keep their modules available for procurement.

NIST Special Publication 800-131A has been warning that these RNGs will be “disallowed” in 2016. The SP800-131A publication contains guidance for the use of stronger cryptographic keys and more robust algorithms. Concerns of increasing computing power and possible new attacks, the older RNGs have been dropped by the NIST Cryptographic Technology Group in favor of the newer SP800-90A DRBG algorithms: HASH_DRBG, HMAC_DRBG and CTR_DRBG. Since randomness in generating keying material is essential to strong cryptography, this is a proactive step by NIST to evolve to stronger security solutions for federal agencies.

The good news: SafeLogic customers will not be affected. Our clients will remain on NIST’s Active Validation Lists. Federal agencies will still be allowed to acquire products that are using SafeLogic’s cryptographic modules when enforcement begins on January 31, 2016, due to our strong support team and aggressive updates to ensure compliance.  SafeLogic’s dedication to certificate maintenance has saved our customers significant time, effort and heartache.  With NIST’s renewed commitment to keeping the validation list current, maintenance is more crucial than ever before.  Neglecting your certificate can quickly render obsolete the product of years of work and significant investment – and that’s never a good thing.

Whether you have questions about the RNG transition, want more information on SafeLogic’s drop-in FIPS solutions, or your current validation is being re-classified to the archive list, please contact us. SafeLogic can help!

Now that you know SafeLogic can take care of your FIPS cert, here’s some RNG humor to help dissipate that stress:

Classic Dilbert from 2001.

Classic Dilbert from 2001.

BlogFooter_Mark