Microsoft Windows Common Criteria Evaluation Microsoft Windows 10 (Anniversary Update) Microsoft Windows Server 2016
Yüklə 0,57 Mb.
|
- Bu səhifədəki naviqasiya:
- 25.6Protection of the TSF 25.6.1Separation and Domain Isolation
- 25.6.2Protection of OS Binaries, Audit and Configuration Data
- 25.6.3Protection From Implementation Weaknesses
- 25.6.4Windows Platform Integrity and Code Integrity
- 25.6.5Windows and Application Updates
- 25.6.5.1Windows 10 and Windows Store Applications
- 25.6.5.2Windows Server 2016 and Application Updates
- 25.6.5.3Distributing updates
FIA_X509_EXT.1: Windows validates X.509 certificates according to RFC 5280 and provides OCSP and CRL services for applications to check certificate revocation status. FIA_X509_EXT.2: Windows uses X.509 certificates for TLS and HTTPS. 25.5Security Management The complete set of management functions are described in Security Management (FMT), the following table maps which activities can be done by a standard Windows user or a local administrator. A checkmark indicates which entity can invoke the management function. Standard users, or programs running on their behalf, are not able to modify policy or configuration that is set by the administrator, the result is that the user cannot override the configuration specified by the administrator.
25.5.1SFR Summary
25.6Protection of the TSF 25.6.1Separation and Domain Isolation The TSF provides a security domain for its own protection and provides process isolation. The security domains used within and by the TSF consists of the following:
The TSF hardware is managed by the TSF kernel-mode software and is not modifiable by untrusted subjects. The TSF kernel-mode software is protected from modification by hardware execution state and protection for both physical memory and memory allocated to a partition; an operating system image runs within a partition. The TSF hardware provides a software interrupt instruction that causes a state change from user mode to kernel mode within a partition. The TSF kernel-mode software is responsible for processing all interrupts, and determines whether or not a valid kernel-mode call is being made. In addition, the TSF memory protection features ensure that attempts to access kernel-mode memory from user mode results in a hardware exception, ensuring that kernel-mode memory cannot be directly accessed by software not executing in the kernel mode. The TSF provides process isolation for all user-mode processes through private virtual address spaces (private per process page tables), execution context (registers, program counters), and security context (handle table and token). The data structures defining process address space, execution context and security context are all stored in protected kernel-mode memory. All security relevant privileges are considered to enforce TSF Protection. User-mode administrator tools execute with the security context of the process running on behalf of the authorized administrator. Administrator processes are protected like other user-mode processes, by process isolation. Application Containers (“App Containers”) provide an execution environment for Universal Windows Applications which prevents Universal Windows Applications from accessing data created by other Universal Windows Applications except through brokered operating system services such as the File Picker dialog. Like TSF processes, user processes also are provided a private address space and process context, and therefore are protected from each other. Additionally, the TSF has the added ability to protect memory pages using Data Execution Prevention (DEP) which marks memory pages in a process as non-executable unless the location explicitly contains executable code. When the processor is asked to execute instructions from a page marked as data, the processor will raise an exception for the OS to handle. The TSF implements cryptographic mechanisms within a distinct user-mode process, where its services can be accessed by both kernel- and user-mode components, in order to isolate those functions from the rest of the TSF to limit exposure to possible errors while protecting those functions from potential tampering attempts. Furthermore, the TSF includes a Code Integrity Verification feature, also known as Kernel-mode code signing (KMCS), whereby device drivers will be loaded only if they are digitally signed by either Microsoft or from a trusted root certificate authority recognized by Microsoft. KMCS uses public-key cryptography technology to verify the digital signature of each driver as it is loaded. When a driver tries to load, the TSF decrypts the hash included with the driver using the public key stored in the certificate. It then verifies that the hash matches the one that it computes based on the driver code using the FIPS -certified cryptographic libraries in the TSF. The authenticity of the certificate is also checked in the same way, but using the certificate authority's public key, which must be configured in and trusted by the TOE. 25.6.2Protection of OS Binaries, Audit and Configuration Data By default, a Windows operating system is installed into the \Windows\ directory of the first bootable storage partition for the computer. The logical name for this directory is %systemRoot%. The kernel, device drivers (.sys files), system executables (.exe files) and dynamically loadable libraries (.dll files) are stored in the \%systemRoot%\system32 directory and subdirectories below system32. Standard users have permissions to read and execute these files, however modify and write permissions are limited to the local administrator and system service accounts. The root directory for audit logs is %systemRoot%\system32\winevt. The local administrator, Event Log service, and the system account have full control over the audit files; standard users are not authorized to access the logs. The primary configuration data store for Windows is the registry, and there are separate registry hives for the computer itself and each user authorized to use the computer. The registry hives for operating system configuration data is located at %systemRoot%\system32\config; the registry hive for the user is located in the user’s profile home directory. Registry files use the same protection scheme as event log files. 25.6.3Protection From Implementation Weaknesses Windows runs on processors that provide support for virtual memory and enforce restrictions to read, write, and execute pages of virtual and physical memory. Collectively, this is known as Data Execution Prevention (DEP). On Intel platforms, DEP is called NX (no execute). The Windows kernel, user-mode applications, and all Windows Store Applications implement Address Space Layout Randomization (ASLR) in order to load executable code at unpredictable base addresses.19 The base address is generated using a pseudo-random number generator that is seeded by high quality entropy sources when available which provides at least 8 random bits for memory mapping. 20 The Windows runtime also provides stack buffer overrun protection capability that will terminate a process after Windows detects a potential buffer overrun on the thread’s stack by checking canary values in the function prolog and epilog as well as reordering the stack. All Windows binaries and Windows Store Applications implement stack buffer overrun protection by being complied with the /GS option,21 and checking that all Windows Store Applications are compiled with buffer overrun protection before ingesting the Windows Store Application into the Windows Store. To enable these protections using the Microsoft Visual Studio development environment, programs are complied with /DYNAMICBASE option for ASLR, and optionally with /HIGHENTROPYVA for 64-bit ASLR, or /NXCOMPAT:NO to opt out of software-based DEP, and /GS (switched on by default) for stack buffer overrun protection. Windows Store Applications are compiled with the /APPCONTAINER option which builds the executable to run in a Windows appcontainer, to run with the user-mode protections described in this section. 25.6.4Windows Platform Integrity and Code Integrity A Windows operating system verifies the integrity of Windows program code using the combination of Secure Boot and Code Integrity capabilities in Windows. On computers with a TPM, such as those used in this evaluation, before Windows will boot, the computer will verify the integrity of the early boot components, which includes the Boot Loader, the OS Loader, and the OS Resume binaries. This capability, known as Secure Boot, checks that the file integrity of early boot components has not been compromised, mitigating the risk of rootkits and viruses, and additionally checks that critical boot-time data have not been modified. Secure Boot collects these file and configuration measurements and seals them to the TPM. When Secure Boot starts in the preboot environment, it will compare the sealed values from the TPM to the measured values from the current boot cycle and if those values do not match the sealed values, Secure Boot will lock the system (which prevents booting) and display a warning on the computer display. While the TPM is part of the external IT environment in this evaluation, the hardware-protected hashes serve as the first step of the chain that provides integrity from the hardware, through the bootchain into the kernel and required device drivers. When the measurements match, the UEFI firmware will load the OS Boot Manager, which is an Authenticode-signed image file, based on the Portable Executable (PE) image file format. A SHA-256 hash based signature and a public key certificate chain are embedded in the boot manager Authenticode signed image file under the “Certificate” IMAGE_DATA_DIRECTORY of the IMAGE_OPTIONAL_HEADER of the file. This public key certificate chain ends in a root public key. The boot manager uses the embedded SHA-256 hash based signature and public key certificate chain to validate its own integrity. A SHA-256 hash of the boot manager image file is calculated for the whole file, with the exception of the following three elements which are excluded from the hash calculation: the CheckSum field in the IMAGE_OPTIONAL_HEADER, the IMAGE_DIRECTORY_ENTRY_SECURITY IMAGE_DATA_DIRECTORY, and the public key certificate table, which always resides at the end of the image file. If the boot manager is validated, then the root public key of the embedded public key certificate chain must match one of the Microsoft root public keys which indicate that Microsoft is the publisher of the boot manager. These root public keys are necessarily hardcoded in the boot manager. If the boot manager cannot validate its own integrity, then the boot manager does not continue to load other modules and displays an error message. After the boot manager determines its integrity, it attempts to load one application from the following list of boot applications:
These boot applications are also Authenticode signed image files and so, the Boot Manager uses the embedded trusted SHA-256 hash based signature and public key certificate chain within the boot application’s IMAGE_OPTIONAL_HEADER to validate the integrity of the boot application before attempting to load it. Except for three elements which are excluded from the hash calculation (these are the same three elements mentioned above in the Boot Manager description), a hash of a boot application image file is calculated in the same manner as for the Boot Manager.24 If the boot application is validated, then the root public key of the embedded public key certificate chain must match one of the hardcoded Microsoft’s root public keys. If the boot manager cannot validate the integrity of the boot application, then the boot manager will not load the boot application and instead displays an error message below along with the full name of the boot application that failed the integrity check. After the boot application’s integrity has been determined, the boot manager attempts to load the boot application. If the boot application is successfully loaded, the boot manager then transfers execution to the loaded application. After the Winload boot application is loaded, it receives the transfer of execution from the boot manager. During its execution, Winload attempts to load the Windows kernel (ntoskrnl.exe) together with a number of early-launch drivers. Among the modules that Winload must validate in the Portable Executable (PE) image file format, are the cryptography-related modules listed below
The four image files above have their trusted SHA hashes stored in catalog files that reside in the local machine catalog directory. Because they are PKCS #7 SignedData messages, catalog files are signed. The root public key of the certificate chain used to verify the signature of a Microsoft’s catalog file must match one of the Microsoft’s root public keys indicating that Microsoft is the publisher of the Windows image files. These Microsoft’s root public keys are hardcoded in the Winload boot application. If the image files are validated, their SHA-256 hashes, as calculated by the Winload boot application, must match their trusted SHA-256 hashes in a Microsoft’s catalog file, which has been verified by the Winload boot application. A hash of an image file is calculated for the whole file, with the exception of the following three elements which are excluded from the hash calculation: the CheckSum field in the IMAGE_OPTIONAL_HEADER, the IMAGE_DIRECTORY_ENTRY_SECURITY IMAGE_DATA_DIRECTORY, and the public key certificate table, which always resides at the end of the image file. Should the Winload boot application be unable to validate the integrity of one of the Windows image files, the Winload boot application does not continue to load other Windows image files. Rather it displays an error message and fails into a non-operational mode. In limited circumstances the pre-boot environment will attempt to repair the boot environment, such as copying files from a repair partition to repair files with integrity errors. When repair is not possible, the boot manager will ask the user to reinstall Windows. After the initial device drivers have been loaded, the Windows kernel will continue to boot the rest of the operating system using the Code Integrity capability (ci.dll) to measure code integrity for (1) the remaining kernel-mode and user-mode programs which need to be loaded for the OS to complete its boot and (2) after booting, CI also verifies the integrity of applications launched by the user (applications from Microsoft are always signed by Microsoft, and third-party applications which may be signed by the developer) by checking the RSA signature for the binary and SHA-256 hashes of the binary which are compared to the catalog files described above. Kernel-mode code signing (KMCS), also managed by CI, prevents kernel-mode device drivers, such as the TCIP/IP network driver (tcpip.sys), from loading unless they are published and digitally signed by developers who have been vetted by one of a handful of trusted certificate authorities (CAs). KMCS, using public-key cryptography technologies, requires that kernel-mode code include a digital signature generated by one of the trusted certificate authorities. When a kernel device driver tries to load, Windows decrypts the hash included with the driver using the public key stored in the certificate, then verifies that the hash matches the one computed with the code. The authenticity of the certificate is checked in the same way, but using the certificate authority's public key, which is trusted by Windows. The root public key of the certificate chain that verifies the signature must match one of the Microsoft’s root public keys indicating that Microsoft is the publisher of the Windows image files. These Microsoft’s root public keys are hardcoded in the Windows boot loader.25 In addition, Windows File Protection maintains a set of protected files that are stored in a cache along with cryptographic hashes of each of those files. Once the system is initialized, Windows File Protection is loaded and will scan the protected files to ensure they have valid cryptographic hashes. Windows File Protection also registers itself to be notified should any of the protected files be modified so that it can recheck the cryptographic checksum at any point while the system is operational. Should the any of the cryptographic hash checks fail, the applicable file will be restored from the cache. 25.6.5Windows and Application Updates Updates to Windows are delivered as Microsoft Update Standalone Package files (.msu files) which are signed by Microsoft with two digital signatures, a RSA SHA1 signature for legacy applications and a RSA SHA-256 signature for modern applications. The digital signature is signed by Microsoft Corporation, with a certification path through a Microsoft Code Signing certificate and ultimately the Microsoft Root Certification Authority. These certificates are checked by the Windows Trusted Installer prior to installing the update. The Windows operating system will check that the certificate is valid and has not been revoked using a standard PKI CRL. Once the Trusted Installer determines that the package is valid, it will update Windows; otherwise the installation will abort and there will be an error message in the event log. Note that the Windows installer will not install an update if the files in the package have lower version numbers than the installed files. The integrity of the Microsoft Code Signing certificate on the computer is protected by the storage root key within the TPM, and the validated integrity of the Windows binaries as a result of Secure Boot and Code Integrity. Updates to the Windows operating system, Windows applications, and Microsoft desktop applications are delivered through the Windows Update capability (for Windows) and Microsoft Update (for Microsoft desktop applications), which is enabled by default, or the user can go to http://catalog.update.microsoft.com to search and obtain security updates on their own volition. A user can then check that the signature is valid either by viewing the digital signature details of the file from Windows Explorer or by using the Get-AuthenticodeSignature PowerShell Cmdlet. The following is an example of using PowerShell:
If the Get-AuthenticodeSignature PowerShell Cmdlet or Windows Explorer could not verify the signature, the status will be marked as invalid. This verification check uses the same functionality described above. 25.6.5.1Windows 10 and Windows Store Applications Universal Windows Platform (UWP) apps can be downloaded from the Windows Store and their installation packages are verified using a digital signature from Microsoft Corporation with the Code Signing usage. These applications are contained in either AppX packages, or a collection of AppX packages known as an AppX bundle.26 The AppX package uses the Open Packaging Conventions (OPC) standard.27 Each package contains a directory file which lists the other files in the package, a digital signature for the package, a block map representing the application files which may be installed on the target computer, and the application files themselves. The AppX Deployment Service will verify the RSA SHA-256 digital signature for the block map and the other AppX metadata at the beginning of the AppX package (or bundle) download. This is described in more detail as part at http://blogs.msdn.com/b/windowsappdev/archive/2012/12/04/designing-a-simple-and-secure-app-package-appx.aspx. 25.6.5.2Windows Server 2016 and Application Updates Windows Server 2016 does not include the inbox Windows Store application, however Server 2016 can still install and upgrade Universal Windows Platform (UWP) apps as described in section 25.6.5.1. Updates to Windows OS applications, such as Edge or Internet Explorer, are verified using the same process as described in section 25.6.5. Windows provides the same mechanisms that third-party applications can use to install their application onto the computer, and by implication, rely on the same verification services used by Microsoft Update packages and AppX packages. 25.6.5.3Distributing updates There are several distribution channels for updates to Windows and Windows applications:
25.6.6SFR Summary
|
