The document discusses Intel's Trusted Execution Technology (TXT) and its mechanisms for establishing a secure environment by creating a dynamic root of trust for measurement. It outlines how measurements are taken and verified to ensure the integrity of the operating system and applications, detailing the role of the Trusted Platform Module (TPM) and various technical specifications like the use of Secure Kernel Initialization (SKINIT). Additionally, it highlights both AMD and Intel's approaches to late launch configurations and their implications for security and system integrity.

1. Intel ® Trusted Execution Technology 1

2. Static root of trust for measurementDynamic root of trust for measurementFlicker: Minimal TCB Code ExecutionStatic root of trust for measurement

3. 3Basic TPM FunctionsPCRs store integrity measurement chainPCRnew = SHA-1(PCRold||measurement)Remote attestation (PCRs + AIK)Attestation Identity Keys (AIKs) for signing PCRsAttest to value of integrity measurements to remote partySealed storage (PCRs + SRK)Protected storage + unlock state under a particular integrity measurement (data portability concern)

4. 4TCG-Style AttestationOS KernelOS KernelAppsAppsModule 1Module 1App 1App 1Module 2Module 2App 2App 2TPMconfconfPCRsBoot LoaderBoot LoaderBIOSBIOSHardwareSoftwareAIK-1

5. 5TCG-Style AttestationHost platformChallenger

6. 6TCG-style Attestation的缺点Static root of trust for measurement (reboot)Measures entire systemRequires hundreds of integrity measurements just to bootEvery host is differentfirmware versions, drivers, patches, apps, spyware, …TCB includes entire system!Integrity measurements are done at load-time not at run-timeTime-of-check-time-of-use (TOCTOU) problemCannot detect any dynamic attacks!No guarantee of executionA1A2A3Operating SystemHardware TPM

7. 7Example: TCG on LinuxIntegrity Measurement Architecture (IMA) by IBMMeasurement principlesWhole system measurementsMeasure all executable content on-demandToo expensive to measure whole systemContent is added dynamicallyMeasure content before executionOnly measured content can introduce and measure new contentPlace as little trust as necessary in measurement system

8. 8Linux Implementation OverviewUse trusted boot to measure BIOS, bootstrap loader, and kernelThe kernel keeps a list of measurements for each loadedExecutable Scripts (shell, Perl, etc)Shared library Java class filesKernel module …Before a measurement is added to the list, PCR10 is extended with that measurement. Integrity of this in-kernel list is guaranteed by PCR10Verification: Given initial value of PCR10, extend it with each measurement and match result to current PCR10Quote is used to attest to PCRs

9. 9Linux Bootstrap StagesOperating System/usr/sbin/httpdGRUBStage2/bin/lsBIOSBootloaderLinuxKernelGRUBStage1(MBR)ROTGRUBStage1.5CRTMPOSTPCR01-07PCR04-05TPMPCR08PCR10Trusted Boot

10. 10SHA1(Boot Loader)SHA1(Kernel)SHA1(Kernel Module)SHA1(Program)SHA1(Configuration)…h+Digest of Measurements Signed by TPMAnalysisTPMKnownHashesIntegrity Measurement Architecture (IMA)NetworkAttesting SystemChallenging SystemProperties of Attesting SystemMeasurements Data Program Config File KernelModule BootLoader Kernel(1) Measurement(2) Attestation(3) Verification

11. 11Linux ModificationsAdded support to Linux kernelTo measure dynamic linkerTo measure each executableAdded support to dynamic linkerTo measure each shared libraryAdded support to kernel module loaderTo measure kernel modulesKernel keeps a measurement cacheFiles are only measured once!Unless modified (opened for writing)

