Intel to include DRM in new Pentium 4 series processors

[Brian Gladman]

From: "Pete Chown" <1@234.cx>
To: <ukcrypto@chiark.greenend.org.uk>
Sent: Friday, September 13, 2002 3:33 AM
Subject: Re: Intel to include DRM in new Pentium 4 series processors


> Brian Gladman wrote:
>
> > It is true that a company can take GPL'd software and provide it in a
form
> > that allows the user to say that it is _this_ particular version of the
> > software that they want to run.
>
> I don't have a problem with this.  I would have a problem if this was
> extended over the network, so the program could satisfy its peers that
> it was unmodified.  With some programs this would remove your ability to
> modify the code in any meaningful sense, since it would become useless.
>
> Are you saying that TCPA can do this, but you don't mind, or that TCPA
> actually cannot do this?

My comments here were only directed at what TCPA can do for the PC owner,
who may or may not utilise these services remotely via a network.

If the PC owner agrees, I believe that TCPA can be used to signal trusted
metrics over a network to a remote agent who is not the owner.   I see this
in broadly the same light as I see the DRM features - that is the PC owner's
control of any such reporting, if used by appropriately by an informed
owner, should be enough to protect their interests.  I can certainly see
situations where such a capability would be valuable and I would not want to
see this eliminated from the TCPA architecture.

> > A key feature of TCPA is that, subject to the PC owner's permission,
remote
> > agents can set up 'trusted boxes' for their use on an owner's PC.
>
> There has been a lot of talk about the implications of this for systems
> like DRM, but I wonder how practical it is too.  Imagine the scenario --
> a critical computer system fails, but the security policy won't let you
> find out why.  Are IT managers going to tolerate this?  I know I would
> be very reluctant.  A system with mandatory access controls is one
> thing, but you need to be able to override them if you have to.
>
> > (c) At the point of a contract between a PC owner and such an agent
(e.g. a
> > software supplier) the full consequences of the contract will be set out
> > (e.g. no later changes to what the trusted box can do).
>
> Do you mean a legal contract, or are you using the word in the
> "programming by contract" sense?  In other words, will the restrictions
> applying to the box be enforced technologically?

I was referring to the legal contract between customer and supplier.

> > But I also have additional worries.  While it is true that some TCPA
> > features can help in a limited way to prevent virii, worms etc., other
> > features might well prove to be a hacker's paradise.
>
> Also it seems to me that the existence of these boxes makes audit very
> difficult.  For example, how can computer based evidence be acceptable
> to a court if there are aspects of the machine which cannot be probed?

Agreed.  This may also be a good feature in some circumstances - its
difficult to extract a key using RIPA legislation if there is no way for the
key to be extracted without destroying it.

>  > I am also worried that these features might actually
> > help very powerful forms of attack ...
>
> I don't really see how TCPA is going to stop viruses or outside break-
> ins.  On systems that have the latest security technology, you can be
> very specific about what behaviour is allowed and what is not.  However,
> this does not make the system "secure".  Suppose Security-Enhanced Linux
> had a buffer overflow which allowed attackers to run arbitrary code with
> kernel privilege.  You would then be able to restrict users' access with
> great precision -- but anyone who knew about the bug could cruise
> straight in.

This is why I used the word 'limited'.  However I think it would be wrong to
say that the facilities are of no use here since some forms of attack will
be eliminated.  Also some of the most powerful covert forms of attack rely
on gaining control of a machine early in the boot sequence and these attacks
can be made much more difficult using TCPA features (I am not suggesting
that TCPA is the only way of doing this).

> I think there is likely to be a similar problem here.  The bugs used by
> virus writers and script kiddies will still be around.  All that will
> have changed is that there will be a few very specific restrictions that
> don't cause them much of a problem in practice

Yes, TCPA has the same problems that code signing has in respect of such
attacks.

   Brian