New version page

Flicker: An Execution Infrastructure for TCB Minimization∗

This preview shows page 1-2-3-4-5 out of 14 pages.

View Full Document
View Full Document

End of preview. Want to read all 14 pages?

Upload your study docs or become a GradeBuddy member to access this document.

View Full Document
Unformatted text preview:

Flicker: An Execution Infrastructure for TCB Minimization∗Jonathan M. McCune†Bryan Parno†Adrian Perrig†Michael K. Reiter†‡Hiroshi Isozaki†§¶†Carnegie Mellon University‡University of North Carolina at Chapel Hill§Toshiba CorporationABSTRACTWe present Flicker, an infrastructure for executing security-sensitive code in complete isolation while trusting as few as250 lines of additional code. Flicker can also provide mean-ingful, fine-grained attestation of the code executed (as wellas its inputs and outputs) to a remote party. Flicker guar-antees these properties even if the BIOS, OS and DMA-enabled devices are all malicious. Flicker leverages newcommodity processors from AMD and Intel and does notrequire a new OS or VMM. We demonstrate a full imple-mentation of Flicker on an AMD platform and describe ourdevelopment environment for simplifying the construction ofFlicker-enabled code.Categories and Subject DescriptorsK.6.5 [Security and Protection]General TermsDesign, SecurityKeywordsTrusted Computing, Late Launch, Secure Execution∗This research was supported in part by CyLab at CarnegieMellon under grant DAAD19-02-1-0389 from the Army Re-search Office, and grants CNS-0509004, CT-0433540 andCCF-0424422 from the National Science Foundation, by theiCAST project, National Science Council, Taiwan under theGrants No. (NSC95-main) and No. (NSC95-org), and bya gift from AMD. Bryan Parno is supported in part by aNational Science Foundation Graduate Research Fellowship.The views and conclusions contained here are those of theauthors and should not be interpreted as necessarily repre-senting the official policies or endorsements, either expressor implied, of AMD, ARO, CMU, NSF, or the U.S. Govern-ment or any of its agencies.¶Hiroshi Isozaki contributed to this work to satisfy the re-quirements for an MS degree at Carnegie Mellon University.Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.EuroSys’08, April 1–4, 2008, Glasgow, Scotland, UK.Copyright 2008 ACM 978-1-60558-013-5/08/04 ...$5.00.1. INTRODUCTIONToday’s popular operating systems run a daunting amountof code in the CPU’s most privileged mode. The plethora ofvulnerabilities in this code makes the compromise of systemscommonplace, and its privileged status is inherited by themalware that invades it. The integrity and secrecy of everyapplication is at risk in such an environment.To address these problems, we propose Flicker, an archi-tecture for isolating sensitive code execution using a minimalTrusted Computing Base (TCB). None of the software ex-ecuting before Flicker begins can monitor or interfere withFlicker code execution, and all traces of Flicker code exe-cution can be eliminated before regular execution resumes.For example, a Certificate Authority (CA) could sign certifi-cates with its private key, even while keeping the key secretfrom an adversary that controls the BIOS, OS, and DMA-enabled devices. Flicker can operate at any time and doesnot require a new OS or even a VMM, so the user’s platformfor non-sensitive operations remains unchanged.Flicker provides strong isolation guarantees while requir-ing the application to trust as few as 250 additional lines ofcode for its secrecy and integrity. As a result, Flicker circum-vents entire layers of legacy system software and eliminatesreliance on their correctness for security properties (see Fig-ure 1). Once the TCB for code execution has been preciselydefined and limited, formal assurance of both reliability andsecurity properties enters the realm of possibility.The use of Flicker, as well as the exact code executed(and its inputs and outputs), can be attested to an externalparty. For example, a piece of server code handling a user’spassword can execute in complete isolation from all othersoftware on the server, and the server can convince the clientthat the secrecy of the password was preserved. Such fine-grained attestations make a remote party’s verification muchsimpler, since the verifier need only trust a small piece ofcode, instead of trusting Application X running alongsideApplication Y on top of OS Z with some number of devicedrivers installed. Also, the party using Flicker does not leakextraneous information about the system’s software state.To achieve these properties, Flicker utilizes hardware sup-port for late launch and attestation recently introduced incommodity processors from AMD and Intel. These proces-sors already ship with off-the-shelf computers and will soonbecome ubiquitous. Although current hardware still hasa high overhead, we anticipate that future hardware per-formance will improve as these functions are increasinglyused. Indeed, in concurrent work, we suggest hardwaremodifications that can improve performance by up to sixCPU, ChipsetOSFlickerTPMApp1Appn...SCPU, Chipset, DMATPMApp1...AppnSOSFigure 1: On the left, a traditional computer with anapplication that executes sensitive code (S). On the right,Flicker protects the execution of the sensitive code. Theshaded portions represent components that must be trusted;other applications are included on the left because many ap-plications run with superuser privileges.orders of magnitude [19]. Finally, many applications per-form security-sensitive operations where the speed of theoperations is not the first priority.From a programmer’s perspective, the sensitive code pro-tected by Flicker can be written from scratch or extractedfrom an existing program. To simplify this task, the pro-grammer can draw on a collection of small code moduleswe have developed for common functions. For example, onesmall module protects the existing execution environmentfrom malicious or malfunctioning PALs. A programmer canalso apply tools we have developed to extract sensitive op-erations and relevant code from an application.We present an implementation of Flicker using AMD’sSVM technology and use it to improve the security of avariety of applications. We develop a rootkit detector thatan administrator can run on a remote machine and receive aguarantee that the detector executed correctly and returnedthe correct result. We also show how


Loading Unlocking...
Login

Join to view Flicker: An Execution Infrastructure for TCB Minimization∗ and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Flicker: An Execution Infrastructure for TCB Minimization∗ and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?