Flicker: An Execution Infrastructure for TCB Minimization Jonathan McCune, Bryan Parno, Adrian Perrig, Michael Reiter, and Hiroshi Isozaki (EuroSys 08) Presented by: Tianyuan Liu Oct 31, 2017
Outline Motivation Background Trusted Platform Module (TPM) Late Launch Flicker Architecture and Extensions Flicker Application Evaluation Summary
Motivation Security primitives Isolation Virtualization [Garfinkel 03, Singaravelu 06, Ta-Min 06] Trusted hardware [Yee 94, Smith 99, Jiang 01] Remote attestation Trusted boot [Sailer 06] Trusted kernel [Shi 05] But additional trusted computing base (TCB) is huge E.g. a system using secure hypervisor adds 50,000 LoC
Motivation Study shows an average of six bug per 1,000 LoC. Driver code is 3-7x worse. [Tanenbaum 06] E.g. Linux kernel: 2.5M LoC ~ 15,000 bugs (as of 2006) How do we achieve these security primitives whereas the additional TCB is minimized?
Background TPM v1.2 The Trusted Platform Module (TPM) is a dedicated security chip Can provide an attestation to remote parties Platform Configuration Registers (PCRs) summarize the computer s software state PCR_Extend(N, V): PCR[N] = SHA-1(PCR[N] V) TPM provides a signature over PCR values Attestation by validating the PCR states Dynamic PCRs (17 23) can be reset without a reboot and PCR 17 can only be reset by hardware command Sealed storage (later)
Background Late Launch Supported by new commodity CPUs Secure Virtual Machine (SVM) for AMD Trusted execution Technology (TXT) for Intel Designed to launch a VMM/Secure Kernel without a reboot Hardware-based protections ensure launch integrity SVM SKINIT instruction accepts a memory region, a.k.a. Secure Loader Block (SLB) as input: Resets dynamic PCRs (17 23) to 0 Disables direct memory access and interrupts Extends a measurement of the region into PCR 17 Begins executing at the start of the SLB
Flicker Architecture Overview Core technique: running a Piece of Application Logic (PAL) within SLB Hardware isolation (DMA and interrupt protection) Attestation only on PAL (dynamic PCRs are reset) Extensions Store states across multiple sessions Establish secure communication channel with remote parties
Flicker Architecture Execution Flow Step 1: Application writes PAL and inputs to the Flicker-module Step 2: Flicker-module initializes the SLB Step 3: Save the state of untrusted OS Step 4: Run SKINIT Step 5: Execute PAL, clean up, and extend PCR 17 Step 6: Resume (Network, OS Disk,
Flicker Architecture SLB Highlights The entry point and size of SLB is 16 bits. The SLB size is limited to 64KB. If PAL > 64 KB, the entry point of next SLB must be provided. Untrusted OS entry is stored in GDT. The default SLB Core includes no support for heaps, memory management, or virtual memory :(
Flicker Extension Multiple Sessions How to save the states between multiple Flicker sessions? TPM sealed storage: TPM can generate an Attestation Identity Key (AIK) pair The private key is encrypted by its Storage Root Key (SRK) The session state is encrypted by AIK, and private key is sealed by TPM. Every time a new session begins, TPM unseals the private key.
Flicker Application Creating PAL Link sensitive code against Flicker library. Specify the skeleton of the binary in a linker script. (like.edl) Application interacts with Flicker via the Flicker kernel module. Available at (Network, /proc/flicker/output Disk,
Flicker Application Modules 56.522 KB
Flicker Application Examples Rootkit detector The administrator runs it periodically on a remote machine which is potentially compromised. Demonstrate a single Flicker session. Distributed computing (like BOINC project) A client runs the task as PAL proving the server of trustworthy results. Demonstrate multiple Flicker sessions. The control is transferred back to untrusted OS when PAL needs to runs for a long time. SSH password authentication SSH server convinces the clients of the secrecy of their password. Demonstrate secure channel by using a TPM sealed key.
Evaluation Single Session The highest overhead comes from TPM quote. SKINIT latency can be improved by reducing SLB size.
Evaluation Multiple Sessions Baselines are the replication solutions for distributed computing.
Summary Pros: Small additional TCB with strong security primitives. Compatible with state-of-the-art hardware. Cons: The impact of binary size (>64 KB) on performance overhead is not presented. Flexibility of PAL is limited, e.g. how about multi-threading? Bad user experience during Flicker session. The evaluations are less meaningful.