Designing a secure boot experience with modern firmware

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

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

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

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

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

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

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

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

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

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

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

13. Jeff BobzinVice President

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

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

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

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

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

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

20. Secure Boot Administration

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

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

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

24. Enrolling a hash

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

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

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

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

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

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

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

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