Trusted Computing and Linux
`
`Kylene Hall
`IBM
`kylene@us.ibm.com
`
`Tom Lendacky
`IBM
`toml@us.ibm.com
`
`Emily Ratliff
`IBM
`emilyr@us.ibm.com
`
`Kent Yoder
`IBM
`yoder1@us.ibm.com
`
`Abstract
`
`1 Introduction
`
`While Trusted Computing and Linux R(cid:13) may
`seem antithetical on the surface, Linux users
`can benefit from the security features, including
`system integrity and key confidentiality, pro-
`vided by Trusted Computing. The purpose of
`this paper is to discuss the work that has been
`done to enable Linux users to make use of their
`Trusted Platform Module (TPM) in a non-evil
`manner. The paper describes the individual
`software components that are required to en-
`able the use of the TPM, including the TPM
`device driver and TrouSerS, the Trusted Soft-
`ware Stack, and TPM management. Key con-
`cerns with Trusted Computing are highlighted
`along with what the Trusted Computing Group
`has done and what individual TPM owners can
`do to mitigate these concerns. Example ben-
`eficial uses for individuals and enterprises are
`discussed including eCryptfs and GnuPG usage
`of the TPM. There is a tremendous opportunity
`for enhanced security through enabling projects
`to use the TPM so there is a discussion on the
`most promising avenues.
`
`The Trusted Computing Group (TCG) released
`the first set of hardware and software specifi-
`cations shortly after the creation of that group
`in 2003.1 This year, a short two years later,
`20 million computers will be sold containing a
`Trusted Platform Module (TPM) [Mohamed],
`which will largely go unused. Despite the
`controversy surrounding abuses potentially en-
`abled by the TPM, Linux has the opportunity
`to build controls into the enablement of the
`Trusted Computing technology to help the end
`user control the TPM and take advantage of se-
`curity gains that can be made by exercising the
`TPM properly. This paper will cover the pieces
`needed for a Linux user to begin to make use of
`the TPM.
`
`This paper is organized into sections covering
`the goals of Trusted Computing, a brief intro-
`duction to Trusted Computing, the components
`required to make an operating system a trusted
`operating system from the TCG perspective,
`the current state of Trusted Computing, uses
`of the TPM, clarification of common techni-
`cal misperceptions, and finally concludes with
`
`1See [Fisher] and [TCGFAQ] for more history of the
`Trusted Computing Group.
`• 91 •
`
`APPLE 1044
`
`1
`
`

`

`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 in
`response to growing security problems in the
`technology field.
`
`“The purpose of TCG is to develop, define, and
`promote open, vendor-neutral industry specifi-
`cations for trusted computing. These include
`hardware building block and software inter-
`face specifications across multiple platforms
`and operating environments.
`Implementation
`of these specifications will help manage data
`and digital identities more securely, protecting
`them from external software attack and phys-
`ical theft. TCG specifications can also pro-
`vide capabilities that can be used for more
`secure remote access by the user and enable
`the user’s system to be used as a security
`token.”[TCGBackground]
`
`Fundamentally, the goal of the Trusted Com-
`puting Group’s specifications is to increase as-
`surance of trust by adding a level of verifiability
`beyond what is provided by the operating sys-
`tem. This does not reduce the requirement for
`a 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 of
`both volatile and non-volatile storage and cryp-
`tographic execution engines. Figure 1 shows
`
`Figure 1: Trusted Platform Module
`
`a logical view of a TPM. The TCG has also
`released a specification for APIs to allow pro-
`grams to interact with the TPM. The next sec-
`tion details the components needed to create
`a completely enabled operating system. The
`interaction 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].
`
`NVRAM
`
`PCRs
`(Min 16)
`
`EK
`
`Opt-In
`
`Program
`Code
`
`Execution
`Engine
`
`RNG
`
`SHA-1
`
`RSA
`
`OPTIONAL
`DSA,
`Eliptic Curve
`Cryptographic
`Co-Processor
`
` DIR
`(Deprecated in 1.2)
`
`Power
`Detection
`
`I/O
`
`2
`
`

`

