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

FCS_CKM.1,¹⁴ FCS_CKM.2,¹⁵ FCS_COP.1(SYM), FCS_COP.1(HASH), FCS_COP.1(SIGN), FCS_COP.1(HMAC), FCS_RBG_EXT.1: See Table Windows 10 and Server 2016 Cryptographic Algorithm Standards and Evaluation Methods.

FCS_CKM_EXT.3: Windows overwrites critical cryptographic parameters immediately after that data is no longer needed.

FCS_STO_EXT.1: Windows provides the Data Protection API (DPAPI) for developers to encrypt and decrypt sensitive data using the CryptProtectData and CryptUnprotectData interfaces.

FCS_TLS_EXT.1, FCS_TLS_EXT.2, FCS_TLS_EXT.3, FCS_TLS_EXT.4: Windows implements TLS 1.2 to provide server and mutual authentication using X.509v3 certificates, confidentiality and integrity to upper-layer protocols such as Extensible Authentication Protocol and HTTP.

FCS_DTLS_EXT.1: The Windows implementation of DTLS 1.0 and DTLS 1.2 is based on underlying SChannel component which implements TLS

25.3User Data Protection

25.3.1Discretionary Access Control

The executive component within the Windows kernel mediates access between subjects and user data objects, also known as named objects. Subjects consist of processes with one or more threads running on behalf of users. While the Windows Discretionary Access Control policy manages several different kinds of named objects, the protection profile that is the basic for this evaluation focuses on the NTFS File and NTFS Directory objects.

25.3.1.1Subject DAC Attributes

Windows security access tokens contain the security attributes for a subject. Tokens are associated with processes and threads running on behalf of the user. Information in a security access token that is used by DAC includes:

• 
  The Security Identifier (SID) for the user account
  
• 
  SIDs representing groups for which the user is a member
  
• 
  Privileges assigned to the user
  
• 
  An owner SID that identifies the SID to assign as owner for newly created objects
  
• 
  A default Discretionary Access Control List (DACL) for newly created objects
  
• 
  Token type which is either a primary or an impersonation token
  
• 
  The impersonation level (for impersonation tokens)
  
• 
  The integrity label SID
  
• 
  An optional list of restricting SIDs
  
• 
  The logon SID that identifies the logon session.
  

An administrator can change all of these except for the user account SID and logon SID.

A thread can be assigned an impersonation token that would be used instead of the process’ primary token when making an access check and generating audit data. Hence, that thread is impersonating the client that provided the impersonation token. Impersonation stops when the impersonation token is removed from the thread or when the thread terminates.

An access token may also include a list of restricting SIDs which are used to limit access to objects. Restricting SIDs are contained in restricted tokens, (which is a special form of a thread impersonation token), and when configured serve to limit the corresponding process access to no more than that available to the restricted SID.

Access decisions are made using the impersonation token of a thread if it exists, and otherwise the thread’s process primary token (which always exists).

25.3.1.2Object DAC Attributes

Security Descriptors (SDs) contain all of the security attributes associated with an object. All named objects have an associated SD. The security attributes from a SD used for discretionary access control are the object owner SID which specifies the owner of the security descriptor, the DACL present flag, and the DACL itself, when present.

DACLs contain a list of Access Control Entries (ACEs). Each ACE specifies an ACE type, a SID representing a user or group, and an access mask containing a set of access rights. Each ACE has inheritance attributes associated with it that specify if the ACE applies to the associated object only, to its children objects only, or to both its children objects and the associated object.

There are two types of ACEs that apply to discretionary access control:

• 
  ALLOW ACES
  
  • 
    ACCESS_ALLOWED_ACE: used to grant access to a user or group of users.
    
  • 
    ACCESS_ALLOWED_OBJECT_ACE: (for DS objects) used to grant access for a user or group to a property or property set on the directory service object, or to limit the ACE_inheritance to a specified type of child object. This ACE type is only supported for directory service objects.
    
• 
  DENY ACES
  
  • 
    ACCESS_DENIED_ACE: used to deny access to a user or group of users.
    
  • 
    ACCESS_DENIED_OBJECT_ACE: (for DS objects) used to deny access for a user or group to a property or property set on the directory service object or to limit the ACE_inheritance to a specified type of child object. This ACE type is only supported for directory service objects.
    

In the ACE, an access mask contains object access rights granted (or denied) to the SID, representing a user or group. An access mask is also used to specify the desired access to an object when accessing the object and to identify granted access associated with an opened object. Each bit in an access mask represents a particular access right. There are four categories of access rights: standard, specific, special, and generic. Standard access rights apply to all object types. Specific access rights have different semantic meanings depending on the type of object. Special access rights are used in desired access masks to request special access or to ask for all allowable rights. Generic access rights are convenient groupings of specific and standard access rights. Each object type provides its own mapping between generic access rights and the standard and specific access rights.

