Notes - MCS
Secure Execution Environments
Notes - MCS
Secure Execution Environments
  • Secure Execution Environments
  • Introduction
    • Trusted Computing Base (TCB)
    • TEE (Trusted Execution Environment)
    • Can you trust the operating system?
  • Security in Operating Systems
    • Operating system
    • Virtual machines and hypervisors
    • Computational model
    • Access control
    • Protection with capabilities
    • Unix file protection ACLs
    • Windows NTFS file protection
    • Unix file protection ACLs
    • Privilege elevation
    • Privilege reduction
    • Linux login
  • Virtualization on Intel Processors
    • Modes of Operation
    • Virtual memory
    • How to put assembly instructions inside C code
    • A more elaborate example
    • Useful assembly instructions
  • Intel Software Guard Extensions
    • What is SGX (Software Guard eXtensions)?
    • SGX Enclave Memory
    • Guidelines for designing applications using SGX
    • Performance Overhead
    • SDK compilation modes
    • Writing Enclave Functions
  • ARM TrustZone
    • SoC and IP
    • ARM TrustZone
    • Worlds
    • Architecture
    • TrustZone bootstrap
  • Linux Kernel Namespaces
    • Namespaces
    • Advantages
    • Process Namespace
    • Network namespace
    • Mount namespace
    • UTS namespace
    • User namespace
  • LXC Linux Containers
    • Container
    • LXC containers
  • AppArmor
    • Purpose
    • Enforcement
    • Benefits
    • Attack prevention
    • Enforcement policies
    • Enforcement modes
    • Logging and auditing
    • Profiles
  • TPM (Trusted Platform Module)
    • Trusted Platform Module (TPM)
    • History
    • Cryptographic Concepts
    • Use cases
    • TPM Software Stack (TSS)
    • TPM concepts
    • Entities
    • Key management
    • Restrict signatures
    • Sessions
    • Authorization roles
  • Bootstrap security
    • AEGIS
    • Trusted computing
    • Root of Trust Measurements
    • Trusted Computing Platform Alliance (TCPA)
    • TPM-based attestation
    • Trusted Platform identity credentials
    • UEFI (Unified Extensible Firmware Interface)
    • NSA Boot Security
    • UEFI secure boot & TPM measurements
    • Intel Trusted Execution Technology (TXT)
    • Smartcards
      • Java Cards
      • OpenCard Framework (OCF)
      • Cryptographic services
Powered by GitBook
On this page
  • Secure boot
  • Secure boot keys
  • UEFI secure boot signature databases
  • UEFI secure boot firmware validation
  • UEFI storage of secure boot keys and DBs
  • UEFI setup and user modes
  • Setup mode
  • User mode
  1. Bootstrap security

UEFI (Unified Extensible Firmware Interface)

Last updated 11 months ago

Current firmware interface for PCs

  • Replacing Basic Input and Output System (BIOS)

Its goal was to define a standard way for the operating system to communicate with the platform firmware during the boot process

  • Instead of the former primary mechanism, software interrupts

UEFI allows for modular firmware design

  • Enables hardware and system designers a greater flexibility in designing firmware for modern computing environments

Secure boot

Firmware validation process.

  • Defines how platform firmware manages security certificates, validation of firmware, and a definition of the interface (protocol) between firmware and the operating system.

Goal: validate an OS bootloader

Secure boot keys

Platform Key (PK)

  • (Usually only one) asymmetric key pair

  • Should be under the control of the platform owner

Key Exchange Key (KEK)

  • Set of Asymmetric key pairs

  • Controlled by the OEM and OS vendors

KEKs can only be changed by the PK owner.

UEFI secure boot signature databases

Forbidden signatures database (blacklist, dbx).

  • Hashes of blacklisted firmware code.

Signature database (whitelist, db).

  • Key or certificates of keys that validate signatures over authorized firmware code.

  • Hashes of allowed firmware.

KEK owners can update both databases.

UEFI secure boot firmware validation

Firmware code is not allowed to execute if its hash is in DBX.

Firmware code is allowed to execute if:

  • It is signed by a key in DB; or

  • Has its hash in the DB; or

  • Is signed by a KEK key.

UEFI storage of secure boot keys and DBs

They are stored in UEFI secure variables.

  • Each variable is bound to a public key.

    • Set upon its creation.

  • Variables can only be changed if an authentication descriptor is provided.

    • With a signature made with the corresponding private key.

  • Authentication descriptors cannot be reused.

    • To avoid replay attacks.

UEFI setup and user modes

Setup mode

  • PK, KEK, db and dbx can be changed without checks.

  • The secure boot is off.

User mode

  • PK, KEK, db and dbx cannot be changed without verification.

    • PK, KEK -> requires PK signature

    • db, dbz -> requires a KEK signature