|v .1||2014-01-08||Initial draft commit|
|v .6||2014-03-14||Attractive presentation achieved|
|v .7||2014-08-08||First round of Technical Community feedback incorporated|
|v .8||2014-08-21||Second round of Technical Community feedback incorporated|
|v .9||2014-09-12||Third round of Technical Community feedback incorporated|
|v .9||2014-10-20||Fourth round of Technical Community feedback incorporated|
|v 1.0||2014-10-20||Initial release|
|v 1.1||2014-11-05||Addition to TLS cipher suite selections|
|v 1.2||2016-04-22||Added server-side TLS requirements (selection-based)
Multiple clarification based on NIAP TRRT inquiries
Refactored FDP_DEC_EXT.1 into separate components
|v 1.3||2019-03-01||Incorporated available TDs
Added a selection to FTP_DIT
Moved SWID Tags requirement
Incorporated TLS Package
Added equivalency section
|Common Criteria (CC)||Common Criteria for Information Technology Security Evaluation.|
|Common Evaluation Methodology (CEM)||Common Evaluation Methodology for Information Technology Security Evaluation.|
|Extended Package (EP)||An implementation-independent set of security requirements for a category of products, which extends those in a Protection Profile.|
|Protection Profile (PP)||An implementation-independent set of security requirements for a category of products.|
|Protection Profile Module (PP-Module)||An implementation-independent statement of security needs for a TOE type complementary to one or more Base Protection Profiles.|
|Security Target (ST)||A set of implementation-dependent security requirements for a specific product.|
|Target of Evaluation (TOE)||The product under evaluation. In this case, application software and its supporting documentation.|
|TOE Security Functionality (TSF)||The security functionality of the product under evaluation.|
|TOE Summary Specification (TSS)||A description of how a TOE satisfies the SFRs in a ST.|
|Security Functional Requirement (SFR)||A requirement for security enforcement by the TOE.|
|Security Assurance Requirement (SAR)||A requirement to assure the security of the TOE.|
|Address Space Layout Randomization (ASLR)||An anti-exploitation feature which loads memory mappings into unpredictable locations. ASLR makes it more difficult for an attacker to redirect control to code that they have introduced into the address space of an application process.|
|Application (app)||Software that runs on a platform and performs tasks on behalf of the user or owner of the platform, as well as its supporting documentation. The terms TOE and application are interchangeable in this document.|
|Application Programming Interface (API)||A specification of routines, data structures, object classes, and variables that allows an application to make use of services provided by another software component, such as a library. APIs are often provided for a set of libraries included with the platform.|
|Credential||Data that establishes the identity of a user, e.g. a cryptographic key or password.|
|Data Execution Prevention (DEP)||An anti-exploitation feature of modern operating systems executing on modern computer hardware, which enforces a non-execute permission on pages of memory. DEP prevents pages of memory from containing both data and instructions, which makes it more difficult for an attacker to introduce and execute code.|
|Developer||An entity that writes application software. For the purposes of this document, vendors and developers are the same.|
|Operating System (OS)||Software that manages hardware resources and provides services for applications.|
|Personally Identifiable Information (PII)||Any information about an individual maintained by an agency, including, but not limited to, education, financial transactions, medical history, and criminal or employment history and information which can be used to distinguish or trace an individual's identity, such as their name, social security number, date and place of birth, mother’s maiden name, biometric records, etc., including any other personal information which is linked or linkable to an individual. [OMB]|
|Platform||The environment in which application software runs. The platform can be an operating system, hardware environment, a software based execution environment, or some combination of these. These types platforms may also run atop other platforms.|
|Sensitive Data||Sensitive data may include all user or enterprise data or may be specific application data such as emails, messaging, documents, calendar items, and contacts. Sensitive data must minimally include PII, credentials, and keys. Sensitive data shall be identified in the application’s TSS by the ST author.|
|Stack Cookie||An anti-exploitation feature that places a value on the stack at the start of a function call, and checks that the value is the same at the end of the function call. This is also referred to as Stack Guard, or Stack Canaries.|
|Vendor||An entity that sells application software. For purposes of this document, vendors and developers are the same. Vendors are responsible for maintaining and updating application software.|
The requirements in this document apply to application software which runs on any type of platform. Some application types are covered by more specific PPs, which may be expressed as PP-Modules of this PP. Such applications are subject to the requirements of both this PP and the PP-Module that addresses their special functionality. PPs for some particularly specialized applications may not be expressed as PP-Modules at this time, though the requirements in this document should be seen as objectives for those highly specialized applications.
Although the requirements in this document apply to a wide range of application software, consult guidance from the relevant national schemes to determine when formal Common Criteria evaluation is expected for a particular type of application. This may vary depending upon the nature of the security functionality of the application.
The application, which consists of the software provided by its vendor, is installed onto the platform(s) it operates on. It executes on the platform, which may be an operating system (Figure 1), hardware environment, a software based execution environment, or some combination of these (Figure 2). Those platforms may themselves run within other environments, such as virtual machines or operating systems, that completely abstract away the underlying hardware from the application. The TOE is not accountable for security functionality that is implemented by platform layers that are abstracted away. Some evaluation activities are specific to the particular platform on which the application runs, in order to provide precision and repeatability. The only platforms currently recognized by the AppPP are those specified in SFR Evaluation Activities. To test on a platform for which there are no EAs, a Vendor should contact NIAP with recommended EAs. NIAP will determine if the proposed platform is appropriate for the PP and accept, reject, or develop EAs as necessary in coordination with the technical community.
Applications include a diverse range of software such as office suites, thin clients, PDF readers, downloadable smartphone apps, and apps running in a cloud container. The TOE includes any software in the application installation package, even those pieces that may extend or modify the functionality of the underlying platform, such as kernel drivers. Many platforms come bundled with applications such as web browsers, email clients and media players and these too should be considered subject to the requirements defined in this document although the expectation of formal Common Criteria evaluation depends upon the national scheme. BIOS and other firmware, the operating system kernel, and other systems software (and drivers) provided as part of the platform are outside the scope of this document.
If use no DRBG functionality is selected, the evaluator shall inspect the application and its developer documentation and verify that the application needs no random bit generation services.
If invoke platform-provided DRBG functionality is selected, the evaluator
performs the following activities. The evaluator shall examine
the TSS to confirm that it identifies all functions (as described by the
SFRs included in the ST) that obtain random numbers from the platform RBG. The evaluator
shall determine that for each of these functions, the TSS states which
platform interface (API) is used to obtain the random numbers. The evaluator shall confirm
that each of these interfaces corresponds to the acceptable interfaces listed for each platform
It should be noted that there is no expectation that the evaluators attempt to confirm that the APIs are being used correctly for the functions identified in the TSS; the activity is to list the used APIs and then do an existence check via decompilation.
javax.crypto.KeyGeneratorclass or the
/dev/randomdirectly to acquire random.
KeyStoreor the Android
KeyChainto store certificates.
Key Management Framework (KMF).
PreferenceActivityclasses for storing configuration data, where package is the Java package of the application.
user defaults systemor
key-value storefor storing all settings.
ls -alR|grep -E '^........w.'inside the application's data directories to ensure that all files are not world-writable. The command should not print any files. The evaluator shall also verify that no sensitive data is written to external storage which could be read/modified by any application containing the READ_EXTERNAL_STORAGE and/or WRITE_EXTERNAL_STORAGE permissions.
find . -perm /002inside the application's data directories to ensure that all files are not world-writable. The command should not print any files.
find . \( -perm -002 \)inside the application's data directories to ensure that all files are not world-writable. The command should not print any files.
find . -perm +002inside the application's data directories to ensure that all files are not world-writable. The command should not print any files.
pmap -x PIDto ensure the two different instances share no mapping locations.
pmap -x PIDto ensure the two different instances share no mapping locations.
vmmap PIDto ensure the two different instances share no mapping locations.
/NXCOMPATflag was used during compilation to verify that DEP protections are enabled for the application.
|mov rcx, QWORD PTR [rsp+(...)]|
|xor rcx, (...)|
Tools such as Canary Detector may help automate these activities.
If encrypt all transmitted is selected and HTTPS is selected, FCS_HTTPS_EXT.1 is required.
If encrypt all transmitted is selected and DTLS is selected, FCS_DTLS_EXT.1 is required.
If encrypt all transmitted is selected and SSH is selected, the TSF shall be validated against the Extended Package for Secure Shell.
If encrypt all transmitted is selected the corresponding FCS_COP.1 requirements will be included.
If the application invokes platform-provided functionality for asymmetric key generation, then the evaluator shall examine the TSS to verify that it describes how the key generation functionality is invoked.
If possible, the Random Probable primes method should also be verified against a known good implementation as described above. Otherwise, the evaluator shall have the TSF generate 10 keys pairs for each supported key length nlen and verify:
FIPS 186-4 Public Key Verification (PKV) Test For each supported NIST curve, i.e., P-256, P-384 and P-521, the evaluator shall generate 10 private/public key pairs using the key generation function of a known good implementation and modify five of the public key values so that they are incorrect, leaving five values unchanged (i.e., correct). The evaluator shall obtain in response a set of 10 PASS/FAIL values.
Key Generation for Finite-Field Cryptography (FFC)The evaluator shall verify the implementation of the Parameters Generation and the Key Generation for FFC by the TOE using the Parameter Generation and Key Generation test. This test verifies the ability of the TSF to correctly produce values for the field prime p, the cryptographic prime q (dividing p-1), the cryptographic group generator g, and the calculation of the private key x and public key y. The Parameter generation specifies 2 ways (or methods) to generate the cryptographic prime q and the field prime p:
Cryptographic and Field Primes:
# Input: PT, IV, Key for i = 1 to 1000: if i == 1: CT = AES-CBC-Encrypt(Key, IV, PT) PT = IV else: CT[i] = AES-CBC-Encrypt(Key, PT) PT = CT[i-1]The ciphertext computed in the 1000th iteration (i.e., CT) is the result for that trial. This result shall be compared to the result of running 1000 iterations with the same values using a known good implementation.
RPMformat. Applications running on Debian and Debian derivatives shall be packaged in
|PP-Specified Functionality||Same||If the differences between Models affect only non-PP-specified functionality, then the Models are equivalent.|
|Different||If PP-specified security functionality is affected by the differences between Models, then the Models are not equivalent and must be tested separately. It is necessary only to test the functionality affected by the software differences. If only differences are tested, then the differences must be enumerated, and for each difference the Vendor must provide an explanation of why each difference does or does not affect PP-specified functionality. If the Product Models are separately tested fully, then there is no need to document the differences.|
|Product Models||Different||Versions of different Product Models are not equivalent unless the Models are equivalent as defined in Section 3.|
|PP-Specified Functionality||Same||If the differences affect only non-PP-specified functionality, then the Versions are equivalent.|
|Different||If PP-specified security functionality is affected by the differences, then the Versions are not considered equivalent and must be tested separately. It is necessary only to test the functionality affected by the changes. If only the differences are tested, then for each difference the Vendor must provide an explanation of why the difference does or does not affect PP-specified functionality. If the Product Versions are separately tested fully, then there is no need to document the differences.|
|Platform Architectures||Different||Platforms that present different processor architectures and instruction sets to the application are not equivalent.|
|PP-Specified Functionality||Same||For platforms with the same processor architecture, the platforms are equivalent with respect to the application if execution of all PP-specified security functionality follows the same code path on both platforms.|
|Platform Architectures||Different||Platforms that run on different processor architectures and instruction sets are not equivalent.|
|Platform Vendors||Different||Platforms from different vendors are not equivalent.|
|Platform Versions||Different||Platforms from the same vendor with different major version numbers are not equivalent.|
|Platform Interfaces||Different||Platforms from the same vendor and major version are not equivalent if there are differences in device interfaces and OS APIs that are relevant to the way the platform provides PP-specified security functionality to the application.|
|Platform Interfaces||Same||Platforms from the same vendor and major version are equivalent if there are no differences in device interfaces and OS APIs that are relevant to the way the platform provides PP-specified security functionality to the application, or if the Platform does not provide such functionality to the application.|
|Platform Type/Vendor||Different||Software-based execution environments that are substantially different or come from different vendors are not equivalent. For example, a java virtual machine is not the same as a container. A Docker container is not the same as a CoreOS container.|
|Platform Versions||Different||Execution environments that are otherwise equivalent are not equivalent if they have different major version numbers.|
|PP-Specified Security Functionality||Same||All other things being equal, execution environments are equivalent if there is no significant difference in the interfaces through which the environments provide PP-specified security functionality to applications.|
|[CC]||Common Criteria for Information Technology Security Evaluation -|
|[CC]||Common Criteria for Information Technology Security Evaluation -|
|[CEM]||Common Evaluation Methodology for Information Technology Security - Evaluation Methodology, CCMB-2017-04-004, Version 3.1, Revision 5, April 2017.|
|[OMB]||Reporting Incidents Involving Personally Identifiable Information and Incorporating the Cost for Security in Agency Information Technology Investments, OMB M-06-19, July 12, 2006.|
|ADB||Android Debug Bridge|
|AES||Advanced Encryption Standard|
|ANSI||American National Standards Institute|
|API||Application Programming Interface|
|APK||Android Application Package|
|APPX||Windows Universal Application Package|
|ASLR||Address Space Layout Randomization|
|BIOS||Basic Input/Output System|
|CMC||Certificate Management over CMS|
|CMS||Cryptographic Message Syntax|
|CRL||Certificate Revocation List|
|CSA||Computer Security Act|
|DEP||Data Execution Prevention|
|DES||Data Encryption Standard|
|DMG||Apple Disk Image|
|DNS||Domain Name System|
|DPAPI||Data Protection Application Programming Interface|
|DRBG||Deterministic Random Bit Generator|
|DSS||Digital Signature Standard|
|DTLS||Datagram Transport Layer Security|
|EAP||Extensible Authentication Protocol|
|ECDHE||Elliptic Curve Diffie-Hellman Ephemeral|
|ECDSA||Elliptic Curve Digital Signature Algorithm|
|EMET||Enhanced Mitigation Experience Toolkit|
|EST||Enrollment over Secure Transport|
|FIPS||Federal Information Processing Standards|
|DSS||Digital Signature Standard|
|ELF||Executable and Linkable Format|
|GPS||Global Positioning System|
|HMAC||Hash-based Message Authentication Code|
|HTTP||Hypertext Transfer Protocol|
|HTTPS||Hypertext Transfer Protocol Secure|
|IANA||Internet Assigned Number Authority|
|IEC||International Electrotechnical Commission|
|IETF||Internet Engineering Task Force|
|IPA||iOS Package archive|
|ISO||International Organization for Standardization|
|ITSEF||Information Technology Security Evaluation Facility|
|JNI||Java Native Interface|
|LDAP||Lightweight Directory Access Protocol|
|MIME||Multi-purpose Internet Mail Extensions|
|NFC||Near Field Communication|
|NIAP||National Information Assurance Partnership|
|NIST||National Institute of Standards and Technology|
|OCSP||Online Certificate Status Protocol|
|OMB||Office of Management and Budget|
|Portable Document Format|
|PII||Personally Identifiable Information|
|PKI||Public Key Infrastructure|
|RBG||Random Bit Generator|
|RFC||Request for Comment|
|RNG||Random Number Generator|
|RNGVS||Random Number Generator Validation System|
|SAN||Subject Alternative Name|
|SAR||Security Assurance Requirement|
|SFR||Security Functional Requirement|
|SHA||Secure Hash Algorithm|
|S/MIME||Secure/Multi-purpose Internet Mail Extensions|
|SIP||Session Initiation Protocol|
|TLS||Transport Layer Security|
|URI||Uniform Resource Identifier|
|URL||Uniform Resource Locator|
|USB||Universal Serial Bus|
|XCCDF||eXtensible Configuration Checklist Description Format|