On Thu, Jun 23, 2011 at 4:21 PM, JB <jb.1234abcd(a)gmail.com> wrote:
I have done some inventory on this topic, and have some questions.
I'm not really an expert on this... Hopefully someone will correct my mistakes.
Why do you need Trusted Boot mechanism to ensure that identified and
verified Linux kernel is booted ?
Why signing a kernel (a la GPG) is not good enough to verify its origin at
boot time ?
The TPM allows verifying that this kernel (and only this kernel) is
actually running. An attacker with access to the hard drive ("evil
maid") can modify the code to disable any signature check that would
be done in software (e.t. inside grub); TPM cannot be bypassed this
Now, regarding the Trusted Boot solution.
The obvious question:
why does an open-source distro like Fedora (but also Red Hat) want to
philosophically accept and technically support this solution ?
All a properly
deployed TPM does is, it verifies that a specific
software is running on the system, and if so, it allows the OS to use
some cryptographic keys stored inside the TPM. This could be used for
various things - yes, one of them is DRM. Something more useful is
only allowing a computer into the "secure" company network after the
TPM has testified that it does not have a rootkit running.
Note that none the keys in TPM are not pre-loaded by any distrusted
software company - each TPM generates its own keys.
Also note that the TPM does not, itself, stop any software from
running, or disconnect anything from a network, and so on - this needs
to be done outside of the TPM, using mechanisms that (mostly) already
exist anyway (e.g. a network switch that only connects devices that
authenticate with a password).
(From a practical standpoint, AFAICS it would be _much_ easier to set
up the network access restriction by an IT department than to set up
DRM by a world-wide software vendor - I can't see how would one even
start to build the list of allowed configurations of all
general-purpose computers, which would be necessary for the DRM.)
Will the TPM allow a third party remote access to the machine ?
Will the TPM be BIOS-configurable (enable/disable) by the user
AFAIK it usually is so in existing BIOSes - but if you don't use the
TPM, it really doesn't affect anything; it's just like an unused sound
How is that tboot blob module secured from tampering ?
signed by the CPU/TPM manufacturer (Intel in this case).
By the virtue of beeing associated with the "root of trust"
"Root of trust" in TPM lingo is something different - it's "we
that the kernel and related software we run has not been tampered
with". The root of trust is established by the tboot blob, which
should verify the state of all relevant hardware.
If the Launch Control Policy can be created and modified by the user,
what prevents an attacker from impersonating the usersysadmin, modifying
the policy, and causing a denial-of-boot or unintended-boot attack ?
sure whether it is actually possible to set up LCP so that the
boot doesn't continue at all. Assuming that it is so...
1) If the LCP did not require a signed kernel, and the attacker has
modified it to require a signed kernel, this is not really different
from an attacker deleting /boot. If an attacker has root access,
denial of service is the smallest of your problems.
2) If the LCP required a signed kernel, and the attacker has somehow
managed to configure the system to boot a different kernel (without
getting complete root access), then "denial of boot" would be
considered a success - the policy has worked exactly as the sysadmin
The big question here is kernel upgrades - there has to be a mechanism
to replace the old "allowed" kernel by a newer version, and I don't
know how that is supposed to work. And assuming an attacker with root
access, it might be possible for the attacker to use this upgrade
mechanism to let the system boot a modified kernel without violating
tcsd is compatible with the IBM Research TPM device driver available
and the TPM device driver
available from http://sf.net/projects/tmpdd
Are these drivers open-source ? Is TPM device driver open-source ?
seems to contain a few open-source drivers for the hardware. AFAIK
none of the required drivers are binary-only.