Trusted Execution

Intel SGX

  • Intel Software Guard Extensions
    • Extension of x86 instruction set (Skylake architecture)
    • Allows isolation of code (enclave)
    • Used to isolate sensitive code
    • Requires trust Intel and the CPU
  • Use Cases
    • Developer does not trust system provider
      • e.g., server host
      • Store keys/personal data inside enclave
    • Remote party does not trust me
      • Software hiding secrets
      • Rights management
      • e.g., use feature X k times
  • Features
    • Trusted execution
    • Memory encryption
    • Integrity checks
    • Change attacker model (towards physical attacker)

Architecture

  • Enclave
    • Part of normal application (less privileged)
    • All memory is encrypted
    • Integrity is verified
    • Run in user-space (create in kernel-space)
    • No system calls allowed
    • No direct communication with enclave (use well-defined end-points, i.e., ecalls/ocalls)
  • Enclave Page Cache (EPC)
    • Integrity protected using hash tree
      • Root hash inside CPU package
      • Every access checks tree
    • Swapping possible
      • Requires EPC table for information of swapped tables
      • Can be recursive
      • High cost
  • Enclave Page Cache Map (EPCM)
    • Keeps track of all pages in EPC
    • Only one
    • EPCM size determines EPC (EPCM has all pages)
    • 188 MiB
    • Information:
      • Permissions of page
      • Page type
      • Is page mapped?
  • SGX Enclave Control Structure (SECS)
    • One per enclave
    • Hold enclave metadata (e.g., size, hash)
    • Only accessible from CPU itself
    • Immutable
  • Thread Control Structure (TCS)
    • Describe entry point into enclave
    • One TCS per enclave thread
    • Inaccessible from outside
    • Immutable
    • References at least one State Save Area
  • State Save Area (SSA)
    • Save processor state (during interrupts)
    • At least one per TCS required (multiple interrupts mean multiple SSAs)
    • Write on interrupt
    • Read on resume
  • Stack/Heap
    • SGX does not enforce enclave stack/head (but recommended)
  • Code/data
    • Encrypted after enclave creation (but integrity checked)
    • Inject secrets later (enclave has not secrets at startup)

../_images/sgx-epcm.png

Attestation & Sealing

Enclave Measurement

  • Use for integrity protection
  • Enclave has unique hash (comprised of pages and their layout)
  • Identical measurements iff enclaves identical
  • MRENCLAVE call

../_images/sgx-measurement.png

Attestation

  • Purpose: Prove that they are the enclaves
  • Allowing for secure communication
  • Types
    • Local: Between two enclaves
    • Remove: Between enclave and remote party
  • Local attestation
    • Scenario: Enclave A and B want to identify identity to each other
    • Report
      • Enclave can generate report with HMAC from processor (EREPORT)
      • Generated for specific target enclave
      • May have payload (e.g., nonce, public key)
    • Result: Secure channel between enclaves Is this a result???
    • Example
      • Alice sends MRENCLAVE to Bob
      • Bob creates report with Alice’s MRENCLAVE
      • Bob sends report to Alice
      • Alice verifies receive report (with EGETKEY)
      • Repeat
  • Remote attestation
    • Quoting enclave:
      • Special enclave
      • Signed by Intel
      • Generates a quote from a report
    • Workflow
      • Alice does local attestation with QE
        • Send MRENCLAVE
        • QE generates report
        • QE sends quote to Alice
      • Alice sends quote to Bob
      • Bob asks Intel Attestation Service (IAS) for verirication
    • Result: Secure channel between enclave and remote party Is this a result???

../_images/sgx-local.png ../_images/sgx-remote.png

Sealing

  • Store data securely and persistently
  • Workflow
    • Enclave generates key
      • Depends on platform
      • EGETKEY:
        • MRENCLAVE: Key tied to enclave memory structure
        • MRSIGNET: Key tied to enclave signing key (allows for enclave updates)
    • Encrypt data
    • Give data to untrusted system to store (contradictory)

Development

  • Instruction set overview:
    • Kernel-mode:
      • ECREATE: Start creation
      • EADD: Add page during creation
      • EEXTEND: Calculate hash sum of added page
      • EINIT: Finalize creation
    • User-mode:
      • EENTER
      • EEXIT
      • ERESUME
  • Compilation
    • Enclave must be self-contained
      • Statically linked
      • Non system calls (use compiler flags)
    • Requires SIGSTRUCT and EINITTOKEN (signed by processor)
    • Use SGX
  • Interrupts
    • Transparent to enclave
    • Generate Asynchronous Enclave Exits (AEX)
    • Register an asynchronous exit handler (AEP) (on enter)
      • Call AEP every AEX (same on exceptions/faults)
      • AEP decides whether to resume or not
  • SDK
    • Library for enclaves
    • SDK has simulation mode
    • Defne ECALLs and OCALLs

