Windows Generate Secure Boot Keys

• Secure boot is a security standard developed by members of the PC industry to help make sure that a device boots using only software that is trusted by the Original Equipment Manufacturer (OEM). When the PC starts, the firmware checks the signature of each piece of boot software, including UEFI firmware drivers (also known as Option ROMs), EFI applications, and the operating system.
• Mar 25, 2015 Or you could tweak Secure Boot and only allow operating systems signed with your own personal signing key to boot. Windows 10 gives manufacturers an option Windows 10 makes the user-configuration.

Applies to:

Windows Secure Boot Key Creation and Management Guidance Secure Boot Key Generation and Signing Using HSM (Example) UEFI Validation Option ROM Validation Guidance.

• Windows 10
• Windows 8.1

The Windows operating system has many features to help protect you from malware, and it does an amazingly good job. Except for apps that businesses develop and use internally, all Microsoft Store apps must meet a series of requirements to be certified and included in the Microsoft Store. This certification process examines several criteria, including security, and is an effective means of preventing malware from entering the Microsoft Store. Even if a malicious app does get through, the Windows 10 operating system includes a series of security features that can mitigate the impact. For instance, Microsoft Store apps are sandboxed and lack the privileges necessary to access user data or change system settings.

Windows 10 has multiple levels of protection for desktop apps and data, too. Windows Defender uses signatures to detect and quarantine apps that are known to be malicious. Windows Defender SmartScreen warns users before allowing them to run an untrustworthy app, even if it’s recognized as malware. Before an app can change system settings, the user would have to grant the app administrative privileges by using User Account Control.

Those are just some of the ways that Windows 10 protects you from malware. However, those security features protect you only after Windows 10 starts. Modern malware—and bootkits specifically—are capable of starting before Windows, completely bypassing operating system security, and remaining completely hidden.

When you run Windows 10 on a PC or any PC that supports Unified Extensible Firmware Interface (UEFI), Trusted Boot protects your PC from malware from the moment you power on your PC until your anti-malware starts. In the unlikely event that malware does infect a PC, it can’t remain hidden; Trusted Boot can prove the system’s integrity to your infrastructure in a way that malware can’t disguise. Even on PCs without UEFI, Windows 10 provides even better startup security than previous versions of Windows.

First, let’s examine what rootkits are and how they work. Then, we’ll show you how Windows 10 can protect you.

The threat: rootkits

Rootkits are a sophisticated and dangerous type of malware that run in kernel mode, using the same privileges as the operating system. Because rootkits have the same rights as the operating system and start before it, they can completely hide themselves and other applications. Often, rootkits are part of an entire suite of malware that can bypass local logins, record passwords and keystrokes, transfer private files, and capture cryptographic data.

Different types of rootkits load during different phases of the startup process:

• Firmware rootkits. These kits overwrite the firmware of the PC’s basic input/output system or other hardware so the rootkit can start before Windows.
• Bootkits. These kits replace the operating system’s bootloader (the small piece of software that starts the operating system) so that the PC loads the bootkit before the operating system.
• Kernel rootkits. These kits replace a portion of the operating system kernel so the rootkit can start automatically when the operating system loads.
• Driver rootkits. These kits pretend to be one of the trusted drivers that Windows uses to communicate with the PC hardware.

The countermeasures

Windows 10 supports four features to help prevent rootkits and bootkits from loading during the startup process:

• Secure Boot. PCs with UEFI firmware and a Trusted Platform Module (TPM) can be configured to load only trusted operating system bootloaders.
• Trusted Boot. Windows checks the integrity of every component of the startup process before loading it.
• Early Launch Anti-Malware (ELAM). ELAM tests all drivers before they load and prevents unapproved drivers from loading.
• Measured Boot. The PC’s firmware logs the boot process, and Windows can send it to a trusted server that can objectively assess the PC’s health.

Figure 1 shows the Windows 10 startup process.

Figure 1. Secure Boot, Trusted Boot, and Measured Boot block malware at every stage

