How To Build Hardware Support For Secure Startup

1. How To Build Hardware Support For Secure Startup Manny Novoa Security Strategist Personal Systems Group Hewlett-Packard Steve Heil & Mark Williams Program ManagersWindows SecurityMicrosoft Corporation

2. Session Outline • Quick overview of Windows codenamed “Longhorn” Secure Startup feature • Overview of Longhorn TPM Services architecture • Developing applications that work with TPM Services • Windows Longhorn Logo Program proposed requirements for Secure Startup & TPM Services • Hewlett-Packard presents options & trade-offs for building Secure Startup-capable systems • Resources & Call to Action

3. Session Goals • This session answers the system builder’s question, “How do I build PC client SKUs that support Secure Startup?” • Attendees should leave this session with the following: • Guidelines for developing software for TPM Services • A better understanding of why and how to build Secure Startup-capable system SKUs • Knowledge of where to find resources for meeting the Secure Startup system Windows Logo Program requirements and building Secure Startup-capable platforms

4. Quick Overview of Secure Startup • Technology providing higher security through use of Trusted Platform Module (TPM) • Addresses the lost or stolen laptop scenarios with TPM-rooted boot integrity and encryption • Provides secure system startup and full volume encryption built on TPM services • Attackers are stopped from using software tools to get at data

5. What is a TPM? • Module on the motherboard that: • Protects secrets from attackers • Performs cryptographic functions • For example, RSA, SHA-1, RNG • Meets encryption export requirements • Can create, protect and manage cryptographic keys • Provides a unique Endorsement Key (EK) • Performs digital signature operations • Holds Platform Measurements (hashes) • Anchors chain of trust for keys, digital certificates and other credentials • To see industry standard specs for TPM 1.2, go to www.trustedcomputinggroup.org

6. TPM Services – Design Requirements • Create an environment where the TPM can be shared • Provide an appropriate level of abstraction for constrained resources • Protect applications from each other • Provide infrastructure for 3rd party developers and system manufacturers to add value • A single driver to support a variety of v1.2-compliant TPMs in the market • Provide mechanisms to support the right to opt-in and the right to privacy

7. TPM Services Architecture Simplified * = TCG Software Stack

8. TPM Services – Application Development • Write code using the Trusted Service Provider layer of a TCG v1.2 TSS that has been built upon the TPM Base Services (TBS) • Some commands are blocked by default • Command blocking is configurable by the administrator • The Storage Root Key authorization data is zero • Access TPM functionality through the Microsoft features • WMI Interface • Key Storage Provider (KSP)

9. TCG Stack vs. TPM Services Stack • TPM applications use the TCG Service Provider (TSP) interfaces • The TCG Core Services component (TCS) is ported to communicate with the TBS instead of the TCG Device Driver Layer (TDDL) • TPM applications are more agile and better protected when using TBS

10. Introducing… Mark Williams Program ManagerWindows SecurityMicrosoft Corporation

11. Secure Startup & Windows Longhorn Logo Program • The two proposed Windows Longhorn Logo Program requirements for Secure Startup are • SYS-SEC-1 System supports Secure Startup via v1.2 TPM • SYS-SEC-2 System supports Secure Startup by using system firmware security enhancements • These are “If implemented” requirements • Based on industry-standard specs • TCG TPM Specification Version 1.2, at www.trustedcomputinggroup.org/home • TCG TPM Interface Specification v1.2, Revision RC26 or later, at www.trustedcomputinggroup.org/members • TCG PC Client Specific Implementation Spec for Conventional BIOS v1.2, Revision 0.98 or later, at www.trustedcomputinggroups.org/members

12. Secure Startup & Core Logic Chipset • Secure Startup code uses memory-mapped I/O to communicate with TPM • Platform core logic chipset MUST implement memory-mapped I/O to TPM 1.2 over LPC bus • Memory region maps to TPM 1.2 Locality 0 • TPM 1.2 Locality 0 system memory address is 0xFED4_0xxx • This memory region MAY be protected • Details about TPM 1.2 memory-mapped LPC interface is in an industry-standard specification • TCG TPM Interface Specification v1.2, Revision RC26 or later, at www.trustedcomputinggroup.org/members

