Trusted Computing and Linux - The Linux Kernel Archives · 92 • Trusted Computing and Linux a section on future work. 2 Goals of Trusted Computing The Trusted Computing Group (TCG)

Trusted Computing and Linux

Kylene HallIBM

[email protected]

Tom LendackyIBM

[email protected]

Emily RatliffIBM

[email protected]

Kent YoderIBM

[email protected]

Abstract

While Trusted Computing and LinuxR© mayseem antithetical on the surface, Linux userscan benefit from the security features, includingsystem integrity and key confidentiality, pro-vided by Trusted Computing. The purpose ofthis paper is to discuss the work that has beendone to enable Linux users to make use of theirTrusted Platform Module (TPM) in a non-evilmanner. The paper describes the individualsoftware components that are required to en-able the use of the TPM, including the TPMdevice driver and TrouSerS, the Trusted Soft-ware Stack, and TPM management. Key con-cerns with Trusted Computing are highlightedalong with what the Trusted Computing Grouphas done and what individual TPM owners cando to mitigate these concerns. Example ben-eficial uses for individuals and enterprises arediscussed including eCryptfs and GnuPG usageof the TPM. There is a tremendous opportunityfor enhanced security through enabling projectsto use the TPM so there is a discussion on themost promising avenues.

1 Introduction

The Trusted Computing Group (TCG) releasedthe first set of hardware and software specifi-cations shortly after the creation of that groupin 2003.1 This year, a short two years later,20 million computers will be sold containing aTrusted Platform Module (TPM) [Mohamed],which will largely go unused. Despite thecontroversy surrounding abuses potentially en-abled by the TPM, Linux has the opportunityto build controls into the enablement of theTrusted Computing technology to help the enduser control the TPM and take advantage of se-curity gains that can be made by exercising theTPM properly. This paper will cover the piecesneeded for a Linux user to begin to make use ofthe TPM.

This paper is organized into sections coveringthe goals of Trusted Computing, a brief intro-duction to Trusted Computing, the componentsrequired to make an operating system a trustedoperating system from the TCG perspective,the current state of Trusted Computing, usesof the TPM, clarification of common techni-cal misperceptions, and finally concludes with

1See [Fisher] and [TCGFAQ] for more history of theTrusted Computing Group.

• 91 •

92 • Trusted Computing and Linux

a section on future work.

2 Goals of Trusted Computing

The Trusted Computing Group (TCG) has cre-ated the Trusted Computing specifications inresponse to growing security problems in thetechnology field.

“The purpose of TCG is to develop, define, andpromote open, vendor-neutral industry specifi-cations for trusted computing. These includehardware building block and software inter-face specifications across multiple platformsand operating environments. Implementationof these specifications will help manage dataand digital identities more securely, protectingthem from external software attack and phys-ical theft. TCG specifications can also pro-vide capabilities that can be used for moresecure remote access by the user and enablethe user’s system to be used as a securitytoken.”[TCGBackground]

Fundamentally, the goal of the Trusted Com-puting Group’s specifications is to increase as-surance of trust by adding a level of verifiabilitybeyond what is provided by the operating sys-tem. This does not reduce the requirement fora secure operating system.

3 Introduction to Trusted Comput-ing

The Trusted Computing Group (TCG) has re-leased specifications about the Trusted Plat-form Module (TPM), which is a “smartcard-like device,” one per platform, typically real-ized in hardware that has a small amount ofboth volatile and non-volatile storage and cryp-tographic execution engines. Figure 1 shows

NVRAM

PCRs(Min 16)

EK

RNG

SHA-1

RSA

CryptographicCo-Processor

OPTIONALDSA, Eliptic Curve

Opt-In

ProgramCode

ExecutionEngine

I/O

PowerDetection

DIR(Deprecated in 1.2)

Figure 1: Trusted Platform Module

a logical view of a TPM. The TCG has alsoreleased a specification for APIs to allow pro-grams to interact with the TPM. The next sec-tion details the components needed to createa completely enabled operating system. Theinteraction between the components is graph-ically shown in Figure 2.

For a rigorous treatment of Trusted Comput-ing and how it compares to other hardware se-curity designs, please read Sean W. Smith’s“Trusted Computing Platforms Design and Ap-plications” [Smith:2005].

2005 Linux Symposium • 93

3.1 Key Concepts

There are a few key concepts that are essentialto understanding the Trusted Computing speci-fications.

3.1.1 Measurement

A measurement is a SHA-1 hash that is thenstored in a Platform Configuration Register(PCR) within the TPM. Storing a value in aPCR can only be done through what is knownas an extend operation. The extend operationtakes the SHA-1 hash currently stored in thePCR, concatenates the new SHA-1 value to it,and performs a SHA-1 hash on that concate-nated string. The resulting value is then storedin the PCR.

3.1.2 Roots of Trust

In the Trusted Computing Group’s model, trust-ing the operating system is replaced by trustingthe roots of trust. There are three roots of trust:

• root of trust for measurement

• root of trust for storage

• root of trust for reporting

The root of trust for measurement is the codethat represents the “bottom turtle”2. The rootof trust for measurement is not itself measured;it is expected to be very simple and immutable.It is the foundation of the chain of trust. It per-forms an initial PCR extend and then the per-forms the first measurement.

2This is an allusion to the folk knowledge of howthe universe is supported.http://en.wikipedia.org/wiki/Turtles_all_the_way_down

The root of trust for storage is the area wherethe keys and platform measurements are stored.It is trusted to prevent tampering with this data.

The root of trust for reporting is the mechanismby which the measurements are reliably con-veyed out of the root of trust for storage. Thisis the execution engine on the TPM.[TCGArch]

3.1.3 Chain of Trust

The chain of trust is a concept used by trustedcomputing that encompasses the idea that nocode other than the root of trust for measure-ment may execute without first being measured.This is also known as transitive trust or induc-tive trust.

3.1.4 Attestation

Attestation is a mechanism for proving some-thing about a system. The values of the PCRsare signed by an Attestation Identity Key andsent to the challenger along with the measure-ment log. To verify the results, the challengermust verify the signature, then verify the valuesof the PCRs by replaying the measurement log.

