Microsoft Windows Common Criteria Evaluation Microsoft Windows 10 (Anniversary Update) Microsoft Windows Server 2016

21.FPT_TUD_EXT.1.1

The evaluator will check for an update using procedures described in the documentation and verify that the OS provides a list of available updates. Testing this capability may require installing and temporarily placing the system into a configuration in conflict with secure configuration guidance which specifies automatic update. (The evaluator is also to ensure that this query occurs over a trusted channel as described in FTP_ITC_EXT.1.)

22.FPT_TUD_EXT.1.2

For the following tests, the evaluator will initiate the download of an update and capture the update prior to installation. The download could originate from the vendor's website, an enterprise­hosted update repository, or another system (e.g. network peer). All supported origins for the update must be indicated in the TSS and evaluated.

• 
  Test 1: The evaluator will ensure that the update has a digital signature belonging to the vendor prior to its installation. The evaluator will modify the downloaded update in such a way that the digital signature is no longer valid. The evaluator will then attempt to install the modified update. The evaluator will ensure that the OS does not install the modified update.
  
• 
  Test 2: The evaluator will ensure that the update has a digital signature belonging to the vendor. The evaluator will then attempt to install the update (or permit installation to continue). The evaluator will ensure that the OS successfully installs the update.
  

22.1.1.1.1Trusted Update for Application Software (FPT_TUD_EXT.2)

23.FPT_TUD_EXT.2.1

The evaluator will check for updates to application software using procedures described in the documentation and verify that the OS provides a list of available updates. Testing this capability may require temporarily placing the system into a configuration in conflict with secure configuration guidance which specifies automatic update. (The evaluator is also to ensure that this query occurs over a trusted channel as described in FTP_ITC_EXT.1.)

24.FPT_TUD_EXT.2.2

The evaluator will initiate an update to an application. This may vary depending on the application, but it could be through the application vendor's website, a commercial app store, or another system. All origins supported by the OS must be indicated in the TSS and evaluated. However, this only includes those mechanisms for which the OS is providing a trusted installation and update functionality. It does not include user or administrator driven download and installation of arbitrary files.

• 
  Test 1: The evaluator will ensure that the update has a digital signature which chains to the OS vendor or another trusted root managed through the OS. The evaluator will modify the downloaded update in such a way that the digital signature is no longer valid. The evaluator will then attempt to install the modified update. The evaluator will ensure that the OS does not install the modified update.
  
• 
  Test 2: The evaluator will ensure that the update has a digital signature belonging to the OS vendor or another trusted root managed through the OS. The evaluator will then attempt to install the update. The evaluator will ensure that the OS successfully installs the update.
  

24.1.1.1TOE Access (FTA)

24.1.1.1.1Default TOE Access Banners (FTA_TAB.1)

The evaluator will configure the OS, per instructions in the OS manual, to display the advisory warning message "TEST TEST Warning Message TEST TEST". The evaluator will then log out and confirm that the advisory message is displayed before logging in can occur.

24.1.1.2Trusted Path / Channels (FTP)

24.1.1.2.1Trusted Channel Communication (FTP_ITC_EXT.1)

The evaluator will configure the OS to communicate with another trusted IT product as identified in the second selection. The evaluator will monitor network traffic while the OS performs communication with each of the servers identified in the second selection. The evaluator will ensure that for each session a trusted channel was established in conformance with the protocols identified in the first selection.

24.1.1.2.2Trusted Path (FTP_TRP.1)

The evaluator will examine the TSS to determine that the methods of remote OS administration are indicated, along with how those communications are protected. The evaluator will also confirm that all protocols listed in the TSS in support of OS administration are consistent with those specified in the requirement, and are included in the requirements in the ST. The evaluator will confirm that the operational guidance contains instructions for establishing the remote administrative sessions for each supported method. The evaluator will also perform the following tests:

• 
  Test 1: The evaluator will ensure that communications using each remote administration method is tested during the course of the evaluation, setting up the connections as described in the operational guidance and ensuring that communication is successful.
  