12. 12Linux Application Measurementscat /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. 13Linux Application Measurementscat /proc/tpm/pcrsPCR-00: 0A 2A B1 F6 56 EA ED 4C 53 F0 C7 9D 5E 05 61 37 51 B7 1C E5PCR-01: 5F DB 12 AD B3 34 7D D6 90 63 46 72 D8 DE 02 1C F3 3C 00 F7PCR-02: EB B3 BA AE E7 57 4B B6 37 AA AB 67 0F 9A C1 BC EB 6F 80 F3PCR-03: 04 FD EC DD 50 1D AF 0F 62 4C 1F 99 60 12 CF 30 44 FF 46 10PCR-04: 28 E3 E8 F0 CA 34 ED DD 58 AA 7E 71 F6 FC AE 08 C3 88 EB 05PCR-05: E7 23 99 CD A3 1D 37 E4 35 61 B7 1A 85 68 3B 66 7F 51 B6 B4PCR-06: 04 FD EC DD 50 1D AF 0F 62 4C 1F 99 60 12 CF 30 44 FF 46 10PCR-07: 04 FD EC DD 50 1D AF 0F 62 4C 1F 99 60 12 CF 30 44 FF 46 10PCR-08: DC 0E 38 C4 F4 46 F7 BC DF C8 83 CA CC 86 E2 69 50 C5 0E 66PCR-09: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00PCR-10: 50 48 FF 78 06 63 CB BF A5 F6 43 0B DA 41 1A 15 74 C3 1A 92PCR-11: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00PCR-12: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00PCR-13: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00PCR-14: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00PCR-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 measurementDynamic root of trust for measurementFlicker: Minimal TCB Code ExecutionDynamic root of trust for measurement

15. 15Late Launch BackgroundSupported by new commodity CPUsSVM for AMDTXT (formerly LaGrande) for IntelDesigned to launch a VMM without a rebootHardware-based protections ensure launch integrityNew CPU instruction (SKINIT/SENTER) accepts a memory region as input and atomically:Resets dynamic PCRs Disables interruptsExtends a measurement of the region into PCR 17Begins executing at the start of the memory region

16. 16Dynamic Root of Trust for Measurementaka: Late LaunchInvolves both CPU and TPM v1.2Security properties similar to rebootWithout a reboot!Removes many things from TCBBIOS, boot loader, DMA-enabled devices, …Long-running OS and Apps if done rightWhen combined with virtualizationVMM can be measured (MVMM)Uptimes measured in yearsIntegrity of loaded code can be attestedUntrusted legacy OS can coexist with trusted softwareAllows introduction of new, higher-assurance software without breaking existing systems

17. 17AMD/Intel Late Launch ExtensionsAMD: Secure Virtual Machine (SVM)Intel: Trusted eXecution Technology (TXT)Formerly LaGrande Technology (LT)Similarities:Late launch of a measured block of codeHardware support for virtualizationDifferences:AMD provides measured environment onlyIntel adds authenticated code capabilitiesThe system’s chipset contains a public key to verify signed code

18. 18AMD Secure Virtual MachineVirtualization supportDMA protection for memoryIntercept selected guest instructions / eventsMuch more…Late launch with support for attestationNew instruction: SKINIT (Secure Kernel Init)Requires appropriate platform support (e.g., TPM 1.2)Allows verifiable startup of trusted softwareSuch as a VMMBased on hash comparison

19. 19SKINIT (Secure Kernel Init)Accepts address of Secure Loader Block (SLB)Memory region up to 64 KBSKINIT executes atomicallySets CPU state similar to INIT (soft reset)Disables interruptsEnables DMA protection for entire 64 KB SLBCauses TPM to reset dynamic PCRs to 0Sends SLB contents to TPMTPM hashes SLB contents and extends PCR 17Begins executing SLB

20. 20SKINIT Security PropertiesVerifier receives attestation after SKINITKnows SKINIT was usedKnows software TCB includes only the SLBKnows exactly what SLB was executedSLB can be written to provide add’l props.Knows any inputs to SLBKnows any outputs from SLBKnows exactly when SLB finished executing

21. 21AMD SVM Security DiscussionProperty: Verifiable untampered code executionSKINIT + TCG 1.2 provide very strong security propertiesMinimal TCB: Only hardware and application need to be trustedA1A2A3Operating SystemHardware

22. 22Secure Loader Block LayoutESPSL RuntimeData AreaSL Stack64 KBSL Code and Static DataLengthSL Image(hash area)SL Entry PointSL HeaderLengthEP OffsetEAX

23. 23SKINIT TPM OperationsTPM v1.2 includes notion called localitySimilar to software privilege level4 is highest, 0 is lowestCertain PCRs associated with localitiesPCR 17 is associated with locality 4SKINIT is the only locality 4 operationSKINIT sends contents of SLB to TPMTPM hashes SLB to create a measurementTPM resets PCR17, sets PCR17 = 0Distinct from boot-time value of PCR17= -1Allows verifier to know that SKINIT was executedTPM performs PCR_Extend(17, hash(SLB))