Secure Boot and Measured Boot are only possible on PCs with UEFI 2.3.1 and a TPM chip. Fortunately, all Windows 10 PCs that meet Windows Hardware Compatibility Program requirements have these components, and many PCs designed for earlier versions of Windows have them as well.

The sections that follow describe Secure Boot, Trusted Boot, ELAM, and Measured Boot.

Secure Boot

When a PC starts, it first finds the operating system bootloader. PCs without Secure Boot simply run whatever bootloader is on the PC’s hard drive. There’s no way for the PC to tell whether it’s a trusted operating system or a rootkit.

When a PC equipped with UEFI starts, the PC first verifies that the firmware is digitally signed, reducing the risk of firmware rootkits. If Secure Boot is enabled, the firmware examines the bootloader’s digital signature to verify that it hasn’t been modified. If the bootloader is intact, the firmware starts the bootloader only if one of the following conditions is true:

• The bootloader was signed using a trusted certificate. In the case of PCs certified for Windows 10, the Microsoft® certificate is trusted.
• The user has manually approved the bootloader’s digital signature. This allows the user to load non-Microsoft operating systems.

All x86-based Certified For Windows 10 PCs must meet several requirements related to Secure Boot:

• They must have Secure Boot enabled by default.
• They must trust Microsoft’s certificate (and thus any bootloader Microsoft has signed).
• They must allow the user to configure Secure Boot to trust other bootloaders.
• They must allow the user to completely disable Secure Boot.

These requirements help protect you from rootkits while allowing you to run any operating system you want. You have three options for running non-Microsoft operating systems:

• Use an operating system with a certified bootloader. Because all Certified For Windows 10 PCs must trust Microsoft’s certificate, Microsoft offers a service to analyze and sign any non-Microsoft bootloader so that it will be trusted by all Certified For Windows 10 PCs. In fact, an open source bootloader capable of loading Linux is already available. To begin the process of obtaining a certificate, go to https://partner.microsoft.com/dashboard.
• Configure UEFI to trust your custom bootloader. All Certified For Windows 10 PCs allow you to trust a non-certified bootloader by adding a signature to the UEFI database, allowing you to run any operating system, including homemade operating systems.
• Turn off Secure Boot. All Certified For Windows 10 PCs allow you to turn off Secure Boot so that you can run any software. This does not help protect you from bootkits, however.

To prevent malware from abusing these options, the user must manually configure the UEFI firmware to trust a non-certified bootloader or to turn off Secure Boot. Software cannot change the Secure Boot settings. For more information about Secure Boot, read the blog, Protecting the pre-OS environment with UEFI.

Like most mobile devices, ARM-based Certified For Windows RT devices, such as the Microsoft Surface RT device, are designed to run only Windows 8.1. Therefore, Secure Boot cannot be turned off, and you cannot load a different operating system. Fortunately, there is a large market of ARM devices designed to run other operating systems.

Windows Generate Secure Boot Keys Free

Trusted Boot

Trusted Boot takes over where Secure Boot leaves off. The bootloader verifies the digital signature of the Windows 10 kernel before loading it. The Windows 10 kernel, in turn, verifies every other component of the Windows startup process, including the boot drivers, startup files, and ELAM. If a file has been modified, the bootloader detects the problem and refuses to load the corrupted component. Often, Windows 10 can automatically repair the corrupted component, restoring the integrity of Windows and allowing the PC to start normally.

Early Launch Anti-Malware

Because Secure Boot has protected the bootloader and Trusted Boot has protected the Windows kernel, the next opportunity for malware to start is by infecting a non-Microsoft boot driver. Traditional anti-malware apps don’t start until after the boot drivers have been loaded, giving a rootkit disguised as a driver the opportunity to work.

/prototype-2-steam-key-generator.html. Early Launch Anti-Malware (ELAM) can load a Microsoft or non-Microsoft anti-malware driver before all non-Microsoft boot drivers and applications, thus continuing the chain of trust established by Secure Boot and Trusted Boot. Because the operating system hasn’t started yet, and because Windows needs to boot as quickly as possible, ELAM has a simple task: examine every boot driver and determine whether it is on the list of trusted drivers. If it’s not trusted, Windows won’t load it.

