TPM & disk crypto

[cyphrpunk]

On 10/13/06, Kuehn, Ulrich <Ulrich.Kuehn at telekom.de> wrote:
> With reliably stopping the boot process I mean the following: Given that
> stage i of the process is running, it takes the hash of the next stage,
> compares that to an expected value. If they match, the current stage extends
> the TPM register (when also running the TCG stuff), and executes the next
> stage. If the computed and expected hashes do not match, the machine goes
> into a predetermined halt state.
>
> Predetermined means that the system administrator (on behalf of the system
> owner) can determine the expected hash value.

You don't need the TPM for this. You could imagine a boot process
where each stage hashed the next stage, and refused to proceed if it
didn't match an expected value. One question though is how you prevent
malware from changing these expected values, even potentially
reflashing the BIOS.

A student project at Dartmouth a few years ago,
enforcer.sourceforge.net, worked like this. It could also optionally
use a TPM but didn't have to. The project appears to be abandoned but
the supervising professor, Sean Smith, in his book Trusted Computing
Platforms says that new students are bringing it up to date, getting
it working with newer kernels including selinux support.

Here's the Enforcer description. Nice piece of work. Hopefully they'll
release an updated version now that TPMs are more common.

"The Enforcer is a Linux Security Module designed to improve integrity
of a computer running Linux by ensuring no tampering of the file
system. It can interact with TCPA hardware to provide higher levels of
assurance for software and sensitive data.

"It can check, as every file is opened, if the file has been changed,
and take an admin specified action when it detects tampering. The
actions can be any combination of log the error, deny access to the
file, panic the system, or several operations that work with the TPM.

"The Enforcer can also work with the TPM to store the secret to an
encrypted loopback file system, and unmount this file system when a
tampered file is detected. The secret will not be accessible to mount
the loopback file system until the machine has been rebooted with
untampered files. This allows sensitive data to be protected from an
attacker.

"The Enforcer can also bind specific files so that only specific
applications can access them (for example, only apache is allowed to
access apache's secret ssl key). This means that even if someone
compromises your system, the attacker will not be able to steal
critical files.

"Finally, the Enforcer can make sure that no files added to
directories after its database is built are allowed to be accessed."

One thing they worked hard on in the design is the balance between
detecting malicious changes, and allowing necessary changes for
maintenance and upgrades. They identified different classes of
components that were updated seldom, occasionally or frequently, and
architected the system to provide an appropriate degree of checking
for each category. The academic paper is here:

http://www.cs.dartmouth.edu/~sws/abstracts/mswm03.shtml

CP

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com