24. 24Intel Trusted eXecution TechnologySafer Mode Extensions (SMX) and Virtual Machine Extensions (VMX)SMX introduces Authenticated Code capabilitiesAC module loaded into CPU-internal RAMAC module contains a digital signatureProcessor calculates hash and verifies signatureExecution isolated from external memory and busSMX introduces a GETSEC “leaf” instructionGETSEC[CAPABILITIES] - get available capabilities

25. 25Intel TXT vs. AMD SVMAMD SVM does not support authenticated codeWhether this will be significant is not yet knownAC needs code signed such that chipset can verify it Chipset needs public key, crypto capabilitiesAdditional complexityCode update issuesAMD systems have been available for almost a yearIntel systems have only just become available

26. 26Safer Mode ExtensionsDetecting and Enabling SMX.软件可以使用CPUID instruction来检测CPU对SMX操作的支持。软件将1放入EAX寄存器，执行CPUID，返回ECX的值的第6位指明了对SMX操作是否支持(即GETSEC指令是否可用)。

27. 271 SMX Functionality在处理器中通过GETSEC指令来提供对SMX的功能的支持。这条指令支持多个子功能。在GETSEC指令执行时由EAX中的值来决定执行哪个子功能（这些子功能共享同一个操作码，0F 37）。282 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操作的控制位。293 SMX Instruction Summary系统软件首先通过执行GETSEC[CAPABILITIES]指令来查询可用的GETSEC子功能。

30. 303 SMX Instruction Summary1 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. 31Tboot for Xen

32. 32Intel® Trusted Execution TechnologyRemoves BIOS/bootloader/OS/etc. from trust chainCreates dynamic root of trust (DRTM)Platform configuration protectionReset memory protectionSafer Mode Extensions (SMX) Intel TXT processor instructions

33. 33What is Trusted Boot (tboot)?Open source, pre-kernel/VMM moduleUses Intel TXT to perform verified launch of OS kernel/VMMToday only supports XenProject also contains tools for policy creation and ProvisioningIntel TXT Launch Control Policy (LCP)Tboot Verified Launch policy

34. 34Trusted Boot provides a foundation for a Trusted XenRoot of trust is in hardware: Intel TXT dynamic launch

35. Tboot is verified by Intel TXT Launch Control Policy (LCP)Part of measured launchCan optionally verify BIOSTboot Verified Launch verifies Xen and Dom0 (+ initrd)Dom0 trust could be extended via IMA, disaggregation, etc.

36. 35Measured Launched EnvironmentMeasured Launched

37. MLE Initialization

38. MLE Operation

39. MLE Teardown361.Measured LaunchedIntel® TXT detection and processor preparation

40. Loading the SINIT AC module

41. Loading the MLE and processor rendezvous

42. Performing a measured launch.371.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. 381.2 Loading the SINIT AC moduleIntel® 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. 391.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. 401.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. 411.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. 421.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. 431.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. 44Measured Launched EnvironmentAny 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. 452.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. 462.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. 472.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. 483.MLE OperationThe 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.493.1 Address Space CorrectnessIt 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. 503.2 Address Space IntegrityThere 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. 513.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.523.4 Intel® Trusted Execution Technology Chipset RegionsIntel® 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 Space533.5 Protecting SecretsIf 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 data543.6 Machine Specific Register Handling3.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.554 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 measurementDynamic root of trust for measurementFlicker: Minimal TCB Code ExecutionFlicker: Minimal TCB Code Execution

60. 57Trusted Computing Base (TCB)……AppApp1AppApp1SSOSOSShimDMA Devices DMA Devices CPU, RAMTPM, ChipsetCPU, RAMTPM, Chipset(Network, Disk, USB, etc.)(Network, Disk, USB, etc.)

61. 58TCB Reduction with Flicker…AppApp1AppToday, TCB for sensitive code S:Includes AppIncludes OSIncludes other AppsIncludes hardwareWith Flicker, S’s TCB:Includes ShimIncludes some hardwareSOSShimCPU, RAMTPM, ChipsetDMA Devices (Network, Disk, USB, etc.)

62. 59Flicker’s PropertiesIsolate security-sensitive code execution from all other code and devicesAttest to security-sensitive code and its arguments and nothing elseConvince a remote party that security-sensitive code was protectedAdd < 250 LoC to the software TCBSSoftwareTCB< 250 LoCShim

