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
  • Modes and Recommendations
  • Legacy (BIOS or CSM) boot
  • UEFI native boot
  • Secure boot standard mode
  • Secure boot custom mode
  • UEFI or legacy boot with TPM auditing
  • UEFI secure boot with TPM auditing
  1. Bootstrap security

NSA Boot Security

Modes and Recommendations

  • Legacy (BIOS or CSM) boot

  • UEFI native boot

  • Secure boot standard mode

  • Secure boot custom mode

  • UEFI or legacy boot with TPM auditing

  • UEFI secure boot with TPM auditing

Legacy (BIOS or CSM) boot

Many computing devices feature a legacy boot mode called Basic Input / Output System (BIOS) mode or Compatibility Support Module (CSM).

Legacy boot modes are intended to be used with older peripherals, hardware, and software lacking support for Unified Extensible Firmware Interface (UEFI)2 standards.

Compatible with decades of solutions and protocols.

Least restrictive solution in terms of security features.

Processor vendors are discontinuing legacy mode support starting in 2020.

UEFI native boot

Unified Extensible Firmware Interface (UEFI) adheres to standards defined by the UEFI Forum.

Hardware, software, peripherals, system vendors, and solution providers collaborate to define common interfaces, variables, protocols, feature sets, and structures for use on modern computing platforms.

Binaries are arranged in the form of modules. Modules can be patched, replaced, added, removed, or otherwise altered individually as needed.

Some modules can execute in parallel to accelerate boot time.

Some modules can fail or enter error states without affecting a device’s ability to boot.

UEFI relies upon Secure Boot or vendor-specific boot protection solutions – no validation or protection of the boot process is granted simply by choosing UEFI over legacy mode.

Some older hardware and software do not function in UEFI mode.

Secure boot standard mode

Secure Boot is a signature and hash-checking mechanism added to the UEFI boot process.

Each firmware and software executable at boot time must have an associated signature or hash. Secure boot validates signatures using RSA-2048 public key certificates.

System firmware, component firmware, bootloaders, kernels, and other boot-time executables are validated by Secure Boot to provide a boot-time anti-malware solution.

Secure Boot signing authorities may make mistakes in granting signatures or loading hashes.

Bootloaders that ignore Secure Boot and boot-time malware have been mistakenly signed and released to the public in the past.

Secure boot custom mode

Custom mode allows the system owner to exert control over Secure Boot’s data stores.

The system owner assumes full responsibility for signing and hashing trusted content (e.g. bootloaders, kernels) rather than relying upon the ecosystems set up by MSFT and system vendors.

Administrators can trust specific hardware components, boot methods, and boot software. Allows system owners such granular control that they can trust an individual version of an OS kernel.

Administrative overhead is required to sign binaries and identify the hashes of items that cannot be signed.

Systems must be provisioned with a custom Secure Boot. Administrators must create custom Secure Boot update scripts.

UEFI or legacy boot with TPM auditing

UEFI and Legacy modes can record hashes of firmware components to the Trusted Platform Module (TPM). The TPM must be both activated and enabled for hashes to be written.

Hashes normally capture firmware images, firmware configurations, expansion component firmware images, expansion component firmware configurations, and the bootloader.

TPM-aware bootloaders can continue logging hashes to describe the kernel, initial file system, and any modules. Kernels, applications, and drivers can log runtime hashes to the TPM too.

TPM PCR hash extensions are automated at the firmware level from the earliest stages of boot.

Newer versions of Windows and Linux also automatically detect the presence of TPM and begin recording integrity information.

There is no automatic enforcement mechanism (TPM performs passive observation during boot).

Malware is not denied execution privileges at boot time.

Any valid UEFI, Legacy, or binary is allowed to execute without signature, hash, or integrity checks.

UEFI secure boot with TPM auditing

Secure Boot can be used in standard mode or custom mode in conjunction with TPM.

TPM provides the ability to cover the early-boot blind spot that exists in Secure Boot. Secure Boot allows the flexibility to handle multiple trusted system images, devices, and configurations when necessary.

The most restrictive option is covered. Windows 10 and newer automatically leverages Secure Boot and TPM when BitLocker is enabled.

Requires the most developer and administrator overhead.

Last updated 11 months ago