13. How Does Secure Startup Use The TPM? • Secure Startup code uses TPM 1.2 to • “Measure” software components of system boot process; for each system boot event: • Performs hash of component code and/or data • Adds entry to Event Log • Extends appropriate PCR with hash value • Later seals secrets against those PCR values • To protect secrets on the next platform reset • Mapping of the PCR usage to system boot events is in an industry-standard specification • TCG PC Client Specific Implementation Spec for Conventional BIOS v1.2, Revision 0.98 or later, at www.trustedcomputinggroups.org/members • TCG draft specification for PCR usage on EFI-based platforms under development

14. Why Are Firmware Extensions Required? • Secure Startup code runs in the pre-OS environment that is controlled by firmware • Secure Startup code must be able to use firmware to access the TPM • BIOS must expose INT 1Ah interface • This INT1A interface is specified in the TCG v1.2 PC Client Implementation Specification • Secure Startup code uses a subset of the INT1Ah functions in the TCG spec • TCG_StatusCheck • TCG_PassThroughToTPM • TCG_CompactHashLogExtendEvent • Draft TCG EFI Protocol Spec contains these same three functions

15. Secure Startup ArchitectureStatic Root of Trust Measurement of early boot components

16. Example Firmware Requirements • Requirements for BIOS usage of TPM 1.2 PCR[4] • The BIOS MUST measure into PCR[4] each IPL that is attempted and executed; if IPL code returns control back to BIOS then each IPL MUST subsequently be measured • The BIOS MUST NOT measure portions of the IPL pertaining to the specific configuration of the platform into PCR[4] • For example, the disk geometry data in the MBR would not be measured into PCR[4] • To measure the content of an MBR style disk, the BIOS would measure 0000-01B7h into PCR[4] and 01B8-01FFh into PCR[5] • These requirements are from TCG spec, proposed for testing in the Windows Longhorn Logo Program

17. EFI Architectures & Requirements • Security-enhanced firmware MAY be conventional BIOS, EFI, or a combination of BIOS and EFI • TCG currently drafting two industry-standard EFI specs • EFI Protocol Spec common to PC Clients and Servers • EFI Implementation Spec for PC Clients • Includes mapping of TPM PCR event measurements to EFI boot components • Microsoft is contributing to these specs • Planned support for EFI support in Longhorn OS loader • Draft TCG EFI specs are currently available to TCG member companies, at www.trustedcomputinggroup.com/members

18. Building a Secure Startup System • After system builder has: • Chosen a TPM 1.2 vendor • Committed a BIOS team to working on the extensions • What else is needed? • Build a TCG-defined “Host Platform” which includes • Motherboard • Host processor(s) • TPM • Immutable part of firmware called the Static Core Root of Trust for Measurement (S-CRTM) • Other devices that connect directly to the CPU and interact directly with the CPU

19. Example Motherboard Requirement • The platform MUST perform a “Host Platform Reset” which may be: • Cold Boot Host Platform Reset, • Hardware Host Platform Reset, or • Warm Boot Host Platform Reset • Boot Strap Host processor MUST be reset & begin execution with the S-CRTM • All remaining Host Processors MUST be reset • The TPM MUST be reset • Execution of TPM_Init signal • TPM MUST NOT be reset without a Host Platform Reset • See TCG PC Client Specific Implementation Spec for Conventional BIOS v1.2, Revision 0.98 or later, at www.trustedcomputinggroups.org/members

20. Options And Trade-offs • After the Secure Startup functional requirements are met, the system builder has options to consider, including: • 1:1 binding of TPM to platform • BIOS & CRTM architectures • Operational states of TPM & customer deployment scenarios

21. Longhorn Secure Startup Manny Novoa Security Strategist Personal Systems Group Hewlett-Packard An OEM Cookbook…

22. TPM V1.2 Platform Requirement • 1:1 binding of TPM to platform • System builders desire common motherboards across multiple platforms (may span consumer/commercial) • Modular TPM facilitates build process and serviceability HOWEVER… • TCG Specification clearly dictates binding requirement • TPM bound to 1 and only 1 platform • Soldered to motherboard is well understood • Modular add-in requires cryptographic binding • Security target implication to demonstrate how TPM can not be used on another platform!  This is not trivial! Choice of binding has implications on platform cost and maintenance/serviceability!

23. TPM BIOS Impacts: CRTM • Two CRTM options for PC Architecture • Boot Block as CRTM • Immutable (fixed) code per TCG Specification or… • Prove secure update process in “conformance” security target • Entire BIOS as CRTM • Prove secure update process in “conformance” security target • Challenge for most flash mechanisms in the runtime state!

