Tony MangefesteSenior Program ManagerMicrosoft Corporation

Designing a secure boot experience with modern firmware

SYS-004T

Secure Boot Policies• Secure boot defined in chapter 27 of UEFI

specification• Refer to revision 2.3.1 for latest time-based,

authenticated variables• Monotonic count not supported by Windows 8

• Policies for establishing root of trust with OS core of secure boot• Inserting platform key places firmware into user

mode• Without platform key, no authentication occurs

Keys (27.5)• Platform key (PKpub) establishes trust

relationship between platform owner and platform firmware• IBV or OEM creates

• Key exchange key (KEKpub) establishes trust relationship between platform firmware and operating system• KEKs enrolled into signature databases

• Firmware may allow for self-provisioning with physical presence

Variables (27.6 & 7.2)• OEM owns PKpub

• Microsoft Provides KEKpub

• Microsoft Provides• Microsoft UEFI CApub

• Windows 8 Signature

• Total signatures in firmware: 4

• Microsoft offering support for UEFI Option ROM signing

Platform Keypub

Key Exchange Keypub

Allow DB “db”

Disallow DB

“dbx”

Windows 8 Application• Secure Boot Pre-Release WCK Tests

v1.0.8 available• Review Latest WCK Document

10/31/2011• Microsoft Providing KEK, UEFI,

Windows 8 signatures• Platform Manufacturer provides PK• Microsoft KEK allows Windows 8 to

provide updates to DB & DBx

Databases (27.6)• MS-KEKpub grants access to signature databases• 2 databases required

• “db” & “dbx” (27.8.1)• “db” – Good database

• OEM may include its KEKpub to support utilities such as UEFI Shell and setvariable.efi when secure boot enabled

• OEM may include signatures from IHVs to allow for third-party signed OpROMs

• Must add MS-CA UEFI signature in “db” by Win8-GA

Databases (27.6) part 2• “dbx” – revocation database

• Augmented over time by Microsoft per signatures in KEK

• Microsoft POR: Add hashes of malware firmware images through Windows Update

• Optional: Ability to add certificates, signatures of companies, and signature of CAs to prohibit execution firmware images

• Database minimum recommended size is 64 KB

Platform key (Pkpub)• PKpub inserted into firmware• Private component kept secure for signing

firmware• Necessary for secure firmware updates• PK owned by OEM, ODM, or IBV• Self-generated• PKpriv must be kept secure!

• No chaining needed

Reset scenario• Factory reset – BIOS initiated• Reverts firmware to initial state• “db” – UEFI CA only (no change)• “dbx” – empty

• Preceding applies to catastrophic reset

Provisioning keys• Option 1 (UEFI shell)• IBV supported by tools (setvariable.efi)• Process• Add DB (“db” + “dbx”) with Microsoft

Signature• Add KEK with Microsoft Signature KEKpub

• Add Pkpub

• Enable secure boot

Provisioning keys• Option 2 – (Windows PowerShell)

• OEM may provision UEFI variables through Windows 8 PowerShell

• Load secureboot cmdlets: “Import-module secureboot” from Admin Level PowerShell

• Requires full Windows 8 install• Option 3 – baked into mass production

• A flat flashmap could be created with all this information burned into NVS during manufacturing

Jeff BobzinVice President

• Before Windows 8, Legacy BIOS was a weak link in the chain• Legacy boot briefly returns boot system to 1984• Vulnerable to root kits and other exploits

• UEFI boot replaces Legacy boot and provides a structured and secure startup environment

• UEFI specification provides a framework for OEMs to implement a secure handoff, firmware to OS• Authenticated variables protected by firmware• Protected security databases • Driver signing based on Microsoft Authenticode

UEFI enhances system protection

UEFI secure boot overview• Firmware image is hardware-protected and

any firmware updates must be a secure process

• Third-party drivers, option ROMs, and boot-loaders can be signed by creator using a CA holding trusted keys

• Database of trusted signing keys initialized at factory and updated by the OS• Along with list of any compromised keys

Firmware/OS security interactionsBoot time:• Firmware checks its own integrity and the integrity

of third-party preboot drivers • Firmware checks the integrity of the Windows boot-loader

• Firmware able to detect unauthorized alteration or replacement• Handoff to boot loader with security status presented in

read-only variables

After OS boot:• Windows can perform any required maintenance of the

