mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-15 10:23:37 +00:00
updates
This commit is contained in:
@ -17,7 +17,7 @@ Secure Boot makes a safe and trusted path from the Unified Extensible Firmware I
|
||||
|
||||
To reduce the risk of firmware rootkits, the PC verifies that firmware is digitally signed as it begins the boot process. Then Secure Boot checks the OS bootloader's digital signature as well as all code that runs prior to the operating system starting to ensure the signature and code are uncompromised and trusted by the Secure Boot policy.
|
||||
|
||||
Trusted Boot picks up the process that begins with Secure Boot. The Windows bootloader verifies the digital signature of the Windows kernel before loading it. The Windows kernel, in turn, verifies every other component of the Windows startup process, including boot drivers, startup files, and any antimalware product's early-launch antimalware (ELAM) driver. If any of these files have been tampered with, the bootloader detects the problem and refuses to load the corrupted component. Often, Windows can automatically repair the corrupted component, restoring the integrity of Windows and allowing the PC to start normally.
|
||||
Trusted Boot picks up the process that begins with Secure Boot. The Windows bootloader verifies the digital signature of the Windows kernel before loading it. The Windows kernel, in turn, verifies every other component of the Windows startup process, including boot drivers, startup files, and any anti-malware product's early-launch anti-malware (ELAM) driver. If any of these files have been tampered with, the bootloader detects the problem and refuses to load the corrupted component. Often, Windows can automatically repair the corrupted component, restoring the integrity of Windows and allowing the PC to start normally.
|
||||
|
||||
Tampering or malware attacks on the Windows boot sequence are blocked by the signature enforcement handshakes between the UEFI, bootloader, kernel, and application environments.
|
||||
|
||||
@ -36,7 +36,7 @@ Learn more: FIPS 140 validation
|
||||
Windows cryptographic modules provide low-level primitives such as:
|
||||
|
||||
- Random number generators (RNG)
|
||||
- Support for AES 128/256 with XTS, ECB, CBC, CFB, CCM, and GCM modes of operation; RSA and DSA 2048, 3072, and 4096 key sizes; ECDSA over curves P-256, P-384, P-521
|
||||
- Support for AES 128/256 with XTS, ECB, CBC, CFB, CCM, and GCM modes of operation; RSA and DSA 2048, 3072, and 4,096 key sizes; ECDSA over curves P-256, P-384, P-521
|
||||
- Hashing (support for SHA1, SHA-256, SHA-384, and SHA-512)
|
||||
- Signing and verification (padding support for OAEP, PSS, and PKCS1)
|
||||
- Key agreement and key derivation (support for ECDH over NIST-standard prime curves P-256, P-384, P-521 and HKDF)
|
||||
@ -53,20 +53,20 @@ exchange, opportunities to engage with technical content about Microsoft's produ
|
||||
## Certificates
|
||||
|
||||
To help safeguard and authenticate information, Windows provides comprehensive support for certificates and certificate management. The built-in certificate management command-line utility (certmgr.exe) or MMC snap-in (certmgr.msc) can be used to view and manage certificates, certificate trust lists (CTLs), and
|
||||
certificate revocation lists (CRLs). Whenever a certificate is used in Windows, we validate that the leaf certificate and all the certificates in its chain of trust have not been revoked or compromised. The CTLs and CRLs on the machine are used as a reference for PKI trust and are updated monthly by the Microsoft Trusted Root program. If a trusted certificate or root is revoked, all global devices will be updated, meaning users can trust that Windows will automatically protect against vulnerabilities in public key infrastructure. For cloud and enterprise deployments, Windows also offers users the ability to auto-enroll and renew certificates in Active Directory with Group Policy to reduce the risk of potential outages due to certificate expiration or misconfiguration. Additionally, enterprise certificate pinning can be used to help reduce man-in-the-middle attacks by enabling users to protect their internal domain names from chaining to unwanted certificates. A web application's server authentication certificate chain is checked to ensure it matches a restricted set of certificate authorities. Any web application triggering a name mismatch will start event logging and prevent user access from Microsoft Edge.
|
||||
certificate revocation lists (CRLs). Whenever a certificate is used in Windows, we validate that the leaf certificate and all the certificates in its chain of trust have not been revoked or compromised. The CTLs and CRLs on the machine are used as a reference for PKI trust and are updated monthly by the Microsoft Trusted Root program. If a trusted certificate or root is revoked, all global devices will be updated, meaning users can trust that Windows will automatically protect against vulnerabilities in public key infrastructure. For cloud and enterprise deployments, Windows also offers users the ability to autoenroll and renew certificates in Active Directory with Group Policy to reduce the risk of potential outages due to certificate expiration or misconfiguration. Additionally, enterprise certificate pinning can be used to help reduce man-in-the-middle attacks by enabling users to protect their internal domain names from chaining to unwanted certificates. A web application's server authentication certificate chain is checked to ensure it matches a restricted set of certificate authorities. Any web application triggering a name mismatch will start event logging and prevent user access from Microsoft Edge.
|
||||
|
||||
## Code signing and integrity
|
||||
|
||||
To ensure that Windows files have not been tampered with, the Windows Code Integrity process verifies the signature of each file in Windows. Code signing is core to establishing the integrity of firmware, drivers, and software across the Windows platform. Code signing creates a digital signature by encrypting the hash of the file with the private key portion of a code-signing certificate and embedding the signature into the file. The Windows code integrity process verifies the signed file by decrypting the signature to check the integrity of the file and confirm that it is from a reputable publisher, ensuring that the file hasn't been tampered with.
|
||||
To ensure that Windows files haven't been tampered with, the Windows Code Integrity process verifies the signature of each file in Windows. Code signing is core to establishing the integrity of firmware, drivers, and software across the Windows platform. Code signing creates a digital signature by encrypting the hash of the file with the private key portion of a code-signing certificate and embedding the signature into the file. The Windows code integrity process verifies the signed file by decrypting the signature to check the integrity of the file and confirm that it is from a reputable publisher, ensuring that the file hasn't been tampered with.
|
||||
|
||||
The digital signature is evaluated across the Windows environment on Windows boot code, Windows kernel code, and Windows user mode applications. Secure Boot and Code Integrity verify the signature on bootloaders, Option ROMs, and other boot components to ensure that it is trusted and from a reputable publisher. For drivers not published by Microsoft, Kernel Code Integrity verifies the signature on kernel drivers and requires that drivers be signed by Windows or certified by the Windows Hardware Compatibility Program (WHCP). This program ensures that third-party drivers are compatible with various hardware and Windows and that the drivers are from vetted driver developers.
|
||||
The digital signature is evaluated across the Windows environment on Windows boot code, Windows kernel code, and Windows user mode applications. Secure Boot and Code Integrity verify the signature on bootloaders, Option ROMs, and other boot components to ensure that it's trusted and from a reputable publisher. For drivers not published by Microsoft, Kernel Code Integrity verifies the signature on kernel drivers and requires that drivers be signed by Windows or certified by the Windows Hardware Compatibility Program (WHCP). This program ensures that third-party drivers are compatible with various hardware and Windows and that the drivers are from vetted driver developers.
|
||||
|
||||
## Device health attestation
|
||||
|
||||
The Windows device health attestation process supports a Zero Trust paradigm that shifts the focus from static, network-based perimeters to users, assets, and resources. The attestation process confirms the device, firmware, and boot process are in a good state and have not been tampered with before they can access corporate resources. These
|
||||
The Windows device health attestation process supports a Zero Trust paradigm that shifts the focus from static, network-based perimeters to users, assets, and resources. The attestation process confirms the device, firmware, and boot process are in a good state and haven't been tampered with before they can access corporate resources. These
|
||||
determinations are made with data stored in the TPM, which provides a secure root-of-trust. The information is sent to an attestation service such as Azure Attestation to verify that the device is in a trusted state. Then a modern device management (MDM) tool like Microsoft Intune<sup>[\[9\]](conclusion.md#footnote9)</sup> reviews device health and connects this information with Microsoft Entra ID<sup>[\[9\]](conclusion.md#footnote9)</sup> for conditional access.
|
||||
|
||||
Windows includes many security features to help protect users from malware and attacks. However, security components are trustworthy only if the platform boots as expected and is not tampered with. As noted above, Windows relies on Unified Extensible Firmware Interface (UEFI) Secure Boot, ELAM, DRTM, Trusted Boot, and other low-level hardware and firmware security features to protect your PC from attacks. From the moment you power on your PC until your antimalware starts, Windows is backed with the appropriate hardware configurations that help keep you safe. Measured Boot, implemented by bootloaders and BIOS, verifies and cryptographically records each step of the boot in a chained manner. These events are bound to the TPM, that functions as a hardware root-of-trust. Remote attestation is the mechanism by which these events are read and verified by a service to provide a verifiable, unbiased, and tamper-resilient report. Remote attestation is the trusted auditor of your system's boot, allowing reliant parties to bind trust to the device and its security.
|
||||
Windows includes many security features to help protect users from malware and attacks. However, security components are trustworthy only if the platform boots as expected and isn't tampered with. As noted above, Windows relies on Unified Extensible Firmware Interface (UEFI) Secure Boot, ELAM, DRTM, Trusted Boot, and other low-level hardware and firmware security features to protect your PC from attacks. From the moment you power on your PC until your antimalware starts, Windows is backed with the appropriate hardware configurations that help keep you safe. Measured Boot, implemented by bootloaders and BIOS, verifies and cryptographically records each step of the boot in a chained manner. These events are bound to the TPM, that functions as a hardware root-of-trust. Remote attestation is the mechanism by which these events are read and verified by a service to provide a verifiable, unbiased, and tamper-resilient report. Remote attestation is the trusted auditor of your system's boot, allowing reliant parties to bind trust to the device and its security.
|
||||
|
||||
A summary of the steps involved in attestation and Zero-Trust on a Windows device are as follows:
|
||||
|
||||
|
Reference in New Issue
Block a user