`3.1 Key Concepts
`
`There are a few key concepts that are essential
`to understanding the Trusted Computing speci-
`fications.
`
`3.1.1 Measurement
`
`A measurement is a SHA-1 hash that is then
`stored in a Platform Configuration Register
`(PCR) within the TPM. Storing a value in a
`PCR can only be done through what is known
`as an extend operation. The extend operation
`takes the SHA-1 hash currently stored in the
`PCR, concatenates the new SHA-1 value to it,
`and performs a SHA-1 hash on that concate-
`nated string. The resulting value is then stored
`in the PCR.
`
`2005 Linux Symposium • 93
`
`The root of trust for storage is the area where
`the keys and platform measurements are stored.
`It is trusted to prevent tampering with this data.
`
`The root of trust for reporting is the mechanism
`by which the measurements are reliably con-
`veyed out of the root of trust for storage. This
`is the execution engine on the TPM.[TCGArch]
`
`3.1.3 Chain of Trust
`
`The chain of trust is a concept used by trusted
`computing that encompasses the idea that no
`code 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.2 Roots of Trust
`
`3.1.4 Attestation
`
`In the Trusted Computing Group’s model, trust-
`ing the operating system is replaced by trusting
`the roots of trust. There are three roots of trust:
`
`• root of trust for measurement
`• root of trust for storage
`• root of trust for reporting
`
`Attestation is a mechanism for proving some-
`thing about a system. The values of the PCRs
`are signed by an Attestation Identity Key and
`sent to the challenger along with the measure-
`ment log. To verify the results, the challenger
`must verify the signature, then verify the values
`of the PCRs by replaying the measurement log.
`
`3.1.5 Binding Data to a TPM
`
`The root of trust for measurement is the code
`that represents the “bottom turtle”2. The root
`of 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 how
`the universe is supported. http://en.wikipedia.
`org/wiki/Turtles_all_the_way_down
`
`Bound data is data that has been encrypted by a
`TPM using a key that is part of the root of trust
`for storage. Since the root of trust of storage
`is different for every TPM, the data can only be
`decrypted by the TPM that originally encrypted
`the data. If the key used is a migratable key,
`however, then it can be migrated to the root of
`trust for storage of a different TPM allowing the
`data to be decrypted by a different TPM.
`
`3
`
`

`

`94 • Trusted Computing and Linux
`
`Figure 2: Trusted Computing Enabled Operat-
`ing System
`
`3.1.6 Sealing Data to a TPM
`
`Sealed data is bound data that additionally
`records the values of selected PCRs at the time
`the data is encrypted. In addition to the restric-
`tions associated with bound data, sealed data
`can only be decrypted when the selected PCRs
`have the same values they had at the time of
`encryption.
`
`4 Components of Trusted Comput-
`ing on Linux
`
`Several components are required to enable an
`operating system to use the Trusted Computing
`concepts. These components are described in
`this 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 encryption
`and signature operations. The TPM provides
`hardware-based protection of data because the
`private 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 on
`which it was created unless created migratable
`and migrated by the user to a new TPM.
`
`The TPM provides functionality to securely
`store hash values that represent platform con-
`figuration information. The secure reporting
`of these values, if authorized by the platform
`owner, enables verifiable attestation of a plat-
`form configuration. Data can also be protected
`under these values, requiring the platform to be
`in the same configuration to access the data as
`when 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 off
`functionality, reset the TPM, and take owner-
`ship of the TPM. There are strong controls to
`protect the privacy of an owner and user.3 The
`platform owner must opt-in. Any user, even if
`different from the owner, may opt-out.
`
`Each TPM contains a unique Endorsement
`Key. This key can be used by a TPM owner
`to anonymously establish Attestation Identity
`Keys (AIKs). Since privacy concerns prevent
`the Endorsement Key from being used to sign
`data generated internally by the TPM, an AIK
`is used. An AIK is an alias to the Endorsement
`Key. The TPM owner controls the creation and
`activation of an AIK as well as the data associ-
`ated with the AIK.[TCGMain],[TPM]
`
`3See Section 7.1 for more details.
`
`App/
`TPM Mgmt
`
`PKCS#11
`
`App
`
`TSS
`
`Linux
`Kernel
`
`Kernel
`Measurement
`
`TPM DD
`
`Boot
`Loader
`
`BIOS/Firmware
`
`Hardware
`Platform
`
`TPM
`
`4
`
`

