[linux-elitists] defanging TCPA?
Thu Feb 6 18:44:06 PST 2003
On Thu, 6 Feb 2003, Seth David Schoen wrote:
> Jay Sulzberger writes:
> > Just one quick note: Assume you are running on fully Palladiated hardware.
> > Further assume that one of the kernels on your disk is a kernel with an
> > Englobulator signature. Then you cannot modify even one bit of that kernel
> > without making the kernel either unbootable and/or unable to run certain
> > Englobulator signed programs, programs which are to deliver "DRMated
> > content". Some variants of Palladium style systems would make it
> > impossible even to change one bit of the on-disk kernel. This is so, even
> > if you load your own fine free kernel to do/attempt-to-do the modification.
> You have to slightly stretch the definition of "unable to run" here,
> but I thought Don _expected_ that outcome (breaking the functionality
> of certain DRM applications).
Well, there is no final specification of "Palladium" nor any running
complete implementation, and I believe that using the Palladiated hardware
to stop an encrypted Englobulator signed kernel from booting will be one
mechanism used by many implementations of the broad Palladium body plan to
enforce DRM. Naturally, there may also be available the "boot but do not
attest" capability too. The format of the kernel blob might include two
different flags: the "do not boot" flag and also the "boot but do not
> The particular effect on the applications' functionality is that they
> become unable to receive and/or unable to display certain third-party
> information. Don, isn't that the outcome you were anticipating?
Yes, I agree, and mentioned that a modification of an Englobulator signed
kernel/application might indeed boot/start, but then fail to attest.
> If a DRM system is implemented with good security engineering
> practices, it should "fail safe". From the point of view of the
> people whose interests DRM systems are actually intended to protect,
> failing safe means not functioning at all in an environment which is
> determined to be significantly different from the intended operating
>  Heh heh.
> Seth David Schoen <firstname.lastname@example.org> | Reading is a right, not a feature!
Yes, I agree and to repeat for the sake of repetition: The standard safest
way to achieve total Englobulator control is to set the "do not boot if
modified" flag on most home users' Microsoft signed kernels. The fineness
of control needed for a "boot but do not attest" defense against the user,
and the natural concomitant ability of the user to run
un-[Englobulator-signed] code on top of a modified kernel, offers too many,
and mostly unknown, points of attack by the user against the Englobulated
system. So my guess is that, if Microsoft ever rolls out a full
Palladiated system, the main defense against the user will be the "do not
boot" defense rather than the "boot but do not attest" defense. I admit
that careful design of software by Microsoft is unusual, but in this case
the standard literature is so screamingly tilted toward "do not boot" that
I think even Microsoft will be conservative in their design.
More information about the linux-elitists