FIPS 140-2 and Common Criteria industry updates (Nov. 2018)

FIPS 140-2

NIST ACVP System

On Dec. 4, 2018, NIST released a new iteration of the CMVP Implementation Guidance (IG) document. The announcement details can be found here and affect IG G.2, G.13, G.17, 1.21, 9.4, 9.11 and 14.5.

Additionally, NIST announced that there is progress being made with regards to the algorithm testing automation system(s). Chronologically:

• NIST will suspend current CAVP validations for the next week and will resume posting CAVP validations with a new system once released. NIST is (at least partially) automating the processing for the current “flow” for CAVP testing, where CAVS is used to produce req/sam files and the IUT produces rsp files.
• NIST will eventually (no date provided) release version 1.0 of a separate automation system described here which will replace the current CAVS system entirely. Once this is released, NIST is hoping to move away from CAVS over the span of 6 months.
• NIST will start charging fees for algorithm validations starting Oct. 1, 2019.

Please don’t hesitate to contact us at [email protected] if you have any questions or comments.

Implementation Guidance (IG) Updates

On Nov. 5, the CMVP provided the draft IGs for IG 9.4 and IG 9.11 along with combined Lab comments for each. Don’t hesitate to reach out to Leidos if you have any questions on the proposed updates to these IGs.

Additionally, the following changes will be made to the IG document:

• General: Changed all references of Communications Security Establishment (CSE) to Canadian Center for Cyber Security (CCCS).
• IG G.2 - Completion of a test report: Information that must be provided to NIST and CSE – Added acceptance of draft certificate submissions from the CST lab to the CMVP in the RTF format (but still recommending DOC or DOCX formatting).
• IG G.13 - Instructions for Validation Information Formatting – Added a certificate caveat example to Section 4 starting with “When installed, initialized and configured…”.  Also updated footnotes in Section 10 for clarity on CVL references and removed the text “allowed in approved mode” since it is already understood that these algorithms are allowed in FIPS mode. Additionally, corrected the Triple-DES example in Section 10 to reference an approved certificate. Finally, updated Section 8 to require the tested processor(s) within the Configuration field on the Certificate with examples.
• IG G.17 - Remote Testing for Software Modules – Updated Resolution bullet 2 to specify that cloud environments are prohibited specifically for 3rd party vendors where the lab does not have control of the environment for testing.
• IG 14.5 - Critical Security Parameters for the SP 800-90 DRBGs  – Removed Additional Comment #2 as “full entropy”, in this context, is an unreasonable expectation.
   

Leidos anticipates the CMVP publishing the aforementioned updates within the next couple of weeks.

Leidos experts are available to help with any questions or concerns regarding the industry updates mentioned above. Please contact us at [email protected] and we will be happy to assist.

Common Criteria

Leidos at International Common Criteria Conference (ICCC): Oct. 30 – Nov. 1

After a two-year hiatus, the International Common Criteria Conference (ICCC) returned this year. This year’s conference was held from 10/30 – 11/1 in Amsterdam. Participants by and large seem to be satisfied with the current international Technical Community approach to the creation and use of Protection Profiles. However, there are a number of key points moving forward that vendors and laboratories will need to be aware of to ensure that they understand the needs of government users, specifically:

• EU cybersecurity programs – the EU as a whole is becoming more involved with cybersecurity, rather than leaving it primarily to its constituent nations. The European Union Agency for Network and Information Security (ENISA) has a proposed framework for cybersecurity certification standards for its member states. Historically, Common Criteria has been used in various EU countries (e.g. through SOGIS for smart card validation) so any such framework would likely continue to use CC in some form.
• Emerging technologies – a continual complaint of CC has been the cost and time involved in completing evaluations. This has been offset to some extent for emerging technologies through the creation of Protection Profiles that allow for relatively fast evaluations at costs that make sense for the product; however, the standard currently has no good way of handling IoT devices. These devices are relatively inexpensive, come to market quickly, have fast product lifecycles, and have a relatively high security impact if compromised. Participants agreed that it is essential that if CC is to be used a method to evaluate IoT devices, then it is necessary to produce materials that allow for rapid and low-cost evaluations that focus a small number of high-impact threats. A six-month evaluation plus any necessary preparatory time is simply too much time for IoT device makers and users to see any real benefit from completing a certification, due to the rapid pace obsolescence with these technologies.

In addition to this, there was much discussion around the notion of expediting evaluations for vendors that have taken numerous products through the certification process already. Standards such as O-TTPS exist to ‘certify’ organizations and product lines, such that their products are automatically assumed to have some degree of security assurance, but adoption of this standard so far has been minimal. CC used to require evaluations of developer sites and development processes through ALC_DVS (previously done at EAL3 or higher), but this is not part of any published Protection Profile. Vendors who repeatedly evaluate the same products over and over again argue that after a certain point, it should be possible to trust their development processes since their development staff repeatedly demonstrate knowledge of the applicable CC requirements and regularly demonstrate conformance to them. As of right now, the only method of expediting re-testing is to re-use test plans and procedures, but this may still result in a labor-intensive evaluation process. Nothing was formally proposed or discussed, but this is going to be something worth paying attention to in the near future.

Overall, it was very encouraging to see that after two years of not having any worldwide conferences for the standard, that interest from all stakeholders still remained high.

Leidos experts are available to help with any questions or concerns regarding the industry updates mentioned above. Please contact us at [email protected] and we will be happy to assist.