Windows 8 70-687 Study Guide to be used as an internal resource only

Secure Boot Overview

Published: February 29, 2012

Updated: May 31, 2012

Applies To: Windows 8, Windows Server 2012

Secure Boot is a feature that helps prevent unauthorized firmware, operating systems, or UEFI drivers (also known as Option ROMs) from running at boot time. Secure Boot does this by maintaining databases of software signers and software images that are pre-approved to run on the individual computer.

Signature Databases and Keys

The firmware maintains two databases. One database lists the signers or image hashes of UEFI applications, operating system loaders, and UEFI drivers that can be loaded on the individual computer. The other database lists the revoked images for items that are no longer trusted and may not be loaded. These databases are known as the signature database (db) and the revoked signatures database (dbx).

Microsoft® signs the Microsoft Operating System Loader (called Boot Manager) with a signer that must be included in the database when systems are manufactured.

The Key Enrollment Key database (KEK) is a separate database of signing keys that can be used to update the signature database and revoked signatures database. Microsoft requires a specified key to be included in the KEK database so that in the future Microsoft can add new operating systems to the signature database or add known bad images to the revoked signatures database.

The OEM stores the signature database, revoked signatures database, and KEK signature databases on the firmware nonvolatile RAM (NV-RAM) at manufacturing time. These signature databases must be included to boot Windows by using Secure Boot.

After these databases have been added, and after final firmware validation and testing, the OEM locks the firmware from editing, except for updates that are signed with the correct key or updates by a physically present user who is using firmware menus, and then generates a platform key (PK). The PK can be used to sign updates to the KEK or to turn off Secure Boot.

After the computer is turned on, the signature databases are each checked against the platform key.

If the firmware is not trusted, the UEFI firmware must initiate OEM-specific recovery to restore trusted firmware.

If there is a problem with Windows Boot Manager, the firmware will attempt to boot a backup copy of Windows Boot Manager. If this also fails, the firmware must initiate OEM-specific remediation.

After Windows Boot Manager has started running, if there is a problem with the drivers or NTOS kernel, Windows Recovery Environment (Windows RE) is loaded so that these drivers or the kernel image can be recovered.

After this, Windows loads antimalware software.

Finally, Windows loads other kernel drivers and initializes the user mode processes.

Requirements

Secure Boot requires a computer that meets the UEFI 2.3.1 Specifications.

Secure Boot is supported for UEFI Class 2 and Class 3 computers. For UEFI Class 2 computers, the compatibility support module (CSM) must be disabled so that the computer can only boot UEFI-based operating systems.

Note

Secure Boot does not require a Trusted Platform Module (TPM).

See Also

Concepts

Windows Authentication Overview

Published: February 29, 2012

Updated: August 8, 2012

Applies To: Windows 8, Windows Server 2012

This navigation topic for the IT professional lists documentation resources for Windows authentication and logon technologies that include product evaluation, getting started guides, procedures, design and deployment guides, technical references, and command references for Windows Server 2012 and Windows 8.

Feature description

Authentication is a process for verifying the identity of an object, service or person. When you authenticate an object, the goal is to verify that the object is genuine. When you authenticate a service or person, the goal is to verify that the credentials presented are authentic.

In a networking context, authentication is the act of proving identity to a network application or resource. Typically, identity is proven by a cryptographic operation that uses either a key only the user knows — as with public key cryptography — or a shared key. The server side of the authentication exchange compares the signed data with a known cryptographic key to validate the authentication attempt.

Storing the cryptographic keys in a secure central location makes the authentication process scalable and maintainable. Active Directory Domain Services is the recommended and default technology for storing identity information (including the cryptographic keys that are the user’s’ credentials). Active Directory is required for default NTLM and Kerberos implementations.

Authentication techniques range from a simple logon, which identifies users based on something that only the user knows — like a password, to more powerful security mechanisms that use something that the user has — like tokens, public key certificates, and biometrics. In a business environment, services or users might access multiple applications or resources on many types of servers within a single location or across multiple locations. For these reasons, authentication must support environments for other platforms and for other Windows operating systems.

The Windows operating system implements a default set of authentication protocols, including Kerberos, NTLM, Transport Layer Security/Secure Sockets Layer (TLS/SSL), and Digest, as part of an extensible architecture. In addition, some protocols are combined into authentication packages such as Negotiate and the Credential Security Support Provider. These protocols and packages enable authentication of users, computers, and services; the authentication process, in turn, enables authorized users and services to access resources in a secure manner.

Windows Authentication is used to verify that the information comes from a trusted source, whether from a person or computer object, such as another computer. Windows provides many different methods to achieve this goal as described below.

For a list of deprecated features in Windows Server 2012, see Features Removed or Deprecated in Windows Server 2012.

Windows Authentication is designed to be compatible with previous versions of the Windows operating system. However, improvements with each release are not necessarily applicable to previous versions. Refer to documentation about specific features for more information.

Many authentication features can be configured using Group Policy, which can be installed using Server Manager. The Windows Biometric Framework feature is installed using Server Manager. Other server roles which are dependent upon authentication methods, such as Web Server (IIS) and Active Directory Domain Services, can also be installed using Server Manager.