Protection Profile for General PurposeOperating Systems

Version: 4.020150814

National Information Assurance Partnership

Revision History

Version Date Comment

4.0 20150814 Release significant revision

Contents

1. Introduction1.1. Overview1.2. Terms1.2.1. Common Criteria Terms1.2.2. Technology Terms1.3. Compliant Targets of Evaluation1.3.1. TOE Boundary1.3.2. TOE Platform1.4. Use Cases2. Conformance Claims3. Security Problem Definition3.1. Threats3.2. Assumptions4. Security Objectives4.1. Security Objectives for the TOE4.2. Security Objectives for the Operational Environment4.3. Security Objectives Rationale5. Security Requirements5.1. Security Functional Requirements5.1.1. Cryptographic Support (FCS)5.1.2. User Data Protection (FDP)5.1.3. Security Management (FMT)5.1.4. Protection of the TSF (FPT)5.1.5. Audit Data Generation (FAU)5.1.6. Identification and Authentication (FIA)5.1.7. Trusted Path/Channels (FTP)5.2. Security Assurance Requirements5.2.1. Class ASE: Security Target5.2.2. Class ADV: Development5.2.3. Class AGD: Guidance Documentation5.2.4. Class ALC: Lifecycle Support5.2.5. Class ATE: Tests5.2.6. Class AVA: Vulnerability AssessmentAppendix A: Optional RequirementsAppendix B: SelectionBased RequirementsAppendix C: Objective RequirementsAppendix D: Inherently Satisfied Requirements

Appendix E: Entropy Documentation and AssessmentAppendix F: ReferencesAppendix G: Acronyms

1. Introduction

1.1 Overview

The scope of this Protection Profile (PP) is to describe the security functionality of operatingsystems in terms of [CC] and to define functional and assurance requirements for such products.An operating system is software that manages computer hardware and software resources, andprovides common services for application programs. The hardware it manages may be physical orvirtual.

1.2 Terms

The following sections provide both Common Criteria and technology terms used in this ProtectionProfile.

1.2.1 Common Criteria Terms

Common Criteria(CC)

Common Criteria for Information Technology Security Evaluation.

Common EvaluationMethodology(CEM)

Common Evaluation Methodology for Information Technology SecurityEvaluation.

Protection Profile(PP)

An implementationindependent set of security requirements for acategory of products.

Security Target (ST) A set of implementationdependent security requirements for a specificproduct.

Target of Evaluation(TOE)

The product under evaluation. In this case, the Operating System asdescribed in section TOE Boundary and its supporting documentation.

TOE SecurityFunctionality (TSF)

The security functionality of the product under evaluation.

TOE SummarySpecification (TSS)

A description of how a TOE satisfies the SFRs in a ST.

Security FunctionalRequirement (SFR)

A requirement for security enforcement by the TOE.

Security AssuranceRequirement (SAR)

A requirement to assure the security of the TOE.

1.2.2 Technology Terms

AddressSpace LayoutRandomization(ASLR)

An antiexploitation feature which loads memory mappings into unpredictablelocations. ASLR makes it more difficult for an attacker to redirect control tocode that they have introduced into the address space of a process.

Administrator An administrator is responsible for management activities, including settingpolicies that are applied by the enterprise on the operating system. Thisadministrator could be acting remotely through a management server, fromwhich the system receives configuration policies. An administrator can enforcesettings on the system which cannot be overridden by nonadministrator users.

Application(app)

Software that runs on a platform and performs tasks on behalf of the user orowner of the platform, as well as its supporting documentation.

ApplicationProgrammingInterface(API)

A specification of routines, data structures, object classes, and variables thatallows an application to make use of services provided by another softwarecomponent, such as a library. APIs are often provided for a set of librariesincluded with the platform.

Credential Data that establishes the identity of a user, e.g. a cryptographic key orpassword.

CriticalSecurityParameters(CSP)

Information that is either user or system defined and is used to operate acryptographic module in processing encryption functions includingcryptographic keys and authentication data, such as passwords, the disclosureor modification of which can compromise the security of a cryptographicmodule or the security of the information protected by the module.

Data At Rest(DAR)Protection

Countermeasures that prevent attackers, even those with physical access,from extracting data from nonvolatile storage. Common techniques includedata encryption and wiping.

DataExecutionPrevention(DEP)

An antiexploitation feature of modern operating systems executing on moderncomputer hardware, which enforces a nonexecute permission on pages ofmemory. DEP prevents pages of memory from containing both data andinstructions, which makes it more difficult for an attacker to introduce andexecute code.

Developer An entity that writes OS software. For the purposes of this document, vendorsand developers are the same.

HostbasedFirewall

A softwarebased firewall implementation running on the OS for filteringinbound and outbound network traffic to and from processes running on theOS.

OperatingSystem (OS)

Software that manages physical and logical resources and provides servicesfor applications. The terms TOE and OS are interchangeable in this document.

PersonallyIdentifiableInformation(PII)

Any information about an individual maintained by an agency, including, butnot limited to, education, financial transactions, medical history, and criminal oremployment history and information which can be used to distinguish or tracean individual's identity, such as their name, social security number, date andplace of birth, mother’s maiden name, biometric records, etc., including any

other personal information which is linked or linkable to an individual. [OMB]

Sensitive Data Sensitive data may include all user or enterprise data or may be specificapplication data such as PII, emails, messaging, documents, calendar items,and contacts. Sensitive data must minimally include credentials and keys.Sensitive data shall be identified in the OS’s TSS by the ST author.

User A user is subject to configuration policies applied to the operating system byadministrators. On some systems under certain configurations, a normal usercan temporarily elevate privileges to that of an administrator. At that time, sucha user should be considered an administrator.

1.3 Compliant Targets of Evaluation

1.3.1 TOE BoundaryThe TOE boundary encompasses the OS kernel and its drivers, shared software libraries, andsome application software included with the OS. The applications considered within the TOE arethose that provide essential security services, many of which run with elevated privileges.Applications which are covered by morespecific Protection Profiles cannot claim evaluation aspart of the OS evaluation, even when it is necessary to evaluate some of their functionality as itrelates to their role as part of the OS.

Figure 1: General TOE

1.3.2 TOE PlatformThe TOE platform, which consists of the physical or virtual hardware on which the TOE executes,is outside the scope of evaluation. At the same time, the security of the TOE relies upon it. Otherhardware components which independently run their own software and are relevant to overallsystem security are also outside the scope of evaluation.

1.4 Use Cases

Requirements in this Protection Profile are designed to address the security problems in at least thefollowing use cases. These use cases are intentionally very broad, as many specific use cases existfor an operating system. These use cases may also overlap with one another. An operatingsystem's functionality may even be effectively extended by privileged applications installed onto it.

However, these are out of scope of this PP.

[USE CASE 1] End User DevicesThe OS provides a platform to end user devices such as desktops, laptops, convertibles,and tablets. These devices may optionally be bound to a directory server or managementserver.

As this Protection Profile does not address threats against dataatrest, enterprisesdeploying operating systems in mobile scenarios should ensure that these systems includedataatrest protection spelled out in other Protection Profiles. Specifically, this includes theProtection Profiles for Full Drive Encryption Encryption Engine, Full DriveEncryption Authorization Acquisition, and Software File Encryption. The ProtectionProfile for Mobile Device Fundamentals includes requirements for dataatrestprotection and is appropriate for many mobile devices.

[USE CASE 2] Server SystemsThe OS provides a platform for serverside services, either on physical or virtual hardware.Many specific examples exist in which the OS acts as a platform for such services, includingfile servers, mail servers, and web servers.

[USE CASE 3] Cloud SystemsThe OS provides a platform for providing cloud services running on physical or virtualhardware. An OS is typically part of offerings identified as Infrastructure as a Service(IaaS), Software as a Service (SaaS), and Platform as a Service (PaaS).

This use case typically involves the use of virtualization technology which should beevaluated against the Protection Profile for Server Virtualization.

2. Conformance Claims

Conformance StatementTo be conformant to this PP, a ST must demonstrate Exact Conformance, a subset of StrictConformance as defined in [CC] Part 1 (ASE_CCL). The ST must include all componentsin this PP that are:

unconditional (which are always required)selectionbased (which are required when certain selections are chosen in theunconditional requirements)

and may include components that areoptional orobjective.

Unconditional requirements are found in the main body of the document, while appendicescontain the selectionbased, optional, and objective requirements. The ST may iterate anyof these components, but it must not include any additional component (e.g. from CC Part 2or 3 or a PP not conformant with this one, or extended by the ST) not defined in this PP ora PP conformant to this one.

Some components in this Protection Profile have a dependency on other components. Inaccordance with [CC] Part 1, Appendix D includes justifications for those cases where thePP does not explicitly contain the component upon which there is a dependency.

CC Conformance ClaimsThis PP is conformant to Parts 2 (extended) and 3 (extended) of Common Criteria Version3.1, Revision 4.[CC].

PP ClaimThis PP does not claim conformance to any other Protection Profile.

Package ClaimThis PP does not claim conformance to any packages.

3. Security Problem Definition

The security problem is described in terms of the threats that the OS is expected to address,assumptions about the operational environment, and any organizational security policies that theOS is expected to enforce.

3.1 Threats

T.NETWORK_ATTACKAn attacker is positioned on a communications channel or elsewhere on the networkinfrastructure. Attackers may engage in communications with applications and servicesrunning on or part of the OS with the intent of compromise. Engagement may consist ofaltering existing legitimate communications.

T.NETWORK_EAVESDROPAn attacker is positioned on a communications channel or elsewhere on the networkinfrastructure. Attackers may monitor and gain access to data exchanged betweenapplications and services that are running on or part of the OS.

T.LOCAL_ATTACKAn attacker may compromise applications running on the OS. The compromised applicationmay provide maliciously formatted input to the OS through a variety of channels includingunprivileged system calls and messaging via the file system.

T.LIMITED_PHYSICAL_ACCESSAn attacker may attempt to access data on the OS while having a limited amount of timewith the physical device.

3.2 Assumptions

A.PLATFORMThe OS relies upon a trustworthy computing platform for its execution. This underlyingplatform is out of scope of this PP.

A.PROPER_USERThe user of the OS is not willfully negligent or hostile, and uses the software in compliancewith the applied enterprise security policy. At the same time, malicious software could actas the user, so requirements which confine malicious subjects are still in scope.

A.PROPER_ADMINThe administrator of the OS is not careless, willfully negligent or hostile, and administers theOS within compliance of the applied enterprise security policy.

4. Security Objectives

4.1 Security Objectives for the TOE

O.ACCOUNTABILITYConformant OSs ensure that information exists that allows administrators to discoverunintentional issues with the configuration and operation of the operating system anddiscover its cause. Gathering event information and immediately transmitting it to anothersystem can also enable incident response in the event of system compromise.Addressed by: FAU_GEN.1

O.INTEGRITYConformant OSs ensure the integrity of their update packages. OSs are seldom if evershipped without errors, and the ability to deploy patches and updates with integrity is criticalto enterprise network security. Conformant OSs provide execution environmentbasedmitigations that increase the cost to attackers by adding complexity to the task ofcompromising systems.Addressed by: FPT_SBOP_EXT.1, FPT_ASLR_EXT.1, FPT_TUD_EXT.1,FPT_TUD_EXT.2, FCS_COP.1.1(2), FCS_COP.1.1(3), FCS_COP.1.1(4),FPT_ACF_EXT.1, FPT_SRP_EXT.1, FIA_X509_EXT.2, FPT_TST_EXT.1,FTP_ITC_EXT.1, FPT_W X_EXT.1.1, FIA_AFL.1, FIA_UAU.5

O.MANAGEMENTTo facilitate management by users and the enterprise, conformant OSes provide consistentand supported interfaces for their securityrelevant configuration and maintenance. Thisincludes the deployment of applications and application updates through the use of platformsupported deployment mechanisms and formats, as well as providing mechanisms forconfiguration and application execution control.Addressed by: FMT_MOF_EXT.1, FTP_TRP.1

O.PROTECTED_STORAGETo address the issue of loss of confidentiality of credentials in the event of loss of physicalcontrol of the storage medium, conformant OSs provide dataatrest protection forcredentials. Conformant OSes also provide access controls which allow a users to keeptheir files private from other users of the same system.Addressed by: FCS_STO_EXT.1, FCS_RBG_EXT.1, FCS_COP.1.1(1),FDP_ACF_EXT.1

O.PROTECTED_COMMSTo address both passive (eavesdropping) and active (packet modification) network attackthreats, conformant OSs provide mechanisms to create trusted channels for CSP andsensitive data. Both CSP and sensitive data should not be exposed outside of the platform.Addressed by: FCS_TLSC_EXT.1, FCS_TLSC_EXT.2, FCS_TLSC_EXT.3,FCS_TLSC_EXT.4, FCS_DTLS_EXT.1, FCS_RBG_EXT.1, FCS_CKM.1, FCS_CKM.2,FCS_COP.1.1(1), FDP_IFC_EXT.1, FIA_X509_EXT.1, FIA_X509_EXT.2,FTP_ITC_EXT.1

4.2 Security Objectives for the Operational Environment

The following security objectives for the operational environment assist the OS in correctlyproviding its security functionality. These track with the assumptions about the environment.

OE.PLATFORMThe OS relies on being installed on trusted hardware.

OE.PROPER_USERThe user of the OS is not willfully negligent or hostile, and uses the software withincompliance of the applied enterprise security policy. Standard user accounts areprovisioned in accordance with the least privilege model. Users requiring higher levels ofaccess should have a separate account dedicated for that use.

OE.PROPER_ADMINThe administrator of the OS is not careless, willfully negligent or hostile, and administers theOS within compliance of the applied enterprise security policy.

4.3 Security Objectives Rationale

This section describes how the assumptions, threats, and organizational security policies map to thesecurity objectives.

Threat, Assumption, or OSP Security Objectives Rationale

T.NETWORK_ATTACK O.PROTECTED_COMMS,O.INTEGRITY,O.MANAGEMENT

The threatT.NETWORK_ATTACK iscountered byO.PROTECTED_COMMS asthis provides for integrity oftransmitted data.The threatT.NETWORK_ATTACK iscountered by O.INTEGRITYas this provides for integrity ofsoftware that is installed ontothe system from the network.The threatT.NETWORK_ATTACK iscountered byO.MANAGEMENT as thisprovides for the ability toconfigure the OS to defendagainst network attack.

T.NETWORK_EAVESDROP O.PROTECTED_COMMS,O.MANAGEMENT

The threatT.NETWORK_EAVESDROPis countered byO.PROTECTED_COMMS asthis provides for confidentialityof transmitted data.The threat

T.NETWORK_EAVESDROPis countered byO.MANAGEMENT as thisprovides for the ability toconfigure the OS to protect theconfidentiality of its transmitteddata.

T.LOCAL_ATTACK O.INTEGRITY The objective O.INTEGRITYprotects against the use ofmechanisms that weaken theTOE with regard to attack byother software on the platform.

T.LIMITED_PHYSICAL_ACCESS O.PROTECTED_STORAGE The objectiveO.PROTECTED_STORAGEprotects against unauthorizedattempts to access physicalstorage used by the TOE.

A.PLATFORM OE.PLATFORM The operational environmentobjective OE.PLATFORM isrealized throughA.PLATFORM.

A.PROPER_USER OE.PROPER_USER The operational environmentobjective OE.PROPER_USERis realized throughA.PROPER_USER.

A.PROPER_ADMIN OE.PROPER_ADMIN The operational environmentobjectiveOE.PROPER_ADMIN isrealized throughA.PROPER_ADMIN.

5. Security Requirements

This chapter describes the security requirements which have to be fulfilled by the OS. Thoserequirements comprise functional components from Part 2 and assurance components from Part 3of [CC]. The following notations are used:

Refinement operation (denoted by bold text): is used to add details to a requirement, andthus further restricts a requirement.Selection (denoted by italicized text): is used to select one or more options provided bythe [CC] in stating a requirement.Assignment operation (denoted by italicized text): is used to assign a specific value to anunspecified parameter, such as the length of a password. Showing the value in squarebrackets indicates assignment.Iteration operation: are identified with a number inside parentheses (e.g. "(1)")

5.1 Security Functional Requirements

The Security Functional Requirements included in this section are derived from Part 2 of theCommon Criteria for Information Technology Security Evaluation, Version 3.1, Revision 4, withadditional extended functional components.

5.1.1 Cryptographic Support (FCS)

FCS_CKM.1 Cryptographic Key Generation

FCS_CKM.1.1The OS shall generate asymmetric cryptographic keys in accordancewith a specified cryptographic key generation algorithm [selection:

RSA schemes using cryptographic key sizes of 2048bit orgreater that meet the following: [selection: FIPS PUB 1864, “Digital Signature Standard (DSS)”, Appendix B.3 ,ANSI X9.311998, Section 4.1] ,ECC schemes using “NIST curves” P256, P384 and[selection: P521 , no other curves ] that meet the following:FIPS PUB 1864, “Digital Signature Standard (DSS)”,Appendix B.4

] .

Application Note: The ST author shall select all key generationschemes used for key establishment and entity authentication. When keygeneration is used for key establishment, the schemes in FCS_CKM.2.1and selected cryptographic protocols must match the selection. Whenkey generation is used for entity authentication, the public key isexpected to be associated with an X.509v3 certificate.

If the OS acts only as a receiver in the RSA key establishment scheme,the OS does not need to implement RSA key generation.