`

`2005 Linux Symposium • 95
`
`4.1.1 A Software-based TPM Emulator for
`Linux
`
`4.2 TPM Device Driver
`
`If you don’t have a machine that has a TPM but
`you’d like to start experimenting with Trusted
`Computing and the TSS API, a software TPM
`emulator can provide a development environ-
`ment in which to test your program. While a
`software 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 introduced
`without being noticed. There must be an ini-
`tial “trusted” measurement established, known
`as the root of trust for measurement, and the
`measurement “chain” must not be interruped.
`
`With a software TPM emulator, you have de-
`layed the initial measurement long into the boot
`cycle of the system. Many measurements have
`not occurred and so the trust of the system can
`not be fully validated. So while you would not
`want to rely on a software TPM to validate the
`trust of your systemm, it does provide you with
`a development environment to begin preparing
`to take advantage of trusted computing.
`
`Mario Sasser, a student at the Swiss Federal
`Institute of Technology has created a TPM em-
`ulator that runs as a kernel module.[Strasser]
`It
`is not a full
`implementation of
`the
`specification and it
`is still under develop-
`ment.
`It is available from http://www.
`infsec.ethz.ch/people/psevinc/
`or https://developer.berlios.de/
`projects/tpm-emulator.
`
`The TPM device driver is a driver for the Linux
`kernel to communicate TPM commands and
`their results between the TCG Software Stack
`(TSS) and the TPM device. Today’s TPMs are
`connected to the LPC bus. The TPM hardware
`is located by the driver from the PCI device for
`the LPC bus and attempts to read manufacturer
`specific information at manufacturer specific
`offsets from the standard TPM address. Since
`the TPM device can only handle one command
`at a time and the result must be cleared before
`another command is issued, the TPM device
`driver takes special care to provide that only
`one command is in-flight at a time and that the
`data is returned to only the requester. Rather
`than 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. Then
`the result is copied to the same user on a sub-
`sequent read call. This coupling of write and
`read calls is enforced by locks, the file struc-
`ture’s private data pointer and timeouts. At
`the direction of the Trusted Computing Group
`Specification, the TSS is the only interface al-
`lowed to communicate with the TPM thus, the
`driver only allows one open at a time, which is
`done by the TSS at boot time. The driver al-
`lows canceling an in-flight command with its
`sysfs file cancel. Other sysfs files provided
`by the driver are pcrs for reading current pcr
`values, caps for reading some basic capability
`information about the TPM such as manufac-
`turer and version and pubek for reading the
`public portion of the Endorsement Key if al-
`lowed by the device. The current driver sup-
`ports the Atmel and National Semiconductor
`version 1.1 TPMs, which are polled to deter-
`mine when the result is available. The com-
`mon functionality of the driver is in the tpm
`kernel module, and the vendor specifics are
`in a separate module. The driver is available
`on Sourceforge at http://sourceforge.
`
`5
`
`