• 
  Test 2: For each method of remote administration supported, the evaluator will follow the operational guidance to ensure that there is no available interface that can be used by a remote user to establish a remote administrative sessions without invoking the trusted path.
  
• 
  Test 3: The evaluator will ensure, for each method of remote administration, the channel data is not sent in plaintext.
  
• 
  Test 4: The evaluator will ensure, for each method of remote administration, modification of the channel data is detected by the OS.
  

25.TOE Summary Specification (TSS)

This chapter describes the Windows 10 and Server 2016 security functions. The Windows 10 and Server 2016 Security Functions (SFs) satisfy the security functional requirements of the protection profile. The TOE also includes additional relevant security functions which are also described in the following sections, as well as a mapping to the security functional requirements satisfied by the TOE.

Unless otherwise noted in this section, all statements apply to both Windows 10 and Server 2016.

This section presents the TOE Security Functions (TSFs) and a mapping of security functions to Security Functional Requirements (SFRs). The TOE performs the following security functions:

• 
  Audit
  
• 
  Cryptographic Support
  
• 
  User Data Protection
  
• 
  Identification and Authentication
  
• 
  Security Management
  
• 
  Protection of the TSF
  
• 
  TOE Access
  
• 
  Trusted Channels
  

25.1Audit

The TOE Audit security function performs:

• 
  Audit Collection
  
• 
  Selective Audit
  
• 
  Audit Log Overflow Protection
  
• 
  Audit Log Restricted Access Protection
  

25.1.1Audit Collection

The Windows Event Log service creates the security event log, which contains security relevant audit records collected on a system, along with other event logs which are also registered by other audit entry providers. The Local Security Authority (LSA) server collects audit events from all other parts of the TSF and forwards them to the Windows Event Log service which will place the event into the log for the appropriate provider. While there is no size limit for a single audit record, the authorized administrator can specify a limit for the size of each event log. For each audit event, the Windows Event Log service stores the following data in each audit entry:

Field in Audit Entry	Description
Date	The date the event occurred.
Time	The time the event occurred.
User	The security identifier (SID) of that represents the user on whose behalf the event occurred that represents the user.
Event ID	A unique number within the audit category that identifies the specific audit event.
Source	The Windows component that generated the audit event.
Outcome	Indicates whether the security audit event recorded is the result of a successful or failed attempt to perform the action.
Category	The type of the event defined by the event source.

Table Standard Fields in a Windows Audit Entry

The LSA service defines the following categories for audit events in the security log:

• 
  System,
  
• 
  Logon / Logoff
  
• 
  Object Access
  
• 
  Directory Service Access
  
• 
  Privilege Use
  
• 
  Detailed Process Tracking
  
• 
  Policy Change
  
• 
  Account Management
  
• 
  Account Logon
  

Each audit entry may also contain category-specific data that is contained in the body of the entry as described below:

• 
  For the System Category, the audit entry includes information relating to the system such as the time the audit trail was cleared, start or shutdown of the audit function, and startup and shutdown of Windows. Furthermore, the specific cryptographic operation is identified when such operations are audited.
  
• 
  For the Logon and Account Logon Category, the audit entry includes the reason the attempted logon failed.
  
• 
  For the Object Access and the Directory Service Access Category, the audit entry includes the object name and the desired access requested.
  
• 
  For the Privilege Use Category, the audit entry identifies the privilege.
  
• 
  For the Detailed Process Tracking Category, the audit event includes the process identifier.
  
• 
  For the Policy Change and Account Management Category, the audit event includes the new values of the policy or account attributes.
  
• 
  For the Account Logon Category, the audit event includes the logon type that indicates the source of the logon attempt as one of the following types in the audit record:
  
  • 
    Interactive (local logon)
    
  • 
    Network (logon from the network)
    
  • 
    Service (logon as a service)
    
  • 
    Batch (logon as a batch job)
    
  • 
    Unlock (for Unlock screen saver)
    
  • 
    Network_ClearText (for anonymous authentication to IIS)
    

