• Like
  • Save
Txt Introduction
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Txt Introduction

  • 5,901 views
Published

This slide is crested and presented by Weiqi Dai, PhD candidate of College of Computer Science, Huazhong University of Science & Technology

This slide is crested and presented by Weiqi Dai, PhD candidate of College of Computer Science, Huazhong University of Science & Technology

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
5,901
On SlideShare
0
From Embeds
0
Number of Embeds
1

Actions

Shares
Downloads
0
Comments
2
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Intel ® Trusted Execution Technology
    1
  • 2. Static root of trust for measurement
    Dynamic root of trust for measurement
    Flicker: Minimal TCB Code Execution
    Static root of trust for measurement
  • 3. 3
    Basic TPM Functions
    PCRs store integrity measurement chain
    PCRnew = SHA-1(PCRold||measurement)
    Remote attestation (PCRs + AIK)
    Attestation Identity Keys (AIKs) for signing PCRs
    Attest to value of integrity measurements to remote party
    Sealed storage (PCRs + SRK)
    Protected storage + unlock state under a particular integrity measurement (data portability concern)
  • 4. 4
    TCG-Style Attestation
    OS Kernel
    OS Kernel
    Apps
    Apps
    Module 1
    Module 1
    App 1
    App 1
    Module 2
    Module 2
    App 2
    App 2
    TPM
    conf
    conf
    PCRs
    Boot Loader
    Boot Loader
    BIOS
    BIOS
    Hardware
    Software
    AIK-1
  • 5. 5
    TCG-Style Attestation
    Host platform
    Challenger
  • 6. 6
    TCG-style Attestation的缺点
    Static root of trust for measurement (reboot)
    Measures entire system
    Requires hundreds of integrity measurements just to boot
    Every host is different
    firmware versions, drivers, patches, apps, spyware, …
    TCB includes entire system!
    Integrity measurements are done at load-time not at run-time
    Time-of-check-time-of-use (TOCTOU) problem
    Cannot detect any dynamic attacks!
    No guarantee of execution
    A1
    A2
    A3
    Operating System
    Hardware TPM
  • 7. 7
    Example: TCG on Linux
    Integrity Measurement Architecture (IMA) by IBM
    Measurement principles
    Whole system measurements
    Measure all executable content on-demand
    Too expensive to measure whole system
    Content is added dynamically
    Measure content before execution
    Only measured content can introduce and measure new content
    Place as little trust as necessary in measurement system
  • 8. 8
    Linux Implementation Overview
    Use trusted boot to measure BIOS, bootstrap loader, and kernel
    The kernel keeps a list of measurements for each loaded
    Executable Scripts (shell, Perl, etc)
    Shared library Java class files
    Kernel module …
    Before a measurement is added to the list, PCR10 is extended with that measurement. Integrity of this in-kernel list is guaranteed by PCR10
    Verification: Given initial value of PCR10, extend it with each measurement and match result to current PCR10
    Quote is used to attest to PCRs
  • 9. 9
    Linux Bootstrap Stages
    Operating System
    /usr/sbin/httpd
    GRUB
    Stage2
    /bin/ls
    BIOS
    Bootloader
    Linux
    Kernel
    GRUB
    Stage1
    (MBR)
    ROT
    GRUB
    Stage1.5
    CRTM
    POST
    PCR01-07
    PCR04-05
    TPM
    PCR08
    PCR10
    Trusted Boot
  • 10. 10
    SHA1(Boot Loader)SHA1(Kernel)SHA1(Kernel Module)SHA1(Program)SHA1(Configuration)…
    h
    +
    Digest of Measurements Signed by TPM
    Analysis
    TPM
    KnownHashes
    Integrity Measurement Architecture (IMA)
    Network
    Attesting System
    Challenging System
    Properties of Attesting System
    Measurements
    Data
    Program
    Config File
    KernelModule
    BootLoader
    Kernel
    (1) Measurement
    (2) Attestation
    (3) Verification
  • 11. 11
    Linux Modifications
    Added support to Linux kernel
    To measure dynamic linker
    To measure each executable
    Added support to dynamic linker
    To measure each shared library
    Added support to kernel module loader
    To measure kernel modules
    Kernel keeps a measurement cache
    Files are only measured once!
    Unless modified (opened for writing)
  • 12. 12
    Linux Application Measurements
    cat /proc/tcg/measurements
    #000: 276249898F406BE176E3D86EDD5A3D20D03EEB11 [remeasure] linuxrc
    #001: 9F860256709F1CD35037563DCDF798054F878705 [remeasure] nash
    #002: 4CC52A8F7584A750303CB2A41DEA637917DB0310 [clean] insmod
    #003: 84ABD2960414CA4A448E0D2C9364B4E1725BDA4F [clean] init
    #004: 194D956F288B36FB46E46A124E59D466DE7C73B6 [clean] ld-2.3.2.so
    #005: 7DF33561E2A467A87CDD4BB8F68880517D3CAECB [clean] libc-2.3.2.so
    #006: 93A0BBC35FD4CA0300AA008F02441B6EAA425643 [clean] rc.sysinit
    #007: 66F445E31575CA1ABEA49F0AF0497E3C074AD9CE [clean] bash
    #008: F4F6CB0ACC2F1BEE13D60330011DF926D24E5688 [clean] libtermcap.so.2.0.8
    #009: 346443AAD8E7089B64B2B67F1A527F7E2CA2D1E5 [clean] libdl-2.3.2.so
    #010: 02385033F849A2A4BFB85FD52BCEA27B45497C6C [clean] libnss_files-2.3.2.so
    #011: 6CB3437EC500767328F2570C0F1D9AA9C5FEF2F6 [clean] initlog
    #012: FD1BCAEF339EAE065C4369798ACAADFF44302C23 [clean] hostname
    #013: F6E44B04811CC6F53C58EEBA4EACA3FE9FF91A2E [clean] consoletype
    #014: 12A5A9B6657EFEE7FD619A68DA653E02A7D8C661 [clean] grep
    #015: 3AF36F2916E574884850373A6E344E4F2C51DD60 [clean] sed
    #016: CE516DE1DF0CD230F4A1D34EFC89491CAF3D50E4 [clean] libpcre.so.0.0.1
    #017: 5EE8CD72AAD26191879E01221F5E051CE5AAE95F [clean] setsysfont
    #018: 8B15F3556E892176B03D775E590F8ADF9DA727C5 [clean] unicode_start
    #019: F948CF91C7AF0C2AB6AD650186A80960F5A0DAB1 [clean] kbd_mode
    #020: FF02DD8E56F0B2DCFB3D9BF392F2FCE045EFE0BC [clean] dumpkeys
    #021: C00804432DFBC924B867FC708CB77F2821B4D320 [clean] loadkeys
    #022: DE3AC70601B9BA797774E59BEC164C0DDF11982D [clean] setfont
    #023: 7334B75FDF47213FF94708D2862978D0FF36D682 [clean] gzip
    #024: AEC13AA4FF01F425ACACF0782F178CDFE3D17282 [clean] minilogd
    #025: 09410DDC5FE2D6E7D8A7C3CF5BB4D51ED6C4C817 [clean] sleep
    ……………
    PCR10
  • 13. 13
    Linux Application Measurements
    cat /proc/tpm/pcrs
    PCR-00: 0A 2A B1 F6 56 EA ED 4C 53 F0 C7 9D 5E 05 61 37 51 B7 1C E5
    PCR-01: 5F DB 12 AD B3 34 7D D6 90 63 46 72 D8 DE 02 1C F3 3C 00 F7
    PCR-02: EB B3 BA AE E7 57 4B B6 37 AA AB 67 0F 9A C1 BC EB 6F 80 F3
    PCR-03: 04 FD EC DD 50 1D AF 0F 62 4C 1F 99 60 12 CF 30 44 FF 46 10
    PCR-04: 28 E3 E8 F0 CA 34 ED DD 58 AA 7E 71 F6 FC AE 08 C3 88 EB 05
    PCR-05: E7 23 99 CD A3 1D 37 E4 35 61 B7 1A 85 68 3B 66 7F 51 B6 B4
    PCR-06: 04 FD EC DD 50 1D AF 0F 62 4C 1F 99 60 12 CF 30 44 FF 46 10
    PCR-07: 04 FD EC DD 50 1D AF 0F 62 4C 1F 99 60 12 CF 30 44 FF 46 10
    PCR-08: DC 0E 38 C4 F4 46 F7 BC DF C8 83 CA CC 86 E2 69 50 C5 0E 66
    PCR-09: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    PCR-10: 50 48 FF 78 06 63 CB BF A5 F6 43 0B DA 41 1A 15 74 C3 1A 92
    PCR-11: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    PCR-12: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    PCR-13: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    PCR-14: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    PCR-15: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  • 14. Static root of trust for measurement
    Dynamic root of trust for measurement
    Flicker: Minimal TCB Code Execution
    Dynamic root of trust for measurement
  • 15. 15
    Late Launch Background
    Supported by new commodity CPUs
    SVM for AMD
    TXT (formerly LaGrande) for Intel
    Designed to launch a VMM without a reboot
    Hardware-based protections ensure launch integrity
    New CPU instruction (SKINIT/SENTER) accepts a memory region as input and atomically:
    Resets dynamic PCRs
    Disables interrupts
    Extends a measurement of the region into PCR 17
    Begins executing at the start of the memory region
  • 16. 16
    Dynamic Root of Trust for Measurementaka: Late Launch
    Involves both CPU and TPM v1.2
    Security properties similar to reboot
    Without a reboot!
    Removes many things from TCB
    BIOS, boot loader, DMA-enabled devices, …
    Long-running OS and Apps if done right
    When combined with virtualization
    VMM can be measured (MVMM)
    Uptimes measured in years
    Integrity of loaded code can be attested
    Untrusted legacy OS can coexist with trusted software
    Allows introduction of new, higher-assurance software without breaking existing systems
  • 17. 17
    AMD/Intel Late Launch Extensions
    AMD: Secure Virtual Machine (SVM)
    Intel: Trusted eXecution Technology (TXT)
    Formerly LaGrande Technology (LT)
    Similarities:
    Late launch of a measured block of code
    Hardware support for virtualization
    Differences:
    AMD provides measured environment only
    Intel adds authenticated code capabilities
    The system’s chipset contains a public key to verify signed code
  • 18. 18
    AMD Secure Virtual Machine
    Virtualization support
    DMA protection for memory
    Intercept selected guest instructions / events
    Much more…
    Late launch with support for attestation
    New instruction: SKINIT (Secure Kernel Init)
    Requires appropriate platform support (e.g., TPM 1.2)
    Allows verifiable startup of trusted software
    Such as a VMM
    Based on hash comparison
  • 19. 19
    SKINIT (Secure Kernel Init)
    Accepts address of Secure Loader Block (SLB)
    Memory region up to 64 KB
    SKINIT executes atomically
    Sets CPU state similar to INIT (soft reset)
    Disables interrupts
    Enables DMA protection for entire 64 KB SLB
    Causes TPM to reset dynamic PCRs to 0
    Sends SLB contents to TPM
    TPM hashes SLB contents and extends PCR 17
    Begins executing SLB
  • 20. 20
    SKINIT Security Properties
    Verifier receives attestation after SKINIT
    Knows SKINIT was used
    Knows software TCB includes only the SLB
    Knows exactly what SLB was executed
    SLB can be written to provide add’l props.
    Knows any inputs to SLB
    Knows any outputs from SLB
    Knows exactly when SLB finished executing
  • 21. 21
    AMD SVM Security Discussion
    Property: Verifiable untampered code execution
    SKINIT + TCG 1.2 provide very strong security properties
    Minimal TCB: Only hardware and application need to be trusted
    A1
    A2
    A3
    Operating System
    Hardware
  • 22. 22
    Secure Loader Block Layout
    ESP
    SL Runtime
    Data Area
    SL Stack
    64 KB
    SL Code and
    Static Data
    Length
    SL Image
    (hash area)
    SL Entry Point
    SL Header
    Length
    EP Offset
    EAX
  • 23. 23
    SKINIT TPM Operations
    TPM v1.2 includes notion called locality
    Similar to software privilege level
    4 is highest, 0 is lowest
    Certain PCRs associated with localities
    PCR 17 is associated with locality 4
    SKINIT is the only locality 4 operation
    SKINIT sends contents of SLB to TPM
    TPM hashes SLB to create a measurement
    TPM resets PCR17, sets PCR17 = 0
    Distinct from boot-time value of PCR17= -1
    Allows verifier to know that SKINIT was executed
    TPM performs PCR_Extend(17, hash(SLB))
  • 24. 24
    Intel Trusted eXecution Technology
    Safer Mode Extensions (SMX) and Virtual Machine Extensions (VMX)
    SMX introduces Authenticated Code capabilities
    AC module loaded into CPU-internal RAM
    AC module contains a digital signature
    Processor calculates hash and verifies signature
    Execution isolated from external memory and bus
    SMX introduces a GETSEC “leaf” instruction
    GETSEC[CAPABILITIES] - get available capabilities
  • 25. 25
    Intel TXT vs. AMD SVM
    AMD SVM does not support authenticated code
    Whether this will be significant is not yet known
    AC needs code signed such that chipset can verify it
    Chipset needs public key, crypto capabilities
    Additional complexity
    Code update issues
    AMD systems have been available for almost a year
    Intel systems have only just become available
  • 26. 26
    Safer Mode Extensions
    Detecting and Enabling SMX.软件可以使用CPUID instruction来检测CPU对SMX操作的支持。软件将1放入EAX寄存器,执行CPUID,返回ECX的值的第6位指明了对SMX操作是否支持(即GETSEC指令是否可用)。
  • 27. 27
    1 SMX Functionality
    • 在处理器中通过GETSEC指令来提供对SMX的功能的支持。这条指令支持多个子功能。在GETSEC指令执行时由EAX中的值来决定执行哪个子功能(这些子功能共享同一个操作码,0F 37)。
  • 28
    2 Enabling SMX Capabilities
    • 系统软件通过设置CR4.SMXE[Bit 15]=1去打开SMX功能。如果没有打开就去执行会返回一个非法操作码异常(#UD)。
    • 28. 如果CPUID的SMX标志位是0(CPUID.01H.ECX[Bit 6] = 0),那么设置CR4.SMXE[Bit 15]位的操作将返回一个general protection异常。
    • 29. IA32_FEATURE_CONTROL MSR(在地址03AH)提供了配置VMX和SMX操作的控制位。
  • 29
    3 SMX Instruction Summary
    系统软件首先通过执行GETSEC[CAPABILITIES]指令来查询可用的GETSEC子功能。
  • 30. 30
    3 SMX Instruction Summary
    1 GETSEC[PARAMETERS] 返回SMX的相关参数信息
    报告SMX操作的attributes, options and limitations。软件使用它来辨识操作限制或附加选项。The parameters index is input in EBX with the result returned in EAX, EBX, and ECX.
  • 31. 31
    Tboot for Xen
  • 32. 32
    Intel® Trusted Execution Technology
    Removes BIOS/bootloader/OS/etc. from trust chain
    Creates dynamic root of trust (DRTM)
    Platform configuration protection
    Reset memory protection
    Safer Mode Extensions (SMX)
    Intel TXT processor instructions
  • 33. 33
    What is Trusted Boot (tboot)?
    Open source, pre-kernel/VMM module
    Uses Intel TXT to perform verified launch of OS kernel/VMM
    Today only supports Xen
    Project also contains tools for policy creation and Provisioning
    Intel TXT Launch Control Policy (LCP)
    Tboot Verified Launch policy
  • 34. 34
    Trusted Boot provides a foundation for a Trusted Xen
    • Root of trust is in hardware: Intel TXT dynamic launch
    • 35. Tboot is verified by Intel TXT Launch Control Policy (LCP)
    Part of measured launch
    Can optionally verify BIOS
    • Tboot Verified Launch verifies Xen and Dom0 (+ initrd)
    Dom0 trust could be extended via IMA, disaggregation, etc.
  • 36. 35
    Measured Launched Environment
    • Measured Launched
    • 37. MLE Initialization
    • 38. MLE Operation
    • 39. MLE Teardown
  • 36
    1.Measured Launched
    • Intel® TXT detection and processor preparation
    • 40. Loading the SINIT AC module
    • 41. Loading the MLE and processor rendezvous
    • 42. Performing a measured launch.
  • 37
    1.1 Intel® TXT detection and processor preparation
    • Intel® Trusted Execution Technology Detection and Processor Preparation
    This action is only performed by the ILP.
    CPUID(EAX=1);
    IF (SMX not supported) OR (VMX not supported) {
    Fail measured environment startup;
    }
    // Enable SMX on ILP & check for Intel® TXT chipset
    CR4.SMXE = 1;
    GETSEC[CAPABILITIES];
    IF (Intel® TXT chipset NOT present) {
    Fail measured environment startup;
    }
  • 43. 38
    1.2 Loading the SINIT AC module
    • Intel® Trusted Execution Technology Detection and Processor Preparation
    This action is only performed by the ILP.
    Matching an AC Module to the Chipset Each AC module is designed for a specific chipset or set of chipsets.
  • 44. 39
    1.3 Loading the MLE and processor rendezvous(1)
    • Loading the MLE
    System software allocates memory for the MLE and MLE page table. 不需要连续的内存空间
    System software creates an MLE page table structure to map the entire MLE image.
    The SINIT AC module will check that the MLE page table matches several special requirements
    Calculate the MLE digest.
    System software writes the physical base address of the MLE page table’s page directory to the Intel® TXT Heap. The size in bytes of the MLE image is also written to the Intel® TXT Heap
  • 45. 40
    1.3 Loading the MLE and processor rendezvous(2)
    • Intel® Trusted Execution Technology Heap Initialization
    Information can be passed from system software to the SINIT AC module and from system software to the MLE using the Intel® TXT Heap. The SINIT AC module will also use this region to pass data to the MLE.
    The system software launching the measured environment is responsible for initializing the following in the Intel® TXT Heap memory (this initialization must be completed before executing GETSEC[SENTER]):
    (1)Initialize contents of the Intel® TXT Heap Memory
    (2)Initialize contents of the OsMleData and OsMleDataSize (with the size of the OsMleData field + 8H) fields.
    (3)Initialize contents of the OsSinitData and OsSinitDataSize (with the size of the OsSinitData field + 8H) fields.
    The OsMleData structure has fields for specifying regions of memory to protect from DMA (PMR Low/High Base/Size) using VT-d.
  • 46. 41
    1.3 Loading the MLE and processor rendezvous(3)
    • Rendezvousing Processors and Saving State
    如果是在OS启动后launching the measured environment 那么all processors should be brought to a rendezvous point before executing GETSEC[SENTER]. At the rendezvous point each processor will set up for GETSEC[SENTER] and save any state needed to resume after the measured launch. If processors are not rendezvoused before executing SENTER then the processors will loose their current operating state including possibly the fact that an in-service interrupt has not been acknowledged.
    Clear Machine Check Status Registers;
    Ensure CR0.CD=0, CR0.NW=0, and CR0.NE=1;
    // Save current system software state in Intel® TXT Heap
    Allocate memory for OsMleData;
    Fill in OsMleData with system software state (including MTRR and IA32_MISC_ENABLE MSR states);
  • 47. 42
    1.4 Performing a Measured Launch(1)
    • MTRR Setup Prior to GETSEC[SENTER] Execution
    System software must set up the variable range MTRRs (memory type range register)to map all of memory (except the region containing the SINIT AC module) to one of the supported memory types as returned by GETSEC[PARAMETERS].
    After MTRR setup is complete, the RLPs mask interrupts (by executing CLI), signal the ILP that they have interrupts masked, and execute halt. Before executing GETSEC[SENTER], the ILP waits for all RLPs to indicate that they have disabled their interrupts. If the ILP executed a GETSEC[SENTER] while an RLP was servicing an interrupt, the interrupt servicing would not complete, possibly leaving the interrupting device unable to generate further interrupts.
  • 48. 43
    1.4 Performing a Measured Launch(2)
    • TPM Preparation
    System software must ensure that the TPM is ready to accept commands and that the TPM.ACCESS_0.activeLocality bit is clear before executing the GETSEC[SENTER] instruction.
    • Intel® Trusted Execution Technology Launch
    The ILP is now ready to launch the measuring process. System software executes the GETSEC[SENTER] instruction.
  • 49. 44
    Measured Launched Environment
    • Any Measured Launched Environment (MLE) will generally consist of three main sections of code: the initialization, the dispatch routine, and the shutdown.
    The initialization code is run each time the Intel® TXT environment is launched. This code includes code to setup the MLE on the ILP and join code to initialize the RLPs.
    After initialization, the MLE behaves like the unmeasured version would have; in the case of a VMM, this is trapping various guest operations and virtualizing certain processor states.
    Finally the MLE prepares for shutdown by again synchronizing the processors, clearing any state and executing the GETSEC[SEXIT] instruction.
  • 50. 45
    2.MLE Initialization
    //1.MLE entry point – ILP and RLP(s) enter here
    Load CR3 with MLE page table pointer;
    Enable paging;
    Load the GDTR with the linear address of MLE GDT;
    Long jump to force reload the new CS;
    Load MLE SS, ESP;
    Load MLE DS, ES, FS, GS;
    Load the IDTR with the linear address of MLE IDT;
    Initialize exception handlers;
    // 2.状态生效
    Check and restore MTRR settings from OsMleData area;
    Validate system memory map against MDRs
    Validate VT-d DMAR table
    Validate VT-d PMR settings against expected values
    Restore IA32_MISC_ENABLE MSR from OsMleData
  • 51. 46
    2.MLE Initialization
    //3. Wake RLPs
    Initialize memory protection and other data structures;
    Build JOIN structure;
    LT.MLE.JOIN = physical address of JOIN structure;
    IF RLP exist
    GETSEC[WAKEUP];
    Wait for all processors to reach this point;
    在processors间做一致性检测;
    // 4.Enable VMX
    CR4.VMXE = 1;
    // 5.Start VMX operation
    Allocate and setup the root controlling VMCS, execute
    VMXON(root controlling VMCS);
  • 52. 47
    2.MLE Initialization
    // 6.Set up the guest container
    Allocate memory for and setup guest VMCS;
    VMCLEAR guest VMCS;
    VMPTRLD guest VMCS;
    Initialize guest VMCS from OsMleData area;
    // 7.All processors launch back into guest
    VMLAUNCH guest;
  • 53. 48
    3.MLE Operation
    • The dispatch routine is responsible for handling all VMExitsfrom the guest. The guest VMExits are caused by various situations, operations or events occurring in the guest. The dispatch routine must handle each VMExit appropriately to maintain the measured environment. In addition, the dispatch routine may need to save and restore some of processor state not automatically saved or restored during VM transitions. The MLE must also ensure that it has an accurate view of the address space and that it restricts access to certain of the memory regions that the GETSEC[SENTER] process will have enabled. The following subsections describe various key components of the MLE dispatch routine.
  • 49
    3.1 Address Space Correctness
    • It is likely that most MLEs will rely on the e820 memory map to determine which regions of the address space are physical RAM and which of those are usable (e.g. not reserved by BIOS). However, as this table is created by BIOS it is not protected from tampering prior to a measured launch. An MLE, therefore, cannot rely on it to contain an accurate view of physical memory.
    • 54. After a measured launch, SINIT will provide the MLE with an accurate list of the actual RAM regions as part of the SinitMleData structure of the Intel® TXT Heap (see Appendix C.4). The SinitMDR field of this data structure specifies the regions of physical memory that are valid for use by the MLE. This data structure can also be used to accurately determine SMRAM and PCIE extended configuration space, if the MLE handles these specifically.
  • 50
    3.2 Address Space Integrity
    • There are several regions of the address space (both physical RAM and Intel® TXT chipset regions) that have special uses for Intel® TXT. Some of these should be reserved for the MLE and some can be exposed to one or more guests/VMs.
  • 51
    3.3 Physical RAM Regions
    • There are two regions of physical RAM that are used by Intel® TXT and are reserved by BIOS prior to the MLE launch. These are the SINIT AC module region and the Intel® TXT Heap. Each region’s base address and size are specified by Intel® TXT configuration registers (e.g. LT.SINIT.BASE and LT.SINIT.SIZE).
    • 55. The SINIT and Intel® TXT Heap regions are only required for measured launch and may be used for other purposes afterwards. However, if the measured environment must be re-launched (e.g. after resuming from S3 state), the MLE may wish to reserve and protect these regions.
  • 52
    3.4 Intel® Trusted Execution Technology Chipset Regions
    • Intel® Trusted Execution Technology Configuration Space
    • 56. The configuration register space is divided into public and private regions. The public region generally provides read only access to configuration registers and the MLE may choose to allow access to this region by guests. The private region allows write access, including to the various command registers. This region should be reserved to the MLE to ensure proper operation of the measured environment.
    • 57. Intel® Trusted Execution Technology Device Space
  • 53
    3.5 Protecting Secrets
    • If there will be data in memory whose confidentiality must be maintained, then the MLE should set the Intel® TXT secrets flag so that the Intel® TXT hardware will maintain protections even if the measured environment is lost before performing a shutdown (e.g. hardware reset). This can be done by writing to the LT.CMD.SECRETS configuration register. The teardown process will clear this flag once it has scrubbed memory and removed any confidential data
  • 54
    3.6 Machine Specific Register Handling
    • 3.7 ACPI Power Management Support (S-State Transitions S3~S5)
    • 58. Before tearing down the Intel® TXT environment, the MLE may remove secrets from memory (clearing pages with secrets) or encrypt secrets for later use (e.g. for a later measured environment launch). Once this operation is complete the MLE must issue the LT.CMD.NO-SECRETS command to clear the secrets flag. After this command is issued, the MLE may allow a transition to a S3, S4 or S5 sleep state.
  • 55
    4 MLE Teardown
    Rendezvous processors in guest OS;
    All processors VMCALL teardown in MLE;
    Rendezvous all processors in MLE teardown routine;
    All processors read guest state from VMCS, store values in
    memory;
    // Remove and encrypt all secrets from registers and memory
    // Stop VMX operation
    // RLPs wait while ILP executes SEXIT
    // Transition back to the guest OS
  • 59. Static root of trust for measurement
    Dynamic root of trust for measurement
    Flicker: Minimal TCB Code Execution
    Flicker: Minimal TCB Code Execution
  • 60. 57
    Trusted Computing Base (TCB)


    App
    App
    1
    App
    App
    1
    S
    S
    OS
    OS
    Shim
    DMA Devices
    DMA Devices
    CPU, RAM
    TPM, Chipset
    CPU, RAM
    TPM, Chipset
    (Network, Disk,
    USB, etc.)
    (Network, Disk,
    USB, etc.)
  • 61. 58
    TCB Reduction with Flicker

    App
    App
    1
    App
    Today, TCB for sensitive code S:
    Includes App
    Includes OS
    Includes other Apps
    Includes hardware
    With Flicker, S’s TCB:
    Includes Shim
    Includes some hardware
    S
    OS
    Shim
    CPU, RAM
    TPM, Chipset
    DMA Devices
    (Network, Disk,
    USB, etc.)
  • 62. 59
    Flicker’s Properties
    Isolate security-sensitive code execution from all other code and devices
    Attest to security-sensitive code and its arguments and nothing else
    Convince a remote party that security-sensitive code was protected
    Add < 250 LoC to the software TCB
    S
    Software
    TCB
    < 250 LoC
    Shim
  • 63. 60
    Adversary Capabilities

    App
    App
    1
    Run arbitrary code with maximum privileges
    Subvert any DMA-enabled device
    E.g., network cards, USB devices, hard drives
    Perform limited hardware attacks
    E.g., power cycle the machine
    Excludes physically monitoring/modifying CPU-to-RAM communication
    OS
    S
    Shim
    DMA Devices
    CPU, RAM
    TPM, Chipset
    (Network, Disk,
    USB, etc.)
  • 64. 61
    App
    RAM
    OS
    Module
    S
    Shim
    SKINIT
    Reset
    Execution Flow
    App
    OS
    Outputs
    Inputs
    0
    0
    0
    Module
    S
    Module
    Shim
    TPM

    PCRs:
    CPU
    K-1
  • 65. 62
    S
    Shim
    Attestation
    TPM
    PCRs:
    Inputs

    Outputs
    K-1
    TPM

    PCRs:
    K-1
  • 66. 63
    App
    App
    5
    App
    4
    App
    3
    App
    2
    App
    1

    S
    OS
    TPM
    PCRs:
    0
    0
    0
    Inputs
    What code are
    you running?
    S

    Shim
    Outputs
    Inputs
    Outputs
    K-1
    S
    )
    (
    Shim
    Sign
    , K-1
    (
    )
    Sign
    , K-1
    Attestation
    Versus
  • 67. 64
    S
    S
    S
    S
    Shim
    Shim
    Shim
    Shim
    S
    S
    S
    Shim
    Shim
    Shim
    Context Switch with Sealed Storage
    • Seal data under combination of code, inputs, outputs
    • 68. Data unavailable to other code
    OS
    Data
    PCRs:
    PCRs:


    Time
  • 69. 65
    Developing With Flicker
    Sensitive code linked against the Flicker library
    Customized linker script lays out binary
    Application interacts with Flicker via a Flicker kernel module
    Made available at:
    /proc/flicker/output
    #include “flicker.h”
    const char* msg = “Hello, world”;
    void flicker_main(void *inputs) {
    }
    for(int i=0;i<13;i++)
    OUTPUT[i] = msg[i];
  • 70. 66
    Default Functionality
    Shim can execute arbitrary x86 code but provides very limited functionality
    Fortunately, many security-sensitive functions do not require much
    E.g., key generation, encryption/decryption, FFT
    Functionality can be added to support a particular security-sensitive operation
    We have partially automated the extraction of support code for security-sensitive code
  • 71. 67
    Existing Flicker Modules
    OS Protection Memory protection, ring 3 execution
    Crypto Crypto ops (RSA, SHA-1, etc.)
    Memory Alloc. Malloc/free/realloc
    Secure Channel Secure remote communication
    TPM Driver Communicate with TPM
    TPM Utilities Perform TPM ops
  • 72. 68
    Application: Rootkit Detector
    Run detector
    OS
    Administrator can check the integrity of remote hosts
    E.g., only allow uncompromised laptops to connect to the corporate VPN

    App
    1
    App
    n
    OS
    OS
    D
    Shim
    Hardware
  • 73. 69
    S
    Shim
    OK!
    S
    K
    Shim
    K
    EncryptK(passwd)
    S
    S
    Shim
    Shim
    nonce
    Start
    Application: SSH Passwords
    Gen {K, K-1}
    K-1
    K-1
    EncryptK(passwd)
    EncryptK(passwd)
    passwd
  • 74. 70
    Other Applications Implemented
    Enhanced Certificate Authority (CA)
    Private signing key isolated from entire system
    Verifiable distributed computing
    Verifiably perform a computational task on a remote computer
    Ex: SETI@Home, Folding@Home, distcc
  • 75. 71
    Generic Context-Switch Overhead
    Each Flicker context switch requires:
    SKINIT
    TPM-based protection of application state
    Results
  • 76. 72
    Rootkit Detection Performance
    37 ms Disruption
    Non-Disruptive
    Running detector every 30 seconds has negligible impact on system throughput
  • 77. 73
    SSH Performance
    Setup time (217 ms) dominated by key generation (185 ms)
    Password verification (937 ms) dominated by TPM Unseal (905 ms)
    Adds < 2 seconds of delay to client login
  • 78. 74
    Optimizing Flicker’s Performance
    Non-volatile storage
    Access control based on PCRs
    Read in 20ms, Write in 200 ms
    Store a symmetric key for “sealing” and “unsealing” state
    Reduces context-switch overhead by an order of magnitude
  • 79. 75
    Breakdown of Late Launch Overhead
    After ~4KB, code can measure itself
  • 80. 76
    Late Launch Performance
    CPU
    CPU
    CPU
    MemoryController
    MemoryController
    MemoryController
    Late launch requires APs to stop execution
    More cores = more expensive
    STOP

    CPU
    CPU
    RAM
    MemoryController
    MemoryController
    RAM
    TPM
    Other CPUsI/O Devices
    Other CPUsI/O Devices
    TPM
  • 81. 77
    Overheads and Recommendations
    O1 Late launch and TPM sealed storage overhead on every context switch
    R1 Secure context switch between sensitive applications without TPM
    O2 Other cores must halt to enable late launch
    R2 Secure execution on multiple CPUs concurrently
    O3 TPM equipped to store measurements from only one late launch
    R3 TPM support for concurrent Flicker sessions
  • 82. 78
    New States for Memory Pages
    Avoid TPM for short-term data protection
    Memory Controller already supports DMA protection vector
    All
    Launch
    Exit
    Sensitive
    Application
    CPU i
    Resume
    Suspend
    None
    Memory
  • 83. 79
    Concurrent Flicker Sessions
    Other CPUs continue to perform useful work
    Memory Controllers isolate secure state
    CPU
    CPU
    RAM
    MemoryController
    MemoryController
    Other CPUsI/O Devices
    Other CPUsI/O Devices
    TPM
  • 84. 80
    Add Secure Execution PCRs to TPM
    Each SE PCR holds state for one Flicker session
    Bounds number of concurrent Flicker sessions
    TPM
    StaticPCRs
    DynamicPCRs
    SecureExecutionPCRs