Phoenix Security Architecture and Devid july 2005 Karen Zelenko
Yüklə
1,51 Mb.
tarix
29.09.2018
ölçüsü
1,51 Mb.
#71102
Phoenix Security Architecture and DevID July 2005
Karen Zelenko
Phoenix
Technologies
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
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
Phoenix Security Framework
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, …
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
Device
Key Handling
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
StrongROM Algorithms
SHA-1
160-bit
AES
128-bit
HMAC-SHA
RSA
1024-2048-bit
PRNG
SHA-1
Based NIST Approved
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
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
Caller Validation
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)
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)
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
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
Yüklə
1,51 Mb.
Dostları ilə paylaş:
Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©genderi.org 2024
rəhbərliyinə müraciət
Ana səhifə
Psixologiya