Welcome to the Acumen Security Blog

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.

The Email Client EP

The email client extended package (EP) hasn’t received much attention since it came out. Originally released as a stand-alone protection profile (PP) in 2014, it was rewritten as an EP for the Application Software PP in 2015. At this point it has been out for over a year without any evaluations on the Product Compliant List (PCL) or in evaluation. For vendors who are considering an evaluation against this EP but who may have only a passing familiarity with Common Criteria some of its requirements may seem unusual. A closer look at the email EP’s more unique SFRs shows that they should not be unreasonably challenging to test and vendors with compliant products and a business case for certification should not be driven away by unfamiliar terminology.

An unusual threat that the email client EP addresses is that of bad third-party utilities or tools, which in the EP is called T.FLAWED_ADDON. This sounds like it may be a challenge to address, but the requirements of the security functional requirements (SFRs) associated with this threat are quite modest. FPT_AON_EXT.1 and .2 simply verify that if the TOE can use add-ons that those add-ons are authorized and digitally signed. One possible challenge is that one of the testing assurance activities associated with these SFRs is a test where an attempt is made to load add-ons that are modified and improperly signed. These tests would be easy to perform on an email client that runs on a standard desktop operating system. On a more restricted mobile operating system it may not be as straightforward to load a modified add on and carrying out these tests may require developer access.

Another unique SFR in the email client EP is FCS_SMIME_EXT.1. This is not something that’s frequently tested in US Common Criteria evaluations but the requirements of the SFR are fairly straightforward. The testing largely involves sending signed messages between clients, but does require the ability to perform man-in-the-middle attack on messages as they are being transmitted. This is the only SFR in the EP that requires packet modification capabilities.

A number of the email client EP’s other unique SFRs have only documentation based assurance activities. Others that have testing AAs only require an evaluator to use the product’s standard functionality that should be available to any user. FDP_NOT_EXT.1 (S/MIME status notification) can be tested entirely by sending different and receiving different types of emails.

Any client looking to evaluate a product against the email client EP would be well advised to first perform a proper gap analysis, however the EP’s requirements for both the vendor and the testing lab are relatively modest compared to those of the base PP that the EP adds on to.