`

`96 • Trusted Computing and Linux
`
`net/projects/tpmdd/ under the project
`name tpmdd and has been in Linux kernel ver-
`sions since 2.6.12.
`
`4.3 TSS
`
`The TCG Software Stack (TSS) is the API that
`applications use to interface with the TPM.
`
`4.3.1 TSS Background
`
`The TCG Software Stack (TSS)[TSS] is the set
`of software components that supports an ap-
`plication’s use of a platform’s TPM. The TSS
`is composed of a set of software modules and
`components that allow applications to commu-
`nicate with a TPM.
`
`The goals of the TSS are:
`
`• Supply one entry point for applications to
`the TPM’s functionality. (Provided by the
`TSS Service Provider Interface (The TSS
`API)).
`• Provide synchronized access to the TPM.
`(Provided by the TSS Core Services Dae-
`mon(TCSD)).
`• Hide issues such as byte ordering and
`alignment from the application.
`(Pro-
`vided by the TSS Service Provider Inter-
`face (TSPI)).
`• Manage TPM resources. (Provided by the
`TCSD).
`
`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 API
`are:
`
`• RSA key pair generation
`• RSA encryption and decryption using
`PKCS v1.5 and OAEP padding
`• RSA sign/verify
`• Extend data into the TPM’s PCRs and log
`these 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 and
`remote TCS daemons, which manage the re-
`sources of an individual TPM.
`
`4.3.2 The TrouSerS project
`
`The TrouSerS project aims to release a fully
`TSS 1.1 specification compliant stack, follow-
`ing up with releases for each successive release
`of the TSS spec. TrouSerS is released under
`the terms of the Common Public License, with
`a full API compliance test suite and example
`code (both licensed under the GPL) and docu-
`mentation. TrouSerS was tested against the At-
`mel TPM on i386 Linux and a software TPM on
`PPC64. TrouSerS is available in source tarball
`form and from CVS at http://trousers.
`sf.net/.
`
`4.3.3 Technical features not in the TSS
`specification
`
`By utilizing udev.permissions for the TPM de-
`vice file and creating a UID and GID just for
`the TSS, the TrouSerS TCS daemon runs with-
`out root owned resources.
`
`6
`
`

`

`For machines with no TPM support in the
`BIOS, TrouSerS supports an application level
`interface to the physical presence commands
`when the TCS daemon is executing in sin-
`gle user mode. This allows administrators to
`enable, disable, or reset their TPMs where a
`BIOS/firmware option is not available. This in-
`terface is automatically closed at the TCS level
`when the TCS daemon is not running in single
`user mode, or cannot determine the run level of
`the system.
`
`In order to maintain logs of all PCR extend
`operations on a machine, TrouSerS supports a
`pluggable interface to retrieve event log data.
`Presumably, the log data would be provided by
`the Integrity Measurement Architecture (IMA)
`(see Section 4.6 below). As executable content
`is loaded and extended by the kernel, a log of
`each extend event is recorded and made avail-
`able through sysfs. The data is then retrieved
`by the TCS Daemon on the next GetPcrEvent
`API call.
`
`To maintain the integrity of BIOS and ker-
`nel controlled PCRs, TrouSerS supports con-
`figurable sets of PCRs that cannot be extended
`through the TSS. This is useful; for example in
`keeping users from extending BIOS controlled
`PCRs or for blocking access to an IMA con-
`trolled PCR.
`
`TCP/IP sockets were chosen as the interface
`between TrouSerS’ TSP and TCS daemon, for
`both local and remote access. This makes con-
`necting to a TCSD locally and remotely essen-
`tially the same operation. Access control to the
`listening socket of the TCSD should be con-
`trolled with firewall rules. Access controls to
`the TCSD’s internal functionality was imple-
`mented as a set of ‘operations,’ each of which
`enable a set of functions to be accessible to a
`remote user that will enable that user to accom-
`plish the operation. For instance, enabling the
`seal operation allows a remote user to open and
`close a context, create authorization sessions,
`
`2005 Linux Symposium • 97
`
`load a key, and seal data. By default, all func-
`tionality is available to local users and denied
`to remote users.
`
`4.4 TPM Management
`
`Some TPM management functionality was im-
`plemented in the tpm-mgmt package and the
`openCryptoki 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 is
`provided in the openCryptoki package.
`
`4.4.1 Controlling the TPM
`
`The owner of the platform has full control of
`the TPM residing on that platform. A TPM
`maintains three discrete states: enabled or dis-
`abled, active or inactive, and owned or un-
`owned. The platform owner controls setting
`these 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 mainly
`of self-test functions, capability functions and
`non-volatile storage functions. In order to take
`full advantage of the TPM, the platform owner
`must enable, activate, and take ownership of the
`TPM. Enabling and activating the TPM is typ-
`ically performed using the platform BIOS or
`firmware.
`If the BIOS or firmware does not
`provide this support, but the TPM allows for
`the establishment of physical presence through
`software, then TrouSerS can be used to estab-
`lish physical presence and accomplish the task
`of enabling and activating the TPM. Taking
`
`7
`
`

`

`98 • Trusted Computing and Linux
`
`ownership of the TPM sets the owner password,
`which is required to execute certain commands.
`
`• PKCS#1 RSA signature with SHA-1 or
`MD5
`
`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 devices
`are represented as tokens, which provide appli-
`cations a common way of viewing and access-
`ing the functionality of the device. Providing
`a PKCS#11 interface allows applications that
`support the PKCS#11 API to take advantage of
`the TPM immediately.
`
`The TPM PKCS#11 interface is implemented
`in the openCryptoki package as the TPM to-
`ken. Each user defined to the system has their
`own private TPM token data store that can hold
`both public and private PKCS#11 objects. All
`private PKCS#11 objects are protected by the
`TPM’s root of trust for storage. A symmet-
`ric key is used to encrypt all private PKCS#11
`objects. The symmetric key is protected by
`an asymmetric TPM key that uses the user’s
`PKCS#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 to
`use a private PKCS#11 object. The TPM token
`provides key generation, encryption and signa-
`ture operations through the RSA, AES, triple
`DES (3DES), and DES mechanisms.
`
`The following RSA mechanisms are supported
`(as defined in the PKCS#11 Cryptographic To-
`ken Interface Standard[PKCS11]):
`
`The following mechanisms are supported
`AES, 3DES, and DES (as defined in the
`PKCS#11 Cryptographic Token
`Interface
`Standard[PKCS11]):
`
`• Key generation
`• Encryption and decryption in ECB, CBC
`or CBC with PKCS padding modes
`
`The RSA mechanisms utilize the TSS to per-
`form the required operations. By utilizing the
`TSS, all RSA private key operations are per-
`formed securely in the TPM. The symmetric
`mechanisms are provided to allow for the pro-
`tection of data through symmetric encryption.
`The symmetric key used to protect the data is
`created on the TPM token and is thus, protected
`by the TPM. Since the key is protected by the
`TPM, the data is protected by the TPM.
`
`Before any PKCS#11 token is able to be used
`it must be initialized. Since each user has their
`own TPM token data store, each user must per-
`form this intialization step. Once the data store
`is initialized it can be used by applications sup-
`porting the PKCS#11 API.
`
`The tpm-mgmt package contains commands to
`initialize the TPM token data store as well as
`perform other tasks. Some of the other tasks
`are:
`
`• Import X509 certificates and/or RSA key
`pairs
`
`• PKCS#1 RSA key pair generation
`• PKCS#1 RSA
`
`Existing certificates and/or key pairs
`can be stored in the data store to be
`used by applications.
`
`8
`
`

`