../_images/sgx-ssa.png ../_images/sgx-edl.png ../_images/sgx-call.png

Attacks

  • Against SGX
    • Rollback attack against swapped pages: NO (EPC version is tracked)
    • Rowhammer on EPC:
      • Rowhammer: Periodically swap memory to change nearby bits due to electrical fields
      • NO: Pages are hashed
      • YES: SGX-Bomb: Lock processor down
    • Bugs in SGX specification: MAYBE
    • Bugs in SGX implementation: MAYBE/YES
    • Break Management Engine: MAYBE (not proven)
  • Against Enclave
    • Rollback attack against sealed data: YES/MAYBE (enclave provides backwards compatibility, use legacy data)
    • Iago attack: MAYBE/YES (depends on app)
    • TOCTTOU attack: MAYBE/YES (depends on app)
  • Against SDK
    • TOCTTOU attack: NO/MAYBE
      • SGX copies arguments
      • Does not deep-copy structures
  • Side channel against SGX/SDK
    • Side-channel attack: Exploit physical implementation of crypto system
    • Spectre: Read virtual memory by exploiting execution order
    • Foreshadow: Extract keys
    • ZombieLoad: Read virtual memory from other processes running on the same core
    • Plundervolt: Control voltage and frequency to corrupt SGX integrity
  • Side channel against Enclave
    • Depends on implementation
    • AsyncShock: Exploit synchronization bugs
    • Controlled-Channel attack
    • Steal page tables
    • Infer control flow

AMD SME/SEV

  • Problem Cloud computing:
    • Applications are usually VMs
    • Hypervisor as access to all sensitive data
    • Hypervisor isolation can have faults
    • User must trust cloud provider
  • Attacks
    • Admin reads memory of VM data
    • Admin injects code into VM
    • User steals data using hypervisor bug
    • Install malicious hardware
    • Freeze and steal RAM
    • Steal non-volatile RAM
  • Components
    • Hardware encryption module
    • Secure processor
  • Summary
    • Easy full-memory encryption
    • Guard against physical attacks
    • SEV does not protect against malicious hypervisor

Hardware encryption module

  • AES engine
  • Part of memory controller
  • Key located inside CPU (isolated)
  • Encrypt DRAM
  • Minimal performance overhead

Secure processor

  • Dedicated security subsystem (SoC)
  • Non-volatile storage
    • Off-chip
    • Secure
    • Stores firmware + data
  • Provide key generation
  • Enables secure boot (chain/root of trust)

Secure Memory Encryption (SME)

  • Simple and efficient encryption
  • Defend against physical memory attacks
  • Use single key for encryption
  • OS/Hypervisor choose pages to encrypt

Secure Encrypted Virtualization (SEV)

  • Provide secure, encrypted virtual machines
  • Combine SME and AMD-V virtualization
  • Protect VMs/Containers from each other and untrusted hypervisors
  • Keys
    • One for Hypervisor
    • One per VM
    • Cryptographically isolates hypervisor from guest VM
  • Requires AMV-V technology
  • Key management (launch guest VM)
    • Hypervisor load BIOS/OS into DRAM (not encrypted)
    • Hypervisor and user exchange keys (DH, AMD Secure processor)
    • Hypervisor prepares BIOS/OS image
      • Allocate address space identified (ASID)
      • Generate encryption key
      • Firmware encrypts image
    • Hypervisor creates Control Block for VM
    • Hypervisor sends authentication information to user
    • User supplies disk decryption key to guest VM via secure channel
  • Details
    • ASID determines encryption key
    • DMA must occur to shared pages

../_images/sev.png

SME/SEV Interaction

  • Host mode (ASID=0): Host C-bit determine encryption status of page
  • Guest mode, non-SEV guest: NPT determines encryption status
  • Guest mode, SEV guest: Consult guest and NPT

../_images/sme-sev.png

Software

  • AMD
    • Currently developing
    • Secure Processor code not public
    • Linux driver for Hypervisor and AMD Secure processor communication is open source
    • Linux kernel supports SME/SEV
    • AMD Secure Processor driver:
      • Marshal between Hypervisor and processor interface
  • Linux changes for SME
    • Setup: Boot unencrypted, encrypt kernel, enable encryption
    • Runtime: Set C-bit on all new pages
    • Exceptions: ???
  • Linux changes for SEV
    • Pages are encrypted by default
    • ???