There are two places within the TSF where security audit events are collected. Inside the kernel, the Security Reference Monitor (SRM), a part of the NT Executive, is responsible for generation of all audit entries for the object access, privilege use, and detailed process tracking event categories. Windows components can request the SRM to generate an audit record and supply all of the elements in the audit record except for the system time, which the Executive provides. With one exception, audit events for the other event categories are generated by various services that either co-exist in the LSA server or call, with the SeAuditPrivilege privilege, the Authz Report Audit interfaces implemented in the LSA Policy subcomponent. The exception is that the Event Log Service itself records an event record when the security log is cleared and when the security log exceeds the warning level configured by the authorized administrator.

The LSA server maintains an audit policy in its database that determines which categories of events are actually collected. Defining and modifying the audit policy is restricted to the authorized administrator. The authorized administrator can select events to be audited by selecting the category or categories to be audited. An authorized administrator can individually select each category. Those services in the security process determine the current audit policy via direct local function calls. The only other TSF component that uses the audit policy is the SRM in order to record object access, privilege use, and detailed tracking audit. LSA and the SRM share a private local connection port, which is used to pass the audit policy to the SRM. When an authorized administrator changes the audit policy, the LSA updates its database and notifies the SRM. The SRM receives a control flag indicating if auditing is enabled and a data structure indicating that the events in particular categories to audit.

In addition to the system-wide audit policy configuration, it is possible to define a per-user audit policy using auditpol.exe. This allows individual audit categories (of success or failure) to be enabled or disabled on a per user basis.⁸ The per-user audit policy refines the system-wide audit policy with a more precise definition of the audit policy for which events will be audited for a specific user.

Within each category, auditing can be performed based on success, failure, or both. For object access events, auditing can be further controlled based on user/group identify and access rights using System Access Control Lists (SACLs). SACLs are associated with objects and indicate whether or not auditing for a specific object, or object attribute, is enabled.

25.1.2SFR Summary

• 
  FAU_GEN.1: The TOE audit collection is capable of generating audit events for items identified in section 5.1.1.1. For each audit event the TSF records the date, time, user Security Identifier (SID) or name, logon type (for logon audit records), event ID, source, type, and category.
  

25.2Cryptographic Support

25.2.1Cryptographic Algorithms and Operations

The Cryptography API: Next Generation (CNG) API is designed to be extensible at many levels and agnostic to cryptographic algorithm suites. Windows uses CNG exclusively for its own encryption needs and provides public APIs for external developers. An important feature of CNG is its native implementation of the Suite B algorithms, including algorithms for AES (128, 192, 256 key sizes)⁹, the SHA-1 and SHA-2 family (SHA-256, SHA-384 and SHA-512) of hashing algorithms, elliptic curve Diffie Hellman (ECDH), and elliptical curve DSA (ECDSA) over the NIST-standard prime curves P-256, P-384, and P-521.

Protocols such as the Internet Key Exchange (IKE), and Transport Layer Security (TLS), make use of elliptic curve Diffie-Hellman (ECDH) included in Suite B as well as hashing functions.

Deterministic random bit generation (DRBG) is implemented in accordance with NIST Special Publication 800-90. Windows generates random bits by taking the output of a cascade of two SP800-90 AES-256 counter mode based DRBGs in kernel-mode and four cascaded SP800-90 AES-256 DRBGs in user-mode; programmatic callers can choose to obtain either 128 or 256 bits from the RBG which is seeded from the Windows entropy pool. Windows has different entropy sources (deterministic and nondeterministic) which produce entropy data that is used for random numbers generation. In particular, this entropy data together with other data (such as the nonce) seed the DRBG algorithm. The entropy pool is populated using the following values:

• 
  An initial entropy value from a seed file provided to the Windows OS Loader at boot time (512 bits of entropy). ¹⁰
  