`• List the PKCS#11 objects in the data store
`
`In addition to any objects that you im-
`port, applications may have created
`or generated objects in the data store.
`tpm-mgmt lets you get a list of all
`the PKCS#11 objects that exist in the
`data store.
`
`• Protect data using the “User Data Protec-
`tion Key”
`
`Protect data by encrypting it with a
`random 256-bit AES key. The key is
`created as a PKCS#11 secret key ob-
`ject with an label attribute of “User
`Data Protection Key.” This label at-
`tribute is used to obtain a PKCS#11
`handle to the key and perform en-
`cryption, or decryption operations on
`the data.
`
`• Change the PKCS#11 PINs (Security Of-
`ficer and User)
`
`PKCS#11 tokens have security offi-
`cer and a user PINs associated with
`them. It may be necessary or desir-
`able to change one or both of these
`PINs at some point in time.
`
`4.5 Boot Loader
`
`To preserve the chain of trust beyond the boot
`loader, the boot loader must be instrumented to
`measure the kernel before it passes over con-
`trol. The root of trust for measurement mea-
`sured the BIOS before it transferred control, the
`BIOS measured the boot loader. Now the boot
`loader must measure the kernel. Seiji Mune-
`toh and Y. Yamashita of IBM’s Tokyo Research
`
`2005 Linux Symposium • 99
`
`Lab have instrumented Grub v.0.94 and v.0.96
`to perform the required measurements. Since
`Grub is a multi-stage boot loader, each stage
`measures the next before it transfers control.
`This is a slight simplification. Stage 1 is mea-
`sured by the BIOS. Stage 1 measures the first
`sector of stage 1.5, which then measures the
`rest of stage 1.5 and stage 2. The configuration
`file is measured early with additional measure-
`ments of files referred to in configuration files
`taken 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 stage
`2. The grub measurements are stored in PCR
`4, the grub configuration file measurement is
`stored in PCR 5, and the kernel measurement
`is stored in PCR 8. The PCRs used are config-
`urable but the defaults meet the requirements
`of the TCG PC Specific Implementation Speci-
`fication Version 1.1[TCGPC].
`
`Lilo has also been instrumented to take the
`measurements by the Dartmouth Enforcer
`team.
`(See more detail about this project in
`Section 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 chain
`of trust to the Linux kernel by implementing
`a measurement architecture for the kernel as
`a LSM.[SailerIMA] (Note: To effectively pre-
`serve the chain of trust, the LSM must be com-
`piled into the kernel rather than dynamically
`loaded.) The file_mmap hook is used to
`perform the measurement on anything that is
`mapped executable before it is loaded into vir-
`tual memory. Kernel modules are measured
`just before they are loaded. The measurement
`is used to extend one of the PCRs numbered
`between 7-16, as configured in the kernel to
`allow for somewhat flexible PCR use. PCR 9
`
`9
`
`

`

