Confidential 1 Phoenix Security Architecture and DevID July 2005 Karen Zelenko Phoenix Technologies.

1

Confidential

Phoenix Security Architecture and DevID

July 2005

Karen ZelenkoPhoenix Technologies

© Copyright 2004 Phoenix Technologies Ltd 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


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

Core System Software

Power-on

Application

OS Kernel

Application Application ‘Ring 3’Applicationprivilege

‘Ring 0’OSprivilege

System Management Mode(Highest privilege on the CPU)

SecurityDriver

‘SMM’CSSprivilege

Caller Validation

Device Key in Secure Silicon


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

Date post:	27-Mar-2015
Category:	Documents
Upload:	kayla-preston
View:	222 times
Download:	7 times

Confidential 1 Phoenix Security Architecture and DevID July 2005 Karen Zelenko Phoenix Technologies.

Documents