Search

Breadcrumb

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

FIPS 140-2

Earlier this month, Leidos Crypto Technical Management was in attendance for the Lab Manager’s meeting and ICMC 2018 conference in Ottawa. Below is the most important information we gleaned from the LMM and ICMC conference with regards to the CMVP’s upcoming plans:

The CMVP stated they are committed to signing FIPS 140-3 by October 1, 2018. However, considering that FIPS 140-3 has been talked about as being “on the horizon” for the past 10 years, Leidos is skeptical of this date commitment.

The CMVP may add REST APIs to the CMVP sites in the future to help with automation scripts. There was no timeline or commitment provided for this potential change.

There will likely be an annual subscription fee for clients to use the ACVP

In order to obtain validations through the ACVP all clients will need to have an NVLAP accreditation. Clients could include both labs and vendors.

The CMVP mentioned that they may someday move to a system where there will be a fixed time period (say 2 years) after receiving a CMVP certificate where a vendor can make free updates (i.e. 1SUBs & 3SUBs) to their product regardless of security-relevance. Beyond that, however, any changes to the code will be treated as a 3SUB regardless of the extent of the changes and will incur a fee. There was no timeline or commitment provided for this potential change.

The CMVP discussed that there will be a new accreditation program for entropy sources and that ultimately vendors will be able to obtain entropy validation certificates that will be able to be listed as an “Approved” algorithm (as opposed to being listed as an “Allowed” algorithm as they are now under the current guidance). The new accreditation program will be in order to demonstrate compliance to SP800-90B and ultimately all entropy sources will need to be certified. No hard timelines or commitments were provided for this change.

The CMVP expressed that Triple-DES is being transitioned away from entirely with the following tentative schedule:

December 31, 2020 - Triple-DES can only be used in new applications when they're interacting with older applications

December 31, 2025 - Triple-DES cannot be used for encryption, decryption only for legacy use

The CMVP encourages participation in the CMUF by both vendors and labs. Right now there are many topics being discussed such as how cloud validations might work and also defining processor equivalency.

The CMVP stated that they will be publishing an update to FIPS 186 (FIPS 186-5) “very soon” and that it will include EdDSA as defined in RFC 8032 and deterministic ECDSA as defined in RFC 6979.

The CMVP stated that they will be publishing a special publication SP800-186 “very soon” and that it will list all recommended elliptic curves (which will include curve25519 and curve448)

The CMVP discussed that there are two currently-active competitions going on:

Common Criteria

Use of RSA in TLS Cipher Suites:

This LabGram/ValGram notified that, effective 1 January 2018, any TLS ciphersuite with RSA key agreement/key transport (i.e., any TLS ciphersuite commencing with “TLS_RSA_”) would no longer be acceptable for use within National Security Systems. Therefore:

NIAP would no longer post products to the PCL that used these ciphersuites.

NIAP would notify vendors with products on the PCL that Assurance Maintenance would require, prior to the effective date, to maintain PCL listing.

Any product listed on the PCL on 1 January 2018 that used only these ciphersuites would be archived.

Use of RSA in TLS Cipher Suites (Impact):

It might be argued that NIST had provided ample notification of the pending deprecation of “TLS_RSA_” ciphersuites. However, NIAP’s LabGram caught most, if not all, CCTLs and vendors by surprise. Given that NIAP published Protection Profiles in 2017 (e.g., Certification Authorities, Mobile Device Fundamentals) that still allowed and even required “TLS_RSA_” cipher suites, it appears that the effect of SP 800-131A on TLS cipher suites was an unintended consequence.

NIST announced on September 27 that it would not be enforcing SP 800-131A compliance until planned revisions to SP 800-56A and SP 800-56B had been completed and published. The same day, NIAP informally advised it would withdraw LabGram #106 and that no products would be archived. NIAP formally rescinded LabGram #106 on October 31.

Use of RSA in TLS Cipher Suites (Future Developments):