• 
  A calculated value based on the high-resolution CPU cycle counter which fires after every 1024 interrupts (a continuous source providing 16384 bits of entropy).
  
• 
  Random values gathered periodically from the Trusted Platform Module (TPM), (320 bits of entropy on boot, 384 bits thereafter on demand based on an OS timer).
  
• 
  Random values gathered periodically by calling the RDRAND CPU instruction, (256 bits of entropy).
  

The entropy data is obtained from the entropy sources in a raw format and is health-tested before using it as input for the DRBG. The main source of entropy in the system is the CPU cycle counter which continuously tracks hardware interrupts. This serves as a sufficient health test; if the computer were not accumulating hardware and software interrupts it would not be running and therefore there would be no need for any entropy to seed, or reseed, the random bit generator. In the same manner, a failure of the TPM chip or the RDRAND instruction for the processor would be a critical error that halts the computer, effectively serving as an on-demand self-test¹¹ In addition, when the user chooses to follow the CC administrative guidance, which includes operating Windows in the FIPS validated mode, it will run FIPS 140 AES-256 Counter Mode DBRG Known Answer Tests (instantiate, generate) on start-up. Windows always runs the SP 800-90-mandated self-tests for AES-CTR-DRBG during a reseed when the user chooses to operate Windows in the FIPS validated mode.¹²

Each entropy source is independent of the other sources and does not depend on time. The CPU cycle counter inputs vary by environmental conditions such as data received on a network interface card, key presses on a keyboard, mouse movement and clicks, and touch input.

The TSF defends against tampering of the random number generation (RNG) / pseudorandom number generation (PRNG) sources by encapsulating its use in Kernel Security Device Driver. The interface for the Windows random number generator is BCryptGenRandom.

The CNG provider for random number generation is the AES_CTR_DRBG, when Windows requires the use of a salt it uses the Windows RBG.

The encryption and decryption operations are performed by independent modules, known as Cryptographic Service Providers (CSPs). Windows generates symmetric keys (AES keys) using the FIPS Approved random number generator.

In addition to encryption and decryption services, the TSF provides other cryptographic operations such as hashing and digital signatures. Hashing is used by other FIPS Approved algorithms implemented in Windows (the hashed message authentication code, RSA, DSA, and EC DSA signature services, Diffie-Hellman and elliptic curve Diffie-Hellman key agreement, and random bit generation). When Windows needs to establish an RSA-based shared secret key it can act both as a sender or recipient, any decryption errors which occur during key establishment are presented to the user at a highly abstracted level, such as a failure to connect.

Cryptographic Operation	Standard	Evaluation Method
Encryption/Decryption	FIPS 197 AES For CBC, CCM, KW, XTS, and GCM modes	NIST CAVP #4061, #4062, #4063, #4064, #4074
Digital signature	FIPS 186-4 RSA	NIST CAVP #2192, #2193, #2194, #2195, #2206
Digital signature	FIPS 186-4 DSA	NIST CAVP #1098
Digital signature	FIPS 186-4 ECDSA	NIST CAVP #911, #920
Hashing	FIPS 180-4 SHA-1 and SHA-256, SHA-384, SHA-512	NIST CAVP #3346, #3347
Keyed-Hash Message Authentication Code	FIPS 198-2 HMAC	NIST CAVP #2651, 2661
Random number generation	NIST SP 800-90 CTR_DRBG	NIST CAVP #1217, #1222
Key agreement	NIST SP 800-56A ECDH NIST SP 800-56B RSA	NIST CAVP #92, #93 NIST CVL #887, #888, Tested by the CC evaluation lab^13
Key-based key derivation	SP800-108	NIST CAVP #101, #102
IKEv1	SP800-135	NIST CVL #886
IKEv2	SP800-135	NIST CVL #886
TLS	SP800-135	NIST CVL #886