3.1.5 Binding Data to a TPM

Bound data is data that has been encrypted by aTPM using a key that is part of the root of trustfor storage. Since the root of trust of storageis different for every TPM, the data can only bedecrypted by the TPM that originally encryptedthe data. If the key used is a migratable key,however, then it can be migrated to the root oftrust for storage of a different TPM allowing thedata to be decrypted by a different TPM.


PKCS#11

App/TPM Mgmt

App

TSS

KernelMeasurement

LinuxKernel

TPM DD

BIOS/Firmware

TPMHardwarePlatform

BootLoader

Figure 2: Trusted Computing Enabled Operat-ing System

3.1.6 Sealing Data to a TPM

Sealed data is bound data that additionallyrecords the values of selected PCRs at the timethe data is encrypted. In addition to the restric-tions associated with bound data, sealed datacan only be decrypted when the selected PCRshave the same values they had at the time ofencryption.

4 Components of Trusted Comput-ing on Linux

Several components are required to enable anoperating system to use the Trusted Computingconcepts. These components are described inthis section.

4.1 TPM

The Trusted Platform Module (TPM) is a hard-ware component that provides the ability to se-curely protect and store keys, certificates, pass-words, and data in general. The TPM enables

more secure storage of data through asymmet-ric key operations that include on-chip key gen-eration (using a hardware random number gen-erator), and public/private key pair encryptionand signature operations. The TPM provideshardware-based protection of data because theprivate key used to protect the data is never ex-posed in the clear outside of the TPM. Addi-tionally, the key is only valid on the TPM onwhich it was created unless created migratableand migrated by the user to a new TPM.

The TPM provides functionality to securelystore hash values that represent platform con-figuration information. The secure reportingof these values, if authorized by the platformowner, enables verifiable attestation of a plat-form configuration. Data can also be protectedunder these values, requiring the platform to bein the same configuration to access the data aswhen the data was first protected.

The owner of the platform controls the TPM.There are initialization and management func-tions that allow the owner to turn on and offfunctionality, reset the TPM, and take owner-ship of the TPM. There are strong controls toprotect the privacy of an owner and user.3 Theplatform owner must opt-in. Any user, even ifdifferent from the owner, may opt-out.

Each TPM contains a unique EndorsementKey. This key can be used by a TPM ownerto anonymously establish Attestation IdentityKeys (AIKs). Since privacy concerns preventthe Endorsement Key from being used to signdata generated internally by the TPM, an AIKis used. An AIK is an alias to the EndorsementKey. The TPM owner controls the creation andactivation of an AIK as well as the data associ-ated with the AIK.[TCGMain],[TPM]

3See Section 7.1 for more details.


4.1.1 A Software-based TPM Emulator forLinux

If you don’t have a machine that has a TPM butyou’d like to start experimenting with TrustedComputing and the TSS API, a software TPMemulator can provide a development environ-ment in which to test your program. While asoftware TPM will provide you with a develop-ment environment, it can’t provide you with the“trust” that a hardware TPM can provide.

The advantage of having the TPM be a hard-ware component is the ability to begin measur-ing a system almost immediately at boot time.This is the start of the “chain of trust.” By mea-suring as early in the boot cycle as possible,you lessen the chance that an untrusted compo-nent (hardware or software) can be introducedwithout being noticed. There must be an ini-tial “trusted” measurement established, knownas the root of trust for measurement, and themeasurement “chain” must not be interruped.

With a software TPM emulator, you have de-layed the initial measurement long into the bootcycle of the system. Many measurements havenot occurred and so the trust of the system cannot be fully validated. So while you would notwant to rely on a software TPM to validate thetrust of your systemm, it does provide you witha development environment to begin preparingto take advantage of trusted computing.

Mario Sasser, a student at the Swiss FederalInstitute of Technology has created a TPM em-ulator that runs as a kernel module.[Strasser]It is not a full implementation of thespecification and it is still under develop-ment. It is available fromhttp://www.infsec.ethz.ch/people/psevinc/or https://developer.berlios.de/projects/tpm-emulator .

4.2 TPM Device Driver

The TPM device driver is a driver for the Linuxkernel to communicate TPM commands andtheir results between the TCG Software Stack(TSS) and the TPM device. Today’s TPMs areconnected to the LPC bus. The TPM hardwareis located by the driver from the PCI device forthe LPC bus and attempts to read manufacturerspecific information at manufacturer specificoffsets from the standard TPM address. Sincethe TPM device can only handle one commandat a time and the result must be cleared beforeanother command is issued, the TPM devicedriver takes special care to provide that onlyone command is in-flight at a time and that thedata is returned to only the requester. Ratherthan tie up all system resources with an ioctl,the command is transmitted and the result gath-ered into a driver buffer on a write call. Thenthe result is copied to the same user on a sub-sequent read call. This coupling of write andread calls is enforced by locks, the file struc-ture’s private data pointer and timeouts. Atthe direction of the Trusted Computing GroupSpecification, the TSS is the only interface al-lowed to communicate with the TPM thus, thedriver only allows one open at a time, which isdone by the TSS at boot time. The driver al-lows canceling an in-flight command with itssysfs filecancel . Other sysfs files providedby the driver arepcrs for reading current pcrvalues,caps for reading some basic capabilityinformation about the TPM such as manufac-turer and version andpubek for reading thepublic portion of the Endorsement Key if al-lowed by the device. The current driver sup-ports the Atmel and National Semiconductorversion 1.1 TPMs, which are polled to deter-mine when the result is available. The com-mon functionality of the driver is in thetpmkernel module, and the vendor specifics arein a separate module. The driver is availableon Sourceforge athttp://sourceforge.


net/projects/tpmdd/ under the projectname tpmdd and has been in Linux kernel ver-sions since 2.6.12.

4.3 TSS

The TCG Software Stack (TSS) is the API thatapplications use to interface with the TPM.

4.3.1 TSS Background

The TCG Software Stack (TSS)[TSS] is the setof software components that supports an ap-plication’s use of a platform’s TPM. The TSSis composed of a set of software modules andcomponents that allow applications to commu-nicate with a TPM.