`100 • Trusted Computing and Linux
`
`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 are
`cached to reduce performance impact. Perfor-
`mance, usability, and bypass-protection are all
`addressed in the Sailer, et al. report. Enforce-
`ment is not part of this architecture. The mea-
`surements (and measurement log) are intended
`to 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 Linux
`Now and in the Future
`
`Although version 1.1 TPMs provide many fea-
`tures usable today, significant hurdles exist to
`deploying the full capabilities of Trusted Com-
`puting outside a structured or corporate envi-
`ronment. Software that exists today basically
`enables the use of a TPM as one would use a
`smartcard. Other features, such as remote attes-
`tation, have more extensive requirements. The
`components required to implement remote atte-
`sation can be seen in Figure 3.
`
`In order to implement remote attestation, TPM
`and Platform Vendor Support is required to:
`
`• Put TPM support in the BIOS of shipping
`platforms (currently shipping).
`• Record the Public Endorsement Key in
`some way (such as make a cryptographic
`hash) in order to identify whether a plat-
`form has a true TPM.
`• Create and ship the TPM credential and
`the platform credential.
`
`Figure 3: Dependencies for Full Trusted Com-
`puting Deployment
`
`As long as the platform vendor has included
`TPM support in the BIOS, a corporate envi-
`ronment can work around the lack of the other
`elements by recording the PubEK as machines
`are deployed and maintaining a PKI internally.
`However, in order to enable remote attestation
`for general use by the public, a new infras-
`tructure among hardware and software vendors
`must be created. This infrastructure would pro-
`vide the credentials and a hash of the PubEK
`of shipping systems to Privacy CAs. The Pri-
`vacy CAs differ from existing CAs in the key
`creation, certificate application, and certificate
`delivery mechanism, so new CAs are needed or
`existing CAs must implement the required soft-
`ware and procedures. At best, shipping plat-
`forms that fully support remote attestation are
`years away. Because of the lack of this infras-
`tructure, no currently shipping platforms will
`have the capability to provide remote attesta-
`tion for general use.
`
`To make use of the more advanced features the
`TPM can provide, in addition to the infrastruc-
`ture element listed above, a Linux distro would
`need to:
`• Incorporate the measurement architecture
`
`TPM / Platform Vendor
`Support
`
`TPM
`BIOS Support
`
`Record of PubEK
`at manufacture time
`
`Credentials supplied
`to End Users
`
`TSS Stack
`TSS Stack
`
`Operating System
`PCR extend support
`
`Operating System
`boot loader support
`
`Privacy CA
`
`Supported (GA)
`
`Supported on some 
`platforms
`
`Creation of
`Attestation Identity Key
`
`Remote Attestation
`
`10
`
`

`