The ANSI X9.311998 option will be removed from the selection in afuture publication of this document. Presently, the selection is notexclusively limited to the FIPS PUB 1864 options in order to allowindustry some further time to complete the transition to the modern FIPSPUB 1864 standard.

Assurance Activity

The evaluator will ensure that the TSS identifies the key sizessupported by the OS. If the ST specifies more than onescheme, the evaluator will examine the TSS to verify that itidentifies the usage for each scheme.

The evaluator will verify that the AGD guidance instructs theadministrator how to configure the OS to use the selected keygeneration scheme(s) and key size(s) for all uses defined inthis PP.

Assurance Activity Note: The following tests may require thevendor to furnish a developer environment and developertools that are typically not available to endusers of the OS.

Key Generation for FIPS PUB 1864 RSA Schemes

The evaluator will verify the implementation of RSA KeyGeneration by the OS using the Key Generation test. This testverifies the ability of the TSF to correctly produce values forthe key components including the public verification exponente, the private prime factors p and q, the public modulus n andthe calculation of the private signature exponent d. Key Pairgeneration specifies 5 ways (or methods) to generate theprimes p and q. These include:

1. Random Primes:Provable primesProbable primes

2. Primes with Conditions:Primes p1, p2, q1,q2, p and q shall all beprovable primesPrimes p1, p2, q1, and q2 shall be provableprimes and p and q shall be probable primesPrimes p1, p2, q1,q2, p and q shall all beprobable primes

To test the key generation method for the Random Provableprimes method and for all the Primes with Conditionsmethods, the evaluator must seed the TSF key generationroutine with sufficient data to deterministically generate theRSA key pair. This includes the random seed(s), the publicexponent of the RSA key, and the desired key length. For each

key length supported, the evaluator shall have the TSFgenerate 25 key pairs. The evaluator will verify thecorrectness of the TSF’s implementation by comparing valuesgenerated by the TSF with those generated from a knowngood implementation.

If possible, the Random Probable primes method should alsobe verified against a known good implementation asdescribed above. Otherwise, the evaluator will have the TSFgenerate 10 keys pairs for each supported key length nlen andverify:

n = p⋅q,p and q are probably prime according to MillerRabintests,GCD(p1,e) = 1,GCD(q1,e) = 1,2 ≤ e ≤ 2 and e is an odd integer,|pq| > 2 ,p ≥ 2 ,q ≥ 2 ,2 < d < LCM(p1,q1),e⋅d = 1 mod LCM(p1,q1).

Key Generation for ANSI X9.311998 RSA SchemesIf the TSF implements the ANSI X9.311998 scheme, theevaluator will check to ensure that the TSS describes how thekeypairs are generated. In order to show that the TSFimplementation complies with ANSI X9.311998, theevaluator will ensure that the TSS contains the followinginformation:

The TSS shall list all sections of the standard to whichthe OS complies;For each applicable section listed in the TSS, for allstatements that are not "shall" (that is, "shall not","should", and "should not") , if the OS implementssuch options it shall be described in the TSS. If theincluded functionality is indicated as "shall not" or"should not" in the standard, the TSS shall provide arationale for why this will not adversely affect thesecurity policy implemented by the OS;For each applicable section of Appendix B, anyomission of functionality related to "shall" or “should”statements shall be described.

Key Generation for Elliptic Curve Cryptography (ECC)FIPS 1864 ECC Key Generation TestFor each supported NIST curve, i.e., P256, P384 and P521,the evaluator will require the implementation under test (IUT)to generate 10 private/public key pairs. The private key shallbe generated using an approved random bit generator (RBG).To determine correctness, the evaluator will submit the

16 256

nlen/2 100

nlen/2 1/2

nlen/2 1/2

(nlen/2)

generated key pairs to the public key verification (PKV)function of a known good implementation.

FIPS 1864 Public Key Verification (PKV) TestFor each supported NIST curve, i.e., P256, P384 and P521,the evaluator will generate 10 private/public key pairs usingthe key generation function of a known good implementationand modify five of the public key values so that they areincorrect, leaving five values unchanged (i.e., correct). Theevaluator will obtain in response a set of 10 PASS/FAILvalues.

FCS_CKM.2 Cryptographic Key Establishment

FCS_CKM.2.1The OS shall implement functionality to perform cryptographic keyestablishment in accordance with a specified cryptographic keyestablishment method:RSAbased key establishment schemes that meets the following:NIST Special Publication 80056B, “Recommendation for PairWiseKey Establishment Schemes Using Integer Factorization Cryptography”and [selection:

Elliptic curvebased key establishment schemes that meetsthe following: NIST Special Publication 80056A,“Recommendation for PairWise Key Establishment SchemesUsing Discrete Logarithm Cryptography” ,No other schemes

] .

Application Note: The ST author shall select all key establishmentschemes used for the selected cryptographic protocols.FCS_TLSC_EXT.1 requires cipher suites that use RSAbased keyestablishment schemes.

The RSAbased key establishment schemes are described in Section 9of NIST SP 80056B; however, Section 9 relies on implementation ofother sections in SP 80056B. If the OS acts as a receiver in the RSAkey establishment scheme, the OS does not need to implement RSAkey generation.

The elliptic curves used for the key establishment scheme shall correlatewith the curves specified in FCS_CKM.1.1.

Assurance Activity

The evaluator will ensure that the supported keyestablishment schemes correspond to the key generationschemes identified in FCS_CKM.1.1. If the ST specifies more

than one scheme, the evaluator will examine the TSS to verifythat it identifies the usage for each scheme.

The evaluator will verify that the AGD guidance instructs theadministrator how to configure the OS to use the selected keyestablishment scheme(s).

Assurance Activity Note: The following tests require thedeveloper to provide access to a test platform that providesthe evaluator with tools that are typically not found onfactory products.

Key Establishment SchemesThe evaluator will verify the implementation of the keyestablishment schemes supported by the OS using theapplicable tests below.

SP80056A Key Establishment SchemesThe evaluator will verify the OS's implementation of SP80056A key agreement schemes using the following Function andValidity tests. These validation tests for each key agreementscheme verify that the OS has implemented the components ofthe key agreement scheme according to the specifications inthe Recommendation. These components include thecalculation of the discrete logarithm cryptography (DLC)primitives (the shared secret value Z) and the calculation ofthe derived keying material (DKM) via the Key DerivationFunction (KDF). If key confirmation is supported, theevaluator will also verify that the components of keyconfirmation have been implemented correctly, using the testprocedures described below. This includes the parsing of theDKM, the generation of MAC data and the calculation ofMAC tag.

Function TestThe Function test verifies the ability of the OS toimplement the key agreement schemes correctly. Toconduct this test the evaluator shall generate or obtaintest vectors from a known good implementation of theOS's supported schemes. For each supported keyagreement schemekey agreement role combination,KDF type, and, if supported, key confirmation role keyconfirmation type combination, the tester shall generate10 sets of test vectors. The data set consists of the NISTapproved curve (ECC) per 10 sets of public keys. Thesekeys are static, ephemeral or both depending on thescheme being tested.

The evaluator will obtain the DKM, the correspondingOS's public keys (static and/or ephemeral), the MACtag(s), and any inputs used in the KDF, such as the

Other Information field OI and OS id fields.

If the OS does not use a KDF defined in SP 80056A, theevaluator will obtain only the public keys and the hashedvalue of the shared secret.

The evaluator will verify the correctness of the TSF’simplementation of a given scheme by using a knowngood implementation to calculate the shared secretvalue, derive the keying material DKM, and comparehashes or MAC tags generated from these values.

If key confirmation is supported, the OS shall performthe above for each implemented approved MACalgorithm.

Validity TestThe Validity test verifies the ability of the OS torecognize another party’s valid and invalid keyagreement results with or without key confirmation. Toconduct this test, the evaluator will obtain a list of thesupporting cryptographic functions included in theSP80056A key agreement implementation to determinewhich errors the OS should be able to recognize. Theevaluator generates a set of 30 test vectors consisting ofdata sets including domain parameter values or NISTapproved curves, the evaluator’s public keys, the OS’spublic/private key pairs, MAC tag, and any inputs usedin the KDF, such as the other info and OS id fields.

The evaluator will inject an error in some of the testvectors to test that the OS recognizes invalid keyagreement results caused by the following fields beingincorrect: the shared secret value Z, the DKM, the otherinformation field OI, the data to be MAC'd, or thegenerated MAC tag. If the OS contains the full or partial(only ECC) public key validation, the evaluator will alsoindividually inject errors in both parties’ static publickeys, both parties’ ephemeral public keys and the OS’sstatic private key to assure the OS detects errors in thepublic key validation function and/or the partial keyvalidation function (in ECC only). At least two of thetest vectors shall remain unmodified and thereforeshould result in valid key agreement results (they shouldpass).

The OS shall use these modified test vectors to emulatethe key agreement scheme using the correspondingparameters. The evaluator will compare the OS’s resultswith the results using a known good implementationverifying that the OS detects these errors.

SP80056B Key Establishment SchemesThe evaluator will verify that the TSS describes whether theOS acts as a sender, a recipient, or both for RSAbased keyestablishment schemes.

If the OS acts as a sender, the following assurance activityshall be performed to ensure the proper operation of every OSsupported combination of RSAbased key establishmentscheme:

To conduct this test the evaluator will generate or obtaintest vectors from a known good implementation of theOS's supported schemes. For each combination ofsupported key establishment scheme and its options(with or without key confirmation if supported, for eachsupported key confirmation MAC function if keyconfirmation is supported, and for each supported maskgeneration function if KTSOAEP is supported), thetester shall generate 10 sets of test vectors. Each testvector shall include the RSA public key, the plaintextkeying material, any additional input parameters ifapplicable, the MAC key and MAC tag if keyconfirmation is incorporated, and the outputtedciphertext. For each test vector, the evaluator shallperform a key establishment encryption operation on theOS with the same inputs (in cases where keyconfirmation is incorporated, the test shall use the MACkey from the test vector instead of the randomlygenerated MAC key used in normal operation) andensure that the outputted ciphertext is equivalent to theciphertext in the test vector.

If the OS acts as a receiver, the following assurance activitiesshall be performed to ensure the proper operation of every OSsupported combination of RSAbased key establishmentscheme:

To conduct this test the evaluator will generate or obtaintest vectors from a known good implementation of theOS's supported schemes. For each combination ofsupported key establishment scheme and its options(with our without key confirmation if supported, for eachsupported key confirmation MAC function if keyconfirmation is supported, and for each supported maskgeneration function if KTSOAEP is supported), thetester shall generate 10 sets of test vectors. Each testvector shall include the RSA private key, the plaintextkeying material, any additional input parameters ifapplicable, the MAC tag in cases where key confirmation

is incorporated, and the outputted ciphertext. For eachtest vector, the evaluator will perform the keyestablishment decryption operation on the OS and ensurethat the outputted plaintext keying material is equivalentto the plaintext keying material in the test vector. Incases where key confirmation is incorporated, theevaluator will perform the key confirmation steps andensure that the outputted MAC tag is equivalent to theMAC tag in the test vector.

The evaluator will ensure that the TSS describes how the OShandles decryption errors. In accordance with NIST SpecialPublication 80056B, the OS must not reveal the particularerror that occurred, either through the contents of anyoutputted or logged error message or through timingvariations. If KTSOAEP is supported, the evaluator willcreate separate contrived ciphertext values that trigger eachof the three decryption error checks described in NIST SpecialPublication 80056B section 7.2.2.3, ensure that eachdecryption attempt results in an error, and ensure that anyoutputted or logged error message is identical for each. IfKTSKEMKWS is supported, the evaluator will createseparate contrived ciphertext values that trigger each of thethree decryption error checks described in NIST SpecialPublication 80056B section 7.2.3.3, ensure that eachdecryption attempt results in an error, and ensure that anyoutputted or logged error message is identical for each.

FCS_CKM_EXT.3 Cryptographic Key Destruction

FCS_CKM_EXT.3.1The OS shall destroy cryptographic keys in accordance with thespecified cryptographic key destruction methods [selection:

For volatile memory, the destruction shall be executed by asingle direct overwrite [selection: consisting of apseudorandom pattern using the TSF’s RBG , consisting ofzeroes ] followed by a readverify. If the readverification ofthe overwritten data fails, the process shall be repeatedagain. ,For nonvolatile EEPROM, the destruction shall be executedby a single, direct overwrite consisting of a pseudorandompattern using the TSF’s RBG (as specified inFCS_RBG_EXT.1), followed by a readverify. If the readverification of the overwritten data fails, the process shall berepeated again. ,For nonvolatile flash memory, the destruction shall beexecuted by [selection: a single, direct overwrite consistingof zeroes , a block erase ] followed by a readverify. If thereadverification of the overwritten data fails, the process

shall be repeated again. ,For nonvolatile memory other than EEPROM and flash, thedestruction shall be executed by overwriting three or moretimes with a random pattern that is changed before eachwrite

] .

Application Note: The clearing indicated above applies to eachintermediate storage area upon the transfer of the key to anotherlocation.

Assurance Activity

The evaluator will check to ensure the TSS lists each type ofkey material and its origin and storage location. Theevaluator will verify that the TSS describes when each type ofkey material is cleared. For each software key clearingsituation the evaluator will repeat the following test.

Test 1: The evaluator will utilize appropriatecombinations of specialized operational environmentand development tools (debuggers, simulators, etc.) forthe TOE and instrumented TOE builds to test that keysare cleared correctly, including all intermediate copiesof the key that may have been created internally by theTOE during normal cryptographic processing with thatkey. Cryptographic TOE implementations in softwareshall be loaded and exercised under a debugger toperform such tests. The evaluator will perform thefollowing steps for each key subject to clearing,including intermediate copies of keys that are persistedencrypted by the TOE:

1. Load the instrumented TOE build in a debugger.2. Record the value of the key in the TOE subject toclearing.

3. Cause the TOE to perform a normalcryptographic processing with the key from #1.

4. Cause the TOE to clear the key.5. Cause the TOE to stop the execution but not exit.6. Cause the TOE to dump the entire memoryfootprint of the TOE into a binary file.

7. Search the content of the binary file created in #4for instances of the known key value from #1.

The test succeeds if no copies of the key from #1 arefound in step #7 above and fails otherwise.

The evaluator will perform this test on all keys,including those persisted in encrypted form, to ensureintermediate copies are cleared.

FCS_COP.1(1) Cryptographic Operation Encryption/Decryption

FCS_COP.1.1(1)The OS shall perform encryption/decryption services for data inaccordance with a specified cryptographic algorithm

AESXTS (as defined in NIST SP 80038E) mode;AESCBC (as defined in NIST SP 80038A) mode;AESCCMP (as defined in FIPS PUB 197, NIST SP 80038Cand IEEE 802.11 2012)

and [selection:AES Key Wrap (KW) (as defined in NIST SP 80038F),AES Key Wrap with Padding (KWP) (as defined in NIST SP80038F),AESGCM (as defined in NIST SP 80038D),AESCCM (as defined in NIST SP 80038C),AESCCMP256 (as defined in NIST SP80038C and IEEE802.11ac2013),AESGCMP256 (as defined in NIST SP80038D and IEEE802.11ac2013),no other modes

] and cryptographic key sizes 128bit and 256bit.

Application Note: For the first selection, the ST author should choosethe mode or modes in which AES operates. For the second selection,the ST author should choose the key sizes that are supported by thisfunctionality. 128bit key size is required in order to comply withFCS_TLSC_EXT.1 and FCS_CKM.1, if those are selected.

Assurance Activity

The evaluator will verify that the AGD documents containsinstructions required to configure the OS to use the requiredmodes and key sizes. The evaluator will execute allinstructions as specified to configure the OS to theappropriate state. The evaluator will perform all of thefollowing tests for each algorithm implemented by the OS andused to satisfy the requirements of this PP:

AESCBC Known Answer TestsThere are four Known Answer Tests (KATs), described below.In all KATs, the plaintext, ciphertext, and IV values shall be128bit blocks. The results from each test may either beobtained by the evaluator directly or by supplying the inputsto the implementer and receiving the results in response. Todetermine correctness, the evaluator will compare theresulting values to those obtained by submitting the sameinputs to a known good implementation.

KAT1. To test the encrypt functionality of AESCBC,

the evaluator will supply a set of 10 plaintext valuesand obtain the ciphertext value that results from AESCBC encryption of the given plaintext using a key valueof all zeros and an IV of all zeros. Five plaintext valuesshall be encrypted with a 128bit allzeros key, and theother five shall be encrypted with a 256bit all zeroskey. To test the decrypt functionality of AESCBC, theevaluator will perform the same test as for encrypt,using 10 ciphertext values as input and AESCBCdecryption.KAT2. To test the encrypt functionality of AESCBC,the evaluator will supply a set of 10 key values andobtain the ciphertext value that results from AESCBCencryption of an allzeros plaintext using the given keyvalue and an IV of all zeros. Five of the keys shall be128bit keys, and the other five shall be 256bit keys.To test the decrypt functionality of AESCBC, theevaluator will perform the same test as for encrypt,using an allzero ciphertext value as input and AESCBC decryption.KAT3. To test the encrypt functionality of AESCBC,the evaluator will supply the two sets of key valuesdescribed below and obtain the ciphertext value thatresults from AES encryption of an allzeros plaintextusing the given key value and an IV of all zeros. Thefirst set of keys shall have 128 128bit keys, and thesecond set shall have 256 256bit keys. Key i in each setshall have the leftmost i bits be ones and the rightmostNi bits be zeros, for i in [1,N]. To test the decryptfunctionality of AESCBC, the evaluator will supply thetwo sets of key and ciphertext value pairs describedbelow and obtain the plaintext value that results fromAESCBC decryption of the given ciphertext using thegiven key and an IV of all zeros. The first set ofkey/ciphertext pairs shall have 128 128bitkey/ciphertext pairs, and the second set ofkey/ciphertext pairs shall have 256 256bitkey/ciphertext pairs. Key i in each set shall have theleftmost i bits be ones and the rightmost Ni bits bezeros, for i in [1,N]. The ciphertext value in each pairshall be the value that results in an allzeros plaintextwhen decrypted with its corresponding key.KAT4. To test the encrypt functionality of AESCBC,the evaluator will supply the set of 128 plaintext valuesdescribed below and obtain the two ciphertext valuesthat result from AESCBC encryption of the givenplaintext using a 128bit key value of all zeros with anIV of all zeros and using a 256bit key value of all zeroswith an IV of all zeros, respectively. Plaintext value i ineach set shall have the leftmost i bits be ones and therightmost 128i bits be zeros, for i in [1,128].