secure boot databases through run-time functions

Firmware/user security interactions• Required user interaction in the typical operating

environment? NONE! • It just works…

• The feature is designed be automatically administered• Invisible to most users with administration tools provided

only for special needs

• Firmware-provided security administration tools• User recovery of a compromised boot environment• Power user and system administrator tools• Broadens OS compatibility

Security administration tool set• Design requirements:• Built inside the firmware security envelope• Password protected. User physical presence

or authenticated remote access required • Tools used before OS boot • No programmatic access to limit attack

vectors• Powerful but clear interface• Profiles for notebook and tablet users

Security tool set – full notebook profile

1. Enforcement disable – Suspend enforcement starting next boot, but preserve database

2. Enroll unsigned driver – Mark a driver/boot-loader as trusted by user

3. Restore security database – factory defaults4. Turn off security and clear database – the

extreme option for sophisticated administrators

Secure Boot Administration

Support for customized security environmentsDisable:• On user command, secure boot enforcement can be disabled.• Useful when user does install of earlier OS version not

supporting boot-loader signing or secure boot

Customized environment:• UEFI secure boot is standardized and available as foundation

for special needs• An organization may undertake to implement customized

security databases• Factory database can be erased using built-in tool, and then

replaced using a provisioning tool

Security database recovery• The secure boot environment is robust and well-

protected from attack, but when required, recovery is an important administrative tool• Fix loss of databases due to mishap or system repair• Return to standard after using localized database

1. Enter <escape> at power-on to enter selection menu2. Choose Security Administration3. Choose Recovery Task4. Choose Reload with Factory Database5. Secure boot automatically enabled after recovery

OS Compatibility Tools• Driver signing is expected to have wide acceptance in

the industry, but as with every advance there is a transitional time period before universal adoption

• Power user may choose to admit earlier ‘unsigned’ drivers into local ‘trusted-software’ list

• Can also be used for dual booting with security

1. Enter Security Administration and choose Enroll Unsigned Driver

2. Navigate to the storage location – PCI or local storage3. On selection, the file can be marked as trusted, and the hash

stored in the database

Enrolling a hash

Tool set contents adjusted by OEM

• Menu of tools selected by system manufacturer depending on form-factor considerations and target market

OEM support tool set• Insyde has created full set of secure boot

support tools for OEM manufacturing and field service • These are standalone, not in the system

firmware ROM

Some examples:1. Windows program for certificate

management and factory-load image generator

2. UEFI-bootable initial security load installer3. Secure firmware update packaging tool

and downloadable secure update tool for current and earlier OS

Closing Remarks

28

Why UEFI?• UX value prop from Day one: Fast Boot, OEM Certification,

smooth transitions, etc.• Secure Boot • eDrive support for BitLocker • SOC support • WDS Multicast• Boot Next support • Seamless Boot • Network unlock support for BitLocker• Support for > 2.2 TB system disks

29

Optimizing for UEFI• Redesign legacy Option ROMs into UEFI Option ROMs• IHVs – deploy UEFI option ROM support,

manufacturing tools and device drivers with UEFI support

• ODMs – provide service with updated toolsets, 64-bit environments, native factory tools with UEFI

• OEMs – secure your firmware, optimize for speed• Consumer – look for newer UEFI based platform

firmware

Microsoft Recommendations to Secure Boot• Resources to aid your Secure Boot

designs:• UEFI Specification version 2.3.1• Windows 8 Certification Requirements• Windows 8 Certification Tests• UEFI Self-Certification Tests• USWG

• Flash considerations: 64K minimum allows for ~1,875 updates to the DBx (using hashes)

Microsoft UEFI Signing Portal

• Singing through WinQual• Available to its members (over

11,000 companies worldwide)• Administrative cost to enroll as a

member• Signing is free of charge• Code signed by Microsoft UEFI

Certificate Authority

Microsoft Recommendations to Secure Boot• Milestones• Now: Read and understand

documentation• +1 Month: Execute Secure Boot tests• +2 Months: Finalize manufacturing

processes to address secure boot & align your IHVs with Option ROM schedules

• >+3 Months: Freeze firmware, self-test it• Prepare for next Windows 8

Milestone: Beta

Thank You!

For questions, please visit me in the Speakers Connection area following this

session.

© 2011 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a

commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.