For most objects, a subject requests access to the object (e.g., opens it) and receives a pointer to a handle in return. The TSF associates a granted access mask with each opened handle. For kernel-mode objects, handles are maintained in a kernel-mode handle table. There is one handle table per process; each entry in the handle table identifies an opened object and the access rights granted to that object. For user-mode TSF servers, the handle is a server-controlled context pointer associated with the connection between the subject and the server. The server uses this context handle in the same manner as with the kernel mode (i.e., to locate an opened object and it’s associated granted access mask). In both cases (user and kernel-mode objects), the SRM makes all access control decisions.

The following table summarizes every DAC access right for each named object which were tested by the evaluation lab:

Named Object	Access Rights
NTFS Directory	ACCESS_SYSTEM_SECURITY READ_CONTROL WRITE_DAC WRITE_OWNER SYNCHRONIZE FILE_LIST_DIRECTORY FILE_ADD_FILE FILE_ADD_SUBDIRECTORY FILE_DELETE_CHILD FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES FILE_DELETE_CHILD|FILE_ADD_FILE DELETE
NTFS File	ACCESS_SYSTEM_SECURITY READ_CONTROL WRITE_DAC WRITE_OWNER SYNCHRONIZE FILE_WRITE_DATA FILE_READ_DATA FILE_APPEND_DATA FILE_WRITE_EA FILE_EXECUTE FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES FILE_WRITE_ATTRIBUTES. FILE_WRITE_DATA and FILE_WRITE_ATTRIBUTES. DELETE FILE_WRITE_DATA | FILE_READ_DATA FILE_READ_DATA | FILE_EXECUTE FILE_READ_DATA | FILE_EXECUTE | FILE_WRITE_DATA FILE_WRITE_DATA | FILE_WRITE_EA | FILE_WRITE_ATTRIBUTES

Table DAC Access Rights and Named Objects
25.3.1.3DAC Enforcement Algorithm

The TSF enforces the DAC policy to objects based on SIDs and privileges in the requestor’s token, the desired access mask requested, and the object’s security descriptor.

Below is a summary of the algorithm used to determine whether a request to access a user data object is allowed. In order for access to be granted, all access rights specified in the desired access mask must be granted by one of the following steps. At the end of any step, if all of the requested access rights have been granted then access is allowed. At the end of the algorithm, if any requested access right has not been granted, then access is denied.

1. 
   Privilege Check:
   
   1. 
      Check for SeSecurity privilege: This is required if ACCESS_SYSTEM_SECURITY is in the desired access mask. If ACCESS_SYSTEM_SECURITY is requested and the requestor does not have this privilege, access is denied. Otherwise ACCESS_SYSTEM_SECURITY is granted.
      
   2. 
      Check for SeTakeOwner privilege: If the desired mask has WRITE_OWNER access right, and the privilege is found in the requestor’s token, then WRITE_OWNER access is granted.
      
   3. 
      Check for SeBackupPrivilege: The Backup Files and Directories privilege allows a subject process to read files and registry objects for backup operations regardless of their ACE in the DACL. If the subject process has the SeBackupPrivilege privilege and the operation requires the privilege, no further checking is performed and access is allowed. Otherwise this check is irrelevant and the access check proceeds.
      
   4. 
      Check for SeRestorePrivilege: The Restore Files and Directories privilege allows a subject process to write files and registry objects for restore operations regardless of their ACE in the DACL. If the subject process has the SeRestorePrivilege privilege and the operation requires the privilege no further checking is performed, and access is allowed. Otherwise this check is irrelevant and the access check proceeds.
      
2. 
   Owner Check:
   
   1. 
      If the DACL contains one or more ACEs with the OwnerRights SID, those entries, along with all other applicable ACEs for the user, are used to determine the owner's rights.
      
   2. 
      Otherwise, check all the SIDs in the token to determine if there is a match with the object owner. If so, the READ_CONTROL and WRITE_DAC rights are granted if requested.
      
3. 
   DACL not present:
   
   1. 
      All further access rights requested are granted.
      
4. 
   DACL present but empty:
   
   1. 
      If any additional access rights are requested, access is denied.
      
5. 
   Iteratively process each ACE in the order that they appear in the DACL as described below:
   
   1. 
      If the inheritance attributes of the ACE indicate the ACE is applicable only to children objects of the associated object, the ACE is skipped.
      
   2. 
      If the SID in the ACE does not match any SID in the requestor’s access token, the ACE is skipped.
      
   3. 
      If a SID match is found, and the access mask in the ACE matches an access in the desired access mask:
      
      1. 
         Access Allowed ACE Types: If the ACE is of type ACCESS_ALLOWED_OBJECT_ACE and the ACE includes a GUID representing a property set or property associated with the object, then the access is granted to the property set or specific property represented by the GUID (rather than to the entire object). Otherwise the ACE grants access to the entire object.
         
      2. 
         Access Denied ACE Type: If the ACE is of type ACCESS_DENIED_OBJECT_ACE and the ACE includes a GUID representing a property set or property associated with the object, then the access is denied to the property set or specific property represented by the GUID. Otherwise the ACE denies access to the entire object. If a requested access is specifically denied by an ACE, then the entire access request fails.
         