To test the decrypt functionality of AESCBC, the evaluatorwill perform the same test as for encrypt, using ciphertextvalues of the same form as the plaintext in the encrypt test asinput and AESCBC decryption.

AESCBC MultiBlock Message TestThe evaluator will test the encrypt functionality by encryptingan iblock message where 1 < i ≤ 10. The evaluator willchoose a key, an IV and plaintext message of length i blocksand encrypt the message, using the mode to be tested, withthe chosen key and IV. The ciphertext shall be compared tothe result of encrypting the same plaintext message with thesame key and IV using a known good implementation. Theevaluator will also test the decrypt functionality for eachmode by decrypting an iblock message where 1 < i ≤10. Theevaluator will choose a key, an IV and a ciphertext messageof length i blocks and decrypt the message, using the mode tobe tested, with the chosen key and IV. The plaintext shall becompared to the result of decrypting the same ciphertextmessage with the same key and IV using a known goodimplementation.

AESCBC Monte Carlo TestsThe evaluator will test the encrypt functionality using a set of200 plaintext, IV, and key 3 tuples. 100 of these shall use 128bit keys, and 100 shall use 256 bit keys. The plaintext and IVvalues shall be 128bit blocks. For each 3tuple, 1000iterations shall be run as follows: # Input: PT, IV, Key for i = 1 to 1000: if i == 1: CT[1] = 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[1000]) is the result for that trial. This result shall becompared to the result of running 1000 iterations with thesame values using a known good implementation.

The evaluator will test the decrypt functionality using thesame test as for encrypt, exchanging CT and PT andreplacing AESCBCEncrypt with AESCBCDecrypt.

AESGCM Monte Carlo TestsThe evaluator will test the authenticated encrypt functionalityof AESGCM for each combination of the following inputparameter lengths:

128 bit and 256 bit keysTwo plaintext lengths. One of the plaintext lengths shall

be a nonzero integer multiple of 128 bits, if supported.The other plaintext length shall not be an integermultiple of 128 bits, if supported.Three AAD lengths. One AAD length shall be 0, ifsupported. One AAD length shall be a nonzero integermultiple of 128 bits, if supported. One AAD length shallnot be an integer multiple of 128 bits, if supported.Two IV lengths. If 96 bit IV is supported, 96 bits shallbe one of the two IV lengths tested.

The evaluator will test the encrypt functionality using a set of10 key, plaintext, AAD, and IV tuples for each combination ofparameter lengths above and obtain the ciphertext value andtag that results from AESGCM authenticated encrypt. Eachsupported tag length shall be tested at least once per set of10. The IV value may be supplied by the evaluator or theimplementation being tested, as long as it is known.

The evaluator will test the decrypt functionality using a set of10 key, ciphertext, tag, AAD, and IV 5tuples for eachcombination of parameter lengths above and obtain aPass/Fail result on authentication and the decrypted plaintextif Pass. The set shall include five tuples that Pass and fivethat Fail.

The results from each test may either be obtained by theevaluator directly or by supplying the inputs to theimplementer and receiving the results in response. Todetermine correctness, the evaluator will compare theresulting values to those obtained by submitting the sameinputs to a known good implementation.

AESCCM TestsThe evaluator will test the generationencryption anddecryptionverification functionality of AESCCM for thefollowing input parameter and tag lengths:

128 bit and 256 bit keysTwo payload lengths. One payload length shall be theshortest supported payload length, greater than orequal to zero bytes. The other payload length shall bethe longest supported payload length, less than or equalto 32 bytes (256 bits).Two or three associated data lengths. One associateddata length shall be 0, if supported. One associateddata length shall be the shortest supported payloadlength, greater than or equal to zero bytes. Oneassociated data length shall be the longest supportedpayload length, less than or equal to 32 bytes (256 bits).If the implementation supports an associated datalength of 2 16 bytes, an associated data length of 216bytes shall be tested.

Nonce lengths. All supported nonce lengths between 7and 13 bytes, inclusive, shall be tested.Tag lengths. All supported tag lengths of 4, 6, 8, 10, 12,14 and 16 bytes shall be tested.

To test the generationencryption functionality of AESCCM,the evaluator will perform the following four tests:

Test 1: For EACH supported key and associated datalength and ANY supported payload, nonce and taglength, the evaluator will supply one key value, onenonce value and 10 pairs of associated data andpayload values and obtain the resulting ciphertext.Test 2: For EACH supported key and payload lengthand ANY supported associated data, nonce and taglength, the evaluator will supply one key value, onenonce value and 10 pairs of associated data andpayload values and obtain the resulting ciphertext.Test 3: For EACH supported key and nonce length andANY supported associated data, payload and taglength, the evaluator will supply one key value and 10associated data, payload and nonce value 3tuples andobtain the resulting ciphertext.Test 4: For EACH supported key and tag length andANY supported associated data, payload and noncelength, the evaluator will supply one key value, onenonce value and 10 pairs of associated data andpayload values and obtain the resulting ciphertext.

To determine correctness in each of the above tests, theevaluator will compare the ciphertext with the result ofgenerationencryption of the same inputs with a known goodimplementation.

To test the decryptionverification functionality of AESCCM,for EACH combination of supported associated data length,payload length, nonce length and tag length, the evaluatorshall supply a key value and 15 nonce, associated data andciphertext 3tuples and obtain either a FAIL result or a PASSresult with the decrypted payload. The evaluator will supply10 tuples that should FAIL and 5 that should PASS per set of15.

Additionally, the evaluator will use tests from the IEEE802.1102/362r6 document “Proposed Test vectors for IEEE802.11 TGi”, dated September 10, 2002, Section 2.1AESCCMP Encapsulation Example and Section 2.2Additional AES CCMP Test Vectors to further verify theIEEE 802.112007 implementation of AESCCMP.

AESGCM TestThe evaluator will test the authenticated encrypt functionalityof AESGCM for each combination of the following input

parameter lengths:128 bit and 256 bit keysTwo plaintext lengths. One of the plaintext lengths shallbe a nonzero integer multiple of 128 bits, if supported.The other plaintext length shall not be an integermultiple of 128 bits, if supported.Three AAD lengths. One AAD length shall be 0, ifsupported. One AAD length shall be a nonzero integermultiple of 128 bits, if supported. One AAD length shallnot be an integer multiple of 128 bits, if supported.Two IV lengths. If 96 bit IV is supported, 96 bits shallbe one of the two IV lengths tested.

The evaluator will test the encrypt functionality using a set of10 key, plaintext, AAD, and IV tuples for each combination ofparameter lengths above and obtain the ciphertext value andtag that results from AESGCM authenticated encrypt. Eachsupported tag length shall be tested at least once per set of10. The IV value may be supplied by the evaluator or theimplementation being tested, as long as it is known.

The evaluator will test the decrypt functionality using a set of10 key, ciphertext, tag, AAD, and IV 5tuples for eachcombination of parameter lengths above and obtain aPass/Fail result on authentication and the decrypted plaintextif Pass. The set shall include five tuples that Pass and fivethat Fail.

The results from each test may either be obtained by theevaluator directly or by supplying the inputs to theimplementer and receiving the results in response. Todetermine correctness, the evaluator will compare theresulting values to those obtained by submitting the sameinputs to a known good implementation.

XTSAES TestThe evaluator will test the encrypt functionality of XTSAESfor each combination of the following input parameterlengths:

256 bit (for AES128) and 512 bit (for AES256) keysThree data unit (i.e., plaintext) lengths. One of the dataunit lengths shall be a nonzero integer multiple of 128bits, if supported. One of the data unit lengths shall bean integer multiple of 128 bits, if supported. The thirddata unit length shall be either the longest supporteddata unit length or 216 bits, whichever is smaller.

using a set of 100 (key, plaintext and 128bit random tweakvalue) 3tuples and obtain the ciphertext that results fromXTSAES encrypt.

The evaluator may supply a data unit sequence number

instead of the tweak value if the implementation supports it.The data unit sequence number is a base10 number rangingbetween 0 and 255 that implementations convert to a tweakvalue internally.

The evaluator will test the decrypt functionality of XTSAESusing the same test as for encrypt, replacing plaintext valueswith ciphertext values and XTSAES encrypt with XTSAESdecrypt.

AES Key Wrap (AESKW) and Key Wrap with Padding(AESKWP) TestThe evaluator will test the authenticated encryptionfunctionality of AESKW for EACH combination of thefollowing input parameter lengths:

128 and 256 bit key encryption keys (KEKs)Three plaintext lengths. One of the plaintext lengthsshall be two semiblocks (128 bits). One of the plaintextlengths shall be three semiblocks (192 bits). The thirddata unit length shall be the longest supported plaintextlength less than or equal to 64 semiblocks (4096 bits).

using a set of 100 key and plaintext pairs and obtain theciphertext that results from AESKW authenticatedencryption. To determine correctness, the evaluator will usethe AESKW authenticatedencryption function of a knowngood implementation.

The evaluator will test the authenticateddecryptionfunctionality of AESKW using the same test as forauthenticatedencryption, replacing plaintext values withciphertext values and AESKW authenticatedencryption withAESKW authenticateddecryption.

The evaluator will test the authenticatedencryptionfunctionality of AESKWP using the same test as for AESKWauthenticatedencryption with the following change in thethree plaintext lengths:

One plaintext length shall be one octet. One plaintextlength shall be 20 octets (160 bits).One plaintext length shall be the longest supportedplaintext length less than or equal to 512 octets (4096bits).

The evaluator will test the authenticateddecryptionfunctionality of AESKWP using the same test as for AESKWP authenticatedencryption, replacing plaintext valueswith ciphertext values and AESKWP authenticatedencryption with AESKWP authenticateddecryption.

FCS_COP.1(2) Cryptographic Operation Hashing

FCS_COP.1.1(2)The OS shall perform cryptographic hashing services in accordance witha specified cryptographic algorithm SHA1 and [selection:

SHA256,SHA384,SHA512,no other algorithms

] and message digest sizes 160 and [selection:256,384,512,no other message digest sizes

] bits that meet the following: FIPS Pub 1804.

Application Note: Per NIST SP 800131A, SHA1 for generatingdigital signatures is no longer allowed, and SHA1 for verification ofdigital signatures is strongly discouraged as there may be risk inaccepting these signatures.

SHA1 is currently required in order to comply with FCS_TLSC_EXT.1and, depending on selections, FCS_DTLS_EXT.1. Vendors are stronglyencouraged to implement updated protocols that support the SHA2family; until updated protocols are supported, this PP allows support forSHA1 implementations in compliance with SP 800131A.

The intent of this requirement is to specify the hashing function. The hashselection must support the message digest size selection. The hashselection should be consistent with the overall strength of the algorithmused.

Assurance Activity

The evaluator will check that the association of the hashfunction with other application cryptographic functions (forexample, the digital signature verification function) isdocumented in the TSS.

The TSF hashing functions can be implemented in one of twomodes. The first mode is the byteoriented mode. In this modethe TSF only hashes messages that are an integral number ofbytes in length; i.e., the length (in bits) of the message to behashed is divisible by 8. The second mode is the bitorientedmode. In this mode the TSF hashes messages of arbitrarylength. As there are different tests for each mode, anindication is given in the following sections for the bitoriented vs. the byteoriented testmacs. The evaluator willperform all of the following tests for each hash algorithmimplemented by the TSF and used to satisfy the requirementsof this PP.

The following tests require the developer to provide access toa test application that provides the evaluator with tools thatare typically not found in the production application.

Test 1: Short Messages Test (Bit oriented Mode) Theevaluator will generate an input set consisting of m+1messages, where m is the block length of the hashalgorithm. The length of the messages rangesequentially from 0 to m bits. The message text shall bepseudorandomly generated. The evaluator will computethe message digest for each of the messages and ensurethat the correct result is produced when the messagesare provided to the TSF.Test 2: Short Messages Test (Byte oriented Mode) Theevaluator will generate an input set consisting ofm/8+1 messages, where m is the block length of thehash algorithm. The length of the messages rangesequentially from 0 to m/8 bytes, with each messagebeing an integral number of bytes. The message textshall be pseudorandomly generated. The evaluator willcompute the message digest for each of the messagesand ensure that the correct result is produced when themessages are provided to the TSF.Test 3: Selected Long Messages Test (Bit orientedMode) The evaluator will generate an input setconsisting of m messages, where m is the block lengthof the hash algorithm. The length of the ith message is512 + 99⋅i, where 1 ≤ i ≤ m. The message text shall bepseudorandomly generated. The evaluator will computethe message digest for each of the messages and ensurethat the correct result is produced when the messagesare provided to the TSF.Test 4: Selected Long Messages Test (Byte orientedMode) The evaluator will generate an input setconsisting of m/8 messages, where m is the block lengthof the hash algorithm. The length of the ith message is512 + 8⋅99⋅i, where 1 ≤ i ≤ m/8. The message text shallbe pseudorandomly generated. The evaluator willcompute the message digest for each of the messagesand ensure that the correct result is produced when themessages are provided to the TSF.Test 5: Pseudorandomly Generated Messages Test This test is for byteoriented implementations only. Theevaluator will randomly generate a seed that is n bitslong, where n is the length of the message digestproduced by the hash function to be tested. Theevaluator will then formulate a set of 100 messages andassociated digests by following the algorithm providedin Figure 1 of [SHAVS]. The evaluator will then ensurethat the correct result is produced when the messagesare provided to the TSF.

FCS_COP.1(3) Cryptographic Operation Signing

FCS_COP.1.1(3)The OS shall perform cryptographic signature services (generation andverification) in accordance with a specified cryptographic algorithm[selection:

RSA schemes using cryptographic key sizes of 2048bit orgreater that meet the following: FIPS PUB 1864, “DigitalSignature Standard (DSS)”, Section 4 ,ECDSA schemes using “NIST curves” P256, P384 and[selection: P521, no other curves] that meet the following:FIPS PUB 1864, “Digital Signature Standard (DSS)”,Section 5

] .

Application Note: The ST Author should choose the algorithmimplemented to perform digital signatures; if more than one algorithm isavailable, this requirement should be iterated to specify the functionality.For the algorithm chosen, the ST author should make the appropriateassignments/selections to specify the parameters that are implementedfor that algorithm. RSA signature generation and verification is currentlyrequired in order to comply with FCS_TLSC_EXT.1.

Assurance Activity

The evaluator will perform the following activities based onthe selections in the ST.

The following tests require the developer to provide access toa test application that provides the evaluator with tools thatare typically not found in the production application.

ECDSA Algorithm TestsTest 1: ECDSA FIPS 1864 Signature Generation Test.For each supported NIST curve (i.e., P256, P384 andP521) and SHA function pair, the evaluator willgenerate 10 1024bit long messages and obtain foreach message a public key and the resulting signaturevalues R and S. To determine correctness, the evaluatorwill use the signature verification function of a knowngood implementation.Test 2: ECDSA FIPS 1864 Signature Verification Test.For each supported NIST curve (i.e., P256, P384 andP521) and SHA function pair, the evaluator willgenerate a set of 10 1024bit message, public key andsignature tuples and modify one of the values (message,public key or signature) in five of the 10 tuples. Theevaluator will verify that 5 reponses indicate success

and 5 reponses indicate failure.

RSA Signature Algorithm TestsTest 1: Signature Generation Test. The evaluator willverify the implementation of RSA Signature Generationby the OS using the Signature Generation Test. Toconduct this test the evaluator must generate or obtain10 messages from a trusted reference implementationfor each modulus size/SHA combination supported bythe TSF. The evaluator will have the OS use its privatekey and modulus value to sign these messages. Theevaluator will verify the correctness of the TSF’ssignature using a known good implementation and theassociated public keys to verify the signatures.Test 2: Signature Verification Test. The evaluator willperform the Signature Verification test to verify theability of the OS to recognize another party’s valid andinvalid signatures. The evaluator will inject errors intothe test vectors produced during the SignatureVerification Test by introducing errors in some of thepublic keys, e, messages, IR format, and/or signatures.The evaluator will verify that the OS returns failurewhen validating each signature.

FCS_COP.1(4) Cryptographic Operation KeyedHash MessageAuthentication

FCS_COP.1.1(4)The OS shall perform keyedhash message authentication services inaccordance with a specified cryptographic algorithm [selection:

SHA1,SHA256,SHA384,SHA512,no other algorithms

] with key sizes [assignment: key size (in bits) used in HMAC] andmessage digest sizes [selection: 160, 256, 384, 512, no other size]bits that meet the following: FIPS Pub 1981 The KeyedHashMessage Authentication Code and FIPS Pub 1804 Secure HashStandard.