Table Windows 10 and Server 2016 Cryptographic Algorithm Standards and Evaluation Methods
CNG includes a user-mode key isolation service designed specifically to host secret and private keys in a protected process to mitigate tampering or access to sensitive key materials for user-mode processes. CNG performs a key error detection check on each transfer of key (internal and intermediate transfers). CNG prevents archiving of expired (private) signature keys and destroys non-persistent cryptographic keys. Windows overwrites each intermediate storage area for plaintext key/critical cryptographic security parameter (i.e., any storage, such as memory buffers for the key or plaintext password which was typed by the user that is included in the path of such data). This overwriting is performed as follows:

• 
  For volatile memory, the overwrite is a single direct overwrite consisting of zeros using the RtlSecureZeroMemory function.
  

The following table describes the keys and secrets used for networking and data protection; when these ephemeral keys or secrets are no longer needed for a network session, due to either normal end of the session or abnormal termination, or after protecting sensitive data using DPAPI, they are deleted as described above and in section 5.1.2.3. Note that the administrative guidance precludes hibernating the computer and so these keys are not persisted into volatile storage

Key	Description
Symmetric encryption/decryption keys	Keys used for AES (FIPS 197) encryption/decryption for IPsec ESP, TLS, Wi-Fi.
HMAC keys	Keys used for HMAC-SHA1, HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512 (FIPS 198-1) as part of IPsec
Asymmetric ECDSA Public Keys	Keys used for the verification of ECDSA digital signatures (FIPS 186-4) for IPsec traffic and peer authentication.
Asymmetric ECDSA Private Keys	Keys used for the calculation of ECDSA digital signatures (FIPS 186-4) for IPsec traffic and peer authentication.
Asymmetric RSA Public Keys	Keys used for the verification of RSA digital signatures (FIPS 186-4) for IPsec, TLS, Wi-Fi and signed product updates.
Asymmetric RSA Private Keys	Keys used for the calculation of RSA digital signatures (FIPS 186-4) for IPsec, TLS, and Wi-Fi as well as TPM-based health attestations. The key size can be 2048 or 3072 bits.
Asymmetric DSA Private Keys	Keys used for the calculation of DSA digital signatures (FIPS 186-4) for IPsec and TLS. The key size can be 2048 or 3072 bits.
Asymmetric DSA Public Keys	Keys used for the verification of DSA digital signatures (FIPS 186-4) for IPsec and TLS. The key size can be 2048 or 3072 bits.
DH Private and Public values	Private and public values used for Diffie-Hellman key establishment for TLS.
ECDH Private and Public values	Private and public values used for EC Diffie-Hellman key establishment for TLS.
DPAPI master secret	512-bit random value used by DPAPI
DPAPI master AES key	256-bit encryption key that protects the DPAPI master secret
DPAPI AES key	256-bit encryption key used by DPAPI
DRBG seed	Seed for the main DRBG, zeroized during reseeding

Table Types of Keys Used by Windows

25.2.2Networking (TLS)

The TOE implements TLS to enable a trusted network path that is used for client and server authentication, as well as HTTPS.

The following table summarizes the TLS RFCs implemented in Windows:

RFC #	Name	How Used
2246	The TLS Protocol Version 1.0	Specifies requirements for TLS 1.0.
3268	Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)	Specifies additional ciphersuites implemented by Windows.
3546	Transport Layer Security (TLS) Extensions	Updates RFC 2246 with TLS 1.0 extensions implemented by Windows.
4346	The Transport Layer Security (TLS) Protocol Version 1.1	Specifies requirements for TLS 1.1.
4366	Transport Layer Security (TLS) Extensions	Obsoletes RFC 3546 Requirements for TLS 1.1 extensions implemented by Windows.
4492	Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)	Specifies additional ciphersuites implemented by Windows.
4681	TLS User Mapping Extension	Extends TLS to include a User Principal Name during the TLS handshake.
5246	The Transport Layer Security (TLS) Protocol Version 1.2	Oboletes RFCs 3268, 4346, and 4366. Specifies requirements for TLS 1.2.
5289	TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM)	Specifies additional ciphersuites implemented by Windows.
SSL3	The SSL Protocol Version 3	Specifies requirements for SSL3.