6. 
   If all accesses are granted but the requestor’s token has at least one restricting SID, the complete access check is performed against the restricting SIDs. If this second access check does not grant the desired access, then the entire access request fails.
   

25.3.1.4Default DAC Protection

The TSF provides a process ensuring a DACL is applied by default to all new objects. When new objects are created, the appropriate DACL is constructed. The default DAC protections for DS objects and non-DS objects are slightly different.

The TOE uses the following rules to set the DACL in the SDs for new named kernel objects:

• 
  The object's DACL is the DACL from the SD specified by the creating process. The TOE merges any inheritable ACEs into the DACL unless SE_DACL_PROTECTED is set in the SD control flags. The TOE then sets the SE_DACL_PRESENT SD control flag. Note that a creating process can explicitly provide a SD that includes no DACL. The result will be an object with no protections. This is distinct from providing no SD which is described below.
  
• 
  If the creating process does not specify a SD, the TOE builds the object's DACL from inheritable ACEs in the parent object's DACL. The TOE then sets the SE_DACL_PRESENT SD control flag.
  
• 
  If the parent object has no inheritable ACEs, the TOE uses its object manager subcomponent to provide a default DACL. The TOE then sets the SE_DACL_PRESENT and SE_DACL_DEFAULTED SD control flags.
  
• 
  If the object manager does not provide a default DACL, the TOE uses the default DACL in the subject's access token. The TOE then sets the SE_DACL_PRESENT and SE_DACL_DEFAULTED SD control flags.
  
• 
  The subject's access token always has a default DACL, which is set by the LSA subcomponent when the token is created.
  

The method used to build a DACL for a new DS object is slightly different. There are two key differences, which are as follows:

• 
  The rules for creating a DACL distinguish between generic inheritable ACEs and object-specific inheritable ACEs in the parent object's SD. Generic inheritable ACEs can be inherited by all types of child objects. Object-specific inheritable ACEs can be inherited only by the type of child object to which they apply.
  
• 
  The AD schema definition for the object can include a SD. Each object class defined in the schema has a defaultSecurityDescriptor attribute. If neither the creating process nor inheritance from the parent object provides a DACL for a new AD object, the TOE uses the DACL in the default SD specified by the schema.
  

The TOE uses the following rules to set the DACL in the security descriptor for new DS objects:

• 
  The object's DACL is the DACL from the SD specified by the creating process. The TOE merges any inheritable ACEs into the DACL unless SE_DACL_PROTECTED is set in the SD control flags. The TOE then sets the SE_DACL_PRESENT SD control flag.
  
• 
  If the creating process does not specify a SD, the TOE checks the parent object's DACL for inheritable object-specific ACEs that apply to the type of object being created. If the parent object has inheritable object-specific ACEs for the object type, the TOE builds the object's DACL from inheritable ACEs, including both generic and object-specific ACEs. It then sets the SE_DACL_PRESENT SD control flag.
  
• 
  If the parent object has no inheritable object-specific ACEs for the type of object being created, the TOE uses the default DACL from the AD schema for that object type. It then sets the SE_DACL_PRESENT and SE_DACL_DEFAULTED SD control flags.
  
• 
  If the AD schema does not specify a default DACL for the object type, the TOE uses the default DACL in the subject's access token. It then sets the SE_DACL_PRESENT and SE_DACL_DEFAULTED SD control flags.
  
• 
  The subject's access token always has a default DACL, which is set by the LSA subcomponent when the token is created.
  

All tokens are created with an appropriate default DACL, which can be applied to the new objects as appropriate. The default DACL is restrictive in that it only allows the SYSTEM SID and the user SID that created the object to have access. The SYSTEM SID is a special SID representing TSF trusted processes.

25.3.1.5DAC Management

• 
  The following are the four methods that DACL changes are controlled:
  
  • 
    Object owner: Has implicit WRITE_DAC access.
    
  • 
    Explicit DACL change access: A user granted explicit WRITE_DAC access on the DACL can change the DACL.
    
  • 
    Take owner access: A user granted explicit WRITE_OWNER access on the DACL can take ownership of the object and then use the owner’s implicit WRITE_DAC access.
    
  • 
    Take owner privilege: A user with SeTakeOwner privilege can take ownership of the object and then user the owner’s implicit WRITE_DAC access.
    

25.3.1.6Reference Mediation