Application Note: The intent of this requirement is to specify thekeyedhash message authentication function used for key establishmentpurposes for the various cryptographic protocols used by the OS (e.g.,trusted channel). The hash selection must support the message digestsize selection. The hash selection should be consistent with the overallstrength of the algorithm used for FCS_COP.1(1). Though HMAC withSHA256 (HMACSHA256) is listed as a selectable cipher suite inthis requirement, FCS_TLSC_EXT.1 effectively makes its

implementation mandatory for compliant OSs.

SHA1 is currently required in order to comply with FCS_TLSC_EXT.1and, depending on selections, FCS_DTLS_EXT.1. SHA1 is currentlyrequired in order to comply with FCS_TLSC_EXT.1, but has beendeprecated and should not be used for any other purpose beyond TLSand DTLS.

Assurance Activity

The evaluator will perform the following activities based onthe selections in the ST.

For each of the supported parameter sets, the evaluator willcompose 15 sets of test data. Each set shall consist of a keyand message data. The evaluator will have the OS generateHMAC tags for these sets of test data. The resulting MACtags shall be compared against the result of generatingHMAC tags with the same key and IV using a knowngoodimplementation.

FCS_RBG_EXT.1 Random Bit Generation

FCS_RBG_EXT.1.1The OS shall perform all deterministic random bit generation (DRBG)services in accordance with [selection, at least one of:

NIST Special Publication 80090A using [selection:Hash_DRBG (any), HMAC_DRBG (any), CTR_DRBG (AES)],FIPS Pub 1402 Annex C: X9.31 Appendix 2.4 using AES

] .

Application Note: The ST author should select the standard to whichthe RBG services comply (either SP 80090A or FIPS 1402 AnnexC).

SP 80090A contains three different methods of generating randomnumbers; each of these, in turn, depends on underlying cryptographicprimitives (hash functions/ciphers). The ST author will select the functionused (if SP 80090A is selected), and include the specific underlyingcryptographic primitives used in the requirement or in the TSS. Whileany of the identified hash functions (SHA1, SHA224, SHA256,SHA384, SHA512) are allowed for Hash_DRBG orHMAC_DRBG, only AESbased implementations for CTR_DRBG areallowed.

Note that for FIPS Pub 1402 Annex C, currently only the methoddescribed in NISTRecommended Random Number Generator basedon ANSI X9.31 Appendix A.2.4, Section 3 is valid. Use of this DRBGis disallowed after 2015 per NIST SP 800131A. The PP will be

updated to reflect this; however, developers should begin transitioningfrom this DRBG as soon as possible.

Assurance Activity

The evaluator will perform the following tests, depending onthe standard to which the RBG conforms.

Implementations Conforming to FIPS 1402 Annex C.

The reference for the tests contained in this section is TheRandom Number Generator Validation System (RNGVS). Theevaluator will conduct the following two tests. Note that the"expected values" are produced by a referenceimplementation of the algorithm that is known to be correct.Proof of correctness is left to each Scheme.

Test 1: The evaluator will perform a Variable SeedTest. The evaluator will provide a set of 128 (Seed, DT)pairs to the TSF RBG function, each 128 bits. Theevaluator will also provide a key (of the lengthappropriate to the AES algorithm) that is constant forall 128 (Seed, DT) pairs. The DT value is incrementedby 1 for each set. The seed values shall have no repeatswithin the set. The evaluator will ensure that the valuesreturned by the TSF match the expected values.Test 2: The evaluator will perform a Monte Carlo Test.For this test, they supply an initial Seed and DT valueto the TSF RBG function; each of these is 128 bits. Theevaluator will also provide a key (of the lengthappropriate to the AES algorithm) that is constantthroughout the test. The evaluator then invoke the TSFRBG 10,000 times, with the DT value beingincremented by 1 on each iteration, and the new seedfor the subsequent iteration produced as specified inNISTRecommended Random Number Generator basedon ANSI X9.31 Appendix A.2.4 Using the 3Key TripleDES and AES Algorithms, Section 3. The evaluatorensure that the 10,000th value produced matches theexpected value.

Implementations Conforming to NIST Special Publication80090A

Test 1: The evaluator will perform 15 trials for theRNG implementation. If the RNG is configurable, theevaluator will perform 15 trials for each configuration.The evaluator will also confirm that the operationalguidance contains appropriate instructions forconfiguring the RNG functionality.

If the RNG has prediction resistance enabled, each trialconsists of (1) instantiate DRBG, (2) generate the first

block of random bits (3) generate a second block ofrandom bits (4) uninstantiate. The evaluator verifiesthat the second block of random bits is the expectedvalue. The evaluator will generate eight input valuesfor each trial. The first is a count (0 – 14). The nextthree are entropy input, nonce, and personalizationstring for the instantiate operation. The next two areadditional input and entropy input for the first call togenerate. The final two are additional input andentropy input for the second call to generate. Thesevalues are randomly generated. “generate one block ofrandom bits” means to generate random bits withnumber of returned bits equal to the Output BlockLength (as defined in NIST SP 80090A).

If the RNG does not have prediction resistance, eachtrial consists of (1) instantiate DRBG, (2) generate thefirst block of random bits (3) reseed, (4) generate asecond block of random bits (5) uninstantiate. Theevaluator verifies that the second block of random bitsis the expected value. The evaluator will generate eightinput values for each trial. The first is a count (0 – 14).The next three are entropy input, nonce, andpersonalization string for the instantiate operation. Thefifth value is additional input to the first call togenerate. The sixth and seventh are additional inputand entropy input to the call to reseed. The final valueis additional input to the second generate call.

The following paragraphs contain more information onsome of the input values to be generated/selected by theevaluator.

Entropy input: the length of the entropy input valuemust equal the seed length.

Nonce: If a nonce is supported (CTR_DRBG with noDerivation Function does not use a nonce), the noncebit length is onehalf the seed length.

Personalization string: The length of thepersonalization string must be less than or equal to seedlength. If the implementation only supports onepersonalization string length, then the same length canbe used for both values. If more than one string lengthis support, the evaluator will use personalization stringsof two different lengths. If the implementation does notuse a personalization string, no value needs to besupplied.

Additional input: the additional input bit lengths have

the same defaults and restrictions as thepersonalization string lengths.

FCS_RBG_EXT.1.2The deterministic RBG used by the OS shall be seeded by an entropysource that accumulates entropy from a [selection:

softwarebased noise source,platformbased noise source

] with a minimum of [selection:128 bits,256 bits

] of entropy at least equal to the greatest security strength (according toNIST SP 80057) of the keys and hashes that it will generate.

Application Note: For the first selection in this requirement, the STauthor selects 'softwarebased noise source' if any additional noisesources are used as input to the DRBG.

In the second selection in this requirement, the ST author selects theappropriate number of bits of entropy that corresponds to the greatestsecurity strength of the algorithms included in the ST. Security strength isdefined in Tables 2 and 3 of NIST SP 80057A. For example, if theimplementation includes 2048bit RSA (security strength of 112 bits),AES 128 (security strength 128 bits), and HMACSHA256 (securitystrength 256 bits), then the ST author would select 256 bits.

Assurance Activity

Documentation shall be produced and the evaluator willperform the activities in accordance with Appendix E andthe Clarification to the Entropy Documentation andAssessment Annex.

In the future, specific statistical testing (in line with NIST SP80090B) will be required to verify the entropy estimates.

FCS_STO_EXT.1 Storage of Sensitive Data

FCS_STO_EXT.1.1The OS shall implement functionality to encrypt sensitive data stored innonvolatile storage and provide interfaces to applications to invoke thisfunctionality.

Application Note: Sensitive data shall be identified in the TSS by theST author, and minimally includes credentials and keys. The interface forinvoking the functionality could take a variety of forms: it could consist ofan API, or simply welldocumented conventions for accessingcredentials stored as files.

Assurance Activity

The evaluator will check the TSS to ensure that it lists allpersistent sensitive data for which the OS provides a storagecapability. For each of these items, the evaluator will confirmthat the TSS lists for what purpose it can be used, and how itis stored. The evaluator will confirm that cryptographicoperations used to protect the data occur as specified inFCS_COP.1(1).

The evaluator will also consult the developer documentationto verify that an interface exists for applications to securelystore credentials.

FCS_TLSC_EXT.1 TLS Client Protocol

FCS_TLSC_EXT.1.1The OS shall implement TLS 1.2 (RFC 5246) supporting the followingcipher suites:Mandatory cipher suites: TLS_RSA_WITH_AES_128_CBC_SHA asdefined in RFC 5246Optional cipher suites: [selection:

TLS_DHE_RSA_WITH_AES_128_CBC_SHA as defined inRFC 5246,TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 as definedin RFC 5246,TLS_DHE_RSA_WITH_AES_256_CBC_SHA as defined inRFC 5246,TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 as definedin RFC 5246,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA asdefined in RFC 4492,TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 asdefined in RFC 5289,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 asdefined in RFC 5289,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA asdefined in RFC 4492,TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 asdefined in RFC 5289,TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 asdefined in RFC 5289,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA as definedin RFC 4492,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 asdefined in RFC 5289,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as

defined in RFC 5289,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA as definedin RFC 4492,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 asdefined in RFC 5289,TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 asdefined in RFC 5289,TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC5246,TLS_RSA_WITH_AES_256_CBC_SHA as defined in RFC5246,TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC5246,no other cipher suite

] .

Application Note: The cipher suites to be tested in the evaluatedconfiguration are limited by this requirement. The ST author shouldselect the optional cipher suites that are supported; if there are no ciphersuites supported other than the mandatory suites, then “No other ciphersuite” should be selected. It is necessary to limit the cipher suites thatcan be used in an evaluated configuration administratively on the serverin the test environment. The Suite B algorithms listed above (RFC 6460)are the preferred algorithms for implementation.TLS_RSA_WITH_AES_128_CBC_SHA is required in order toensure compliance with RFC 5246.

These requirements will be revisited as new TLS versions arestandardized by the IETF.

If any cipher suites are selected using ECDHE, thenFCS_TLSC_EXT.2.1 is required.

Assurance Activity

The evaluator will check the description of theimplementation of this protocol in the TSS to ensure that thecipher suites supported are specified. The evaluator will checkthe TSS to ensure that the cipher suites specified include thoselisted for this component. The evaluator will also check theoperational guidance to ensure that it contains instructions onconfiguring the OS so that TLS conforms to the description inthe TSS. The evaluator will also perform the following tests:

Test 1: The evaluator will establish a TLS connectionusing each of the cipher suites specified by therequirement. This connection may be established aspart of the establishment of a higherlevel protocol,e.g., as part of an EAP session. It is sufficient toobserve the successful negotiation of a cipher suite to

satisfy the intent of the test; it is not necessary toexamine the characteristics of the encrypted traffic inan attempt to discern the cipher suite being used (forexample, that the cryptographic algorithm is 128bitAES and not 256bit AES).Test 2: The evaluator will attempt to establish theconnection using a server with a server certificate thatcontains the Server Authentication purpose in theextendedKeyUsage field and verify that a connection isestablished. The evaluator will then verify that theclient rejects an otherwise valid server certificate thatlacks the Server Authentication purpose in theextendedKeyUsage field and a connection is notestablished. Ideally, the two certificates should beidentical except for the extendedKeyUsage field.Test 3: The evaluator will send a server certificate inthe TLS connection that does not match the serverselected cipher suite (for example, send a ECDSAcertificate while using theTLS_RSA_WITH_AES_128_CBC_SHA cipher suite orsend a RSA certificate while using one of the ECDSAcipher suites.) The evaluator will verify that the OSdisconnects after receiving the server’s Certificatehandshake message.Test 4: The evaluator will configure the server to selectthe TLS_NULL_WITH_NULL_NULL cipher suite andverify that the client denies the connection.Test 5: The evaluator will perform the followingmodifications to the traffic:

Test 5.1: Change the TLS version selected by theserver in the Server Hello to a nonsupportedTLS version (for example 1.3 represented by thetwo bytes 03 04) and verify that the client rejectsthe connection.Test 5.2: Modify at least one byte in the server’snonce in the Server Hello handshake message,and verify that the client rejects the Server KeyExchange handshake message (if using a DHE orECDHE cipher suite) or that the server deniesthe client’s Finished handshake message.Test 5.3: Modify the server’s selected cipher suitein the Server Hello handshake message to be acipher suite not presented in the Client Hellohandshake message. The evaluator will verifythat the client rejects the connection afterreceiving the Server Hello.Test 5.4: Modify the signature block in theServer’s Key Exchange handshake message, andverify that the client rejects the connection afterreceiving the Server Key Exchange message.Test 5.5: Modify a byte in the Server Finished

handshake message, and verify that the clientsends a fatal alert upon receipt and does not sendany application data.Test 5.6: Send a garbled message from theServer after the Server has issued the ChangeCipher Spec message and verify that the clientdenies the connection.

FCS_TLSC_EXT.1.2The OS shall verify that the presented identifier matches the referenceidentifier according to RFC 6125.

Application Note: The rules for verification of identity are described inSection 6 of RFC 6125. The reference identifier is established by theuser (e.g. entering a URL into a web browser or clicking a link), byconfiguration (e.g. configuring the name of a mail server or authenticationserver), or by an application (e.g. a parameter of an API) depending onthe OS service. Based on a singular reference identifier’s source domainand application service type (e.g. HTTP, SIP, LDAP), the clientestablishes all reference identifiers which are acceptable, such as aCommon Name for the Subject Name field of the certificate and a(caseinsensitive) DNS name, URI name, and Service Name for theSubject Alternative Name field. The client then compares this list of allacceptable reference identifiers to the presented identifiers in the TLSserver’s certificate.

The preferred method for verification is the Subject Alternative Nameusing DNS names, URI names, or Service Names. Verification using theCommon Name is required for the purposes of backwardscompatibility. Additionally, support for use of IP addresses in theSubject Name or Subject Alternative name is discouraged, as againstbest practices, but may be implemented. Finally, the client should avoidconstructing reference identifiers using wildcards. However, if thepresented identifiers include wildcards, the client must follow the bestpractices regarding matching; these best practices are captured in theassurance activity.

Assurance Activity

The evaluator will ensure that the TSS describes the client’smethod of establishing all reference identifiers from theapplicationconfigured reference identifier, including whichtypes of reference identifiers are supported (e.g. CommonName, DNS Name, URI Name, Service Name, or otherapplicationspecific Subject Alternative Names) and whetherIP addresses and wildcards are supported. The evaluator willensure that this description identifies whether and the mannerin which certificate pinning is supported or used by the OS.

The evaluator will verify that the AGD guidance includes

instructions for setting the reference identifier to be used forthe purposes of certificate validation in TLS.

The evaluator will configure the reference identifieraccording to the AGD guidance and perform the followingtests during a TLS connection:

Test 1: The evaluator will present a server certificatethat does not contain an identifier in either the SubjectAlternative Name (SAN) or Common Name (CN) thatmatches the reference identifier. The evaluator willverify that the connection fails.Test 2: The evaluator will present a server certificatethat contains a CN that matches the referenceidentifier, contains the SAN extension, but does notcontain an identifier in the SAN that matches thereference identifier. The evaluator shall verify that theconnection fails. The evaluator will repeat this test foreach supported SAN type.Test 3: The evaluator will present a server certificatethat contains a CN that matches the reference identifierand does not contain the SAN extension. The evaluatorwill verify that the connection succeeds.Test 4: The evaluator will present a server certificatethat contains a CN that does not match the referenceidentifier but does contain an identifier in the SAN thatmatches. The evaluator will verify that the connectionsucceeds.Test 5: The evaluator will perform the followingwildcard tests with each supported type of referenceidentifier:

Test 5.1: The evaluator will present a servercertificate containing a wildcard that is not in theleftmost label of the presented identifier (e.g.foo.*.example.com) and verify that theconnection fails.Test 5.2: The evaluator will present a servercertificate containing a wildcard in the leftmostlabel but not preceding the public suffix (e.g.*.example.com). The evaluator will configure thereference identifier with a single leftmost label(e.g. foo.example.com) and verify that theconnection succeeds. The evaluator willconfigure the reference identifier without a leftmost label as in the certificate (e.g. example.com)and verify that the connection fails. Theevaluator will configure the reference identifierwith two leftmost labels (e.g.bar.foo.example.com) and verify that theconnection fails.Test 5.3: The evaluator will present a servercertificate containing a wildcard in the leftmost

label immediately preceding the public suffix (e.g.*.com). The evaluator will configure thereference identifier with a single leftmost label(e.g. foo.com) and verify that the connectionfails. The evaluator will configure the referenceidentifier with two leftmost labels (e.g.bar.foo.com) and verify that the connection fails.

Test 6: [conditional] If URI or Service name referenceidentifiers are supported, the evaluator will configurethe DNS name and the service identifier. The evaluatorwill present a server certificate containing the correctDNS name and service identifier in the URIName orSRVName fields of the SAN and verify that theconnection succeeds. The evaluator will repeat this testwith the wrong service identifier (but correct DNSname) and verify that the connection fails.Test 7: [conditional] If pinned certificates aresupported the evaluator will present a certificate thatdoes not match the pinned certificate and verify thatthe connection fails.

FCS_TLSC_EXT.1.3The OS shall only establish a trusted channel if the peer certificate isvalid.

Application Note: Validity is determined by the identifier verification,certificate path, the expiration date, and the revocation status inaccordance with RFC 5280. Certificate validity shall be tested inaccordance with testing performed for FIA_X509_EXT.1.

