Version | Date | Comment |
---|---|---|
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 Technical Decisions
Refactored FPT_TUD Added a selection to FTP_DIT Moved SWID Tags requirement Leveraged TLS Package Added equivalency section |
v 1.4 | 2021-10-07 | Incorporated applicable Technical Decisions
Updated to TLS FP 1.1 Incorporated SSH FP 1.0 |
Assurance | Grounds for confidence that a TOE meets the SFRs [CC]. |
Base Protection Profile (Base-PP) | Protection Profile used as a basis to build a PP-Configuration. |
Collaborative Protection Profile (cPP) | A Protection Profile developed by international technical communities and approved by multiple schemes |
Common Criteria (CC) | Common Criteria for Information Technology Security Evaluation (International Standard ISO/IEC 15408). |
Common Criteria Testing Laboratory | Within the context of the Common Criteria Evaluation and Validation Scheme (CCEVS), an IT security evaluation facility, accredited by the National Voluntary Laboratory Accreditation Program (NVLAP) and approved by the NIAP Validation Body to conduct Common Criteria-based evaluations. |
Common Evaluation Methodology (CEM) | Common Evaluation Methodology for Information Technology Security Evaluation. |
Distributed TOE | A TOE composed of multiple components operating as a logical whole. |
Operational Environment (OE) | Hardware and software that are outside the TOE boundary that support the TOE functionality and security policy. |
Protection Profile (PP) | An implementation-independent set of security requirements for a category of products. |
Protection Profile Configuration (PP-Configuration) | A comprehensive set of security requirements for a product type that consists of at least one Base-PP and at least one PP-Module. |
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 Assurance Requirement (SAR) | A requirement to assure the security of the TOE. |
Security Functional Requirement (SFR) | A requirement for security enforcement by the TOE. |
Security Target (ST) | A set of implementation-dependent security requirements for a specific product. |
The security functionality of the product under evaluation. | |
A description of how a TOE satisfies the SFRs in an ST. | |
Target of Evaluation (TOE) | The product under evaluation. |
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. |
Mobile Code | Software transmitted from a remote system for execution within a limited execution environment on the local system. Typically, there is no persistent installation and execution begins without the user's consent or even notification. Examples of mobile code technologies include JavaScript, Java applets, Adobe Flash, and Microsoft Silverlight. |
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. |
Threat, Assumption, or OSP | Security Objectives | Rationale |
T.NETWORK_ATTACK | O.PROTECTED_COMMS | The threat T.NETWORK_ATTACK is countered by O.PROTECTED_COMMS as this provides for integrity of transmitted data. |
O.INTEGRITY | The threat T.NETWORK_ATTACK is countered by O.INTEGRITY as this provides for integrity of software that is installed onto the system from the network. | |
O.MANAGEMENT | The threat T.NETWORK_ATTACK is countered by O.MANAGEMENT as this provides for the ability to configure the application to defend against network attack. | |
T.NETWORK_EAVESDROP | O.PROTECTED_COMMS | The threat T.NETWORK_EAVESDROP is countered by O.PROTECTED_COMMS as this provides for confidentiality of transmitted data. |
O.QUALITY | The objective O.QUALITY ensures use of mechanisms that provide protection against network-based attack. | |
O.MANAGEMENT | The threat T.NETWORK_EAVESDROP is countered by O.MANAGEMENT as this provides for the ability to configure the application to protect the confidentiality of its transmitted data. | |
T.LOCAL_ATTACK | O.QUALITY | The objective O.QUALITY protects against the use of mechanisms that weaken the TOE with regard to attack by other software on the platform. |
T.PHYSICAL_ACCESS | O.PROTECTED_STORAGE | The objective O.PROTECTED_STORAGE protects against unauthorized attempts to access physical storage used by the TOE. |
A.PLATFORM | OE.PLATFORM | The operational environment objective OE.PLATFORM is realized through A.PLATFORM. |
A.PROPER_USER | OE.PROPER_USER | The operational environment objective OE.PROPER_USER is realized through A.PROPER_USER. |
A.PROPER_ADMIN | OE.PROPER_ADMIN | The operational environment objective OE.PROPER_ADMIN is realized through A.PROPER_ADMIN. |
The following rationale provides justification for each security objective for the TOE,
showing that the SFRs are suitable to meet and achieve the security objectives:
Objective | Addressed by | Rationale |
---|---|---|
O.INTEGRITY | FDP_DEC_EXT.1 | The PP includes FDP_DEC_EXT.1 to limit access to platform hardware resources, which limits the methods by which an attacker can attempt to compromise the integrity of the TOE. |
FMT_CFG_EXT.1 | The PP includes FMT_CFG_EXT.1 for the TSP to limit unauthorized access to itself by preventing the use of default authentication credentials and by ensuring that the TOE uses appropriately restrictive platform permissions on its binaries and data | |
FPT_AEX_EXT.1 | The PP includes FPT_AEX_EXT.1 to add complexity to the task of compromising systems by ensuring that application is compatible with security features provided by the platform vendor and that the application implements platform-provided anti-exploitations such as ASLR and stack overflow protection. | |
FPT_TUD_EXT.1 | The PP includes FPT_TUD_EXT.1 to ensure that the TOE can be patched and that any updates to the TOE have appropriate integrity protection. | |
O.QUALITY | FCS_CKM.1 | The PP supports this objective by allowing FCS_CKM_EXT.1 to specify that the TSF may rely on platform-provided key generation services. |
FCS_RBG_EXT.1 | The PP supports this objective by allowing FCS_RBG_EXT.1 to specify that the TSF may rely on platform-provided random bit generation services. | |
FCS_STO_EXT.1 | The PP supports this objective by allowing FCS_STO_EXT.1 to specify that the TSF may rely on platform-provided credential storage services. | |
FDP_DAR_EXT.1 | The PP supports this objective by allowing FDP_DAR_EXT.1 to specify that the TSF may rely on platform-provided data-at-rest protection services. | |
FMT_MEC_EXT.1 | The PP includes FMT_MEC_EXT.1 to ensure that the TOE can use platform services to store and set configuration options. | |
FPT_API_EXT.1 | The PP includes FPT_API_EXT.1 to require the TOE to leverage platform functionality by using only documented and supported APIs. | |
FPT_LIB_EXT.1 | The PP includes FPT_LIB_EXT.1 to ensure that the TOE does not include any unnecessary or unexpected third-party libraries which could present a privacy threat or vulnerability. | |
FTP_DIT_EXT.1 | The PP supports this objective by allowing FTP_DIT_EXT.1 to specify that the TSF may rely on platform-provided services to implement trusted communications. | |
FCS_CKM.1/AK (selection-based) | The PP supports this objective by allowing FCS_CKM.1/AK to specify that the TSF may rely on platform-provided asymmetric key generation services. | |
FCS_CKM.2 (selection-based) | The PP supports this objective by allowing FCS_CKM.2 to specify that the TSF may rely on platform-provided key establishment services. | |
FIA_X509_EXT.1 (selection-based) | The PP supports this objective by allowing FIA_X509_EXT.1 to specify that the TSF may rely on platform-provided X.509 certificate validation services. | |
FPT_TUD_EXT.2 (selection-based) | The TSF includes FPT_TUD_EXT.2 to specify that the TOE may leverage the platform-supported package manager for application distribution and leverages platform-provided mechanisms to remove all traces of itself when removed from the platform system. | |
FPT_API_EXT.2 (objective) | The PP includes FPT_API_EXT.2 to permit the TOE to use platform-provided libraries for parsing IANA MIME media formats. | |
O.MANAGEMENT | FMT_SMF.1 | The PP includes FMT_SMF.1 to define the security-relevant management functions that are supported by the TOE. |
FPR_ANO_EXT.1 | The PP includes FPR_ANO_EXT.1 to define how the TSF provides control to the user regarding the disclosure of any PII. | |
FPT_IDV_EXT.1 | The PP includes FPT_IDV_EXT.1 to provide a methodology for identifying the TOE versioning. | |
FPT_TUD_EXT.1 | The PP includes FPT_TUD_EXT.1 to define how updates to the TOE are deployed and verified. | |
FCS_COP.1/Sig | The PP includes FCS_COP.1/Sig to define the mechanism used to verify TOE updates if the TOE implements this functionality rather than the underlying platform. | |
O.PROTECTED_STORAGE | FCS_RBG_EXT.1 | The PP includes FCS_RBG_EXT.1 to define whether random bit generation services are implemented by the TSF or the platform. Depending on how data at rest is protected, the TOE may rely on the use of a random bit generator to create keys that are subsequently used for data protection. |
FCS_STO_EXT.1 | The PP includes FCS_STO_EXT.1 to define the mechanism that the TSF uses or relies upon to protect stored credential data. | |
FDP_DAR_EXT.1 | The PP includes FDP_DAR_EXT.1 to define the mechanism that the TSF uses or relies upon to protect sensitive data at rest. | |
FCS_CKM.1/SK (optional) | The PP includes FCS_CKM.1/SK to define the TOE’s capability to generate symmetric keys. These keys may subsequently be used to encrypt stored credential data based on the claims made in FCS_STO_EXT.1. | |
FCS_CKM.1/PBKDF (selection-based) | The PP includes FCS_CKM.1/PBKDF to define the password-based key derivation function that may be used to encrypt stored credential data based on the claims made in FCS_STO_EXT.1. | |
FCS_COP.1/SKC (selection-based) | The PP includes FCS_COP.1/SKC to define the AES cryptographic algorithm that may be used to encrypt stored credential data based on the claims made in FCS_STO_EXT.1. | |
FCS_COP.1/Hash (selection-based) | The PP includes FCS_COP.1/Hash to define integrity mechanisms that may be used by the TOE as part of ensuring that data at rest is protected. | |
FCS_COP.1/KeyedHash (selection-based) | The PP includes FCS_COP.1/KeyedHash to define HMAC mechanisms that may be used by the TOE as part of ensuring that data at rest is protected. | |
FCS_RBG_EXT.2 (selection-based) | The PP includes FCS_RBG_EXT.2 to define the TOE’s implementation of random bit generation functionality in the event that the TOE provides this function in support of generating keys that are used for data protection. | |
O.PROTECTED_COMMS | FCS_RBG_EXT.1 | The PP includes FCS_RBG_EXT.1 to define whether the random bit generation services used in establishing trusted communications are implemented by the TSF or by the platform. |
FCS_CKM.1 | The PP includes FCS_CKM_EXT.1 to specify whether the TOE or the platform is responsible for generation of any asymmetric keys that may be used for establishing trusted communications. | |
FTP_DIT_EXT.1 | The PP includes FTP_DIT_EXT.1 to define the trusted channels used to protect data in transit, the data that is protected, and whether the trusted channels are implemented by the TSF or the platform. | |
FCS_CKM.1/AK | The PP includes FCS_CKM.1/AK to define whether the TSF or the platform generates asymmetric keys that are used in support of trusted communications. | |
FCS_CKM.2 | The PP includes FCS_CKM.2 to define whether the TSF or the platform performs key establishment for trusted communications. | |
FCS_COP.1/SKC | The PP includes FCS_COP.1/SKC to define the symmetric encryption algorithms used in support of trusted communications. | |
FCS_COP.1/Hash | The PP includes FCS_COP.1/Hash to define the hash algorithms used in support of trusted communications. | |
FCS_COP.1/Sig | The PP includes FCS_COP.1/Sig to define the digital signature algorithms used in support of trusted communications. | |
FCS_COP.1/KeyedHash | The PP includes FCS_COP.1/KeyedHash to define the HMAC algorithms used in support of trusted communications. | |
FCS_RBG_EXT.2 | The PP includes FCS_RBG_EXT.2 to define the DRBG algorithms used in support of trusted communications. | |
FCS_HTTPS_EXT.1/Client | The PP includes FCS_HTTPS_EXT.1 to define the TOE’s support for the HTTPS trusted communications protocol as a client. | |
FCS_HTTPS_EXT.1/Server | The PP includes FCS_HTTPS_EXT.1 to define the TOE’s support for the HTTPS trusted communications protocol as a server. | |
FDP_NET_EXT.1 | The PP includes FDP_NET_EXT.1 to define the TOE’s usage of network communications, which may include the transmission or receipt of data over a trusted channel. | |
FIA_X509_EXT.1 | The PP includes FIA_X509_EXT.1 to define X.509 certificate validation activities in support of trusted communications. | |
FIA_X509_EXT.2 | The PP includes FIA_X509_EXT.2 to define the trusted communications that X.509 certificate services support, as well as the extent to which trusted communications can be established when using a certificate with unknown validity. |
This PP does not define any Implementation-Based requirements.
As indicated in the introduction to this PP, the baseline requirements (those that must be performed by the TOE or its underlying platform) are contained in the body of this PP. There are additional requirements based on selections in the body of the PP: if certain selections are made, then additional requirements below must be included.
Factor | Same/Different | Guidance |
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. |
Factor | Same/Different | Guidance |
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. |
Factor | Same/Different/None | Guidance |
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. |
Factor | Same/Different/None | Guidance |
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. |
Factor | Same/Different/None | Guidance |
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. |
Acronym | Meaning |
---|---|
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 |
Base-PP | Base Protection Profile |
CC | Common Criteria |
CEM | Common Evaluation Methodology |
CMC | Certificate Management over CMS |
CMS | Cryptographic Message Syntax |
CN | Common Names |
CRL | Certificate Revocation List |
CSA | Computer Security Act |
DEP | Data Execution Prevention |
DES | Data Encryption Standard |
DHE | Diffie-Hellman Ephemeral |
DMG | Apple Disk Image |
DNS | Domain Name System |
DPAPI | Data Protection Application Programming Interface |
DRBG | Deterministic Random Bit Generator |
DSS | Digital Signature Standard |
DT | Date/Time Vector |
DTLS | Datagram Transport Layer Security |
EAP | Extensible Authentication Protocol |
ECDHE | Elliptic Curve Diffie-Hellman Ephemeral |
ECDSA | Elliptic Curve Digital Signature Algorithm |
ELF | Executable and Linkable Format |
EMET | Enhanced Mitigation Experience Toolkit |
EST | Enrollment over Secure Transport |
FIPS | Federal Information Processing Standards |
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 |
IP | Internet Protocol |
IPA | iOS Package archive |
IR | Intermediate Integer |
ISO | International Organization for Standardization |
IT | Information Technology |
ITSEF | Information Technology Security Evaluation Facility |
JNI | Java Native Interface |
LDAP | Lightweight Directory Access Protocol |
MIME | Multi-purpose Internet Mail Extensions |
MPKG | Meta Package |
MSI | Microsoft Installer |
NFC | Near Field Communication |
NIAP | National Information Assurance Partnership |
NIST | National Institute of Standards and Technology |
OCSP | Online Certificate Status Protocol |
OE | Operational Environment |
OID | Object Identifier |
OMB | Office of Management and Budget |
OS | Operating System |
Portable Document Format | |
PE | Portable Executable |
PID | Process Identifier |
PII | Personally Identifiable Information |
PKG | Package file |
PKI | Public Key Infrastructure |
PP | Protection Profile |
PP-Configuration | Protection Profile Configuration |
PP-Module | Protection Profile Module |
RBG | Random Bit Generator |
RFC | Request for Comment |
RNG | Random Number Generator |
RNGVS | Random Number Generator Validation System |
S/MIME | Secure/Multi-purpose Internet Mail Extensions |
SAN | Subject Alternative Name |
SAR | Security Assurance Requirement |
SE | Security Enhancements |
SFR | Security Functional Requirement |
SHA | Secure Hash Algorithm |
SIP | Session Initiation Protocol |
SP | Special Publication |
SSH | Secure Shell |
ST | Security Target |
SWID | Software Identification |
TLS | Transport Layer Security |
TOE | Target of Evaluation |
TSF | TOE Security Functionality |
TSFI | TSF Interface |
TSS | TOE Summary Specification |
UI | User Interface |
URI | Uniform Resource Identifier |
URL | Uniform Resource Locator |
USB | Universal Serial Bus |
XCCDF | eXtensible Configuration Checklist Description Format |
XOR | Exclusive Or |
app | Application |
cPP | Collaborative Protection Profile |
Identifier | Title |
---|---|
[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. |