FIPS 140-2 and Common Criteria industry updates (April 2018)
On April 17, 2018, The National Institute of Standards and Technology (NIST) announced the release of updated versions of SP800-56A (Revision 3) and SP800-56C (Revision 1).
Although the CMVP may not enforce compliance with SP800-56A until SP800-186 has been published to formally approve the ECC curves from RFC 7748, now is the time to review any (EC) Diffie-Hellman or MQV schemes used by your products to assure that they’re compliant once enforcement begins in the near future.
The publications can be found here:
SP800-56A is the NIST publication that defines (EC) Diffie-Hellman and MQV based key agreement schemes. Below please find some noteworthy updates:
- Added FIPS 202 (SHA-3) and KMAC (a SHA-3-based MAC) to the publication as Approved hash functions and MAC algorithms
- New FFC groups are now Approved for usage (i.e. “safe primes”: IKE MODP groups from RFC 3526, TLS groups from RFC 7919)
- Approved ECC curves are still just listed as the NIST curves, but changes have been made to reference a currently-non-existent SP800-186 publication which will ultimately mark additional common curves as “Approved”.
- This will include Curve25519 and Curve448 according to NIST’s previous notice
- Key derivation methods have been moved out of SP800-56A and into SP800-56C, making the publications more modular
SP800-56C is the NIST publication that now defines Key Derivation Methods for Key Establishment Schemes (i.e.: SP800-56A / SP800-56B). Below please find some noteworthy updates:
- SP800-56C now includes the one-step key derivation functions that formerly only appeared in SP800-56A and SP800-56B
- The parameter sets from SP800-56A and SP800-56B are no longer referenced in SP800-56C, but rather now the publication is written in terms of supported security strengths to make it more generally applicable
- KMAC (a SHA-3-based MAC) is now listed as an Approved function for one-step key derivation
Leidos experts are available to help with any questions or concerns regarding the new Special Publication updates. Please contact us at [email protected] and we will be happy to assist. Additionally, if you are planning to attend the ICMC conference in May, please stop by and say hi to Leidos CSTL Lab Manager Jason Tseng and Leidos CSTL Technical Director Mike Powers.
Over the past couple of months, a few key Protection Profiles have been updated and/or are in development for their next release. See Leidos’ high level overview below.
Network Device collaborative Protection Profile (NDcPP) and Firewall collaborative Protection Profile (FWcPP) Errata:
On March 14, NIAP issued errata to the collaborative Protection Profiles for Network Devices (NDcPP) and Stateful Traffic Filter Firewalls (FWcPP). These updated PPs went into effect immediately, so it’s critical for vendors, laboratories, and users to be aware of the changes so that they are not caught off guard when planning an evaluation. The updated PPs now incorporate the following changes:
- Use of the assignment convention in the functional requirements was updated to ensure that it is applied correctly in all cases. FCS_CKM.1.1, FCS_CKM.2.1, and FAU_STG_EXT.1.3 have all been updated to be written properly. This is not a technical change but it is something that ST authors should be aware of.
- Use of the selection convention in the functional requirements was updated to ensure that it is applied correctly in all cases. The conventions themselves were updated to be less ambiguous, and the entire SFR sections have been reviewed to ensure that these conventions are consistently applied. This also involved resolving discrepancies between the SFRs and their associated extended component definitions.
- Application notes for FCS_DTLS_EXT.2.6 and FCS_DTLSS_EXT.1.5 both suggest that a MAC must be used for integrity purposes. This is inconsistent with the list of supported ciphersuites, which include some that use AES-GCM for the same purpose. Vendors should be aware that AES-GCM is in fact permitted for this.
- Some TLS client test Evaluation Activities state that TLS server testing can be used to satisfy the requirement, which is inconsistent with the intent of the testing. These statements have been removed so that the client tests must be completed as written. It is likely that this was already being done correctly by most laboratories, but clarifying this will now make sure that this is the case.
- TLS server requirements previously mandated the use of 2048-bit Diffie-Hellman parameters, with 3072-bit parameters being an optional selection. There is no reason that the smaller size must always be supported if the larger size is also supported, so this requirement was updated to make this selectable.
- FCS_IPSEC_EXT.1.10 no longer requires the nonce length to be specified if it is tied to the security strength of the negotiated Diffie-Hellman group. This is because the TOE will not know the specific DH group that will be negotiated at the time the nonce is generated.
- The glossary has been updated to remove terms that do not appear elsewhere in the PP (e.g., “key chaining”).
- The T.SECURITY_FUNCTIONALITY_FAILURE threat was not correctly written in terms of an agent, asset, and adverse action, as required by the CC. The wording of the threat has been updated to meet this requirement while still conveying the same intent.
Overall, Leidos considers these changes to be of minor impact, but it’s important to ensure that Security Targets take these changes into consideration to ensure that the NIAP review process goes as quickly as possible.
New Version of (Peripheral Sharing Switch Protection Profile (PSS PP) Nearing Completion:
The Peripheral Sharing Switch (PP) PP will soon be getting its first major update in over three years. The new PP, which will now refer to the technology as “Peripheral Sharing Device,” is being changed more from an organizational standpoint than a functional one. Essentially the same threat model will be applied in the new PP, but there are some key differences that users should be aware of:
- New layout: the current PSS PP (version 3.0) is written as a single PP where users pick and choose the types of peripherals their product supports and follows a relatively confusing list of conditional tests, depending what is and isn’t supported. The new PP makes use of the “Modular PP” concept introduced last year in CC 3.1 Revision 5 to clean this up. In the new PP, there will be a single “Base-PP” that defines functionality that will be common to all Peripheral Sharing Devices (such as self-tests, physical protection, and channel isolation), and the multiple “PP-Modules” for each supported peripheral type (keyboard/mouse, video/display, audio in, audio out, and USB authentication device). These PP-Modules define requirements and Assurance Activities that are unique to each peripheral type so that each supported peripheral type can be included or excluded from the evaluation on an individual basis.
- New requirements: the current PSS PP has a number of requirements that users have found to be ambiguous. The updated PP and PP-Modules are expected to take most of the same functionality and define it more clearly as extended requirements to make the expectations of the PP more straightforward. In addition to that, the current PSS PP has several Assurance Activities that do not correspond to functionality listed in the functional requirements. These inconsistencies should be resolved in the new version.
- New Assurance Activities: in some cases, it was determined that the Assurance Activities in the current PSS PP do not fully satisfy the objectives that they are expected to satisfy. Some additional tests have been developed collaboratively by the PSS Technical Community to ensure better coverage of these areas while still keeping the overall test level of effort reasonable.
Overall, the new PP is expected to take a lot of lessons learned by the vendors, laboratories, and NIAP, and incorporate them into a more straightforward and understandable set of documentation.
Leidos experts are available to help with any questions or concerns regarding the new/updated Protection Profiles. Please contact us at [email protected] and we will be happy to assist.