For TLS connections, this channel shall not be established if the peercertificate is invalid.

Assurance Activity

The evaluator will use TLS as a function to verify that thevalidation rules in FIA_X509_EXT.1.1 are adhered to andshall perform the following additional test:

Test 1: The evaluator will demonstrate that a peerusing a certificate without a valid certification pathresults in an authenticate failure. Using theadministrative guidance, the evaluator will then loadthe trusted CA certificate(s) needed to validate thepeer's certificate, and demonstrate that the connectionsucceeds. The evaluator then shall delete one of the CAcertificates, and show that the connection fails.Test 2: The evaluator will demonstrate that a peerusing a certificate which has been revoked results in anauthentication failure.

Test 3: The evaluator will demonstrate that a peerusing a certificate which has passed its expiration dateresults in an authentication failure.Test 4: the evaluator will demonstrate that a peer usinga certificate which does not have a valid identifier shallresult in an authentication failure.

5.1.2 User Data Protection (FDP)

FDP_ACF_EXT.1 Access Controls for Protecting User Data

FDP_ACF_EXT.1.1The OS shall implement access controls which can prohibit unprivilegedusers from accessing files and directories owned by other users.

Application Note: Effective protection by access controls may alsodepend upon system configuration. This requirement is designed toensure that, for example, files and directories owned by one user in amulti user system can be protected from access by another user in thatsystem.

Assurance Activity

The evaluator will confirm that the TSS comprehensivelydescribes the access control policy enforced by the OS. Thedescription must include the rules by which accesses toparticular files and directories are determined for particularusers. The evaluator will inspect the TSS to ensure that itdescribes the access control rules in such detail that given anypossible scenario between a user and a file governed by theOS the access control decision is unambiguous.

The evaluator will create two new standard user useraccounts on the system and conduct the following tests:

Test 1: The evaluator will authenticate to the system asthe first user and create a file within that user's homedirectory. The evaluator will then log off the systemand log in as the second user. The evaluator will thenattempt to read the file created in the first user's homedirectory. The evaluator will ensure that the readattempt is denied.Test 2: The evaluator will authenticate to the system asthe first user and create a file within that user's homedirectory. The evaluator will then log off the systemand log in as the second user. The evaluator will thenattempt to modify the file created in the first user'shome directory. The evaluator will ensure that themodification is denied.Test 3: The evaluator will authenticate to the system as

the first user and create a file within that user's userdirectory. The evaluator will then log off the systemand log in as the second user. The evaluator will thenattempt to delete the file created in the first user's homedirectory. The evaluator will ensure that the deletion isdenied.Test 4: The evaluator will authenticate to the system asthe first user. The evaluator will attempt to create a filein the second user's home directory. The evaluator willensure that the creation of the file is denied.Test 5: The evaluator will authenticate to the system asthe first user and attempt to modify the file created inthe first user's home directory. The evaluator willensure that the modification of the file is accepted.Test 6: The evaluator will authenticate to the system asthe first user and attempt to delete the file created inthe first user's directory. The evaluator will ensure thatthe deletion of the file is accepted.

FDP_IFC_EXT.1 Information flow control

FDP_IFC_EXT.1.1The OS shall [selection:

provide an interface which allows a VPN client to protect allIP traffic using IPsec ,provide a VPN client which can protects all IP traffic usingIPsec

] with the exception of IP traffic required to establish the VPNconnection.

Application Note: Typically, the traffic required to establish the VPNconnection is referred to as "Control Plane" traffic whereas the IP trafficprotected by the IPsec VPN is referred to as "Data Plane" traffic. All"Data Plane" traffic must flow through the VPN connection and theVPN must not splittunnel.

If no native IPsec client is validated or thirdparty VPN clients may alsoimplement the required Information Flow Control, the first option shallbe selected. In these cases, the TOE provides an API to thirdpartyVPN clients that allows them to configure the TOE’s network stack toperform the required Information Flow Control.

The ST author shall select the second option if the TSF implements anative VPN client (IPsec is selected in FTP_ITC_EXT.1). If the nativeVPN client is to be validated (IPsec is selected in FTP_ITC_EXT.1 andthe TSF is validated against the Extended Package for IPsec VirtualPrivate Network (VPN) Clients), the ST author shall also includeFDP_IFC_EXT from this package. In the future, this requirement mayalso make a distinction between the current requirement (which requiresthat when the IPsec trusted channel is enabled, all traffic from the TSF is

routed through that channel) and having an option to force theestablishment of an IPsec trusted channel to allow any communicationby the TSF.

Assurance Activity

The evaluator will verify that the TSS section of the STdescribes the routing of IP traffic when a VPN client isenabled. The evaluator will ensure that the descriptionindicates which traffic does not go through the VPN andwhich traffic does, and that a configuration exists for each inwhich only the traffic identified by the ST author as necessaryfor establishing the VPN connection (IKE traffic and perhapsHTTPS or DNS traffic) is not encapsulated by the VPNprotocol (IPsec).

5.1.3 Security Management (FMT)

FMT_MOF_EXT.1 Management of security functions behavior

FMT_MOF_EXT.1.1The OS shall be capable of performing the following managementfunctions, controlled by the user and overridden by an administrator asshown:

X: MandatoryO: Optional

Management Function Administrator User

configure minimum password length O O

configure minimum number of specialcharacters in password

O O

configure minimum number of numericcharacters in password

O O

configure minimum number of uppercasecharacters in password

O O

configure minimum number of lowercasecharacters in password

O O

enable/disable screen lock O O

configure screen lock inactivity timeout O O

configure remote connection inactivitytimeout

O O

enable/disable unauthenticated logon X X

configure lockout policy for unsuccessfulauthentication attempts through [selection:timeouts between attempts, limitingnumber of attempts during a timeperiod]

O O

configure hostbased firewall O O

configure name/address of directory serverto bind with

O O

configure name/address of remotemanagement server from which to receivemanagement settings

O O

configure name/address of audit/loggingserver to which to send audit/loggingrecords

O O

configure local audit storage capacity O O

configure audit rules O O

configure name/address of network timeserver

O O

enable/disable automatic software update O O

configure WiFi interface O O

enable/disable Bluetooth interface O O

configure USB interfaces O O

enable/disable [assignment: list of otherexternal interfaces]

O O

[assignment: list of other managementfunctions to be provided by the TSF]

O O

Application Note: The terms "Administrator" and "User" are defined inSection 1.2.2. The intent of this requirement is to ensure that the ST ispopulated with the management functions that are provided by the OS.This enables developers of compliance checklists, including thoseprovided as operational user guidance as specified in AGD_OPE.1.3C,to leverage this table by providing enterprisespecific values for eachevaluated item.

Sophisticated account management policies, such as intricate passwordcomplexity requirements and handling of temporary accounts, are afunction of directory servers. The OS can enroll in such account

management and enable the overall information system to achieve suchpolicies by binding to a directory server.

In cases where both the user and administrator can control a particularmanagement function, if an administrator has not set a policy then theuser may be permitted to perform that function. The ST author shoulduse a "" (instead of "X") to indicate where management is not provided.

Assurance Activity

The evaluator will verify that every management functioncaptured in the ST is described in the operational guidanceand that the description contains the information required toperform the management duties associated with themanagement function. The evaluator will test the operatingsystem's ability to provide the management functions byconfiguring the operating system and testing each optionselected from above. The evaluator is expected to test thesefunctions in all the ways in which the ST and guidancedocumentation state the configuration can be managed.

5.1.4 Protection of the TSF (FPT)

FPT_ACF_EXT.1 Access controls

FPT_ACF_EXT.1.1The OS shall implement access controls which prohibit unprivilegedusers from modifying:

Kernel and its drivers/modulesSecurity audit logsShared librariesSystem executablesSystem configuration files[assignment: other objects]

Assurance Activity

The evaluator will confirm that the TSS specifies the locationsof kernel drivers/modules, security audit logs, sharedlibraries, system executables, and system configuration files.Every file does not need to be individually identified, but thesystem's conventions for storing and protecting such filesmust be specified. The evaluator will create an unprivilegeduser account. Using this account, the evaluator will ensurethat the following tests result in a negative outcome (i.e., theaction results in the OS denying the evaluator permission tocomplete the action):

Test 1: The evaluator will attempt to modify all kernel

drivers and modules.Test 2: The evaluator will attempt to modify all securityaudit logs generated by the logging subsystem.Test 3: The evaluator will attempt to modify all sharedlibraries that are used throughout the system.Test 4: The evaluator will attempt to modify all systemexecutables.Test 5: The evaluator will attempt to modify all systemconfiguration files.Test 6: The evaluator will attempt to modify anyadditional components selected.

FPT_ACF_EXT.1.2The OS shall implement access controls which prohibit unprivilegedusers from reading:

Security audit logsSystemwide credential repositories[assignment: list of other objects]

Assurance Activity

The evaluator will create an unprivileged user account. Usingthis account, the evaluator will ensure that the following testsresult in a negative outcome (i.e., the action results in the OSdenying the evaluator permission to complete the action):

Test 1: The evaluator will attempt to read securityaudit logs generated by the auditing subsystemTest 2: The evaluator will attempt to read systemwidecredential repositoriesTest 3: The evaluator will attempt to read any otherobject specified in the assignment

FPT_ASLR_EXT.1 Address Space Layout Randomization

FPT_ASLR_EXT.1.1The OS shall always randomize process address space memorylocations except for [assignment: list of explicit exceptions] .

Assurance Activity

The evaluator will select 3 executables included with the TSF.These must include any web browser or mail client includedwith the TSF. For each of these apps, the evaluator willlaunch the same executables on two separate instances of theOS on identical hardware and compare all memory mappinglocations. The evaluator will ensure that no memorymappings are placed in the same location. If the rare chance

occurs that two mappings are the same for a singleexecutable and not the same for the other two, the evaluatorwill repeat the test with that executable to verify that in thesecond test the mappings are different.

FPT_SBOP_EXT.1 Stack Buffer Overflow Protection

FPT_SBOP_EXT.1.1The OS shall be compiled with stackbased buffer overflow protectionsenabled.

Application Note: It is expected that most of the OS, to include thekernel, libraries, and application software from the OS vendor becompiled with stackbased buffer overflow protection enabled.

Assurance Activity

The evaluator will determine that the TSS contains adescription of stackbased buffer overflow protections usedby the OS. Example implementations may be activatedthrough compiler options such as "fstackprotectorall", "fstackprotector", and "/GS" flags. These are referred to by avariety of terms, such as stack cookie, stack guard, and stackcanaries. The TSS must include a rationale for any binariesthat are not protected in this manner.

Test 1: The evaluator will inventory the kernel,libraries, and application binaries to determine thosethat do not implement stackbased buffer overflowprotections. This list should match up with the listprovided in the TSS.

FPT_TST_EXT.1 Boot Integrity

FPT_TST_EXT.1.1The OS shall verify the integrity of the bootchain up through the OSkernel and [selection:

all executable code stored in mutable media,[assignment: list of other executable code] ,no other executable code

] prior to its execution through the use of [selection:a digital signature using a hardwareprotected asymmetrickey,a hardwareprotected hash

]

Application Note: The bootchain of the OS is the sequence ofsoftware, to included the OS loader, the kernel, system drivers or

modules, and system files, which ultimately result in loading the OS. Thefirst part of the OS, usually referred to as the firststage bootloader,must be loaded by the platform. Assessing its integrity, while critical, isthe platform's responsibility; and therefore outside the scope of this PP.All software loaded after this stage is potentially within the control of theOS and is in scope.

The verification may be transitive in nature: a hardwareprotected publickey or hash may be used to verify the mutable bootloader code whichcontains a key or hash used by the bootloader to verify the mutable OSkernel code, which contains a key or hash to verify the next layer ofexecutable code, and so on. However, the way in which the hardwarestores and protects these keys is out of scope.

If all executable code (including bootloader(s), kernel, device drivers,preloaded applications, userloaded applications, and libraries) isverified, “all executable code stored in mutable media” should beselected.

Assurance Activity

The evaluator will verify that the TSS section of the STincludes a comprehensive description of the boot procedures,including a description of the entire bootchain, for the TSF.The evaluator will ensure that the OS cryptographicallyverifies each piece of software it loads in the bootchain toinclude bootloaders and the kernel. Software loaded forexecution directly by the platform (e.g. firststagebootloaders) is out of scope. For each additional category ofexecutable code verified before execution, the evaluator willverify that the description in the TSS describes how thatsoftware is cryptographically verified.

The evaluator will verify that the TSS contains a descriptionof the protection afforded to the mechanism performing thecryptographic verification.

The evaluator will perform the following tests:Test 1: The evaluator will perform actions to causeTSF software to load and observe that the integritymechanism does not flag any executables as containingintegrity errors and that the OS properly boots.Test 2: The evaluator will modify a TSF executablethat is part of the bootchain verified by the TSF (i.e.Not the firststage bootloader) and attempt to boot.The evaluator will ensure that an integrity violation istriggered and the OS does not boot (Care must betaken so that the integrity violation is determined to bethe cause of the failure to load the module, and not thefact that in such a way to invalidate the structure of the

module.).Test 3: If the ST author indicates that the integrityverification is performed using a public key, theevaluator will verify that the update mechanismincludes a certificate validation according toFIA_X509_EXT.1. The evaluator will digitally sign theTSF executable with a certificate that does not havethe Code Signing purpose in the extendedKeyUsagefield and verify that an integrity violation is triggered.The evaluator shall repeat the test using a certificatethat contains the Code Signing purpose and verify thatthe integrity verification succeeds. Ideally, the twocertificates should be identical except for theextendedKeyUsage field.

FPT_TUD_EXT.1 Integrity for Installation and Update

FPT_TUD_EXT.1.1The OS shall provide the ability to check for updates to the OSsoftware itself.

Application Note: This requirement is about the ability to check for theavailability of authentic updates, while the installation of authenticupdates is covered by FPT_TUD_EXT.1.2.

Assurance Activity

The evaluator will check for an update using proceduresdescribed in the documentation and verify that the OSprovides a list of available updates. Testing this capabilitymay require installing and temporarily placing the system intoa configuration in conflict with secure configuration guidancewhich specifies automatic update. (The evaluator is also toensure that this query occurs over a trusted channel asdescribed in FTP_ITC_EXT.1.)

FPT_TUD_EXT.1.2The OS shall cryptographically verify updates to itself using a digitalsignature prior to installation using schemes specified in FCS_COP.1(3).

Assurance Activity

For the following tests, the evaluator will initiate thedownload of an update and capture the update prior toinstallation. The download could originate from the vendor'swebsite, an enterprisehosted update repository, or anothersystem (e.g. network peer). All supported origins for theupdate must be indicated in the TSS and evaluated.

Test 1: The evaluator will ensure that the update has adigital signature belonging to the vendor prior to itsinstallation. The evaluator will modify the downloadedupdate in such a way that the digital signature is nolonger valid. The evaluator will then attempt to installthe modified update. The evaluator will ensure that theOS does not install the modified update.Test 2: The evaluator will ensure that the update has adigital signature belonging to the vendor. Theevaluator will then attempt to install the update (orpermit installation to continue). The evaluator willensure that the OS successfully installs the update.

FPT_TUD_EXT.2 Integrity for Installation and Update of ApplicationSoftware

FPT_TUD_EXT.2.1The OS shall provide the ability to check for updates to applicationsoftware.

Application Note: This requirement is about the ability to check forauthentic updates, while the actual installation of such updates is coveredby FPT_TUD_EXT.2.2.

Assurance Activity

The evaluator will check for updates to application softwareusing procedures described in the documentation and verifythat the OS provides a list of available updates. Testing thiscapability may require temporarily placing the system into aconfiguration in conflict with secure configuration guidancewhich specifies automatic update. (The evaluator is also toensure that this query occurs over a trusted channel asdescribed in FTP_ITC_EXT.1.)

FPT_TUD_EXT.2.2The OS shall cryptographically verify the integrity of updates toapplications using a digital signature specified by FCS_COP.1(3) priorto installation.

Assurance Activity

The evaluator will initiate an update to an application. Thismay vary depending on the application, but it could bethrough the application vendor's website, a commercial appstore, or another system. All origins supported by the OS mustbe indicated in the TSS and evaluated. However, this onlyincludes those mechanisms for which the OS is providing a

trusted installation and update functionality. It does notinclude user or administratordriven download andinstallation of arbitrary files.

Test 1: The evaluator will ensure that the update has adigital signature which chains to the OS vendor oranother trusted root managed through the OS. Theevaluator will modify the downloaded update in such away that the digital signature is no longer valid. Theevaluator will then attempt to install the modifiedupdate. The evaluator will ensure that the OS does notinstall the modified update.Test 2: The evaluator will ensure that the update has adigital signature belonging to the OS vendor or anothertrusted root managed through the OS. The evaluatorwill then attempt to install the update. The evaluatorwill ensure that the OS successfully installs the update.

5.1.5 Audit Data Generation (FAU)

FAU_GEN.1 Audit Data Generation

FAU_GEN.1.1The OS shall be able to generate an audit record of the followingauditable events:

a. Startup and shutdown of the audit functions;b. All auditable events for the not specified level of audit; andc.

