Welcome to the Acumen Security Blog

Archives for October 2016

Version 1.2 of the Application PP

On October 25 version 1.1 of the Application Software Protection Profile (PP_APP) will sunset. It is being replaced with PP_APP version 1.2.

Like its predecessor PP_APP 1.2 is aimed at mobile, server and desktop application software. It is meant to be used in conjunction with Extended Packages (EPs) for more specialized applications. EPs that currently exist for this PP include the Redaction Tools EP, the SSH EP and the VoIP EP.

The changes to this version of the PP_APP are relatively modest. It has the same TOE boundary as previous versions, addresses the same use cases and includes the same threats, objectives and assumptions.

The mandatory cryptographic support (FCS) and security management (FMT) requirements have not been changed in this version of the PP. In the User Data Protection (FDP) requirements FDP_DEC_EXT.1.3 through 1.5 have been removed. What used to be FDP_DEC_EXT.1.4 is now a separate SFR named FDP_NET_EXT.1.1. FDP_DEC_EXT.1.3 and 1.5 which cover justification for accessing resources and protection of Personally Identifiable Information (PII) have been taken out completely. In addition, there have been some minor changes to the Android assurance activities for FDP_DEC_EXT.1.1 and 1.2. As in the previous version PP_APP 1.2 does not have any mandatory identification and authentication (FIA) SFRs.

To cover the PII related requirement that was removed from FDP this new PP adds a privacy related SFR named FPR_ANO_EXT.1. Even though the name and family of the SFR has changed the wording of the requirement and the related assurance activity have remained the same.

Mandatory requirements for the protection of the (FPT) have also remained the same in this PP update. In the trusted path/channel (FTP) requirements it is now permissible to use SSH to protect data in transit if the SSH EP is used as well. This is covered in FTP_DIT_EXT.1. The assurance activities for that SFR now also include more specific instructions for TOEs running on iOS and Android.

In its optional requirements the updated PP now includes an SFR for the generation of symmetric cryptographic keys. The purpose of this SFR is to support the generation of keys along a key chain. At this time the assurance activities for this SFR are purely documentation based, although it also relies on FCS_RBG_EXT.1. The other minor change to optional requirements has been to rename FCS_TLSC_EXT.1.4 which is the SFR for TLS mutual authentication to FCS_TLSC_EXT.2.1.

In the PP’s selection based requirements FCS_RBG_EXT.2.1 has been changed to remove support for FIPS 140-2 X9.31 random bit generation. The previous version of the PP had warned that these DRNGs would be disallowed after 2015 so this change should come as no surprise to developers.

FCS_COP.1.1(1) has been changed to make 256-bit keys mandatory while 128-bit keys are optional which is the opposite of the previous PP version. This was another change that old PP had said would be made in 2015. FCS_COP.1.1(2) has also removed SHA-1 as a mandatory hashing algorithm and made it an optional selection instead. In the TLS client requirements FCS_TLSC_EXT.1.5 has been renamed FCS_TLSC_EXT.4.1 even though the wording and assurance activities have remained the same.

One new capability that has been added to PP_APP 1.2 is TLS Server. The requirement says that it depends on a selection in FTP_DIT_EXT.1 however FTP_DIT contains no selection that requires FCS_TLSS. This was presumably an oversight on the part of the PP authors and will likely soon be corrected by a NIAP technical decision.

As we’ve shown the newest version of the PP_APP contains a number of changes but most of them are administrative in nature. The updates that have been made to bring it up to current cryptography standards were all described in the previous PP version. The only new capabilities that are covered are for SSH and TLS server, and those are both optional. Developers who have created products for previous versions of the PP_APP should have little difficulty meeting the standards of the updated protection profile.

RSA Key Generation and Common Criteria

Hi all! Does your application or HW product being considered for CC validation use the validated OpenSSL FOM for crypto? If so, you should pay close attention to a recent Technical Decision issued by NIAP (TD107). As many of you know, the open source validated version of the OpenSSL supports FIPS 186-2 Key Generation and not the more recent standard revision (FIPS 186-4). It is this functionality that the TD addresses. The following is an excerpt,

The referenced protection profiles (PPs) allow for the generation of asymmetric keys using RSA schemes that meet FIPS PUB 186-4, “Digital Signature Standard (DSS)”, Appendix B.3. or ANSI X9.31-1998, Section 4.1.

Up until this point many of the Protection Profiles have allowed for FIPS 186-4 Key Generation or ANSI X9.31 Key Generation (with the caveat that the older PRNG listed in ANSI X9.31 is not used for randomness). This is allowance is included in several PPs which are commonly evaluated against, including, Application Software PP, Mobile Device PP, OS PP, VP Client PP, and VoIP PP.

The TD goes on to modify the Key Generation requirement, as follows,

Effective immediately, RSA schemes using ANSI X9.31-1998, Section 4.1 is no longer a valid selection. NIAP will not accept products into evaluation that claim RSA schemes that meet ANSI X9.31-1998 Section 4.1

While for typical network devices being evaluated against the NDcPP this has been a hard requirement for some time, this is essentially a new requirement for software applications planning to go through certification. It is no longer possible to use the stock validated OpenSSL FOM to meet the crypto requirements in the PPs listed above.

Now there are several lightweight modifications you can make to the OpenSSL FOM code bring it into conformance with FIPS 186-4, however, as you likely know it will invalidate the previous FIPS certification for the OpenSSL module. I anticipate that this will be a problem for vendors hoping to meet their FIPS validated cryptography requirements leveraging the embedded OpenSSL module and going against any of these PP.

Please do keep this in mind when considering your upcoming certification efforts. As always, if you have any questions please give me a call or send me an email. I love to talk 