An ELAM driver isn’t a full-featured anti-malware solution; that loads later in the boot process. Windows Defender (included with Windows 10) supports ELAM, as does Microsoft System Center 2012 Endpoint Protection and several non-Microsoft anti-malware apps.

Measured Boot

If a PC in your organization does become infected with a rootkit, you need to know about it. Enterprise anti-malware apps can report malware infections to the IT department, but that doesn’t work with rootkits that hide their presence. In other words, you can’t trust the client to tell you whether it’s healthy.

As a result, PCs infected with rootkits appear to be healthy, even with anti-malware running. Infected PCs continue to connect to the enterprise network, giving the rootkit access to vast amounts of confidential data and potentially allowing the rootkit to spread across the internal network.

Working with the TPM and non-Microsoft software, Measured Boot in Windows 10 allows a trusted server on the network to verify the integrity of the Windows startup process. Measured Boot uses the following process:

1. The PC’s UEFI firmware stores in the TPM a hash of the firmware, bootloader, boot drivers, and everything that will be loaded before the anti-malware app.
2. At the end of the startup process, Windows starts the non-Microsoft remote attestation client. The trusted attestation server sends the client a unique key.
3. The TPM uses the unique key to digitally sign the log recorded by the UEFI.
4. The client sends the log to the server, possibly with other security information.

Depending on the implementation and configuration, the server can now determine whether the client is healthy and grant the client access to either a limited quarantine network or to the full network.

Figure 2 illustrates the Measured Boot and remote attestation process.

Figure 2. Measured Boot proves the PC’s health to a remote server

Windows 10 includes the application programming interfaces to support Measured Boot, but you’ll need non-Microsoft tools to implement a remote attestation client and trusted attestation server to take advantage of it. For an example of such a tool, download the TPM Platform Crypto-Provider Toolkit from Microsoft Research or Microsoft Enterprise Security MVP Dan Griffin’s Measured Boot Tool.

Measured Boot uses the power of UEFI, TPM, and Windows 10 to give you a way to confidently assess the trustworthiness of a client PC across the network.

Summary

Secure Boot, Trusted Boot, and Measured Boot create an architecture that is fundamentally resistant to bootkits and rootkits. In Windows 10, these features have the potential to eliminate kernel-level malware from your network. This is the most ground-breaking anti-malware solution that Windows has ever had; it’s leaps and bounds ahead of everything else. With Windows 10, you can truly trust the integrity of your operating system.

Additional resources

Version 1.3

Here's an example of how to generate Secure Boot keys (PK and others) by using a hardware security module (HSM).

You'll need to know the Secure Boot Public Key Infrastructure (PKI). For more info, see Windows 8.1 Secure Boot Key Creation and Management Guidance.

Requirements

Tools Needed

• certreq.exe – Available Inbox

• certutil.exe – Available Inbox

• Signtool.exe – Available in the latest Windows SDK

Hardware Security Module (HSM)

The whitepaper demonstrates the key generation using examples from the nCipher (now Thales) PCI HSM model nC1003P/nC3023P/nC3033P and the SafeNet Luna HSMs. Most of the concepts apply to other HSM vendors as well.

For other HSMs, contact your manufacturer for additional instructions on how to tailor your approach with the HSM Cryptographic Service Provider (CSP).

Approach

We use the Microsoft certificate creation tool: certreq.exe to generate the Secure Boot Platform Key (PK) and other keys needed for Secure Boot.

The certreq tool can be adapted to use an HSM by providing the Cryptographic Service Provider (CSP) to be the HSM.

Find the Cryptographic Service Provider (CSP)

You can use either the certutil.exe tool or a tool used by the HSM to list the CSPs.

• This example uses the certutil tool to show the CSPs on the Thales/nCipher HSM:

  For the SHA-256 digesting algorithm, use the CNG provider: 'nCipher Security World Key Storage Provider'. Legacy providers do not support SHA-256 and are not suitable for use with Secure Boot.