24. TPM BIOS Impacts: Size Implications • S-CRTM TPM interface codeadds 3KB to 6KB to boot block • F000 segment size limitationrequires creative mapping of BIOS core • BIOS Setup must include TPM functions including enable/disable and factory reset (ForceClear) • RTM TPM interface code is now 32-bit • Mechanism required to transition from natural BIOS state to 32-bit mode

25. Physical Presence • Remote Deployment Consideration • Customers demand automated mechanism to activate and take ownership of TPM However… • TCG specification conflicts in its physical presence requirements • New process is under review by PC Client Workgroup • Conduit to BIOS for command sequences requiring physical presence • S-CRTM must detect user presence (i.e. button press, etc.), otherwise physical presence is locked • e.g. BIOS must distinguish a SW initiated warm/coldboot from a physical pressing of the power button • Value add opportunity in requiring platformadministration credential • Platform builder action: ensure any existingremote deployment scripts migrate to supportnew physical presence process

26. TPM Ownership • TPM Services will handle the process of TPM ownership • Current TCG V1.1 implementations each have specific tools for ownership, which integrate to TSS stack • Ownership Blobs are NOT universally compatible • Blob exchange/process mechanism is currently in definition • Migration from TCG-enabled Windows XP and Windows 2000 platforms? • TCG defined Migration/Maintenance facility may suffice where treat Longhorn installation as a new device/platform • Mechanism under evaluation/creation at Microsoft • Fresh Longhorn/Secure Startup installation • Platform builder must ensure only a single GUIfor ownership (via the OS) • Information gathered must be provided seamlesslyto TSS software layer

27. Case Study: HP ProtectTools & Longhorn HP ProtectTools Security Manager for client PCs Credential Manager for HP ProtectTools BIOS Configuration for HP ProtectTools Smart Card Security for HP ProtectTools Embedded Security for HP ProtectTools • HP ProtectTools focus areas: • Pre-boot security • Single sign-on convenience • Multifactor authentication • Leverage infrastructure components (e.g. TPM) • Migration to Longhorn Secure Startup only affects Embedded Security & BIOS modules • Update to TPM V1.2 • BIOS Integration of INT 1A, PCR measurements & physical presence • Securing CRTM • Other value-add modules focus on pre-boot or via well defined OS interfaces (CAPI, PKCS11, TSS) only

28. ProtectTools Platform Lessons App 1 App 2 App N CAPI PKCS#11 CSP TSS/TCS TBS • Use highest level API whenever possible • CSP for CAPI allows TPM to function as any other crypto device/token • S/Mime support, IE integration for certs, etc. • PKCS#11 module for TPM • RSA SecureID, smart card support, USB crypto token support, etc. • Enhance Secure Startupwith TPM and Smart Card pre-boot authentication • Independent of Secure Startup to preventsystem boot without strong user authentication • Offers strong pre-OS credential storage • Enhanced by Secure Startup in offline scenario

29. Recap For System Builder (OEM) • Begin TPM 1.2 integration process • Standalone chip: Atmel, Infineon, ST Micro, … • Integrated: BroadCom (NIC), National (SIO), … • Ensure 1-1 binding of TPM to platform/motherboard • BIOS Implications • Immutable S-CRTM or define secure flash process • Support physical presence detection within CRTM • Space requirements to add Integrity measurement code and TPM interface code to S-CRTM and RTM • INT 1A support for runtime environment • Leverage TPM in tools/applications • Example: HP ProtectTools Credential Manager uses TPM to protect SSO store • Design value add to highest API level possible

30. Call to Action • Develop TPM applications using a TSS that’s been ported to TBS • Get on the list to receive “Secure Startup Design Guide” publication from Microsoft • Send e-mail to sstartup@microsoft.com • System builders send your reference platforms to Secure Startup test team at Microsoft for evaluation • Review the v1.2 TCG specifications at www.trustedcomputinggroup.org

31. Secure Startup Resources • For answers to questions about Secure Startup and related TPM Services • sstartup@microsoft.com • TCG Web Site • http://www.trustedcomputinggroup.org

32. Community Resources • Windows Hardware & Driver Central (WHDC) • www.microsoft.com/whdc/default.mspx • Technical Communities • www.microsoft.com/communities/products/default.mspx • Non-Microsoft Community Sites • www.microsoft.com/communities/related/default.mspx • Microsoft Public Newsgroups • www.microsoft.com/communities/newsgroups • Technical Chats and Webcasts • www.microsoft.com/communities/chats/default.mspx • www.microsoft.com/webcasts • Microsoft Blogs • www.microsoft.com/communities/blogs

34. © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.