How To Build Hardware Support For Secure Startup

How To Build Hardware Support For
Secure Startup
Steve Heil & Mark Williams
Program Managers
Windows Security
Microsoft Corporation
Manny Novoa
Security Strategist
Personal Systems Group
Hewlett-Packard
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
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
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
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
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.2compliant TPMs in the market
Provide mechanisms to support the right to opt-in
and the right to privacy
TPM Services Architecture Simplified
* = TCG Software Stack
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)
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
Introducing…
Mark Williams
Program Manager
Windows Security
Microsoft Corporation
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
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
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
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
Secure Startup Architecture
Static Root of Trust Measurement of early boot components
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
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
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
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
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
Longhorn Secure Startup
An OEM Cookbook…
Manny Novoa
Security Strategist
Personal Systems Group
Hewlett-Packard
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!
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!
TPM BIOS Impacts: Size Implications
S-CRTM TPM interface code
adds 3KB to 6KB to boot block
F000 segment size limitation
requires 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
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/cold
boot from a physical pressing of the power button
Value add opportunity in requiring platform
administration credential
Platform builder action: ensure any existing
remote deployment scripts migrate to support
new physical presence process
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 GUI
for ownership (via the OS)
Information gathered must be provided seamlessly
to TSS software layer
Case Study: HP ProtectTools & Longhorn
HP ProtectTools Security Manager
for client PCs
Credential
Manager
BIOS
Configuration
for HP ProtectTools
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)
ProtectTools Platform Lessons
Use highest level API whenever possible
CSP for CAPI allows TPM to function
as any other crypto device/token
App 1
App 2
App N
S/Mime support, IE integration for
certs, etc.
CAPI
PKCS#11 module for TPM
RSA SecureID, smart card support,
USB crypto token support, etc.
PKCS
#11
CSP
Enhance Secure Startup
with TPM and Smart Card pre-boot
authentication
Independent of Secure Startup to prevent
system boot without strong user authentication
Offers strong pre-OS credential storage
Enhanced by Secure Startup in offline scenario
TSS/TCS
TBS
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
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
Secure Startup Resources
For answers to questions about Secure Startup
and related TPM Services
sstartup@microsoft.com
TCG Web Site
http://www.trustedcomputinggroup.org
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
© 2005 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.