The Integrity Measurement Architecture [LWN.net]

One of the many new features in the 2.6.11 kernel was a driver for "trusted platform module" (TPM) chips. This driver made the low-level capabilities of TPM chips available, but gave no indication of what sort of applications were envisioned for those capabilities. Reiner Sailer of IBM has now taken the next step with a set of patches implementing the "Integrity Measurement Architecture" (IMA) for Linux using TPM.

IMA is a remote attestation mechanism, designed to be able to convince a remote party that a system is running (nothing but) a set of known and approved executables. It is set up as a security module, and works by hooking into the mmap() operation. Whenever a file is mapped in an executable mode (which is what happens when a program is run or a sharable library is mapped), the IMA hook will first perform and save an SHA1 hash of the file. On request, the IMA module can produce a list of all programs run and their corresponding hash values. This list can be examined by a (possibly remote) program to ensure that no unknown or known-vulnerable applications have been run.

If a hostile application has managed to take over the system, however, it will be in a position to corrupt the list from the IMA module, rendering that list useless. This is where the TPM chip comes in. The TPM contains a set of "platform configuration registers" (PCRs) which are accessible to the the rest of the system only in very specific ways. The PCRs can be reset to zero only when the system hardware itself is reset. The host system can pass data to the TPM which is to be included in a given PCR; the TPM then computes a hash with the new information and stores the value in the PCR. A given set of values, if sent to a PCR in any order, will, at the end, yield the same final hash value. The TPM can provide that value on request; it can also be made to sign the hash value using a top-secret key hidden deeply within its tamper-proof packaging.

The IMA module works by sending each hash it computes to a PCR on the TPM chip. When it provides the list of executables and hash values, it can also obtain and hand over a signed hash from the TPM. A remote party can then recompute the hash, compare it to what the TPM produced, and verify that the provided list is accurate. It is still possible for an intruder to corrupt the list, but it will then fail to match the hash from the TPM. It thus should be possible to remotely detect a compromised system.

Of course, if an attacker can gain control of the kernel at boot time, before the IMA module has been initialized, the entire battle has been lost. The TPM designers have thought of this possibility, however; it is possible to set up hardware so that it will not boot a system in the first place unless the TPM approves of the code to be booted.

There are numerous possible applications of this sort of capability. In a highly secured network, systems could refuse to talk to each other until each proves that it is running only approved software. Financial web sites could, if given access to this information, refuse access from systems running browsers with known security problems. The less flexible sort of Linux support provider could refuse to work on systems which have run programs which are not on The List Of Supported Applications. Corporate IT departments could get verifiable lists of which programs have run on each system. DRM-enabled software could refuse to unlock its valuable intellectual property if the system looks suspicious. And so on.

In the short term, however, this code looks like it will need some work before it will be considered seriously for inclusion. James Morris has questioned the security module implementation, arguing that this functionality should be implemented directly in the kernel. Loading the IMA module also makes it impossible to use any other security module (such as SELinux), which may not enhance the overall security of the system. And Greg Kroah-Hartman was unimpressed with the quality of the code in general:

Wow, for such a small file, every single function was incorrect. And you abused sysfs in a new and interesting way that I didn't think was even possible. I think this is two new records you have set here, congratulations.

The IMA authors have now gone off to rework things. At some point, however, it seems likely that this sort of functionality will be available in Linux. Whether it will then be used to increase or restrict the freedom of Linux users remains to be seen.

(For more information, see the IBM tcgLinux and Trusted Computing Group pages).

(Log in to post comments)

The Integrity Measurement Architecture

