FIPS 140-2 and Common Criteria industry updates (March 2018)
In January 2018, the National Institute of Standards and Technology (NIST) announced three major FIPS 140-2 related transitions that require your attention. These transitions are already in progress or just around the corner, and they could have an impact on your current FIPS 140-2 certificate or future development planning to meet the standards. Here is a brief look:
December 31, 2017 (transition in progress) – Symmetric Key Wrapping Transition
With this transition, modules that implement formerly “allowed” AES or Triple-DES key wrapping schemes (i.e. ones that do not comply with SP800-38F and do not include authentication) will be marked as historical. As stated in NIST’s Dec. 20, 2017 announcement, vendors have until June 30, 2018 to submit a 1SUB change letter to address this transition and avoid being moved to the historical list.
Early 2018 – SP800-56A Diffie-Hellman Related Transition
With this transition, modules that implement formerly “allowed” Diffie-Hellman schemes (i.e. ones that do not comply with SP800-56A) will be transitioned. See NIST’s Oct. 31, 2017 announcement for more detail.
Summer of 2018 or later – SP800-56B RSA Key Wrapping Transition
With this transition, modules that implement formerly “allowed” RSA Key Wrapping schemes (i.e. ones that do not comply with SP800-56B) will be transitioned. See NIST’s Oct. 31, 2017 announcement for more detail.
In addition to these transitions, there was also a major announcement in early January regarding two processor-related exploits called “Meltdown” and “Spectre.” We strongly recommend you ensure that these exploits are mitigated in your products (i.e. there are Kernel patches for Meltdown and there are some mitigations available for Spectre, like the LLVM compiler patches).
Next, in February 2018, the NIST CMVP announced the release of two new draft implementation guides (IGs) which we've summarized below:
May 31, 2019 – Draft IG D.9 (high impact)
Transition date was added to this Draft IG which marks non-SP-800-38F compliant symmetric key unwrapping as non-approved. Note that non-SP-800-38F compliant symmetric key wrapping is already considered non-approved, and that this is just transitioning out unwrapping as well. Draft IG document can be provided upon request.
Date TBD – Draft IG G.X (low impact)
This new IG is informational and provides a detailed explanation and definition of what exactly a “Cryptographic Module” is. This IG does not impose or introduce any new requirements, but is rather just an explanatory piece. Draft IG document can be provided upon request.
Meanwhile on the NIAP Common Criteria side, two major announcements were made this year:
NIAP Director Janine Pederson announced that she would be leaving her position, with her last day being March 2, 2018. Mary Baish, who was serving as her deputy, would be stepping in as NIAP's new director. Baish is well known within the industry for being technically savvy with her prominence beginning while she was a member of the Information Assurance Directorate (IAD). Baish was the sole responsible party for leading NIAP’s odyssey of entropy NIST SP800-90b. She was the primary approver of all NIAP entropy submissions.
In response to the Intel Spectre/Meltdown vulnerability, NIAP has made efforts to expunge Spectre/Meltdown products from its Product Compliant List (PCL). Leidos Common Criteria Testing Lab provided the following guidance to all affected vendors:
As instructed by NIAP, the vendor must inform NIAP of their intentions to submit an IAR highlighting no known vulnerabilities of the version of the product that was pulled from the PCL no later than March 9. Albeit not required, Leidos recommends the vendor cc Leidos POC’s on their March 9 response. The IAR itself then must be authored (https://www.niap-ccevs.org/Documents_and_Guidance/ccevs/scheme-pub-6.pdf). Specific to NIAP's request, a vulnerability analysis must be conducted of the product covering the timeframe from original certification to now. This needs to be articulated clearly in the IAR report and all discovered vulnerabilities must have administrative or technical mitigations detailed. If no such fix clearly exists, then “regression testing” may be required to provide assurance that any such discovered vulnerability is of non-issue.
Please note that there’s no requirement that an accredited lab conduct the efforts of the IAR and, as such, the vendor maintains the decision of where the IAR is developed. Leidos will happily clarify any aspects of aforementioned statement and can conduct the activities of the IAR for a nominal fee.
Leidos experts are available to help with any questions or concerns regarding any of the transitions/new IGs, NIAP and/or International Evaluation Assurance Level (EAL) certification options. Please contact us at [email protected] and we will be happy to assist.