63. 60Adversary Capabilities…AppApp1Run arbitrary code with maximum privilegesSubvert any DMA-enabled deviceE.g., network cards, USB devices, hard drivesPerform limited hardware attacksE.g., power cycle the machineExcludes physically monitoring/modifying CPU-to-RAM communicationOSSShimDMA Devices CPU, RAMTPM, Chipset(Network, Disk, USB, etc.)

64. 61AppRAMOSModuleSShimSKINITResetExecution FlowAppOSOutputsInputs000ModuleSModuleShimTPM…PCRs:CPUK-1

65. 62SShimAttestationTPMPCRs:Inputs…OutputsK-1TPM…PCRs:K-1

66. 63AppApp5App4App3App2App1…SOSTPMPCRs:000InputsWhat code areyou running?S…ShimOutputsInputsOutputsK-1S)(ShimSign, K-1()Sign, K-1AttestationVersus

67. 64SSSSShimShimShimShimSSSShimShimShimContext Switch with Sealed StorageSeal data under combination of code, inputs, outputs

68. Data unavailable to other codeOSDataPCRs:PCRs:……Time

69. 65Developing With Flicker Sensitive code linked against the Flicker libraryCustomized linker script lays out binaryApplication interacts with Flicker via a Flicker kernel moduleMade 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. 66Default FunctionalityShim can execute arbitrary x86 code but provides very limited functionalityFortunately, many security-sensitive functions do not require muchE.g., key generation, encryption/decryption, FFTFunctionality can be added to support a particular security-sensitive operationWe have partially automated the extraction of support code for security-sensitive code

71. 67Existing Flicker ModulesOS Protection Memory protection, ring 3 executionCrypto Crypto ops (RSA, SHA-1, etc.)Memory Alloc. Malloc/free/reallocSecure Channel Secure remote communication TPM Driver Communicate with TPMTPM Utilities Perform TPM ops

72. 68Application: Rootkit DetectorRun detectorOSAdministrator can check the integrity of remote hostsE.g., only allow uncompromised laptops to connect to the corporate VPN…App1AppnOSOSDShimHardware

73. 69SShimOK!SKShimKEncryptK(passwd)SSShimShimnonceStartApplication: SSH PasswordsGen {K, K-1}K-1K-1EncryptK(passwd)EncryptK(passwd)passwd

74. 70Other Applications ImplementedEnhanced Certificate Authority (CA)Private signing key isolated from entire systemVerifiable distributed computingVerifiably perform a computational task on a remote computerEx: SETI@Home, Folding@Home, distcc

75. 71Generic Context-Switch OverheadEach Flicker context switch requires:SKINITTPM-based protection of application stateResults

76. 72Rootkit Detection Performance37 ms DisruptionNon-DisruptiveRunning detector every 30 seconds has negligible impact on system throughput

77. 73SSH PerformanceSetup 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. 74Optimizing Flicker’s PerformanceNon-volatile storage Access control based on PCRsRead in 20ms, Write in 200 msStore a symmetric key for “sealing” and “unsealing” stateReduces context-switch overhead by an order of magnitude

79. 75Breakdown of Late Launch OverheadAfter ~4KB, code can measure itself

80. 76Late Launch PerformanceCPUCPUCPUMemoryControllerMemoryControllerMemoryControllerLate launch requires APs to stop executionMore cores = more expensiveSTOP…CPUCPURAMMemoryControllerMemoryControllerRAMTPMOther CPUsI/O DevicesOther CPUsI/O DevicesTPM

81. 77Overheads and RecommendationsO1 Late launch and TPM sealed storage overhead on every context switchR1 Secure context switch between sensitive applications without TPMO2 Other cores must halt to enable late launchR2 Secure execution on multiple CPUs concurrentlyO3 TPM equipped to store measurements from only one late launchR3 TPM support for concurrent Flicker sessions

82. 78New States for Memory PagesAvoid TPM for short-term data protectionMemory Controller already supports DMA protection vectorAllLaunchExitSensitiveApplicationCPU iResumeSuspendNoneMemory

83. 79Concurrent Flicker SessionsOther CPUs continue to perform useful workMemory Controllers isolate secure stateCPUCPURAMMemoryControllerMemoryControllerOther CPUsI/O DevicesOther CPUsI/O DevicesTPM

84. 80Add Secure Execution PCRs to TPMEach SE PCR holds state for one Flicker sessionBounds number of concurrent Flicker sessionsTPMStaticPCRsDynamicPCRsSecureExecutionPCRs