Posted May 28, 2005 17:57 UTC (Sat) by stephen_pollei (guest, #23348) [Link]

Pavel Machek <pavel@ucw.cz> made the same kind of objection on lkml saying "What is it good for, then? So I have to put my backdoor into script, not into an executable...".
Reiner Sailer <sailer@us.ibm.com> replied Scripts can be measured as well (from the user space). For example, equipping the bash shell with 5-10 lines of code, bash initiates IMA measurements on scripts and files that are sourced into bash before they are "executed" by bash. This way, startup scripts and executed scripts can be logged as measurements and the measuremnt list will include them.
That led to more talk about lots of things and with Pavel concluding Well, you'll have to add measurement of any security-sensitive config file, any script, and will have to make sure that all parsing of system config files does not contain buffer-overrun problems. That's lot of work before IMA is usefull. It is true you do not make situation any worse.
What I wonder is if you can measure arbritary files from userspace what is to stop you from using altered scripts but also having the valid scripts put into the list?

The Integrity Measurement Architecture

Posted Jun 2, 2005 20:48 UTC (Thu) by zakaelri (guest, #17928) [Link]

Do you mean "How do you prevent the exploit of registering A while runnning B?"? If so, read on...

First off. TPM makes a few fundamental assumption about it's use: If [everything loaded before A] is valid, and A appears valid, then A is valid. If A is valid, than A can be truested.

Basically, they check to make sure that every program that runs has not been modified from the version used to build the original hash. This includes the BIOS, the bootloader, the kernel, init, etc.

So, given that assumption:

If you add the TPM code to (say) bash, and bash is valid, then you know that any script run by bash will be verified by the TPM. Why? Because if the TPM code was changed, bash wouldn't be valid. (When the kernel loads bash, it would fail the check). As long as the script passed, you know it's safe to run.

So, unless there was a security hole programmed into bash, you wouldn't need to worry about it running 1 script while verifying another.

The Integrity Measurement Architecture

Posted May 28, 2005 19:03 UTC (Sat) by Ross (guest, #4065) [Link]

Presumably you would just lie to the hardware that does the checksums. It
has no way to verify what you tell it is valid and will end up signing bad
data. Normally this wouldn't be possible because untrusted code isn't
allowed to run, and even if it did, it would corrupt the secret state
information. All bets are off when the untrusted code is in charge from the
start. But maybe I misunderstand.

The Integrity Measurement Architecture

Posted Jun 2, 2005 8:51 UTC (Thu) by emj (guest, #14307) [Link]

Since you start loading the PCRs when you use GRUB you can be assured that the boot block where grub resides is ok and that the kernel that GRUB loads is ok.

But it all hangs on the weakest link during startup, if you manage to crack the bootup process to insert your own code then: Yes you can fool TCPA/TPM. But as long as you can load the kernel and there's no root exploit in it, you will have a verifiable environment.

The TCPA chip of course rely alot on the human administrating the computer. You need to lock it down alot to make this work.

The measurement taken

Posted Jun 2, 2005 8:53 UTC (Thu) by emj (guest, #14307) [Link]

These are the steps when booting:

http://www.research.ibm.com/secure_systems_department/pro...

Doesn't do so much for remote verification

Posted May 28, 2005 14:30 UTC (Sat) by jvotaw (subscriber, #3678) [Link]

If I understand correctly, the system boils down to securely computing a hash of all programs run on a machine, signing it, and reporting it. A remote party, such as a publisher or bank, refuses to communicate with you unless you're only running software that will look after the data (intellectual property, financial data, whatever).

The reporting step seems to be the weakest link. If you want to steal intellectual property, simply run your machine once in the secure mode and record the signed hash as it is transmitted. Reuse that value in the future as needed. The same approach works if the attacker is a thief and the remote party is your bank: the thief records the correct signed hash on an uncompromised system and forces your (compromised) system to return it.

This may be more or less difficult if there are race conditions in IMA, there are available computers that can eavesdrop, the TPM's key is unique per computer, or your connection to the remote party is encrypted. I can think of a few things that would probably solve the problem completely, but it's not clear if the authors have considered them.

Or am I confused and missing something important?

-Joel

Doesn't do so much for remote verification

Posted May 28, 2005 17:32 UTC (Sat) by stephen_pollei (guest, #23348) [Link]

Reiner Sailer <sailer@us.ibm.com> on the LKML has said "You retrieve not only the measurement list from a system (kernel) but also a signature over the TPM PCR holding the integrity value. Nonces (random numbers) are used to protect against replay of old signed TPM PCR contents by the kernel. Since PCR is signed inside the TPM together with the nonce, corrupt system software can't cheat unnoticedly.". So it seems they have thought of replay attacks.

Doesn't do so much for remote verification

Posted May 28, 2005 19:09 UTC (Sat) by Ross (guest, #4065) [Link]

However they can't protect against an untrusted system feeding the hardware
the checksums that would exist, in the correct order, on a trusted system.
The untrusted system simply lies to itself. Unless this hardware actually
scanned through all of RAM I don't see how it could avoid this -- it relies
on something external to perform the checksums.

Thus the remote attestation feature can only be trusted when the system is
not compromized before running the trusted IMA module, which is a severe
limitation when you are talking about systems that people have physical
access to.

Weak

Posted Jun 2, 2005 20:57 UTC (Thu) by zakaelri (guest, #17928) [Link]

The trusted computing folk can get around this by prohibiting gdb

Presumably, the trusted computing folks would not have gdb installed on a secure machine--gdb is inheirently insecurable from their perspective. The entire suite of dev tools is usually the first thing removed from a secure system.

Also, you could use strip to remove the symbols from your binaries. That would make it nigh impossible to find anything with gdb.

Weak

Posted Nov 17, 2005 9:48 UTC (Thu) by pkolloch (guest, #21709) [Link]

> Also, you could use strip to remove the symbols from your binaries. That would make it nigh impossible to find anything with gdb.

Well, only statically linked stuff, or? Any symbol references to dynamically linked libraries remain clearly visible. Ok, ok, from a strict security point of view, dynamic linking has its own large set of issues.