The goals of the TSS are:

• Supply one entry point for applications tothe TPM’s functionality. (Provided by theTSS Service Provider Interface (The TSSAPI)).

• Provide synchronized access to the TPM.(Provided by the TSS Core Services Dae-mon(TCSD)).

• Hide issues such as byte ordering andalignment from the application. (Pro-vided by the TSS Service Provider Inter-face (TSPI)).

• Manage TPM resources. (Provided by theTCSD).

All components of the TSS reside in user space,interfacing with the TPM through the TPM de-vice driver.

TPM services provided through the TSS APIare:

• RSA key pair generation

• RSA encryption and decryption usingPKCS v1.5 and OAEP padding

• RSA sign/verify

• Extend data into the TPM’s PCRs and logthese events

• Seal data to arbitrary PCRs

• RNG

• RSA key storage

Applications will link with the TSP library,which provides them the TSS API and the un-derlying code necessary to connect to local andremote TCS daemons, which manage the re-sources of an individual TPM.

4.3.2 The TrouSerS project

The TrouSerS project aims to release a fullyTSS 1.1 specification compliant stack, follow-ing up with releases for each successive releaseof the TSS spec. TrouSerS is released underthe terms of the Common Public License, witha full API compliance test suite and examplecode (both licensed under the GPL) and docu-mentation. TrouSerS was tested against the At-mel TPM on i386 Linux and a software TPM onPPC64. TrouSerS is available in source tarballform and from CVS athttp://trousers.sf.net/ .

4.3.3 Technical features not in the TSSspecification

By utilizing udev.permissions for the TPM de-vice file and creating a UID and GID just forthe TSS, the TrouSerS TCS daemon runs with-out root owned resources.


For machines with no TPM support in theBIOS, TrouSerS supports an application levelinterface to the physical presence commandswhen the TCS daemon is executing in sin-gle user mode. This allows administrators toenable, disable, or reset their TPMs where aBIOS/firmware option is not available. This in-terface is automatically closed at the TCS levelwhen the TCS daemon is not running in singleuser mode, or cannot determine the run level ofthe system.

In order to maintain logs of all PCR extendoperations on a machine, TrouSerS supports apluggable interface to retrieve event log data.Presumably, the log data would be provided bythe Integrity Measurement Architecture (IMA)(see Section 4.6 below). As executable contentis loaded and extended by the kernel, a log ofeach extend event is recorded and made avail-able through sysfs. The data is then retrievedby the TCS Daemon on the next GetPcrEventAPI call.

To maintain the integrity of BIOS and ker-nel controlled PCRs, TrouSerS supports con-figurable sets of PCRs that cannot be extendedthrough the TSS. This is useful; for example inkeeping users from extending BIOS controlledPCRs or for blocking access to an IMA con-trolled PCR.

TCP/IP sockets were chosen as the interfacebetween TrouSerS’ TSP and TCS daemon, forboth local and remote access. This makes con-necting to a TCSD locally and remotely essen-tially the same operation. Access control to thelistening socket of the TCSD should be con-trolled with firewall rules. Access controls tothe TCSD’s internal functionality was imple-mented as a set of ‘operations,’ each of whichenable a set of functions to be accessible to aremote user that will enable that user to accom-plish the operation. For instance, enabling theseal operation allows a remote user to open andclose a context, create authorization sessions,

load a key, and seal data. By default, all func-tionality is available to local users and deniedto remote users.

4.4 TPM Management

Some TPM management functionality was im-plemented in the tpm-mgmt package and theopenCryptoki package. The tpm-mgmt pack-age contains support for controlling the TPM(enabling, activating, and so on) and for initial-izing and utilizing the PKCS#11 support that isprovided in the openCryptoki package.

4.4.1 Controlling the TPM

The owner of the platform has full control ofthe TPM residing on that platform. A TPMmaintains three discrete states: enabled or dis-abled, active or inactive, and owned or un-owned. The platform owner controls settingthese states. These states, when combined,form eight operational modes. Each opera-tional mode dictates what commands are avail-able.

Typically, a TPM is shipped disabled, inac-tive and unowned. In this operational mode,a very limited set of commands is available.This limited set of commands consists mainlyof self-test functions, capability functions andnon-volatile storage functions. In order to takefull advantage of the TPM, the platform ownermust enable, activate, and take ownership of theTPM. Enabling and activating the TPM is typ-ically performed using the platform BIOS orfirmware. If the BIOS or firmware does notprovide this support, but the TPM allows forthe establishment of physical presence throughsoftware, then TrouSerS can be used to estab-lish physical presence and accomplish the taskof enabling and activating the TPM. Taking


ownership of the TPM sets the owner password,which is required to execute certain commands.

The tpm-mgmt package contains the com-mands that are used to control the TPM as de-scribed above, as well as perform other tasks.

4.4.2 PKCS#11 Support

The PKCS#11 standard defines an API inter-face used to interact with cryptographic de-vices. Through this API, cryptographic devicesare represented as tokens, which provide appli-cations a common way of viewing and access-ing the functionality of the device. Providinga PKCS#11 interface allows applications thatsupport the PKCS#11 API to take advantage ofthe TPM immediately.

The TPM PKCS#11 interface is implementedin the openCryptoki package as the TPM to-ken. Each user defined to the system has theirown private TPM token data store that can holdboth public and private PKCS#11 objects. Allprivate PKCS#11 objects are protected by theTPM’s root of trust for storage. A symmet-ric key is used to encrypt all private PKCS#11objects. The symmetric key is protected byan asymmetric TPM key that uses the user’sPKCS#11 user login PIN as the key’s autho-rization data. A user must be able to success-fully login to the PKCS#11 token in order touse a private PKCS#11 object. The TPM tokenprovides key generation, encryption and signa-ture operations through the RSA, AES, tripleDES (3DES), and DES mechanisms.