• This example uses the built-in Thales/nCipher tool to list the CSP:

  For the SHA-256 digesting algorithm, use the CNG provider: 'nCipher Security World Key Storage Provider'. Legacy providers do not support SHA-256 and are not suitable for use with Secure Boot.

• This example uses the SafeNet Luna HSMs tool to list the CSP:

  For SHA-256 digest algorithm you will need to use a CNG provider – “SafeNet Key Storage Provider”. Legacy providers do not support SHA-256 and are not suitable for use with Secure Boot.

To generate the key:

Sample request.inf file:

Update the following values:

• Subject: Replace the TODO’s with real data 'CN=Corporation TODO Platform Key,O=TODO Corporation,L=TODO_City,S=TODO_State,C=TODO_Country'.

• ValidityPeriod, ValidityPeriodUnits: Use the validity period of 6 years. While a PK may only be valid for 2 years, the 6-year period allows for potential future servicing.

• KeyContainer: Enter the container id that you used to create the Key with the HSM. You may be asked to provide the tokens that you have used to create the Security World for the Thales HSM.

Validating certificate (self-signed)

Verify that the certificate has been generated correctly:

For example: certutil -store -v my '7569d364a2e77b814274c81ae6360ffe'

Windows Enable Secure Boot

Sample output:

Backing up the certificate

Back up your certificates. This way, if either the certificate store or the server goes down, you can add the certificate back to the store. For more info on certreq.exe, see Advanced Certificate Enrollment and Management: Appendix 3: Certreq.exe Syntax

Note, the PK is a self-signed certificate, and is also used to sign the KEK.

There are 2 parts to PK signing / initial provisioning. Please talk to your Microsoft contact to get these scripts:

• subcreate_set_PK_example_initial_provisioning_example.ps1. Used by the signtool to sign the PK comes later in the servicing case.

• subcreate_set_PK_service_example.ps1. Since we are dealing with the HSM case, the following line applies in the script applies.

Signing with PK certificate (servicing scenario)

This section applies to signing with your PK certificate and may not be applicable for initial provisioning of system. However, you can use the method here to test your service scenario.

Determine the certificate hash (sha1)

Determine the SHA1 hash of the certificate. You can get the SHA1 hash by using either of the following methods:

• In Windows, open the Certificate file, select the Details tab, and check the value for Thumbprint.

• Or use the following command:

  Sample output:

Sign with signtool with the certificate store specified as a reference

Use the SHA1 hash to sign the KEK certificate:

Where KEK.bin is the filename of the binary certificate you want to sign.

Sample output:

NOTE For compatibility with the UEFI Specification and maximum compatibility across UEFI implementations, the /p7co and /p7ce parameters must be present, the value passed to /p7co must be 1.2.840.113549.1.7.1, and the value passed to /p7ce must be DetachedSignedData. Also, for improved compatibility with production signing environments, a signtool.exe commandline that fully specifies the hardware key container is as follows:

For more info, see Sign Tool (SignTool.exe) and Windows 8.1 Secure Boot Key Creation and Management Guidance.

Appendix A – Using Thales KeySafe for viewing keys

Thales KeySafe is based on a GUI.

To use KeySafe, you must have installed JRE/JDK 1.4.2, 1.5, or 1.6. Install Java before you install the nCipher software.

Configure the hardserver config file under the %NFAST_KMDATA%config folder:

Edit settings in the server_startup section:

nonpriv_port. This field specifies the port on which the hardserver listens for local non-privileged TCP connections.

• Default to connecting to port 9000.

• If the NFAST_SERVER_PORT environment variable is set, it overrides any value set for nonpriv_port

priv_port. This field specifies the port on which the hardserver listens for local privileged TCP connections.

• Default to connecting to port 9001.

• If the NFAST_SERVER_PRIVPORT environment variable is set, it overrides any value set for priv_port

The following are screenshots from the Thales KeySafe GUI:

The following image is generated by launching the KeySafe utility and then navigating to the KeyList menu.

For more info, see the nCipher/Thales Users Guide.

Appendix B: Using SafeNet CMU Utility to view keys

For more details, please consult the SafeNet Luna HSM documentation.

Related topics