Table TLS RFCs Implemented by Windows
These protocols are described at:

• 
  MS-TLSP Transport Layer Security (TLS) Profile
  
• 
  RFC 2246 The TLS Protocol Version 1.0
  
• 
  RFC 3268 -AES Ciphersuites for TLS
  
• 
  RFC 3546 Transport Layer Security (TLS) Extensions
  
• 
  RFC 4366 Transport Layer Security (TLS) Extensions
  
• 
  RFC 4492 ECC Cipher Suites for TLS
  
• 
  RFC 4681 TLS User Mapping Extension
  
• 
  RFC 5246 - The Transport Layer Security (TLS) Protocol, Version 1.2
  
• 
  RFC 5289 - TLS ECC Suites with SHA-256384 and AES GCM
  

The Cipher Suites in Schannel article describes the complete set of TLS cipher suites implemented in Windows (reference: http://msdn.microsoft.com/en-us/library/windows/desktop/aa374757(v=vs.85).aspx), of which the following are used in the evaluated configuration:

• 
  TLS_RSA_WITH_AES_128_CBC_SHA
  
• 
  TLS_RSA_WITH_AES_256_CBC_SHA
  
• 
  TLS_RSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5246
  
• 
  TLS_RSA_WITH_AES_256_CBC_SHA256 as defined in RFC 5246
  
• 
  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA as defined in RFC 4492
  
• 
  TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA as defined in RFC 4492
  
• 
  TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 as defined in RFC 5289
  
• 
  TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 as defined in RFC 5289
  
• 
  TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 as defined in RFC 5289
  
• 
  TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 as defined in RFC 5289.
  

When negotiating a TLS 1.2 elliptic curve cipher suite, Windows will include automatically as part of the Client Hello message both its supported elliptic curves extension, i.e., secp256r1, secp384r1, and secp521r1 as well as signature algorithm, i.e., SHA256, SHA384, and SHA512 based on the ciphersuites selected by the administrator. By default, the curve secp521r1 is disabled. This curve can be enabled adding its name in the ECC Curve Order file. In addition, the curve priority can be edited in this file.

On the other hand, by default the signature algorithms in the Client Hello message are: SHA1, SHA256, SHA384 and SHA512. The signature algorithm extension is configurable by editing a registry key to meet with the FCS_TLSC_EXT.3 requirement. Each Windows component that uses TLS checks that the identifying information in the certificate matches what is expected, the component should reject the connection, these checks include checking the expected Distinguished Name (DN), Subject Name (SN), or Subject Alternative Name (SAN) attributes along with any applicable extended key usage identifiers. The DN, and any Subject Alternative Name, in the certificate is checked against the identity of the remote computer’s DNS entry or IP address to ensure that it matches as described at http://technet.microsoft.com/en-us/library/cc783349(v=WS.10).aspx, and in particular the “Server Certificate Message” section. The reference identifier in Windows 10 and Windows Server 2016 for TLS is the DNS name or IP address of the remote server, which is compared against the DNS name as presented identifier in the Subject Alternative Name (SAN) or the Subject Name of the certificate. There is no configuration of the reference identifier.

A certificate that uses a wildcard in the leftmost portion of the resource identifier (i.e., *.contoso.com) can be accepted for authentication, otherwise the certificate will be deemed invalid. Windows does not provide a general-purpose capability to “pin” TLS certificates.

Windows implements HTTPS as described in RFC 2818 so that Windows Store and system applications executing on the TOE can securely connect to external servers using HTTPS.

25.2.3Protecting Data with DPAPI

Windows provides the Data Protection API, DPAPI, which Windows components, first-party and third-party applications can use to protect any persisted data which the developer deems to be sensitive. DPAPI will use AES CBC encryption with a key that is based in part on the user’s password to protect the user data. When storing private keys and secrets associated with the user account, the encrypted data is stored on the file system in a directory which is part of the user’s profile.

25.2.4SFR Summary

•