Designing a secure boot experience with modern firmware
1 / 34

Designing a secure boot experience with modern firmware - PowerPoint PPT Presentation

  • Uploaded on

SYS-004T. Designing a secure boot experience with modern firmware. Tony Mangefeste Senior Program Manager Microsoft Corporation . Secure Boot Policies. Secure boot defined in c hapter 27 of UEFI specification Refer to revision 2.3.1 for latest time-based, authenticated variables

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Designing a secure boot experience with modern firmware' - lindsey

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Designing a secure boot experience with modern firmware l.jpg


Designing a secure boot experience with modern firmware

Tony Mangefeste

Senior Program Manager

Microsoft Corporation

Secure boot policies l.jpg
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 l.jpg
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 l.jpg
Variables (27.6 & 7.2)

Platform Keypub

  • 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

Key Exchange Keypub

Allow DB “db”

Disallow DB “dbx”

Windows 8 application l.jpg
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 l.jpg
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 l.jpg
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 pk pub l.jpg
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 s cenario l.jpg
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 l.jpg
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 keys12 l.jpg
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 bobzin vice president l.jpg

Jeff BobzinVice President

Uefi enhances system protection l.jpg
UEFI enhances system protection

  • 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 secure boot overview l.jpg

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

UEFI secure boot overview

Firmware os security interactions l.jpg
Firmware/OS security interactions updates must be a secure process

Boot 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 l.jpg
Firmware/user security interactions updates must be a secure process

  • 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 l.jpg
Security administration tool set updates must be a secure process

  • 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 l.jpg
Security tool set – full notebook profile updates must be a secure process

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

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

  • Restore security database – factory defaults

  • Turn off security and clear database – the extreme option for sophisticated administrators

Secure boot administration l.jpg
Secure Boot Administration updates must be a secure process

Support for customized security environments l.jpg
Support for customized security environments updates must be a secure process


  • 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 l.jpg
Security database recovery updates must be a secure process

  • 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

    • Enter <escape> at power-on to enter selection menu

    • Choose Security Administration

    • Choose Recovery Task

    • Choose Reload with Factory Database

    • Secure boot automatically enabled after recovery

Os compatibility tools l.jpg
OS Compatibility Tools updates must be a secure process

  • 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

    • Enter Security Administration and choose Enroll Unsigned Driver

    • Navigate to the storage location – PCI or local storage

    • On selection, the file can be marked as trusted, and the hash stored in the database

Enrolling a hash l.jpg
Enrolling a hash updates must be a secure process

Tool set contents adjusted by oem l.jpg
Tool set contents adjusted by OEM updates must be a secure process

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

Oem support tool set l.jpg
OEM support tool set updates must be a secure process

  • 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:

  • Windows program for certificate management and factory-load image generator

  • UEFI-bootable initial security load installer

  • Secure firmware update packaging tool and downloadable secure update tool for current and earlier OS

Slide27 l.jpg

Closing Remarks updates must be a secure process

Why uefi l.jpg
Why UEFI? updates must be a secure process

  • 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

Optimizing for uefi l.jpg
Optimizing for UEFI updates must be a secure process

  • 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 l.jpg
Microsoft Recommendations to Secure Boot updates must be a secure process

  • 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 l.jpg
Microsoft UEFI Signing Portal updates must be a secure process

  • 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 boot32 l.jpg
Microsoft Recommendations to Secure Boot updates must be a secure process

  • 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

Slide33 l.jpg

Thank You! updates must be a secure process

For questions, please visit me in the

Speakers Connection area following this session.

Slide34 l.jpg

© 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.