The following RSA mechanisms are supported(as defined in the PKCS#11 Cryptographic To-ken Interface Standard[PKCS11]):

• PKCS#1 RSA key pair generation

• PKCS#1 RSA

• PKCS#1 RSA signature with SHA-1 orMD5

The following mechanisms are supportedAES, 3DES, and DES (as defined in thePKCS#11 Cryptographic Token InterfaceStandard[PKCS11]):

• Key generation

• Encryption and decryption in ECB, CBCor CBC with PKCS padding modes

The RSA mechanisms utilize the TSS to per-form the required operations. By utilizing theTSS, all RSA private key operations are per-formed securely in the TPM. The symmetricmechanisms are provided to allow for the pro-tection of data through symmetric encryption.The symmetric key used to protect the data iscreated on the TPM token and is thus, protectedby the TPM. Since the key is protected by theTPM, the data is protected by the TPM.

Before any PKCS#11 token is able to be usedit must be initialized. Since each user has theirown TPM token data store, each user must per-form this intialization step. Once the data storeis initialized it can be used by applications sup-porting the PKCS#11 API.

The tpm-mgmt package contains commands toinitialize the TPM token data store as well asperform other tasks. Some of the other tasksare:

• Import X509 certificates and/or RSA keypairs

Existing certificates and/or key pairscan be stored in the data store to beused by applications.


• List the PKCS#11 objects in the data store

In addition to any objects that you im-port, applications may have createdor generated objects in the data store.tpm-mgmt lets you get a list of allthe PKCS#11 objects that exist in thedata store.

• Protect data using the “User Data Protec-tion Key”

Protect data by encrypting it with arandom 256-bit AES key. The key iscreated as a PKCS#11 secret key ob-ject with an label attribute of “UserData Protection Key.” This label at-tribute is used to obtain a PKCS#11handle to the key and perform en-cryption, or decryption operations onthe data.

• Change the PKCS#11 PINs (Security Of-ficer and User)

PKCS#11 tokens have security offi-cer and a user PINs associated withthem. It may be necessary or desir-able to change one or both of thesePINs at some point in time.

4.5 Boot Loader

To preserve the chain of trust beyond the bootloader, the boot loader must be instrumented tomeasure the kernel before it passes over con-trol. The root of trust for measurement mea-sured the BIOS before it transferred control, theBIOS measured the boot loader. Now the bootloader must measure the kernel. Seiji Mune-toh and Y. Yamashita of IBM’s Tokyo Research

Lab have instrumented Grub v.0.94 and v.0.96to perform the required measurements. SinceGrub is a multi-stage boot loader, each stagemeasures the next before it transfers control.This is a slight simplification. Stage 1 is mea-sured by the BIOS. Stage 1 measures the firstsector of stage 1.5, which then measures therest of stage 1.5 and stage 2. The configurationfile is measured early with additional measure-ments of files referred to in configuration filestaken in sequence. If stage 1.5 is not loaded,stage 1 measures the first sector of stage 2 in-stead and that sector measures the rest of stage2. The grub measurements are stored in PCR4, the grub configuration file measurement isstored in PCR 5, and the kernel measurementis stored in PCR 8. The PCRs used are config-urable but the defaults meet the requirementsof the TCG PC Specific Implementation Speci-fication Version 1.1[TCGPC].

Lilo has also been instrumented to take themeasurements by the Dartmouth Enforcerteam. (See more detail about this project inSection 6.1.1).

4.6 Kernel Measurement Architecture—IMA

Reiner Sailer, and others of the IBM T.J. Wat-son Research Center have extended the chainof trust to the Linux kernel by implementinga measurement architecture for the kernel asa LSM.[SailerIMA] (Note: To effectively pre-serve the chain of trust, the LSM must be com-piled into the kernel rather than dynamicallyloaded.) Thefile_mmap hook is used toperform the measurement on anything that ismapped executable before it is loaded into vir-tual memory. Kernel modules are measuredjust before they are loaded. The measurementis used to extend one of the PCRs numberedbetween 7-16, as configured in the kernel toallow for somewhat flexible PCR use. PCR 9


is the default. Other files that are read and in-terpreted, such as bash scripts or Apache con-figuration files, require application modifica-tions to measure these files. Measurements arecached to reduce performance impact. Perfor-mance, usability, and bypass-protection are alladdressed in the Sailer, et al. report. Enforce-ment is not part of this architecture. The mea-surements (and measurement log) are intendedto be used by the challenger during remote at-testation to determine the integrity of the sys-tem, rather than by the system to enforce a se-curity policy.

5 Trusted Computing on LinuxNow and in the Future

Although version 1.1 TPMs provide many fea-tures usable today, significant hurdles exist todeploying the full capabilities of Trusted Com-puting outside a structured or corporate envi-ronment. Software that exists today basicallyenables the use of a TPM as one would use asmartcard. Other features, such as remote attes-tation, have more extensive requirements. Thecomponents required to implement remote atte-sation can be seen in Figure 3.

In order to implement remote attestation, TPMand Platform Vendor Support is required to:

• Put TPM support in the BIOS of shippingplatforms (currently shipping).

• Record the Public Endorsement Key insome way (such as make a cryptographichash) in order to identify whether a plat-form has a true TPM.

• Create and ship the TPM credential andthe platform credential.

Record of PubEKat manufacture time

Credentials suppliedto End Users

Privacy CA

TSS Stack

Creation ofAttestation Identity Key

Operating Systemboot loader support

Operating SystemPCR extend support

Remote Attestation

TSS Stack

TPM / Platform VendorSupport

TPMBIOS Support

Supported (GA)

Supported on some platforms

Figure 3: Dependencies for Full Trusted Com-puting Deployment

As long as the platform vendor has includedTPM support in the BIOS, a corporate envi-ronment can work around the lack of the otherelements by recording the PubEK as machinesare deployed and maintaining a PKI internally.However, in order to enable remote attestationfor general use by the public, a new infras-tructure among hardware and software vendorsmust be created. This infrastructure would pro-vide the credentials and a hash of the PubEKof shipping systems to Privacy CAs. The Pri-vacy CAs differ from existing CAs in the keycreation, certificate application, and certificatedelivery mechanism, so new CAs are needed orexisting CAs must implement the required soft-ware and procedures. At best, shipping plat-forms that fully support remote attestation areyears away. Because of the lack of this infras-tructure, no currently shipping platforms willhave the capability to provide remote attesta-tion for general use.

To make use of the more advanced features theTPM can provide, in addition to the infrastruc-ture element listed above, a Linux distro wouldneed to:

• Incorporate the measurement architecture


into the kernel.

• Ship measurement support for the bootloader.

• Include TrouSerS or some TCG SoftwareStack.

• Include attestation software.

• Include software for safe handling of theTPM and Platform credentials.

When this level of TPM hardware support isachieved, the groundwork will be laid to enablethe software that will be used for attestation.Ideas for an interoperable attestation interfaceinclude a stand-alone attestation daemon and amodified TLS protocol that includes attestation.Until one of these solutions is specified and im-plemented, attestation solutions are ad hoc atbest.

Finally, before general purpose remote attesta-tion can be widely used, tools and best practiceguidelines are needed to help define valid poli-cies and maintain policy currency. Dependingon the measurement architectures implementedby various operating systems, the policy be-comes quite complex very quickly.

6 Example Uses of the TPM

Given the passive nature of the TPM device, thedecision about its usefulness rests almost en-tirely on how one will use the device. Many ofthe doomsday scenarios surrounding the TPMdevice are based on scenarios involving soft-ware that Linux users will never agree to runon their hardware. In this section, some of themost promising uses of the TPM device are ad-dressed. See also “Interesting Uses of TrustedComputing”[Anonymous] and “The Role of

TPM in Enterprise Security”[Sailer] for morediscussion around this topic. Anonymous notesin the first article “Before wide-scale use of TCfor DRM, it will be necessary for the manufac-turers, software vendors and content providersto get past a few tiny details, like setting upa global, universal, widely trusted and securePKI. Hopefully readers . . . will understand thatthis is not exactly a trivial problem.” The usesdiscussed below do not depend on full deploy-ment of a complete Trusted Computing infras-tructure but only on existing capabilities.

6.1 Beyond Measurement –Enforcement

A couple of examples of how the Trusted Com-puting measurements can be used to enforce asecurity policy exist and are described in thissection.

6.1.1 Dartmouth’s Enforcer

Enforcer is an LSM that measures each fileas it is opened.[MacDonald] The measure-ment is compared against a database of pre-vious measurements. File attributes (mtime,inode number, and so on) are also inspected.If the file has changed, the system will ei-ther log the condition, deny access to the file,panic the kernel, or “lock” the TPM (by ex-tending the PCR used by Enforcer with ran-dom data, which makes decrypting data sealedto this PCR fail) based on the setting se-lected by the administrator. Enforcer doesnot require a TPM, but can optionally use theTPM to protect the database and configura-tion files. Enforcer also provideshelper ,which allows encrypting a loopback file systemwith a key protected by the TPM. Enforcer isavailable athttp://sourceforge.net/projects/enforcer/ .


6.1.2 Trusted Linux Client

The IMA kernel measurement architecture de-scribed previously provides no direct enforce-ment mechanisms. Dave Safford of IBM’sT.J. Watson Research Center has proposedan extension to the concept that includes en-forcement. The idea is to provide a se-ries of LSMs that provide authenticated boot,encrypted home directories and file attributechecking. The first module validates the in-tegrity of initrd and the kernel, and releasesa TPM based kernel symmetric key. The keyis used to derive keys for encrypted home di-rectories via loopback file system and authen-ticated file attribute checking. The next mod-ule deals with extended attributes that are ap-plied to every file including a file hash, MAClabel, and others. The derived symmetric key isused to HMAC these attributes, and the value ischecked and cached once at open/execute. A fi-nal module provides LOMAC style mandatoryaccess control. See the presentation ’PuttingTrust into Computing: Where does it Fit?—RSA Conference 2005’ for an overview ofthis concept.[TCGRSA]

6.2 Enterprise Uses

Since the Trusted Computing Group is an in-dustry led standards organization it is no sur-prise that compelling use cases exist for the en-terprise.

6.2.1 Network attach

Enterprise networks are often described as’hard and crunchy on the outside, but soft andchewy on the inside’ reflecting the fact that theytypically have very good perimeter defenses,but are less well protected from the inside. Thisposes a problem for enterprises that allow their

employees to take mobile computing deviceson the road and connect to non-protected net-works. Viruses very often use unprotected mo-bile devices as a gateway device through whichto invade corporate networks. To defeat virusesand worms that come in this way, more inter-nal firewalls and choke points are architectedinto the network. A few vendors are now of-fering compliance checking software that chal-lenge mobile devices when they attempt to re-attach to the internal network; this is to provethat they meet corporate guidelines before al-lowing them to attach. This is typically donethrough agent software running on the mobiledevice. The agent software becomes the logi-cal attack point.

Trusted Computing can make this compliancechecking stronger. The Trusted Network Con-nect (TNC) subgroup of the Trusted ComputingGroup has released a specification[TNC] forclient and server APIs that allow developmentof plugins for existing network attach productsto do client integrity measurement and server-side verification of client integrity. The plug-ins add remote attestation capabilities to exist-ing network attach products. The products con-tinue to operate in their normal manner with theassurance that the client agents have not beensubverted.

6.2.2 Systems management

Remote attestation is extremely useful whencombined with systems management software.System integrity of the managed system is ver-ified through remote attestation periodically, oron demand. Tied into the intrusion detectionsystem, systematic integrity checking ensuresthat compromises can be quickly detected.


6.2.3 Common Criteria Compliance

Common Criteria evaluations are based on awell-defined and usually strict Security Target.Installing new software may cause the systemto flip to an unevaluated mode. Remote attes-tation can be employed to confirm that all sys-tems that are required to be Common Criteriacompliant, retain adherence to the Security Tar-get. This is one of the simpler uses of remoteattestation since the policy to which the clientmust adhere is so static, strict, and well-definedthat it eliminates the need for much policy man-agement.

6.3 Uses by Individuals

The TPM can also be used to secure individ-ual’s computer and data.

6.3.1 TPM Keyring

The TPM Keyring application illustrates us-age of the TSS API, and some of the proper-ties of keys created with a TPM. TPM Keyringis licensed under the GPL and contains ex-amples of how to wrap a software generatedkey with a TPM key, connect to local and re-mote TCS daemons, store and retrieve keys andencrypt and decrypt data using the TSS API.The source is available from CVS athttp://trousers.sf.net/ . TPM Keyring willwrap a software generated OpenSSL key withthe Storage Root Key (SRK) of an arbitrarynumber of users. Once each user has a copyof this wrapped key, all users of the keyringcan send secure messages to one another, butno user can give the key to anyone else, exceptthe owner of the original OpenSSL key. Scriptsare also provided to easily encrypt a symmetrickey and use OpenSSL to encrypt large files.

You can imagine usingtpm_keyring itself,or the concepts presented bytpm_keyringto create private and secure peer-to-peer net-works.

Creating a New Keyring tpm_keyringgenerates a plaintext RSA key pair in memoryand wraps the private key of that key with thepublic key of your TPM’s root key. The plain-text RSA key is then encrypted with a password(that you are prompted for), and written to disk.Once the new key ring is created, you shouldmove the encrypted software generated key toa safe place off your machine.

Adding Members to a Keyring After you’vecreated a keyring, you’ll probably want to addmembers so that you can start exchanging data.You’ll need to bring your encrypted key file outof retirement from off-site backup in order towrap it with your friend’s TPM’s root key. Con-tact this person and ask for their IP address orhostname. The public portion of your friend’sroot key will be pulled out of their TCS dae-mon’s persistent storage and used to wrap yourplaintext key. The resulting encrypted key isstored in your friend’s persistent storage, witha UUID generated by hashing the name of thekeyring you created. Let your friend know thename you gave the keyring so that they can im-port the key.

Importing a Key Once a friend has storedtheir key in your persistent store, you can im-port it so thattpm_keyring can use it. Runthe import command with the same name of thekey ring that your friend created and some host-name and alias pair to help you remember thefriend who’s keyring you’re joining.


6.3.2 eCryptfs

The need for disk encryption is often over-looked but well motivated by security eventsin the news; for example, this article athttp://sanjose.bizjournals.com/sanjose/stories/2005/04/04/daily47.html about a physical theft com-promising 185,000 patients’ medical records.eCryptfs [Halcrow:2005], being presented atOLS 2005 by Michael Halcrow, offers as anoption, file encryption using TPM keys. Inthe case mentioned, if the information on diskhad been encrypted with a TPM key, the datawould not have been recoverable by the thief.Hot swappable drives and mobile storage beingso easy to remove, in particular, benefit fromencryption tied to a TPM key.

6.3.3 mod_ssl

Another use for the TPM is to provide securestorage for SSL private keys. Many system ad-ministrators face a problem of securely protect-ing the SSL private key and still being able torestart a web server as needed without humaninteraction. With the TPM, the private key canbe bound, or optionally, sealed to a certain setof PCRs allowing it to be unsealed as necessaryfor starting SSL in a trusted environment on theexpected platform.

6.3.4 GnuPG

Project Aegypten (http://www.gnupg.org/aegypten/ ) has extended GnuPG andother related projects so that GnuPG can usekeys stored on smartcards. This can be ex-tended to enable GnuPG to use keys stored onthe TPM.

6.3.5 OpenSSH

Similarly, as the mod_ssl use case mentionedabove, the TPM can be used to provide securestorage for SSH keys. In addition to the serverkey being protected, individuals can use theirown TPM key to protect their SSH keys.

7 Pros and Cons of Trusted Com-puting

So much emotionally charged material hasbeen written about Trusted Computing that itis difficult to separate the wheat from the chaff.

The seminal anti-TCG commentary is availablefrom [Anderson], [RMS], [Schoen:2003], and[Moglen] with the seminal pro-TCG commen-tary available from [Safford].

Seth Schoen has written an excellent paper“EFF Comments on TCG Design Implementa-tion and Usage Principles 0.95” with thought-ful, informed criticism of Trusted Computing.This paper makes the point “Many [criticisms]depend on what platform or operating systemvendors do.” [Schoen:2004]

Catherine Flick has written a comprehensivesurvey of the criticisms of Trusted Computingin her honor’s thesis entitled “The Controversyover Trusted Computing.” [Flick:2004]

This paper will address and attempt to clarifyonly the few technical issues that seem to comeup repeatedly.

7.1 Privacy

There were many valid privacy concerns sur-rounding the 1.1 version of the TPM specifica-tion requiring ’trusted third parties’ (PKI ven-dors) to issue AIKs. The concern was that the


trusted third party is able to link all pseudony-mous AIKs back to a single Platform Creden-tial. To address this concern, v. 1.2 now pro-vides a new way for requesting AIKs called Di-rect Anonymous Attestation. DAA is beyondthe scope of this paper, more information canbe found in [Brickell]. In the v.1.1 timeframe,privacy concerns are mitigated by the fact thatno manufacturer records a hash of the EK be-fore shipping the TPM.

The measurement log, as maintained by theIMA kernel measurement architecture containsan entry about every executable that has runsince boot. Like systems management data,this measurment log data may be consideredsensitive data that should not be shared be-yond the confines of the system, or perhapsthe local network. A couple of solutions havebeen proposed for this problem. One veryinteresting solution calls for a compact veri-fier which verifies the targeted system and re-ports the results back to the challenger with-out leaking data. The verifier is a stocksmall entity with no private attributes. Inthis solution, the verifier would ideally bea small neighboring partition or part of thehypervisor[Garfinkel:2003]. Another solutioncalls for attestation based on abstract propertiesrather than complete knowledge of the systemattributes. See [SadStu:2004] and [?].

7.2 TPM Malfunction

What happens to my encrypted data if the TPMon my motherboard dies? This depends on howthe data was encrypted and what type of keywas used to encrypt the data. When TPM keysare created, you have the option of making thekey migratable. This implies a trade-off be-tween security and availability so you are en-couraged to consider their goal for each indi-vidual key. If the key was created migratableand the data is bound but not sealed to the TPM,

you can import the key on a new TPM, restorethe encrypted data from a backup, and use thekey on the new TPM to access the data. If thekey was not created as a migratable key or thedata was sealed to the TPM, then the data willbe lost.4 Note that a backup of the migratablekey must be made and stored in a safe place.

7.3 Secure Boot

Will trusted computing help me be able to per-form secure boot as described by Arbaugh, andothers[Arbaugh:1997] Arbaugh and others de-scribed “A Secure and Reliable Bootstrap Ar-chitecture” that is widely believed to be an in-spiration for Trusted Computing. This paperdescribes the AEGIS architecture for establish-ing a chain of trust, driving the trust to lowerlevels of the system, and, based on those ele-ments, secure boot. Trusted Computing sup-plies some elements of this architecture, butthe TPM cannot completely replace the PROMboard described in the paper. Commerciallyavailable TPMs currently do not have enoughstorage to contain the secure recovery code.Additionally, the infrastructural5 and procedu-ral hurdles, described in Section 5, would stillhave to be overcome. Trusted Computing en-hanced BIOSes do not currently perform theverfication described in the paper, so the securerecovery has to be added to the BIOS imple-mentation or enforced at a higher level than de-scribed in the paper.

4This is a slight simplification. If the PCR(s) selectedfor the seal operation on the new machine are exactlyidentical to the ones that the data was sealed to, then youcan migrate the sealed data. Depending on the PCR cho-sen, to have the PCRs be the same the system, kernel,boot loader, and patch level of the two systems wouldhave to be identical.

5The assumption of “the existence of a cryptographiccertificate authority infrastructure” and the assumptionthat “some trusted source exists for recovery purposes.”


7.4 Kernel Lock-out

Does trusted computing lock me out of beingable to boot my custom kernel? No, this func-tionality does not exist. The technical, infras-tructural, and procedural hurdles, described inSection 5, would have to be overcome to en-force this technology on a global basis. Willthis technology ever exist? There are culturaland political forces barring adoption of tech-nology that takes aways the individual’s rightto run their operating system of choice on theirgeneral purpose computer. There is economicdisincentive to forcibly limiting general pur-pose computing. The realization of this sce-nario depends more on political factors thantechnical capabilities.

7.5 Free and Open Source BIOS

Will I still be able to replace my computer’sBIOS with a free BIOS? Trusted Computingdoes not prevent you from replacing your sys-tem BIOS with one of the free BIOS replace-ments, however, doing so currently violates thechain of trust. The TPM on the system canbe used as a smartcard, but attestation wouldbe broken. Free BIOS replacements can im-plement the relevant measurement architectureand maintain the chain of trust, if the bootblock remains immutable and measures thenew BIOS before it takes control of the sys-tem. The challenger during attestation wouldsee that a different BIOS is loaded and canchoose to trust the system, or not, based on theirlevel of trust in the free BIOS.

7.6 Specific Additional Concerns

Is the Trusted Computing Group takingcomments about specific concerns? TheTrusted Computing Group has interacted

with many people and organizations whohave expressed concern with the group’sspecifications. Several of the concerns haveresulted in changes to the TPM specifica-tion, for example, the introduction of DirectAnonymous Attestation, which solves manyof the privacy problems that the BSI andindividuals expressed. The Trusted ComputingGroup invites serious comments to be sent [email protected], or enteredinto their comment web page athttps://www.trustedcomputinggroup.org/about/contact_us/ .

8 Conclusion

This paper has quickly covered a great dealof ground from Trusted Computing definitionsand components to uses and common concerns;no discussion about Trusted Computing andLinux is complete without citing Linus Tor-vald’s famous email ’Flame Linus to a crisp!’proclaiming ’DRM is perfectly ok with Linux.’6 Even though Linus considers DRM okay,the hope is that this paper makes clear that theuses of Trusted Computing are not limited toDRM, and that individual Linux users can usethe TPM to improve their security. The TrustedComputing Group has shown itself willing towork with serious critiques and the Linux com-munity is capabable of defending itself fromabusive technologies being adopted. With es-timates that more than 20 million computershave been sold containing a TPM, and the ex-istence of open source drivers and libraries,let’s put this technology to productive use inways that are compatible with free and opensource philosophies. While the infrastructureand software for complete support are futurework items, that does not prevent users from

6http://marc.theaimsgroup.com/?l=linux-kernel&m=105115686114064&w=2


utilizing their TPM to gain secure storage fortheir personal keys and data through projectsalready available or proposed by this and otherpapers.

9 Legal Statement

Copyright c©2005 IBM.

This work represents the view of the authorsand does not necessarily represent the view ofIBM.

IBM and the IBM logo are trademarks or regis-tered trademarks of International Business Ma-chines Corporation in the United States, othercountries, or both.

Linux is a registered trademark of Linus Tor-valds in the United States, other countries, orboth.

Other company, product, and service namesmay be trademarks or service marks of others.

References in this publication to IBM productsor services do not imply that IBM intends tomake them available in all countries in whichIBM operates.

This document is provided “AS IS,” with no ex-press or implied warranties. Use this informa-tion at your own risk.

References

[Anderson] Ross Anderson’TrustedComputing’ Frequently Asked Questions,2003,http://www.cl.cam.ac.uk/users/rja14/tcpa-faq.html

[Anonymous] AnonymousInteresting Uses ofTrusted Computing, 2004,http://invisiblog.com/1c801df4aee49232/article/0df117d5d9b32aea8bc23194ecc270ec

[Arbaugh:1997] William A. Arbaugh, DavidJ. Farber, and Jonathan M. SmithASecure and Reliable BootstrapArchitecture, Proceedings of the IEEESymposium on Security and Privacy,May 1997

[Brickell] E. Brickell, J. Camenisch, and L.ChenDirect Anonymous Attestation,Proceedings of 11th ACM Conference onComputer and Communications Security,2004

[Fisher] Dennis Fisher,Trusted ComputingGroup Forms, eWeek, April 8, 2003,http://www.eweek.com/article2/0,1759,1657467,00.asp

[Flick:2004] Catherine FlickThe Controversyover Trusted Computing, The Universityof Sydney, 2004,http://luddite.cst.usyd.edu.au/~liedra/misc/Controversy_Over_Trusted_Computing.pdf

[Garfinkel:2003] Tal Garfinkel, Ben Pfaff, JimChow, Mendel Rosenblum, and DanBonehTerra: A Virtual Machine-BasedPlatform for Trusted Computing,Proceedings of the 19th Symposium onOperating System Principles(SOSP2003), October 2003

[Halcrow:2005] Michael Austin HalcroweCryptfs: An Enterprise-classCryptographic Filesystem for Linux,Ottawa Linux Symposium, 2005

[Haldar:2004] Vivek Haldar, DeepakChandra, and Michael FranzSemantic


Remote attestation: A Virtual MachineDirected Approach to TrustedComputing, USENIX Virtual MachineResearch and Technology Symposium,2004,http://gandalf.ics.uci.edu/~haldar/pubs/trustedvm-tr.pdf

[MacDonald] Rich MacDonald, Sean Smith,John Marchesini, and Omen WildBear:An Open-Source Virtual SecureCoprocessor based on TCPA, DartmouthCollege, August 2003,http://www.cs.dartmouth.edu/~sws/papers/msmw03.pdf

[Moglen] Eben MoglenFree SoftwareMatters: Untrustworthy Computing,2002,http://emoglen.law.columbia.edu/publications/lu-22.html

[Mohamed] Arif Mohamed,Who Can YouTrust?, ComputerWeekly.com, April 26,2005,http://www.computerweekly.com/articles/article.asp?liArticleID=138102&liArticleTypeID=20&liCategoryID=2&liChannelID=22&liFlavourID=1&sSearch=&nPage=1

[RMS] Richard StallmanCan you trust yourcomputer?, 2002,http://www.gnu.org/philosophy/can-you-trust.html

[PKCS11] RSA Laboratories PKCS #11v2.20: Cryptographic Token InterfaceStandard, 28 June 2004,ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-11/v2-20/pkcs-11v2-20.pdf

[SadStu:2004] Ahmad-Reza Sadeghi andChristian StuebleProperty-basedAttestation for Computing Platforms:Caring about properties, notmechanisms, 20th Annual ComputerSecurity Applications Conference,December 2004,http://www.prosec.rub.de/Publications/SadStu2004.pdf

[Safford] David SaffordTCPAMisinformation Rebuttal, IBM T.J.Watson Research Center, 2002,http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf

[SailerIMA] Reiner Sailer, Xiaolan Zhang,Trent Jaeger, and Leendert van Doorn,Design and Implementation of aTCG-based Integrity MeasurementArchitecture, 13th Usenix SecuritySymposium, August 2004

[Sailer] Reiner Sailer, Leendert van Doorn,and James P. WardThe Role of TPM inEnterprise Security, September 2004,https://www.trustedcomputinggroup.org/press/news_articles/rc23363.pdf

[Schoen:2003] Seth SchoenTrustedComputing Promise and Risk, EFF, 2003,http://www.eff.org/Infrastructure/trusted_computing/20031001_tc.pdf

[Schoen:2004] Seth SchoenEFF Commentson TCG Design, Implementation andUsage Principles 0.95, EFF, 2004,http://www.eff.org/Infrastructure/trusted_computing/20041004_eff_comments_tcg_principles.pdf

[Smith:2005] Sean W. SmithTrustedComputing Platforms Design and


Applicatons, Springer, 2005, ISBN0-387-23916-2

[Strasser] Mario StrasserA Software-basedTPM Emulator for Linux, Swiss FederalInstitute of Technology, 2004,http://www.infsec.ethz.ch/people/psevinc/TPMEmulatorReport.pdf

[TCGArch] TCGTrusted Computing GroupSpecification Architectural Overview,Revision 1.2, April 28, 2004,http://www.trustedcomputinggroup.org/downloads/TCG_1_0_Architecture_Overview.pdf

[TCGBackground] TCGTrusted ComputingGroup Backgrounder, January 2005,http://www.trustedcomputinggroup.org/downloads/background_docs/TCGBackgrounder_revised_012605.pdf

[TCGFAQ] TCGTrusted Computing GroupFact Sheet, 2005,http://www.trustedcomputinggroup.org/downloads/background_docs/FACTSHEET_revised_020105.pdf

[TCGMain] TCGTCG Main SpecificationVersion 1.1b, 2003,http://www.trustedcomputinggroup.org/downloads/specifications/TCPA_Main_Architecture_v1_1b.zip

[TCGPC] TCGTCG PC SpecificImplementation Specification Version 1.1,August 18, 2003,http://www.trustedcomputinggroup.org/downloads/TCG_PCSpecification_v1_1.pdf

[TCGRSA] TCGPutting Trust intoComputing: Where does it Fit? - RSAConference 2005, https://www.trustedcomputinggroup.org/downloads/Putting_Trust_Into_Computing_Where_Does_It_Fit_021405.pdf

[TNC] TCG TCG TNC Architecture Version1.0, 2005,http://www.trustedcomputinggroup.org/downloads/specifications/TNC_Architecture_v1_0_r4.pdf

[TPM] TCG TCG TPM Specification Version1.2, 2004,http://www.trustedcomputinggroup.org/downloads/specifications/mainP1DP_rev85.zip

[TSS] TCGTCG Software Stack SpecificationVersion 1.1, 2003,http://www.trustedcomputinggroup.org/downloads/TSS_Version__1.1.pdf


Proceedings of theLinux Symposium

Volume Two

July 20nd–23th, 2005Ottawa, Ontario

Canada

Conference Organizers

Andrew J. Hutton,Steamballoon, Inc.C. Craig Ross,Linux SymposiumStephanie Donovan,Linux Symposium

Review Committee

Gerrit Huizenga,IBMMatthew Wilcox,HPDirk Hohndel,IntelVal Henson,Sun MicrosystemsJamal Hadi Salimi,ZnyxMatt Domsch,DellAndrew Hutton,Steamballoon, Inc.

Proceedings Formatting Team

John W. Lockhart,Red Hat, Inc.

Authors retain copyright to all submitted papers, but have granted unlimited redistribution rightsto all as a condition of submission.

Documents

Trusted Computing and Linux - The Linux Kernel Archives · 92 • Trusted Computing and Linux a section on future work. 2 Goals of Trusted Computing The Trusted Computing Group (TCG)