Phoenix Security Architecture and Devid july 2005 Karen Zelenko



Yüklə 1,51 Mb.
tarix29.09.2018
ölçüsü1,51 Mb.
#71102


Phoenix Security Architecture and DevID July 2005


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



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

  • 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

  • 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

  • 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ə