Phoenix Security Architecture and DevID July 2005

1. Phoenix Security Architecture and DevIDJuly 2005 Karen Zelenko Phoenix Technologies

2. Objectives for DevID • Provide strong means to identify and authenticate the identity of “devices” in a network – including during initial provisioning (possibly remotely) • Identity is permanently bound to device • Each identity is unique • Centralized infrastructure not required for DevID to be usable

3. Phoenix Security Architecture • Security Architecture provides secure cryptographic operations and the ability to bind applications and data to a specific device • Operations done in Secure SMI Environment • Caller Validation provides extra protection • Binding to device via Secure Storage

4. Phoenix Security Framework Caller Validation Power-on Application Application Application ‘Ring 3’ Application privilege Core System Software OS Kernel ‘Ring 0’ OS privilege Security Driver System Management Mode (Highest privilege on the CPU) ‘SMM’ CSS privilege Device Key in Secure Silicon

5. Secure Storage • Nonvolatile memory • Hardware-Based • OAR-Locking (Open at Reset) • Offline storage of Device Key (DK) • 20 Bytes = 16 byte DK + 4 byte status • Retrieved at BIOS reset • Contents transferred to SMRAM • Locked until next reset • Examples – CMOS, FWH, EC, …

6. Device Key (DK) • 128-bit Advanced Encryption Standard (AES) • Systems typically ship with no DK • DK randomly generated on first use of a cME Security application • DK unique to that specific device (motherboard) • Never exposed outside of SMI for StrongROM

7. Device Key Handling

8. StrongROM • Embedded Crypto Engine • StrongROM provides: • Secure Storage and DK access • General Crypto • Caller Validation • Runs in SMM (System Management Mode) • SMRAM (Locked, Paged in by hardware) • Time-slicing for compute-intensive operations

9. StrongROM Algorithms • SHA-1 • 160-bit • AES • 128-bit • HMAC-SHA • RSA • 1024-2048-bit • PRNG • SHA-1 Based NIST Approved

10. Caller Validation • Inter-module communication involves checking caller against a signature • driver-to-StrongROM • application-to-driver • Requires that calling applications are • Signed • Authorized • Undamaged • Protects against debug attacks

11. Caller Validation (cont.) • Portion of executable’s in-memory image is hashed into an Owner’s Code Digest (OCD) • OCD is signed by Phoenix • Phoenix maintains hierarchy of keys in a secure location with root key protected by Verisign • Caller validation compares in-memory image of calling application against signature

12. Caller Validation

13. Security Services • Data Protection and Binding to Device • Seal / Unseal AppContainer using Device Key • Data accessed by authorized application on authorized platform • RSA Key Protection and Binding to Device • Special AppContainer storing keys • Private Keys are not exposed outside of SMM • Platform Identifier • Platform ID = HMAC (DK, OCD || Usage Flags)

14. Phoenix Security Strengths • Unique DK – limits class attacks • DK Handled in a secure environment • Secure Storage variety (as opposed to homogenous storage) • Caller validation • Privacy – Limited exposure of the DK • Basic building blocks for applications (ex. Client-server application)

15. DevID with Phoenix Framework • Use the Platform ID as a DevID • Statistically unique credential bound to the device • Derive a new credential unique to DevID, unrelated to the Device Key except by platform association • presumably stored as a protected BLOB outside of StrongROM

16. Summary • Phoenix Security Framework provides the necessary components to implement DevID • strong asymmetric crypto • secure hashing • integrated secure storage • Platform ID by itself meets the needs of DevID • Phoenix Security Framework could be optimized for variety device classes