1 / 34

Designing a secure boot experience with modern firmware

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

lindsey
Télécharger la présentation

Designing a secure boot experience with modern firmware

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. SYS-004T Designing a secure boot experience with modern firmware Tony Mangefeste Senior Program Manager Microsoft Corporation

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

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

  4. 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”

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

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

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

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

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

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

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

  12. Jeff BobzinVice President

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

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

  15. Firmware/OS security interactions 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

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

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

  18. Security tool set – full notebook profile • 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

  19. Secure Boot Administration

  20. Support for customized security environments Disable: • 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

  21. 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 • 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

  22. 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 • 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

  23. Enrolling a hash

  24. Tool set contents adjusted by OEM • Menu of tools selected by system manufacturer depending on form-factor considerations and target market

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

  26. Closing Remarks

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

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

  29. 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)

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

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

  32. Thank You! For questions, please visit me in the Speakers Connection area following this session.

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

More Related