RC23064 (W0401-082) January 16, 2004
花旗木
Computer Science
IBM Rearch Report
Design and Implementation of a TCG-Bad Integrity
Measurement Architecture
Reiner Sailer, Xiaolan Zhang, Trent Jaeger, Leendert Van Doorn
IBM Rearch Division
Thomas J. Watson Rearch Center
P.O. Box 704
Yorktown Heights, NY 10598
Design and Implementation of a TCG-bad
Integrity Measurement Architecture
Reiner Sailer and Xiaolan Zhang and Trent Jaeger and Leendert van Doorn
IBM T.J.Watson Rearch Center
19Skyline Drive,Hawthorne,NY10532
{sailer,cxzhang,jaegert,leendert}@
莲子芯的功效与作用Abstract
We prent the design and implementation of a -cure integrity measurement system for Linux.All executable content that is loaded onto the Linux sys-tem is measured before execution and the measure-ments are protected by the Trusted Platform Mod-ule(TPM)that is part of the Trusted Comp
uting Group(TCG)standards.Our system is thefirst to extend the TCG trust concepts to dynamic exe-cutable content from the BIOS all the way up into the application layer.In effect,we show that many of the Microsoft NGSCB guarantees can be obtained on today’s hardware and today’s software and that the guarantees do not require a new CPU mode or operating system but merely depend on the avail-ability of an independent trusted entity,a TPM for example.We apply the measurement architecture to a web rver application where we show how our system can detect undesirable invocations,such as rootkit programs,and that measurement is practical in terms of the number of measurements taken and the performance impact of making them.
1Introduction
With the introduction of autonomic computing,grid computing and on demand computing there is an in-creasing need to be able to curely identify the soft-ware stack that is running on remote systems.For autonomic computing,you want to determine that the correct patches have been installed on a given system.For grid computing,you are concerned that the rvices advertid really exist and that the sys-tem is not compromid.For on demand computing, you may be concerned that your outsourcing part-ner is providing the software facilities and perfor-mance that have been stipulated in the rvice level
agreement.Yet another scenario is where you are interacting with your home banking or booklling webrvices application and you want to make sure it has not been tampered with.
The problem with the scenarios above is,who do you trust to give you that answer?It cannot be the pro-gram itlf becau is could be modified to give you wrong answers.For the same reason we cannot trust the kernel or the BIOS on which the programs are running since they may be tampered with too.In-stead we need to go back to an immutable root to provide that answer.This is esntially the cure boot problem[1],although for our scenarios we are interested in an integrity statement of the software stack rather than ensuring compliance with respect to a digital signature.
The Trusted Computing Group(TCG)has defined a t of standards[2]that describe how to take in-tegrity measurements of a system and store the re-sult in a parate trusted coprocessor(Trusted Plat-form Module)who state cannot be compromid by a potentially malicious host system.This mecha-nism is called trusted boot.Unlike cure boot,this system only takes measurements and leaves it up to the remote party to determine the system’s trustwor-thiness.The way this works is that when the system is powered on it transfers control to an immutable ba.This ba will measure the next part of BIOS by computing a SHA1cure hash over its contents and protect the result by using the TPM.This pro-cedure is then applied recursively to the next portion of code until the OS has bee
n bootstrapped.
The TCG trusted boot process is compod of a t of ordered quential steps and is only defined up to the bootstrap loader.Conceptually,we would like to maintain the chain of trust measurements up to the application layer,but unlike the bootstrap pro-1
cess,an operating system handles a large variety of executable content(kernel,kernel modules,binaries. shared libraries,scripts,plugins,etc.)and the order in which the content is loaded is emingly random. Furthermore,an operating system almost continu-ously loads executable content and measuring the content at each load time incurs a considerable per-formance overhead.
The system that we describe in this paper address the concerns.We have modified the Linux kernel and the runtime system to take integrity measure-ments as soon as executable content is loaded into the system,but before it is executed.We keep an ordered list of measurements inside the kernel.We change the role of the TPM slightly and u it to protect the integrity of the in-kernel list rather than holding measurements directly.To prove to a re-mote party what software stack is loaded,the sys-tem needs to prent the TPM state using the TCG attestation mechanisms and this ordered list.The remote party can then determine whether the or-dered list has been tampered with a
nd,once the list is validated,what kind of trust it associates with the measurements.To minimize the performance over-head,we cache the measurement results and elim-inate future measurement computations as long as the executable content has not been altered.The amount of modifications we made to the Linux sys-tem were minimal,about1000lines of code.
Our enhancement keeps track of all the software components that are executed by a system.The number of unique components is surprisingly small and the system quickly ttles into a steady state. For example,the workstation ud by this author which runs RedHat9and who workload consists of writing this paper,compile programs and brow the web does not accumulate more than500mea-surement entries.On a typical web rver the ac-cumulated measurements are about250.Thus,the notion of completelyfingerprinting the running soft-ware stack is surprisingly tractable. Contributions:This paper makes the following contributions:
•A non-intrusive and verifiable remote software stack attestation mechanism that us standard (commodity)hardware.
•An efficient measurement system for dynamic executable content.
•A tractable software stack attestation mecha-
nism that does not require new CPU modes or
a new operating system.
Outline:Next,we introduce the structure of a typ-ical run-time system,for which we will establish an integrity-measurement architecture throughout this paper.In Section3,we prent related work in the area of integrity protecting systems and attes-tation.In Sections4and5,we describe the de-sign of our approach and its implementation in a standard Linux operating environment.Section6 describes experiments that highlight how integrity breaches are made visible by our solution when val-idating measurement-lists.It also summarizes run-time overhead.Finally,Section7sketches enhance-ments to our architecture that are being imple-mented or planned.Our results show and validate that our architecture is efficient,scales with regard to the number of elements,successfully recognizes integrity breaches,and offers a valuable platform for extensions and future experiments.
白色英文怎么写
2Problem Statement
To provide integrity verification rvices,wefirst ex-amine the meaning of system integrity,in general. We then describe a web rver example system to identify the types of problems that must be solved to prove integrity to a remote system with a high degree of confidence.We show that the oper
ating system lacks the context to provide the level of in-tegrity measurement necessary,but with a hardware root of trust,the operating system can be a founda-tion of integrity measurement.Currently,we sur-mi that it is more appropriate forfinding integrity bugs than full verification,but we aim to define an architecture that can eventually be extended to meet our measurement requirements.
2.1Integrity Background
Our goal is to enable a remote system(the chal-lenger)to prove that a program on another system (the attesting system owned by the attestor)is of sufficient integrity to u.The integrity of a pro-gram is a binary property that indicates whether the program and/or its environment have been modified in an unauthorized manner.Such an unauthorized modification may result in incorrect or malicious be-havior by the program,such that it would be unwi for a challenger to rely on it.
2
While integrity is a binary property,integrity is a relative property that depends on the verifier’s view of the ability of a program to protect itlf.Biba defines that integrity is compromid when a pro-gram depends ,reads or executes)low in-tegrity data[3].In practice,programs often pro-cess lo
w integrity data without being compromid (but not all programs,all the time),so this defini-tion is too restricted.Clark-Wilson define a model in which integrity verification procedures verify in-tegrity at system startup and high integrity data is only modified by transformation procedures that are certified to maintain integrity even when their in-puts include low integrity data[4].Unfortunately, the certification of applications is too expensive to be practical.
蝴蝶结怎么叠
More recent efforts focus on measuring code and as-sociating integrity mantics with the code.The IBM4758explicitly defines that the integrity of a program is determined by the code of the program and its ancestors[5].In practice,this assumption is practical becau the program and its configura-tion are installed in a trusted manner,it is isolated from usingfiles that can be modified by other pro-grams,and it is assumed to be capable of handling low integrity requests from the external system.To make this guarantee plausible,the IBM4758envi-ronment is restricted to a single program with a well-defined input state and the integrity is enforced with cure boot.However,even the assumptions have not been sufficient to prevent compromi of applica-tions running on the4758which cannot handle low integrity inputs properly[6].Thus,further measure-ment of low integrity inputs and their impact appear to be likely.
The key differences in this paper are that:(1)we endeavor to define practical integrity for aflexible, tra
ditional systems environment under the control of a potentially untrusted party and(2)the only special hardware that we leverage is the root of trust pro-vided by the Trusted Computing Group’s Trusted Platform Module(TCG/TPM).In thefirst ca,we may not assume that all programs are loaded cor-rectly simply by examining the hash becau the untrusted party may try to change the input data that the program us.For example,many pro-grams enable configurationfiles to be specified in the command line.Ultimately,applications define the mantics of the inputs that they u,so it is difficult for an operating system to detect whether all inputs have been ud in an appropriate manner by an application if its environment is controlled by
an untrusted party.However,a number of vulnera-bilities can be found by the operating system alone, and it is fundamental that the operating system col-lect and protect measurements.
Second,the specialized hardware environment of the IBM4758enables cure boot and memory lock-down,but such features are either not available or not practical for current PC systems.Secure boot is not practical becau integrity requirements are notfixed,but defined by the remote challengers. If remote parties could determine the cure boot properties of a system,systems would be vulnerable to a significant denial-of-rvice threat.Instead the TCG/TPM supports trusted boot,where the attest-ing system is measured and the measurements are ud by the challengers to
verify their integrity re-quirements.Since trusted boot does not terminate a boot when a low integrity process is loaded,all data could be subject to attack during the“untrusted”boot.Since multiple applications can run in a dis-cretionary access control environment currently,it is difficult to determine whether the dynamic data of a ,a databa)is still acceptable.Dis-cretionary integrity mechanisms,such as aled stor-age[7],do not solve this problem in general.
2.2Example
We u as an example a rver machine running an Apache Webrver and Tomcat Web Containers that rve static and dynamic content to ll books to clients running on remote systems.The system is running a RedHat9.0Linux environment.Figure1 illustrates the runtime environment that affects the Web rver.
Kernel Space
Ur Space Figure1:Runtime System Components
3
The system is initiated by booting the operating system.The boot process is determined by the BIOS,grub bootloader,and kernel configurationfile (/f).Thefirst two can alter the sys-tem in arbitrary ways,so they must be measured. An interesting point is that measurement of config-urationfiles,such f,is not necessary as long as they do not:(1)modify code already loaded and(2)all subquentfile loads can be en by the measurement infrastructure.Since the BIOS and grub bootloader are unaffected,we only need to en-sure that the kernel and other programs who loads are triggered by the configuration are measured. The boot process results in a particular ker-nel being run.There are a variety of different types of kernels,kernel versions,and kernel con-figurations that determine the actual system be-ing booted.For example,we load Linux 2.4.21 from/boot/vmlinuz-2.4.21-tcg which includes a TCPA driver and our measurement hooks.Further, the kernel may be extended by loadable kernel mod-ules.The measurement infrastructure must be able to measure the kernel and any modules that are loaded.The challenger must be able to determine whether this specific kernel booted and the dynam-ically loaded modules meet the desired integrity re-quirements.
离骚Once the kernel is booted,then ur-level rvices and applications may be run.In Linux,a program execution starts by loading an appropriate ,a dynamic loader,such as ld.so)bad on the format of the executablefile.Loads of the target executable’s code and supporting libraries are done by the dynamic loader.Executables include the followingfiles on our experimental system:•Apache rver(apachectl,httpd,...)
•Apache modules(mod access.so,mod auth.so, mod cgi.so,...)
•Tomcat rvlet machine(startup.sh, catalina.sh,java,...)
•Dynamic libraries(libjvm.so,libcore.so,lib-java.so,libc-2.3.2.so,libssl.so.4,...)
All of this code impacts system integrity,so we need to measure them,but the operating system does not e a distinction between thefiles and typical data fi,they are all opened and read).An advan-tage is that the dynamic loader(for thatfile format)understands that thefiles are being loaded as ex-ecutable code.Dynamic loaders are trusted by the system,typically,so they trigger the measurement of libraryfiles.
Some otherfiles loaded by the application itlf also define its execution behavior.For example,the Ja
va classfiles that define rvlets and web rvices must be measured becau they are loaded by the Tom-cat rver to create dynamic content,such as shop-ping cart or payment pages.Application config-urationfiles,such as the startupfiles for Apache (f)and Tomcat(startup scripts)may also alter the behavior of the Web rver.Thefiles in our example system include:
•Apache configurationfif)
•Java virtual machine curity configuration (java.curity,java.policy)
•Servlets and web rvices libraries(axis.jar, rvlet.jar,wsdl4j.jar,...)
While each of thefiles may have standard contents that can be identified by the challenger,it is diffi-cult to determine whichfiles are actually being ud by an application and for what purpo.Even f has the expected contents,it may not be loaded as expected.For example,Apache has a com-mand line option to load a differentfile,links in the file system may result in a differentfile being loaded, and races are possible between when thefile is mea-sured and when it is loaded.Thus,a Tripwire-like[8] measurement of the key systemfiles is not sufficient becau the urs of the attesting system(attestors) may change thefiles that actually determine its in-tegrity,and the urs are not necessarily trusted by the challengers.As in the dynamic loader ca, the integrity impact of
opening afile is only known to the requesting program.However,unlike the ca for the dynamic loader,the problem of determining the integrity impact of application loads involves in-strumentation of many more programs,and the may be of varying trust levels.
软卧和硬卧的区别图片事物的两面性The integrity of the Web rver environment also depends on dynamic,unstructured data that is con-sumed by running executables.The key issue is that even if the application knows that this data can impact its integrity,its measurement is uless becau the challenger cannot predict values that would prerve integrity.In the web rver exam-ple,the key dynamic data are:(1)the various kinds 4
of requests from remote clients,administrators,and other rvlets and(2)the databa of book orders. The sorts of things that need to be determined are whether the order data or administrator commands can be modified only by high integrity , Biba)and whether the low integrity requests can be converted to high integrity data or , Clark-Wilson).Sealed storage is insufficient to en-sure thefirst property,informationflow bad on mandatory policy is necessary in general,and en-forcement of the cond property requires trusted upgraders or trust in the application itlf.
2.3Measuring Systems
Bad on the analysis of the web rver example,we list the types of tasks that must be accomplished to achieve a Clark-Wilson level of integrity verification.•Verification Scope:Unless informationflows among process are under a mandatory restric-tion,the integrity of all process must be mea-sured.Otherwi,the scope of integrity impact-ing a process may be reduced to only tho pro-cess upon which it depends for high integrity code and data.
•Executable Content:For each process,all code executed must be of sufficient integrity re-gardless of whether it is loaded by the operating system,dynamic loader,or application.•Structured Data:For each process,data who content has an identifiable integrity -mantics may be treated in the same manner as executable content above.However,we must be sure to capture the data that is actually loaded by the operating system,dynamic loaders,and applications.
•Unstructured Data:For each process,the data who content does not have an identifiable integrity mantics,the integrity of the data is dependent on the integrity of the process that have modified it or the integrity may be upgraded by explicit upgrade process or this process(if it is qualified to be a transformation procedure in the Clark-Wilson n).
Thefirst statement indicates that for systems that u discretionary ,NGSCB),the integrity
of all process must be measured becau all can im-pact each other.Second,we must measure all code
including modules,libraries,and code loaded in an ad hoc fashion by applications to verify the integrity of an individual process.Third,some data may have integrity mantics similar to code,such that it may be treated that way.Fourth,dynamic data cannot be verified as code,so data history,curity policy, etc.are necessary to determine its integrity.The challengers may assume that some code can handle low integrity data as input.The lack of correct un-derstanding about particular code’s ability to handle low integrity data is the source of many current cu-rity problems,so we would ultimately prefer a clear identification of how low integrity data is ud. Further,an esntial part of our architecture is the ability of challengers to ensure that the measurement list is:
王佳芬•fresh and ,includes all measure-
ments up to the point in time when the attes-
tation is executed,
•,thefingerprints are truly from
the loaded executable and static datafiles and
have not been tampered with.
An attestor that has been corrupted can try to cheat by either truncating measurements or deliv-ering changed measurements to hide the programs that have corrupted its state.Replaying old mea-surement lists is equivalent to hiding new measure-ments.
This analysis indicates that integrity verification for aflexible systems environment is a difficult prob-lem that requires veral coordinated tasks.Rather than tackle all problems at once,a more practical approach is to provide an extensible approach that can identify some integrity bugs now and form a ba-sis for constructing reasonable integrity verification in the future.This approach is motivated by the approach adopted by static analysis rearchers in recent work[9].Rather than proving the integrity of a program,the tools are design tofind bugs and be extensible tofinding other,more complex bugs in the future.Finding integrity bugs is also uful for identifying that code needs to be patched,illegal in-formationflows,or cas where low integrity data is ud without proper safeguards.For example,a challenger can verify that an attesting system is us-ing high integrity code for its current applications. In this paper,we define operating systems support for measuring the integrity of code and structured 5