Access to objects on the system is generally predicated on obtaining a handle to the object. Handles are usually obtained as the result of opening or creating an object. In these cases, the TSF ensures that access validation occurs before creating a new handle for a subject. Handles may also be inherited from a parent process or directly copied (with appropriate access) from another subject. In all cases, before creating a handle, the TSF ensures that that the security policy allows the subject to have the handle (and thereby access) to the object. A handle always has a granted access mask associated with it. This mask indicates, based on the security policy, which access rights to the object that the subject was granted. On every attempt to use a handle, the TSF ensures that the action requested is allowed according to the handle’s granted access mask. In a few cases, such as with DS, objects are directly accessed by name without the intermediate step of obtaining a handle first. In these cases, the TSF checks the request against the access policy directly (rather than checking for a granted access mask).

25.3.2VPN Client

The Windows IPsec VPN client can be configured by the device local administrator. The administrator can configure the IPsec VPN client that all IP traffic is routed through the IPsec tunnel except for:

• 
  IKE traffic used to establish the VPN tunnel
  
• 
  IPv4 ARP traffic for resolution of local network layer addresses and to establish a local address
  
• 
  IPv6 NDP traffic for resolution of local network layer addresses and to establish a local address
  

The IPsec VPN is an end-to-end internetworking technology and so VPN sessions can be established over physical network protocols such as wireless LAN (Wi-Fi) or local area network.

The components responsible for routing IP traffic through the VPN client:

• 
  The IPv4 / IPv6 network stack in the kernel processes ingoing and outgoing network traffic.
  
• 
  The IPsec and IKE and AuthIP Keying Modules service which hosts the IKE and Authenticated Internet Protocol (AuthIP) keying modules. These keying modules are used for authentication and key exchange in Internet Protocol security (IPsec).
  
• 
  The Remote Access Service device driver in the kernel, which is used primarily for VPN connections; known as the “RAS IPsec VPN” or “RAS VPN”.
  
• 
  The IPsec Policy Agent service which enforces IPsec policies.
  

Universal Windows App developers can implement their own VPN client if authorized by Microsoft to use the networkingVpnProvider capability, which includes setting the policy to lockdown networking traffic as described above.¹⁶

25.3.3SFR Summary

• 
  FDP_ACF_EXT.1: Windows provides a Discretionary Access Control policy to limit modification and reading of objects by non-authorized users.
  

• 
  FDP_IFC_EXT.1: Windows provides interfaces for developers to implement their own VPN client.
  

25.4Identification and Authentication

All logons are treated essentially in the same manner regardless of their source (e.g., interactive logon, network interface, internally initiated service logon) and start with an account name, domain name (which may be NULL; indicating the local system), and credentials that must be provided to the TSF.

Windows 10 and Windows Server 2016 can authenticate users based on username and password being able to support multiple user authentication.

The Local Security Authority component within Windows maintains a count of the consecutive failed logon attempts by security principals from their last successful authentication. When the number of consecutive failed logon attempts is larger than the policy for failed logon attempts, which ranges from 0 (never lockout the account) to 999, Windows will lockout the user account. Windows persists the number of consecutive failed logons on for the user and so rebooting the computer does not reset the failed logon counter. Interactive logons are done on the secure desktop, which does not allow other programs to run, and therefore prevents automated password guessing. In addition, the Windows logon component enforces a one second delay between every failed logon with an increased delay after several consecutive logon failures.

25.4.1X.509 Certificate Validation and Generation

Every Windows component that uses X.509 certificates is responsible for performing certificate validation, however all components use a common system subcomponent,¹⁷ which validates certificates as described in RFC 5280, and particular, the specific validation listed in section 5.1.4.3, including all applicable usage constraints such as Server Authentication for networking sessions and Code Signing when installing product updates. Every component that uses X.509 certificates will have a repository for public certificates and will select a certificate based on criteria such as entity name for the communication partner, any extended key usage constraints, and cryptographic algorithms associated with the certificate. The Windows component will use the same kinds of information along with a certification path and certificate trust lists as part of deciding to accept the certificate.

If certificate validation fails, or if Windows is not able to check the validation status for a certificate, Windows will not establish a trusted network channel, however it will inform the user and seek their consent before establishing a HTTPS web browsing session. Certification validation for updates to Windows, mobile applications, and integrity verification is mandatory, neither the administrator nor the user have the option to bypass the results of a failed certificate validation; software installation and updates is further described in Error: Reference source not found.

When Windows needs to generate a certificate enrollment request it will include a distinguished name, information about the cryptographic algorithms used for the request, any certification extensions, and information about the client requesting the certificate.

25.4.2SFR Summary

• 
  FIA_AFL.1: After the number of consecutive failed authentication attempts for a user account has been surpassed, Windows can be configured to lockout the user account.
  
• 
  FIA_UAU.5: Windows provides authentication using a username and password.
  
•