On October 31, 2017, NIST published “Transition Plans for Key Establishment Schemes using Public Key Cryptography” (https://csrc.nist.gov/News/2017/Transition-Plans-for-Key-Establishment-Schemes). This announcement identifies that widely-used applications and protocols, including TLS 1.2, use key establishment schemes that are not covered by the SP 800-56 series of publications. In the specific case of RSA and the use of PKCS#1 v1.5 padding, NIST solicited input from implementers, users and security researchers on whether to continue to allow RSA PKCS#1 v1.5 encryption as a deprecated scheme in certain protocols. The deadline for comments was December 15, 2017, and comments received will be considered as part of the upcoming revision of SP 800-56B. NIST initially expected to release a draft of SP 800-56B Rev. 2 in the summer of 2018, but NIST recently indicated “before the end of 2018”.

Leidos now understands that non-compliant RSA-based key establishment schemes will not be allowed after 2019. As such, NIAP can be expected to issue a policy similar to LabGram #106 sometime after formal publication of SP 800-56B. If this occurs, products including implementations of TLS will be required to support TLS cipher suites using Diffie-Hellman or Elliptic Curve Diffie-Hellman for key agreement/key transport and to provide a means to disable “TLS_RSA_” ciphersuites if the product continues to support them.

NDcPP Technical Decisions:

NIAP has just published the following Technical Decisions (TDs), all applicable to the Network Device collaborative Protection Profile (NDcPP). TD0321 additionally applies to the Firewall cPP. These TDs apply immediately to any product evaluation that has not yet entered the Check-out phase with NIAP.

TD0321 Protection of NTP communications: requires that when an NTP server is used to set the TOE clock, the communication channel between the NTP server and TOE must be protected in accordance with FTP_ITC.1. This TD is interesting, because it appears, based on the first paragraph in the resolution, that this is a NIAP decision and not based on a TRRT query submitted to NIAP or the international Technical Community.

TD0322 NIT Technical Decision for TLS server testing - Empty Certificate Authorities list: this TD supersedes TD0262. It replaces Test 4 for FCS_TLSS_EXT.2.4 and FCS_TLSS_EXT.2.5. Evaluations that have completed this test need to review the TD and determine if the testing already conducted is still applicable or needs to be redone.

TD0323 NIT Technical Decision for DTLS server testing - Empty Certificate Authorities list: similar effect to TD0322. We are not aware of any ND cPP evaluations that are claiming DTLS, so this should have no immediate impact.

TD0324 NIT Technical Decision for Correction of section numbers in SD Table 1: This is a bookkeeping exercise for the Supporting Document and does not affect the content of the Security Target or the conduct of an evaluation.

Application Software PP Technical Decisions:

NIAP has issued TD0326 RSA-based key establishment schemes, applicable to the App SW PP. It supersedes TD0293. It makes the following changes to SFRs in the current v1.2 of the App SW PP:

FCS_CKM.1(1): ST author can specify if asymmetric key generation is implemented by the TOE or if the TOE invokes platform-provided functionality; selection of ANSI X9.31 as a standard for RSA key generation has been removed – only FIPS 186-4 is now supported [Note, these changes are essentially what was specified in TD0293].

FCS_CKM.2.1: RSA is now made a selectable key establishment scheme, which is consistent with changes to TLS SFRs that no longer mandate support for a TLS_RSA_* ciphersuite.

FCS_TLSS_EXT.1.3: Use of RSA for generation of key establishment parameters is now made a selection, consistent with FCS_TLSS_EXT.1.1 and the modification to FCS_CKM.2.1 discussed above.

These changes are potentially applicable to STs for products currently in evaluation against the App SW PP that have not yet reached the Check-out phase. There are no changes to assurance activities, so no changes should be necessary to AAR or Test reports.

Leidos experts are available to help with any questions or concerns regarding the updates mentioned above. Please contact us at ATE@leidos.com and we will be happy to assist.