Authentication events (Success/Failure);Use of privileged/special rights events (Successful andunsuccessful security, audit, and configuration changes);Privilege or role escalation events (Success/Failure);[selection:

File and object events (Successful andunsuccessful attempts to create, access, delete,modify, modify permissions),User and Group management events (Successfuland unsuccessful add, delete, modify, disable,Audit and log data access events(Success/Failure),Cryptographic verification of software(Success/Failure),Program initiations (Success/Failure e.g. due tosoftware restriction policy) ,System reboot, restart, and shutdown events(Success/Failure),Kernel module loading and unloading events(Success/Failure),

Administrator or rootlevel access events(Success/Failure),Command line input (Success/Failure),[assignment: other specifically defined auditableevents] .

]

Assurance Activity

The evaluator shall check the administrative guide and ensurethat it lists all of the auditable events. The evaluator shallcheck to make sure that every audit event type selected in theST is included.

The evaluator shall test the OS's ability to correctly generateaudit records by having the TOE generate audit records forthe events listed in the ST. This should include all instancetypes of an event specified. When verifying the test results, theevaluator shall ensure the audit records generated duringtesting match the format specified in the administrative guide,and that the fields in each audit record have the properentries.

FAU_GEN.1.2The OS shall record within each audit record at least the followinginformation:

a. Date and time of the event, type of event, subject identity (ifapplicable), and outcome (success or failure) of the event; and

b. For each audit event type, based on the auditable eventdefinitions of the functional components included in the PP/ST,[assignment: other audit relevant information]

.

Application Note: The term subject here is understood to be the userthat the process is acting on behalf of. If no auditable event definitions offunctional components are provided, then no additional auditrelevantinformation is required.

Assurance Activity

The evaluator shall check the administrative guide and ensurethat it provides a format for audit records. Each audit recordformat type must be covered, along with a brief description ofeach field. The evaluator shall ensure that the fields containsthe information required.

The evaluator shall test the OS's ability to correctly generate

audit records by having the TOE generate audit records forthe events listed in the ST. The evaluator shall ensure theaudit records generated during testing match the formatspecified in the administrative guide, and that the fields ineach audit record provide the required information.

5.1.6 Identification and Authentication (FIA)

FIA_AFL.1 Authentication failure handling

FIA_AFL.1.1The OS shall detect when [selection:

[assignment: a positive integer number] ,an administrator configurable positive integer within a[assignment: range of acceptable values]

] unsuccessful authentication attempts for [selection:authentication based on user name and password,authentication based on user name and a PIN that releasesan asymmetric key stored in OEprotected storage,authentication based on X.509 certificates

] occur related to [assignment: list of authentication events] .

Assurance Activity

The evaluator will set an administratorconfigurablethreshold for failed attempts, or note the STspecifiedassignment. The evaluator will then (per selection) repeatedlyattempt to authenticate with an incorrect password, PIN, orcertificate until the number of attempts reaches the threshold.Note that the authentication attempts and lockouts must alsobe logged as specified in FAU_GEN.1.

FIA_AFL.1.2When the defined number of unsuccessful authentication attempts for anaccount has been met, the OS shall: [selection: Account Lockout,Account Disablement, Mandatory Credential Reset, [assignment:list of actions] ]

Application Note: The action to be taken shall be populated in theassignment of the ST and defined in the administrator guidance.

Assurance Activity

Test 1: The evaluator will attempt to authenticaterepeatedly to the system with a known bad password.Once the defined number of failed authenticationattempts has been reached the evaluator will ensure

that the account that was being used for testing hashad the actions detailed in the assignment list aboveapplied to it. The evaluator will ensure that an eventhas been logged to the security event log detailing thatthe account has had these actions applied.Test 2: The evaluator will attempt to authenticaterepeatedly to the system with a known bad certificate.Once the defined number of failed authenticationattempts has been reached the evaluator will ensurethat the account that was being used for testing hashad the actions detailed in the assignment list aboveapplied to it. The evaluator will ensure that an eventhas been logged to the security event log detailing thatthe account has had these actions applied.Test 3: The evaluator will attempt to authenticaterepeatedly to the system using both a bad password anda bad certificate. Once the defined number of failedauthentication attempts has been reached the evaluatorwill ensure that the account that was being used fortesting has had the actions detailed in the assignmentlist above applied to it. The evaluator will ensure thatan event has been logged to the security event logdetailing that the account has had these actionsapplied.

FIA_UAU.5 Multiple Authentication Mechanisms

FIA_UAU.5.1The OS shall provide the following authentication mechanisms[selection:

authentication based on user name and password,authentication based on user name and a PIN that releasesan asymmetric key stored in OEprotected storage,authentication based on X.509 certificates

] to support user authentication.

Assurance Activity

If user name and password authentication is selected, theevaluator will configure the OS with a known user name andpassword and conduct the following tests:

Test 1: The evaluator will attempt to authenticate tothe OS using the known user name and password. Theevaluator will ensure that the authentication attempt issuccessful.Test 2: The evaluator will attempt to authenticate tothe OS using the known user name but an incorrectpassword. The evaluator will ensure that theauthentication attempt is unsuccessful.

If user name and PIN that releases an asymmetric key isselected, the evaluator will examine the TSS for guidance onsupported protected storage and will then configure the TOEor OE to establish a PIN which enables release of theasymmetric key from the protected storage (such as a TPM, ahardware token, or isolated execution environment) withwhich the OS can interface. The evaluator will then conductthe following tests:

Test 1: The evaluator will attempt to authenticate tothe OS using the known user name and PIN. Theevaluator will ensure that the authentication attempt issuccessful.Test 2: The evaluator will attempt to authenticate tothe OS using the known user name but an incorrectPIN. The evaluator will ensure that the authenticationattempt is unsuccessful.

If X.509 certificate authentication is selected, the evaluatorwill generate an X.509v3 certificate for a user with the ClientAuthentication Enhanced Key Usage field set. The evaluatorwill provision the OS for authentication with the X.509v3certificate. The evaluator will ensure that the certificates arevalidated by the OS as per FIA_X509_EXT.1.1 and thenconduct the following tests:

Test 1: The evaluator will attempt to authenticate tothe OS using the X.509v3 certificate. The evaluator willensure that the authentication attempt is successful.Test 2: The evaluator will generate a second certificateidentical to the first except for the public key and anyvalues derived from the public key. The evaluator willattempt to authenticate to the OS with this certificate.The evaluator will ensure that the authenticationattempt is unsuccessful.

FIA_X509_EXT.1 X.509 Certificate Validation

FIA_X509_EXT.1.1The OS shall implement functionality to validate certificates inaccordance with the following rules:

RFC 5280 certificate validation and certificate path validation.The certificate path must terminate with a trusted CA certificate.The OS shall validate a certificate path by ensuring the presenceof the basicConstraints extension and that the CA flag is set toTRUE for all CA certificates.The OS shall validate the revocation status of the certificate using[selection: the Online Certificate Status Protocol (OCSP) asspecified in RFC 2560, a Certificate Revocation List (CRL)as specified in RFC 5759, an OCSP TLS Status RequestExtension (i.e., OCSP stapling) as specified in RFC 6066] .The OS shall validate the extendedKeyUsage field according to

the following rules:Certificates used for trusted updates and executable codeintegrity verification shall have the Code Signing purpose(idkp 3 with OID 1.3.6.1.5.5.7.3.3) in theextendedKeyUsage field.Server certificates presented for TLS shall have the ServerAuthentication purpose (idkp 1 with OID1.3.6.1.5.5.7.3.1) in the extendedKeyUsage field.Client certificates presented for TLS shall have the ClientAuthentication purpose (idkp 2 with OID1.3.6.1.5.5.7.3.2) in the extendedKeyUsage field.S/MIME certificates presented for email encryption andsignature shall have the Email Protection purpose (idkp 4with OID 1.3.6.1.5.5.7.3.4) in the extendedKeyUsagefield.OCSP certificates presented for OCSP responses shallhave the OCSP Signing purpose (idkp 9 with OID1.3.6.1.5.5.7.3.9) in the extendedKeyUsage field.(Conditional) Server certificates presented for EST shallhave the CMC Registration Authority (RA) purpose (idkpcmcRA with OID 1.3.6.1.5.5.7.3.28) in theextendedKeyUsage field.

Application Note: FIA_X509_EXT.1.1 lists the rules for validatingcertificates. The ST author shall select whether revocation status isverified using OCSP or CRLs. FIA_X509_EXT.2 requires thatcertificates are used for HTTPS, TLS and DTLS; this use requires thatthe extendedKeyUsage rules are verified.

Assurance Activity

The evaluator will ensure the TSS describes where the checkof validity of the certificates takes place. The evaluatorensures the TSS also provides a description of the certificatepath validation algorithm.

The tests described must be performed in conjunction with theother certificate services assurance activities, including thefunctions in FIA_X509_EXT.2.1. The tests for theextendedKeyUsage rules are performed in conjunction withthe uses that require those rules. The evaluator will create achain of at least four certificates: the node certificate to betested, two Intermediate CAs, and the selfsigned Root CA.

Test 1: The evaluator will demonstrate that validatinga certificate without a valid certification path results inthe function failing. The evaluator will then load acertificate or certificates as trusted CAs needed tovalidate the certificate to be used in the function, anddemonstrate that the function succeeds. The evaluatorshall then delete one of the certificates, and show that

the function fails.Test 2: The evaluator will demonstrate that validatingan expired certificate results in the function failing.Test 3: The evaluator will test that the OS can properlyhandle revoked certificates–conditional on whetherCRL, OCSP, or OCSP stapling is selected; if multiplemethods are selected, then a test shall be performed foreach method. The evaluator will test revocation of thenode certificate and revocation of the intermediate CAcertificate (i.e. the intermediate CA certificate shouldbe revoked by the root CA). The evaluator will ensurethat a valid certificate is used, and that the validationfunction succeeds. The evaluator then attempts the testwith a certificate that has been revoked (for eachmethod chosen in the selection) to ensure when thecertificate is no longer valid that the validationfunction fails.Test 4: If either OCSP option is selected, the evaluatorwill configure the OCSP server or use a maninthemiddle tool to present a certificate that does not havethe OCSP signing purpose and verify that validation ofthe OCSP response fails. If CRL is selected, theevaluator will configure the CA to sign a CRL with acertificate that does not have the cRLsign key usage bitset, and verify that validation of the CRL fails.Test 5: The evaluator will modify any byte in the firsteight bytes of the certificate and demonstrate that thecertificate fails to validate. (The certificate should failto parse correctly.)Test 6: The evaluator will modify any byte in the lastbyte of the certificate and demonstrate that thecertificate fails to validate. (The signature on thecertificate should not validate.)Test 7: The evaluator will modify any byte in the publickey of the certificate and demonstrate that thecertificate fails to validate. (The signature on thecertificate should not validate.)

FIA_X509_EXT.1.2The OS shall only treat a certificate as a CA certificate if thebasicConstraints extension is present and the CA flag is set to TRUE.

Application Note: This requirement applies to certificates that are usedand processed by the TSF and restricts the certificates that may beadded as trusted CA certificates.

Assurance Activity

The tests described must be performed in conjunction with theother certificate services assurance activities, including the

functions in FIA_X509_EXT.2.1. The evaluator will create achain of at least four certificates: the node certificate to betested, two Intermediate CAs, and the selfsigned Root CA.

Test 1: The evaluator will construct a certificate path,such that the certificate of the CA issuing the OS'scertificate does not contain the basicConstraintsextension. The validation of the certificate path fails.Test 2: The evaluator will construct a certificate path,such that the certificate of the CA issuing the OS'scertificate has the CA flag in the basicConstraintsextension not set. The validation of the certificate pathfails.Test 3: The evaluator will construct a certificate path,such that the certificate of the CA issuing the OS'scertificate has the CA flag in the basicConstraintsextension set to TRUE. The validation of the certificatepath succeeds.

FIA_X509_EXT.2 X.509 Certificate Authentication

FIA_X509_EXT.2.1The OS shall use X.509v3 certificates as defined by RFC 5280 tosupport authentication for TLS and [selection: DTLS, HTTPS,[assignment: other protocols] , no other protocols] connections.

Assurance Activity

The evaluator will acquire or develop an application that usesthe OS TLS mechanism with an X.509v3 certificate. Theevaluator will then run the application and ensure that theprovided certificate is used to authenticate the connection.

The evaluator will repeat the activity for any other selectionslisted.

5.1.7 Trusted Path/Channels (FTP)

FTP_ITC_EXT.1 Trusted channel communication

FTP_ITC_EXT.1.1The OS shall use [selection:

TLS as conforming to FCS_TLSC_EXT.1,DTLS as conforming to FCS_DTLS_EXT.1,IPsec as conforming to the Extended Package for IPsec VPNClients,SSH as conforming to the Extended Package for Secure Shell

] to provide a trusted communication channel between itself and

authorized IT entities supporting the following capabilities: [selection:audit server, authentication server, management server,[assignment: other capabilities] ] that is logically distinct from othercommunication channels and provides assured identification of its endpoints and protection of the channel data from disclosure and detectionof modification of the channel data.

Application Note: If the ST author selects IPsec, the TSF shall bevalidated against the Extended Package for IPsec Virtual PrivateNetwork (VPN) Clients. If the ST author selects SSH, the TSF shallbe validated against the Extended Package for Secure Shell. The STauthor must include the security functional requirements for the trustedchannel protocol selected in FTP_ITC_EXT.1 in the main body of theST.

Assurance Activity

The evaluator will configure the OS to communicate withanother trusted IT product as identified in the secondselection. The evaluator will monitor network traffic while theOS performs communication with each of the serversidentified in the second selection. The evaluator will ensurethat for each session a trusted channel was established inconformance with the protocols identified in the firstselection.

FTP_TRP.1 Trusted Path

FTP_TRP.1.1The OS shall provide a communication path between itself and remoteusers that is logically distinct from other communication paths andprovides assured identification of its endpoints and protection of thecommunicated data from modification and disclosure.

FTP_TRP.1.2The OS shall permit [selection: the TSF, local users, remote users] toinitiate communication via the trusted path.

FTP_TRP.1.3The OS shall require use of the trusted path for all remote administrativeactions.

Application Note: This requirement ensures that authorized remoteadministrators initiate all communication with the OS via a trusted path,and that all communication with the OS by remote administrators isperformed over this path. The data passed in this trusted communicationchannel is encrypted as defined in FTP_ITC_EXT.1.

The assurance activities for this requirement also test requirementsFTP_TRP.1.1 and FTP_TRP.1.2.

Assurance Activity

The evaluator will examine the TSS to determine that themethods of remote OS administration are indicated, alongwith how those communications are protected. The evaluatorwill also confirm that all protocols listed in the TSS in supportof OS administration are consistent with those specified in therequirement, and are included in the requirements in the ST.The evaluator will confirm that the operational guidancecontains instructions for establishing the remoteadministrative sessions for each supported method. Theevaluator will also perform the following tests:

Test 1: The evaluator will ensure that communicationsusing each remote administration method is testedduring the course of the evaluation, setting up theconnections as described in the operational guidanceand ensuring that communication is successful.Test 2: For each method of remote administrationsupported, the evaluator will follow the operationalguidance to ensure that there is no available interfacethat can be used by a remote user to establish a remoteadministrative sessions without invoking the trustedpath.Test 3: The evaluator will ensure, for each method ofremote administration, the channel data is not sent inplaintext.Test 4: The evaluator will ensure, for each method ofremote administration, modification of the channeldata is detected by the OS.

5.2 Security Assurance Requirements

The Security Objectives in Section 4 were constructed to address threats identified in Section 3.1.The Security Functional Requirements (SFRs) in Section 5.1 are a formal instantiation of theSecurity Objectives. The PP identifies the Security Assurance Requirements (SARs) to frame theextent to which the evaluator assesses the documentation applicable for the evaluation andperforms independent testing.

This section lists the set of SARs from CC part 3 that are required in evaluations against this PP.Individual Assurance Activities to be performed are specified both in Section 5 as well as in thissection.

The general model for evaluation of OSs against STs written to conform to this PP is as follows:

After the ST has been approved for evaluation, the Information Technology Security EvaluationFacility (ITSEF) will obtain the OS, supporting environmental IT, and the administrative/userguides for the OS. The ITSEF is expected to perform actions mandated by the Common

Evaluation Methodology (CEM) for the ASE and ALC SARs. The ITSEF also performs theAssurance Activities contained within Section 5, which are intended to be an interpretation of theother CEM assurance requirements as they apply to the specific technology instantiated in the OS.The Assurance Activities that are captured in Section 5 also provide clarification as to what thedeveloper needs to provide to demonstrate the OS is compliant with the PP.

5.2.1 Class ASE: Security TargetAs per ASE activities defined in [CEM].

5.2.2 Class ADV: DevelopmentThe information about the OS is contained in the guidance documentation available to the end useras well as the TSS portion of the ST. The OS developer must concur with the description of theproduct that is contained in the TSS as it relates to the functional requirements. The AssuranceActivities contained in Section 5.1 should provide the ST authors with sufficient information todetermine the appropriate content for the TSS section.

ADV_FSP.1 Basic Functional Specification (ADV_FSP.1)

Developer action elements:

ADV_FSP.1.1DThe developer shall provide a functional specification.

ADV_FSP.1.2DThe developer shall provide a tracing from the functional specification tothe SFRs.

Application Note: As indicated in the introduction to this section, thefunctional specification is comprised of the information contained in theAGD_OPE and AGD_PRE documentation. The developer mayreference a website accessible to application developers and theevaluator. The assurance activities in the functional requirements point toevidence that should exist in the documentation and TSS section; sincethese are directly associated with the SFRs, the tracing in elementADV_FSP.1.2D is implicitly already done and no additionaldocumentation is necessary.

Content and presentation elements:

ADV_FSP.1.1CThe functional specification shall describe the purpose and method ofuse for each SFRenforcing and SFRsupporting TSFI.

ADV_FSP.1.2CThe functional specification shall identify all parameters associated witheach SFRenforcing and SFRsupporting TSFI.

ADV_FSP.1.3CThe functional specification shall provide rationale for the implicitcategorization of interfaces as SFRnoninterfering.

ADV_FSP.1.4CThe tracing shall demonstrate that the SFRs trace to TSFIs in thefunctional specification.

Evaluator action elements:

ADV_FSP.1.1EThe evaluator shall confirm that the information provided meets allrequirements for content and presentation of evidence.

ADV_FSP.1.2EThe evaluator shall determine that the functional specification is anaccurate and complete instantiation of the SFRs.

Assurance Activity

There are no specific assurance activities associated withthese SARs, except ensuring the information is provided. Thefunctional specification documentation is provided to supportthe evaluation activities described in Section 5.1, and otheractivities described for AGD, ATE, and AVA SARs. Therequirements on the content of the functional specificationinformation is implicitly assessed by virtue of the otherassurance activities being performed; if the evaluator isunable to perform an activity because there is insufficientinterface information, then an adequate functionalspecification has not been provided.

5.2.3 Class AGD: Guidance DocumentationThe guidance documents will be provided with the ST. Guidance must include a description ofhow the IT personnel verifies that the Operational Environment can fulfill its role for the securityfunctionality. The documentation should be in an informal style and readable by the IT personnel.Guidance must be provided for every operational environment that the product supports asclaimed in the ST. This guidance includes instructions to successfully install the TSF in thatenvironment; and Instructions to manage the security of the TSF as a product and as a componentof the larger operational environment. Guidance pertaining to particular security functionality is alsoprovided; requirements on such guidance are contained in the assurance activities specified witheach requirement.

AGD_OPE.1 Operational User Guidance (AGD_OPE.1)

Developer action elements:

AGD_OPE.1.1DThe developer shall provide operational user guidance.

Application Note: The operational user guidance does not have to becontained in a single document. Guidance to users, administrators andapplication developers can be spread among documents or web pages.Rather than repeat information here, the developer should review the

assurance activities for this component to ascertain the specifics of theguidance that the evaluator will be checking for. This will provide thenecessary information for the preparation of acceptable guidance.

Content and presentation elements:

AGD_OPE.1.1CThe operational user guidance shall describe, for each user role, theuseraccessible functions and privileges that should be controlled in asecure processing environment, including appropriate warnings.

Application Note: User and administrator are to be considered in thedefinition of user role.

AGD_OPE.1.2CThe operational user guidance shall describe, for each user role, how touse the available interfaces provided by the OS in a secure manner.

AGD_OPE.1.3CThe operational user guidance shall describe, for each user role, theavailable functions and interfaces, in particular all security parametersunder the control of the user, indicating secure values as appropriate.

Application Note: This portion of the operational user guidance shouldbe presented in the form of a checklist that can be quickly executed byIT personnel (or endusers, when necessary) and suitable for use incompliance activities. When possible, this guidance is to be expressed inthe eXtensible Configuration Checklist Description Format (XCCDF) tosupport security automation. Minimally, it should be presented in astructured format which includes a title for each configuration item,instructions for achieving the secure configuration, and any relevantrationale.

AGD_OPE.1.4CThe operational user guidance shall, for each user role, clearly presenteach type of securityrelevant event relative to the useraccessiblefunctions that need to be performed, including changing the securitycharacteristics of entities under the control of the TSF.

AGD_OPE.1.5CThe operational user guidance shall identify all possible modes ofoperation of the OS (including operation following failure or operationalerror), their consequences, and implications for maintaining secureoperation.

AGD_OPE.1.6CThe operational user guidance shall, for each user role, describe thesecurity measures to be followed in order to fulfill the security objectivesfor the operational environment as described in the ST.

AGD_OPE.1.7CThe operational user guidance shall be clear and reasonable.

Evaluator action elements:

AGD_OPE.1.1EThe evaluator shall confirm that the information provided meets allrequirements for content and presentation of evidence.

Assurance Activity

Some of the contents of the operational guidance are verifiedby the assurance activities in Section 5.1 and evaluation ofthe OS according to the [CEM]. The following additionalinformation is also required. If cryptographic functions areprovided by the OS, the operational guidance shall containinstructions for configuring the cryptographic engineassociated with the evaluated configuration of the OS. It shallprovide a warning to the administrator that use of othercryptographic engines was not evaluated nor tested duringthe CC evaluation of the OS. The documentation mustdescribe the process for verifying updates to the OS byverifying a digital signature – this may be done by the OS orthe underlying platform. The evaluator will verify that thisprocess includes the following steps: Instructions forobtaining the update itself. This should include instructionsfor making the update accessible to the OS (e.g., placement ina specific directory). Instructions for initiating the updateprocess, as well as discerning whether the process wassuccessful or unsuccessful. This includes generation of thehash/digital signature. The OS will likely contain securityfunctionality that does not fall in the scope of evaluationunder this PP. The operational guidance shall make it clear toan administrator which security functionality is covered bythe evaluation activities.

AGD_PRE.1 Preparative Procedures (AGD_PRE.1)

Developer action elements:

AGD_PRE.1.1DThe developer shall provide the OS, including its preparativeprocedures.

Application Note: As with the operational guidance, the developershould look to the assurance activities to determine the required contentwith respect to preparative procedures.

Content and presentation elements:

AGD_PRE.1.1CThe preparative procedures shall describe all the steps necessary forsecure acceptance of the delivered OS in accordance with the

developer's delivery procedures.

AGD_PRE.1.2CThe preparative procedures shall describe all the steps necessary forsecure installation of the OS and for the secure preparation of theoperational environment in accordance with the security objectives forthe operational environment as described in the ST.

Evaluator action elements:

AGD_PRE.1.1EThe evaluator shall confirm that the information provided meets allrequirements for content and presentation of evidence.

AGD_PRE.1.2EThe evaluator shall apply the preparative procedures to confirm that theOS can be prepared securely for operation.

Assurance Activity

As indicated in the introduction above, there are significantexpectations with respect to the documentation—especiallywhen configuring the operational environment to support OSfunctional requirements. The evaluator shall check to ensurethat the guidance provided for the OS adequately addressesall platforms claimed for the OS in the ST.

5.2.4 Class ALC: Lifecycle SupportAt the assurance level provided for OSs conformant to this PP, lifecycle support is limited to enduservisible aspects of the lifecycle, rather than an examination of the OS vendor’s developmentand configuration management process. This is not meant to diminish the critical role that adeveloper’s practices play in contributing to the overall trustworthiness of a product; rather, it is areflection on the information to be made available for evaluation at this assurance level.

ALC_CMC.1 Labeling of the TOE (ALC_CMC.1)

Developer action elements:

ALC_CMC.1.1DThe developer shall provide the OS and a reference for the OS.

Content and presentation elements:

ALC_CMC.1.1CThe OS shall be labeled with a unique reference.

Application Note: Unique reference information includes:OS NameOS VersionOS Description

Software Identification (SWID) tags, if available

Evaluator action elements:

ALC_CMC.1.1EThe evaluator shall confirm that the information provided meets allrequirements for content and presentation of evidence.

Assurance Activity

The evaluator will check the ST to ensure that it contains anidentifier (such as a product name/version number) thatspecifically identifies the version that meets the requirementsof the ST. Further, the evaluator will check the AGDguidance and OS samples received for testing to ensure thatthe version number is consistent with that in the ST. If thevendor maintains a web site advertising the OS, the evaluatorwill examine the information on the web site to ensure thatthe information in the ST is sufficient to distinguish theproduct.

ALC_CMS.1 TOE CM Coverage (ALC_CMS.1)

Developer action elements:

ALC_CMS.1.1DThe developer shall provide a configuration list for the OS.

Content and presentation elements:

ALC_CMS.1.1CThe configuration list shall include the following: the OS itself; and theevaluation evidence required by the SARs.

ALC_CMS.1.2CThe configuration list shall uniquely identify the configuration items.

Evaluator action elements:

ALC_CMS.1.1EThe evaluator shall confirm that the information provided meets allrequirements for content and presentation of evidence.

Assurance Activity

The "evaluation evidence required by the SARs" in this PP islimited to the information in the ST coupled with the guidanceprovided to administrators and users under the AGDrequirements. By ensuring that the OS is specifically identifiedand that this identification is consistent in the ST and in the

AGD guidance (as done in the assurance activity forALC_CMC.1), the evaluator implicitly confirms theinformation required by this component. Lifecycle support istargeted aspects of the developer’s lifecycle and instructionsto providers of applications for the developer’s devices,rather than an indepth examination of the TSFmanufacturer’s development and configuration managementprocess. This is not meant to diminish the critical role that adeveloper’s practices play in contributing to the overalltrustworthiness of a product; rather, it’s a reflection on theinformation to be made available for evaluation.

The evaluator will ensure that the developer has identified (inguidance documentation for application developersconcerning the targeted platform) one or more developmentenvironments appropriate for use in developing applicationsfor the developer’s platform. For each of these developmentenvironments, the developer shall provide information onhow to configure the environment to ensure that bufferoverflow protection mechanisms in the environment(s) areinvoked (e.g., compiler and linker flags). The evaluator willensure that this documentation also includes an indication ofwhether such protections are on by default, or have to bespecifically enabled. The evaluator will ensure that the TSF isuniquely identified (with respect to other products from theTSF vendor), and that documentation provided by thedeveloper in association with the requirements in the ST isassociated with the TSF using this unique identification.

ALC_TSU_EXT.1 Timely Security Updates

Developer action elements:

ALC_TSU_EXT.1.1DThe developer shall provide a description in the TSS of how timelysecurity updates are made to the OS.

ALC_TSU_EXT.1.2DThe developer shall provide a description in the TSS of how users arenotified when updates change security properties or the configuration ofthe product.

Content and presentation elements:

ALC_TSU_EXT.1.1CThe description shall include the process for creating and deployingsecurity updates for the OS software.

ALC_TSU_EXT.1.2CThe description shall include the mechanisms publicly available forreporting security issues pertaining to the OS. The reporting mechanism

could include web sites, email addresses, as well as a means to protectthe sensitive nature of the report (e.g., public keys that could be used toencrypt the details of a proofofconcept exploit).

Evaluator action elements:

ALC_TSU_EXT.1.1EThe evaluator shall confirm that the information provided meets allrequirements for content and presentation of evidence.

Assurance Activity

The evaluator will verify that the TSS contains a descriptionof the timely security update process used by the developer tocreate and deploy security updates. The evaluator will verifythat this description addresses the entire application. Theevaluator will also verify that, in addition to the OSdeveloper’s process, any thirdparty processes are alsoaddressed in the description. The evaluator will also verifythat each mechanism for deployment of security updates isdescribed.

The evaluator will verify that, for each deploymentmechanism described for the update process, the TSS lists atime between public disclosure of a vulnerability and publicavailability of the security update to the OS patching thisvulnerability, to include any thirdparty or carrier delays indeployment. The evaluator will verify that this time isexpressed in a number or range of days.

The evaluator will verify that this description includes thepublicly available mechanisms (including either an emailaddress or website) for reporting security issues related to theOS. The evaluator shall verify that the description of thismechanism includes a method for protecting the report eitherusing a public key for encrypting email or a trusted channelfor a website.

5.2.5 Class ATE: TestsTesting is specified for functional aspects of the system as well as aspects that take advantage ofdesign or implementation weaknesses. The former is done through the ATE_IND family, while thelatter is through the AVA_VAN family. At the assurance level specified in this PP, testing is basedon advertised functionality and interfaces with dependency on the availability of design information.One of the primary outputs of the evaluation process is the test report as specified in the followingrequirements.

ATE_IND.1 Independent Testing – Conformance (ATE_IND.1)

Developer action elements:

ATE_IND.1.1DThe developer shall provide the OS for testing.

Content and presentation elements:

ATE_IND.1.1CThe OS shall be suitable for testing.

Evaluator action elements:

ATE_IND.1.1EThe evaluator shall confirm that the information provided meets allrequirements for content and presentation of evidence.

ATE_IND.1.2EThe evaluator shall test a subset of the TSF to confirm that the TSFoperates as specified.

Application Note: The evaluator will test the OS on the most currentfully patched version of the platform.

Assurance Activity

The evaluator will prepare a test plan and reportdocumenting the testing aspects of the system, including anyapplication crashes during testing. The evaluator shalldetermine the root cause of any application crashes andinclude that information in the report. The test plan covers allof the testing actions contained in the [CEM] and the body ofthis PP’s Assurance Activities.

While it is not necessary to have one test case per test listed inan Assurance Activity, the evaluator must document in thetest plan that each applicable testing requirement in the ST iscovered. The test plan identifies the platforms to be tested,and for those platforms not included in the test plan butincluded in the ST, the test plan provides a justification fornot testing the platforms. This justification must address thedifferences between the tested platforms and the untestedplatforms, and make an argument that the differences do notaffect the testing to be performed. It is not sufficient to merelyassert that the differences have no affect; rationale must beprovided. If all platforms claimed in the ST are tested, then norationale is necessary. The test plan describes the compositionof each platform to be tested, and any setup that is necessarybeyond what is contained in the AGD documentation. Itshould be noted that the evaluator is expected to follow theAGD documentation for installation and setup of eachplatform either as part of a test or as a standard pretestcondition. This may include special test drivers or tools. Foreach driver or tool, an argument (not just an assertion)

should be provided that the driver or tool will not adverselyaffect the performance of the functionality by the OS and itsplatform.

This also includes the configuration of the cryptographicengine to be used. The cryptographic algorithms implementedby this engine are those specified by this PP and used by thecryptographic protocols being evaluated (IPsec, TLS). Thetest plan identifies highlevel test objectives as well as the testprocedures to be followed to achieve those objectives. Theseprocedures include expected results.

The test report (which could just be an annotated version ofthe test plan) details the activities that took place when thetest procedures were executed, and includes the actual resultsof the tests. This shall be a cumulative account, so if therewas a test run that resulted in a failure; a fix installed; andthen a successful rerun of the test, the report would show a“fail” and “pass” result (and the supporting details), and notjust the “pass” result.

5.2.6 Class AVA: Vulnerability AssessmentFor the first generation of this protection profile, the evaluation lab is expected to survey opensources to discover what vulnerabilities have been discovered in these types of products. In mostcases, these vulnerabilities will require sophistication beyond that of a basic attacker. Untilpenetration tools are created and uniformly distributed to the evaluation labs, the evaluator will notbe expected to test for these vulnerabilities in the OS. The labs will be expected to comment onthe likelihood of these vulnerabilities given the documentation provided by the vendor. Thisinformation will be used in the development of penetration testing tools and for the development offuture protection profiles.

AVA_VAN.1 Vulnerability Survey (AVA_VAN.1)

Developer action elements:

AVA_VAN.1.1DThe developer shall provide the OS for testing.

Content and presentation elements:

AVA_VAN.1.1CThe OS shall be suitable for testing.

Evaluator action elements:

AVA_VAN.1.1EThe evaluator shall confirm that the information provided meets allrequirements for content and presentation of evidence.

AVA_VAN.1.2E

The evaluator shall perform a search of public domain sources to identifypotential vulnerabilities in the OS.

Application Note: Public domain sources include the CommonVulnerabilities and Exposures (CVE) dictionary for publiclyknownvulnerabilities. Public domain sources also include sites which providefree checking of files for viruses.

AVA_VAN.1.3EThe evaluator shall conduct penetration testing, based on the identifiedpotential vulnerabilities, to determine that the OS is resistant to attacksperformed by an attacker possessing Basic attack potential.

Assurance Activity

The evaluator will generate a report to document theirfindings with respect to this requirement. This report couldphysically be part of the overall test report mentioned inATE_IND, or a separate document. The evaluator performs asearch of public information to find vulnerabilities that havebeen found in similar applications with a particular focus onnetwork protocols the application uses and document formatsit parses. The evaluator documents the sources consulted andthe vulnerabilities found in the report.

For each vulnerability found, the evaluator either provides arationale with respect to its nonapplicability, or theevaluator formulates a test (using the guidelines provided inATE_IND) to confirm the vulnerability, if suitable. Suitabilityis determined by assessing the attack vector needed to takeadvantage of the vulnerability. If exploiting the vulnerabilityrequires expert skills and an electron microscope, forinstance, then a test would not be suitable and an appropriatejustification would be formulated.

A. Optional Requirements

As indicated in Section 2, the baseline requirements (those that must be performed by the OS) arecontained in the body of this PP. Additionally, there are three other types of requirements specifiedin Appendix A, Appendix B, and Appendix C. The first type (in this Appendix) are requirementsthat can be included in the ST, but are not required in order for a OS to claim conformance to thisPP. The second type (in Appendix B) are requirements based on selections in the body of the PP:if certain selections are made, then additional requirements in that appendix must be included. Thethird type (in Appendix C are components that are not required in order to conform to this PP, butwill be included in the baseline requirements in future versions of this PP, so adoption by vendors isencouraged. Note that the ST author is responsible for ensuring that requirements that may beassociated with those in Appendix A, Appendix B, and Appendix C but are not listed (e.g., FMTtype requirements) are also included in the ST.

FCS_TLSC_EXT.4 TLS Client Protocol

FCS_TLSC_EXT.4.1The OS shall support mutual authentication using X.509v3 certificates.

Application Note: The use of X.509v3 certificates for TLS isaddressed in FIA_X509_EXT.2.1. This requirement adds that a clientmust be capable of presenting a certificate to a TLS server for TLSmutual authentication.

Assurance Activity

The evaluator will ensure that the TSS description requiredper FIA_X509_EXT.2.1 includes the use of clientsidecertificates for TLS mutual authentication.

The evaluator will verify that the AGD guidance required perFIA_X509_EXT.2.1 includes instructions for configuring theclientside certificates for TLS mutual authentication.

The evaluator will also perform the following test:

Configure the server to require mutual authentication andthen modify a byte in a CA field in the Server’s CertificateRequest handshake message. The modified CA field must notbe the CA used to sign the client’s certificate. The evaluatorwill verify the connection is unsuccessful.

FTA_TAB.1 Default TOE access banners

FTA_TAB.1.1Before establishing a user session, the OS shall display an advisorywarning message regarding unauthorized use of the OS.

Assurance Activity

The evaluator will configure the OS, per instructions in theOS manual, to display the advisory warning message "TESTTEST Warning Message TEST TEST". The evaluator will thenlog out and confirm that the advisory message is displayedbefore logging in can occur.

B. SelectionBased Requirements

As indicated in the introduction to this PP, the baseline requirements (those that must be performedby the OS or its underlying platform) are contained in the body of this PP. There are additionalrequirements based on selections in the body of the PP: if certain selections are made, thenadditional requirements below will need to be included.

FCS_DTLS_EXT.1 DTLS Implementation

FCS_DTLS_EXT.1.1The OS shall implement the DTLS protocol in accordance with[selection: DTLS 1.0 (RFC 4347), DTLS 1.2 (RFC 6347)] .

This requirement depends upon selection inFTP_ITC_EXT.1.1.

Assurance Activity

Test 1: The evaluator will attempt to establish aconnection with a DTLS server, observe the traffic witha packet analyzer, and verify that the connectionsucceeds and that the traffic is identified as DTLS.

Other tests are performed in conjunction with theAssurance Activity listed for FCS_TLSC_EXT.1.

FCS_DTLS_EXT.1.2The OS shall implement the requirements in TLS (FCS_TLSC_EXT.1)for the DTLS implementation, except where variations are allowedaccording to DTLS 1.2 (RFC 6347).

This requirement depends upon selection inFTP_ITC_EXT.1.1.

Application Note: Differences between DTLS 1.2 and TLS 1.2 areoutlined in RFC 6347; otherwise the protocols are the same. Inparticular, for the applicable security characteristics defined for the TSF,the two protocols do not differ. Therefore, all application notes andassurance activities that are listed for TLS apply to the DTLSimplementation.

Assurance Activity

The evaluator will perform the assurance activities listed forFCS_TLSC_EXT.1.

FCS_TLSC_EXT.2 TLS Client Protocol

FCS_TLSC_EXT.2.1The OS shall present the Supported Elliptic Curves Extension in theClient Hello with the following NIST curves: [selection: secp256r1,secp384r1, secp521r1] and no other curves.

This requirement depends upon selection inFCS_TLSC_EXT.1.1.

Application Note: This requirement limits the elliptic curves allowed forauthentication and key agreement to the NIST curves fromFCS_COP.1(3) and FCS_CKM.1 and FCS_CKM.2. This extension isrequired for clients supporting Elliptic Curve cipher suites.

Assurance Activity

The evaluator will verify that TSS describes the supportedElliptic Curves Extension and whether the required behavioris performed by default or may be configured. If the TSSindicates that the supported Elliptic Curves Extension mustbe configured to meet the requirement, the evaluator willverify that AGD guidance includes configuration of thesupported Elliptic Curves Extension.

The evaluator will also perform the following test:

The evaluator will configure the server to perform anECDHE key exchange message in the TLS connection using anonsupported ECDHE curve (for example, P192) and shallverify that the OS disconnects after receiving the server's KeyExchange handshake message.

C. Objective Requirements

This appendix includes requirements that specify security functionality which also addressesthreats. The requirements are not currently mandated in the body of this PP as they describesecurity functionality not yet widelyavailable in commercial technology. However, theserequirements may be included in the ST such that the OS is still conformant to this PP, and it isexpected that they be included as soon as possible.

FCS_TLSC_EXT.3 TLS Client Protocol

FCS_TLSC_EXT.3.1The OS shall present the signature_algorithms extension in the ClientHello with the supported_signature_algorithms value containing thefollowing hash algorithms: [selection: SHA256, SHA384, SHA512] andno other hash algorithms.

Application Note: This requirement limits the hashing algorithmssupported for the purpose of digital signature verification by the clientand limits the server to the supported hashes for the purpose of digitalsignature generation by the server. The signature_algorithm extension isonly supported by TLS 1.2.

Assurance Activity

The evaluator will verify that TSS describes thesignature_algorithm extension and whether the requiredbehavior is performed by default or may be configured. If theTSS indicates that the signature_algorithm extension must beconfigured to meet the requirement, the evaluator will verifythat AGD guidance includes configuration of thesignature_algorithm extension.

The evaluator will also perform the following test:

The evaluator will configure the server to send a certificate inthe TLS connection that is not supported according to theClient’s HashAlgorithm enumeration within thesignature_algorithms extension (for example, send acertificate with a SHA1 signature). The evaluator will verifythat the OS disconnects after receiving the server’sCertificate handshake message.

FPT_SRP_EXT.1 Software Restriction Policies

FPT_SRP_EXT.1.1The OS shall restrict execution to only programs which match anadministratorspecified [selection:

file path,

file digital signature,version,hash,[assignment: other characteristics]

]

Application Note: The assignment permits implementations whichprovide a low level of granularity such as a volume. The restriction isonly against direct execution of executable programs. It does not forbidinterpreters which may take data as an input, even if this data cansubsequently result in arbitrary computation.

Assurance Activity

For each selection specified in the ST, the evaluator willensure that the corresponding tests result in a negativeoutcome (i.e., the action results in the OS denying theevaluator permission to complete the action):

Test 1: The evaluator will configure the OS to onlyallow code execution from the core OS directories. Theevaluator will then attempt to execute code from adirectory that is in the allowed list. The evaluator willensure that the code they attempted to execute hasbeen executed.Test 2: The evaluator will configure the OS to onlyallow code execution from the core OS directories. Theevaluator will then attempt to execute code from adirectory that is not in the allowed list. The evaluatorwill ensure that the code they attempted to execute hasnot been executed.Test 3: The evaluator will configure the OS to onlyallow code that has been signed by the OS vendor toexecute. The evaluator will then attempt to executecode signed by the OS vendor. The evaluator willensure that the code they attempted to execute hasbeen executed.Test 4: The evaluator will configure the OS to onlyallow code that has been signed by the OS vendor toexecute. The evaluator will then attempt to executecode signed by another digital authority. The evaluatorwill ensure that the code they attempted to execute hasnot been executed.Test 5: The evaluator will configure the OS to allowexecution of a specific application based on version.The evaluator will then attempt to execute the sameversion of the application. The evaluator will ensurethat the code they attempted to execute has beenexecuted.Test 6: The evaluator will configure the OS to allowexecution of a specific application based on version.

The evaluator will then attempt to execute an olderversion of the application. The evaluator will ensurethat the code they attempted to execute has not beenexecuted.Test 7: The evaluator will configure the OS to allowexecution based on the hash of the applicationexecutable. The evaluator will then attempt to executethe application with the matching hash. The evaluatorwill ensure that the code they attempted to execute hasbeen executed.Test 8: The evaluator will configure the OS to allowexecution based on the hash of the applicationexecutable. The evaluator will modify the application insuch a way that the application hash is changed. Theevaluator will then attempt to execute the applicationwith the matching hash. The evaluator will ensure thatthe code they attempted to execute has not beenexecuted.

FPT_W^X_EXT.1 Write XOR Execute Memory Pages

FPT_W X_EXT.1.1The OS shall prevent allocation of any memory region with both writeand execute permissions except for [assignment: list of exceptions] .

Application Note: Requesting a memory mapping with both write andexecute permissions subverts the platform protection provided by DEP.If the OS provides no exceptions (such as for justintime compilation),then "no exceptions" should be indicated in the assignment. Fullrealization of this requirement requires hardware support, but this iscommonly available.

Assurance Activity

The evaluator will inspect the vendorprovided developerdocumentation and verify that no memorymapping can bemade with write and execute permissions except for the caseslisted in the assignment.

Test 1: The evaluator will acquire or construct a testprogram which attempts to allocate memory that isboth writable and executable. The evaluator will runthe program and confirm that it fails to allocatememory that is both writable and executable.Test 2: The evaluator will acquire or construct a testprogram which allocates memory that is executableand then subsequently requests additional write/modifypermissions on that memory. The evaluator will run theprogram and confirm that at no time during the lifetimeof the process is the memory both writable and

executable.Test 3: The evaluator will acquire or construct a testprogram which allocates memory that is writable andthen subsequently requests additional executepermissions on that memory. The evaluator will run theprogram and confirm that at no time during the lifetimeof the process is the memory both writable andexecutable.

D. Inherently Satisfied Requirements

This appendix lists requirements that should be considered satisfied by products successfullyevaluated against this Protection Profile. However, these requirements are not featured explicitly asSFRs and should not be included in the ST. They are not included as standalone SFRs because itwould increase the time, cost, and complexity of evaluation. This approach is permitted by [CC]Part 1, 8.2 Dependencies between components.

This information benefits systems engineering activities which call for inclusion of particular securitycontrols. Evaluation against the Protection Profile provides evidence that these controls are presentand have been evaluated.

Requirement Rationale for Satisfaction

FIA_UAU.1 Timing ofauthentication

FIA_AFL.1 implicitly requires that the OS perform all necessary actions,including those on behalf of the user who has not been authenticated, in orderto authenticate; therefore it is duplicative to include these actions as a separateassignment and test.

FIA_UID.1 Timing ofidentification

FIA_AFL.1 implicitly requires that the OS perform all necessary actions,including those on behalf of the user who has not been identified, in order toauthenticate; therefore it is duplicative to include these actions as a separateassignment and test.

FMT_SMR.1 Securityroles

FMT_MOF_EXT.1 specifies rolebased management functions that implicitlydefines user and privileged accounts; therefore, it is duplicative to includeseparate role requirements.

FPT_STM.1 Reliable timestamps

FAU_GEN.1.2 explicitly requires that the OS associate timestamps with auditrecords; therefore it is duplicative to include a separate timestamp requirement.

FTA_SSL.1 TSFinitiatedsessionlocking

FMT_MOF_EXT.1 defines requirements for managing session locking;therefore, it is duplicative to include a separate session locking requirement.

FTA_SSL.2 Userinitiatedlocking

FMT_MOF_EXT.1 defines requirements for userinitiated session locking;therefore, it is duplicative to include a separate session locking requirement.

FAU_STG.1 Protectedaudit trailstorage

FPT_ACF_EXT.1 defines a requirement to protect audit logs; therefore, it isduplicative to include a separate protection of audit trail requirements.

FAU_GEN.2 User identityassociation

FAU_GEN.1.2 explicitly requires that the OS record any user accountassociated with each event; therefore, it is duplicative to include a separaterequirement to associate a user account with each event.

FAU_SAR.1 Audit review

FPT_ACF_EXT.1.2 requires that audit logs (and other objects) are protectedfrom reading by unprivileged users; therefore, it is duplicative to include aseparate requirement to protect only the audit information.

E. Entropy Documentation andAssessment

This appendix describes the required supplementary information for the entropy source used bythe OS.

The documentation of the entropy source should be detailed enough that, after reading, theevaluator will thoroughly understand the entropy source and why it can be relied upon to providesufficient entropy. This documentation should include multiple detailed sections: design description,entropy justification, operating conditions, and health testing. This documentation is not required tobe part of the TSS.

E.1 Design Description

Documentation shall include the design of the entropy source as a whole, including the interactionof all entropy source components. Any information that can be shared regarding the design shouldalso be included for any thirdparty entropy sources that are included in the product.

The documentation will describe the operation of the entropy source to include, how entropy isproduced, and how unprocessed (raw) data can be obtained from within the entropy source fortesting purposes. The documentation should walk through the entropy source design indicatingwhere the entropy comes from, where the entropy output is passed next, any postprocessing ofthe raw outputs (hash, XOR, etc.), if/where it is stored, and finally, how it is output from theentropy source. Any conditions placed on the process (e.g., blocking) should also be described inthe entropy source design. Diagrams and examples are encouraged.

This design must also include a description of the content of the security boundary of the entropysource and a description of how the security boundary ensures that an adversary outside theboundary cannot affect the entropy rate.

If implemented, the design description shall include a description of how thirdparty applicationscan add entropy to the RBG. A description of any RBG state saving between poweroff andpoweron shall be included.

E.2 Entropy Justification

There should be a technical argument for where the unpredictability in the source comes from andwhy there is confidence in the entropy source delivering sufficient entropy for the uses made of theRBG output (by this particular OS). This argument will include a description of the expected minentropy rate (i.e. the minimum entropy (in bits) per bit or byte of source data) and explain thatsufficient entropy is going into the OS randomizer seeding process. This discussion will be part of ajustification for why the entropy source can be relied upon to produce bits with entropy.

The amount of information necessary to justify the expected minentropy rate depends on the typeof entropy source included in the product.

For developer provided entropy sources, in order to justify the minentropy rate, it is expectedthat a large number of raw source bits will be collected, statistical tests will be performed, and theminentropy rate determined from the statistical tests. While no particular statistical tests arerequired at this time, it is expected that some testing is necessary in order to determine the amountof minentropy in each output.

For thirdparty provided entropy sources, in which the OS vendor has limited access to the designand raw entropy data of the source, the documentation will indicate an estimate of the amount ofminentropy obtained from this thirdparty source. It is acceptable for the vendor to “assume” anamount of minentropy, however, this assumption must be clearly stated in the documentationprovided. In particular, the minentropy estimate must be specified and the assumption included inthe ST.

Regardless of type of entropy source, the justification will also include how the DRBG is initializedwith the entropy stated in the ST, for example by verifying that the minentropy rate is multiplied bythe amount of source data used to seed the DRBG or that the rate of entropy expected based onthe amount of source data is explicitly stated and compared to the statistical rate. If the amount ofsource data used to seed the DRBG is not clear or the calculated rate is not explicitly related to theseed, the documentation will not be considered complete.

The entropy justification shall not include any data added from any thirdparty application or fromany state saving between restarts.

E.3 Operating Conditions

The entropy rate may be affected by conditions outside the control of the entropy source itself. Forexample, voltage, frequency, temperature, and elapsed time after poweron are just a few of thefactors that may affect the operation of the entropy source. As such, documentation will alsoinclude the range of operating conditions under which the entropy source is expected to generaterandom data. It will clearly describe the measures that have been taken in the system design toensure the entropy source continues to operate under those conditions. Similarly, documentationshall describe the conditions under which the entropy source is known to malfunction or becomeinconsistent. Methods used to detect failure or degradation of the source shall be included.

E.4 Health Testing

More specifically, all entropy source health tests and their rationale will be documented. Thisincludes a description of the health tests, the rate and conditions under which each health test isperformed (e.g., at start, continuously, or ondemand), the expected results for each health test,and rationale indicating why each test is believed to be appropriate for detecting one or morefailures in the entropy source.

F. References

Identifier Title

[CC] Common Criteria for Information Technology Security Evaluation Part 1: Introduction and General Model, CCMB201209001, Version3.1 Revision 4, September 2012.Part 2: Security Functional Components, CCMB201209002, Version3.1 Revision 4, September 2012.Part 3: Security Assurance Components, CCMB201209003, Version3.1 Revision 4, September 2012.

[CEM] Common Evaluation Methodology for Information Technology Security Evaluation Methodology, CCMB201209004, Version 3.1, Revision 4,September 2012.

[CESG] CESG End User Devices Security and Configuration Guidance

[CSA] Computer Security Act of 1987, H.R. 145, June 11, 1987.

[OMB] Reporting Incidents Involving Personally Identifiable Information and Incorporatingthe Cost for Security in Agency Information Technology Investments, OMB M0619, July 12, 2006.

G. Acronyms

Acronym Meaning

AES Advanced Encryption Standard

ANSI American National Standards Institute

API Application Programming Interface

ASLR Address Space Layout Randomization

CESG CommunicationsElectronics Security Group

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 DiffieHellman Ephemeral

DNS Domain Name System

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 DiffieHellman Ephemeral

ECDSA Elliptic Curve Digital Signature Algorithm

EST Enrollment over Secure Transport

FIPS Federal Information Processing Standards

DSS Digital Signature Standard

HMAC Hashbased Message Authentication Code

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

DSS Digital Signature Standard

IETF Internet Engineering Task Force

IP Internet Protocol

ISO International Organization for Standardization

IT Information Technology

ITSEF Information Technology Security Evaluation Facility

NFC Near Field Communication

NIAP National Information Assurance Partnership

NIST National Institute of Standards and Technology

OCSP Online Certificate Status Protocol

OID Object Identifier

OMB Office of Management and Budget

OS Operating System

PII Personally Identifiable Information

PKI Public Key Infrastructure

PP Protection Profile

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/Multipurpose Internet Mail Extensions

SIP Session Initiation Protocol

SWID Software Identification

TLS Transport Layer Security

URI Uniform Resource Identifier

URL Uniform Resource Locator

USB Universal Serial Bus

XCCDF eXtensible Configuration Checklist Description Format

XOR Exclusive Or