`2005 Linux Symposium • 101
`
`into the kernel.
`• Ship measurement support for the boot
`loader.
`• Include TrouSerS or some TCG Software
`Stack.
`• Include attestation software.
`• Include software for safe handling of the
`TPM and Platform credentials.
`
`TPM in Enterprise Security”[Sailer] for more
`discussion around this topic. Anonymous notes
`in the first article “Before wide-scale use of TC
`for DRM, it will be necessary for the manufac-
`turers, software vendors and content providers
`to get past a few tiny details, like setting up
`a global, universal, widely trusted and secure
`PKI. Hopefully readers . . . will understand that
`this is not exactly a trivial problem.” The uses
`discussed below do not depend on full deploy-
`ment of a complete Trusted Computing infras-
`tructure but only on existing capabilities.
`
`When this level of TPM hardware support is
`achieved, the groundwork will be laid to enable
`the software that will be used for attestation.
`Ideas for an interoperable attestation interface
`include a stand-alone attestation daemon and a
`modified TLS protocol that includes attestation.
`Until one of these solutions is specified and im-
`plemented, attestation solutions are ad hoc at
`best.
`
`Finally, before general purpose remote attesta-
`tion can be widely used, tools and best practice
`guidelines are needed to help define valid poli-
`cies and maintain policy currency. Depending
`on the measurement architectures implemented
`by 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, the
`decision about its usefulness rests almost en-
`tirely on how one will use the device. Many of
`the doomsday scenarios surrounding the TPM
`device are based on scenarios involving soft-
`ware that Linux users will never agree to run
`on their hardware. In this section, some of the
`most promising uses of the TPM device are ad-
`dressed. See also “Interesting Uses of Trusted
`Computing”[Anonymous] and “The Role of
`
`6.1 Beyond Measurement –Enforcement
`
`A couple of examples of how the Trusted Com-
`puting measurements can be used to enforce a
`security policy exist and are described in this
`section.
`
`6.1.1 Dartmouth’s Enforcer
`
`Enforcer is an LSM that measures each file
`as 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 sealed
`to this PCR fail) based on the setting se-
`lected by the administrator. Enforcer does
`not require a TPM, but can optionally use the
`TPM to protect the database and configura-
`tion files. Enforcer also provides helper,
`which allows encrypting a loopback file system
`with a key protected by the TPM. Enforcer is
`available at http://sourceforge.net/
`projects/enforcer/.
`
`11
`
`

`

`102 • Trusted Computing and Linux
`
`6.1.2 Trusted Linux Client
`
`The IMA kernel measurement architecture de-
`scribed previously provides no direct enforce-
`ment mechanisms. Dave Safford of IBM’s
`T.J. Watson Research Center has proposed
`an 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 attribute
`checking. The first module validates the in-
`tegrity of initrd and the kernel, and releases
`a TPM based kernel symmetric key. The key
`is 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, MAC
`label, and others. The derived symmetric key is
`used to HMAC these attributes, and the value is
`checked and cached once at open/execute. A fi-
`nal module provides LOMAC style mandatory
`access control. See the presentation ’Putting
`Trust
`into Computing: Where does it Fit?
`—RSA Conference 2005’ for an overview of
`this 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.
`
`employees to take mobile computing devices
`on the road and connect to non-protected net-
`works. Viruses very often use unprotected mo-
`bile devices as a gateway device through which
`to invade corporate net