Transcript Phoenix Security Architecture and DevID July 2005 Karen Zelenko Phoenix Technologies Confidential Objectives for DevID  Provide strong means to identify and authenticate the identity of “devices” in.

Phoenix Security
Architecture and DevID
July 2005
Karen Zelenko
Phoenix Technologies
Confidential
1
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
© Copyright 2004 Phoenix Technologies Ltd
2
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
© Copyright 2004 Phoenix Technologies Ltd
3
Phoenix Security Framework
Caller
Validation
Power-on
Core System Software
Application Application Application
‘Ring 3’
Application
privilege
OS Kernel
‘Ring 0’
OS
privilege
Security
Driver
System Management Mode
(Highest privilege on the CPU)
‘SMM’
CSS
privilege
Device Key in
Secure Silicon
© Copyright 2004 Phoenix Technologies Ltd
4
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, …
© Copyright 2004 Phoenix Technologies Ltd
5
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
© Copyright 2004 Phoenix Technologies Ltd
6
Device Key Handling
© Copyright 2004 Phoenix Technologies Ltd
7
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
© Copyright 2004 Phoenix Technologies Ltd
8
StrongROM Algorithms
 SHA-1
• 160-bit
 AES
• 128-bit
 HMAC-SHA
 RSA
• 1024-2048-bit
 PRNG
• SHA-1 Based NIST Approved
© Copyright 2004 Phoenix Technologies Ltd
9
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
© Copyright 2004 Phoenix Technologies Ltd
10
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
© Copyright 2004 Phoenix Technologies Ltd
11
Caller Validation
© Copyright 2004 Phoenix Technologies Ltd
12
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)
© Copyright 2004 Phoenix Technologies Ltd
13
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)
© Copyright 2004 Phoenix Technologies Ltd
14
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
© Copyright 2004 Phoenix Technologies Ltd
15
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
© Copyright 2004 Phoenix Technologies Ltd
16