Intel to include DRM in new Pentium 4 series processors

[Brian Gladman]

From: "David Wagner" <daw@mozart.cs.berkeley.edu>
Newsgroups: isaac.lists.ukcrypto
To: <ukcrypto@chiark.greenend.org.uk>
Sent: Saturday, September 14, 2002 9:17 AM
Subject: Re: Intel to include DRM in new Pentium 4 series processors


> Brian Gladman wrote:
> >Mainly those that involve deliberate or accidental expolitable weaknesses
in
> >the operating system kernel and the lower level supporting code in driver
> >and component BIOSes.
>
> I don't see how TCPA helps with accidental bugs in the OS or its drivers.
> Secure boot makes sure you get what you asked for; it doesn't guarantee
> that what you asked for is free of buffer overruns in the first place.

It is the combination of Free/Open Source software and secure boot/code
metrics that matters, not either of these alone.

Free/Open Source OS and applications are needed to allow code inspection and
progressive discovery and removal of deliberate and accidental exploitable
weaknesses.   And secure boot and code metrics are needed to remove the
principal weakness of Free/Open Source software, namely that it is very easy
to modify it in subtle ways and plant subverted versions of it.

> [ ... about attacking the boot process ... ]
> >I would guess that the number of users who have been attacked using such
> >techniques is very, very small.
>
> Right.  Are there any reasons to expect this to change?  I can't see
> any.  It seems unlikely to me that attacks on the boot process will
> be a significant problem in the foreseeable future for most users.
> If attacking the boot process requires physical access, such attacks
> won't happen too often.

I am not quite sure of the extent of your disbelief in these forms of
attack:
(a) do you deny that such attacks are possible;
(b) do you deny that secure boot and code metrics have some value in
thwarting them

From what you say the answer to (a) is 'no' but I am not sure about (b)

If your answer to (b) is 'yes' I think we have to agree to disagree.  But
assuming that your answer to (b) is 'no', the what you are saying simply
means that our approach to risks is different - I am more risk averse than
you are.  If I know there is a vulnerability that exists which is relatively
easy to deter or remove, I want to eliminate it before it is widely
exploited.

If for example I came to know that a certain aircraft had a fault that might
mean that the doors fell off in flight in certain unusual circumstances, I
would avoid this risk if I could even though it had never happened and even
though there are more likely causes of plane crashes.

I see improving the trustworthiness of mass market PCs as a challenging task
and one that requires steady incremental progress in removing sources of
vulnerability.  I certainly don't claim that secure boot and code metrics
_alone_ are a major step forward but they are one more piece in the jigsaw
that we now seem able to put in place.

I would also say that I don't think that large chip and PC suppliers put
things like this in their products unless there is a demand for them.  And I
know that I am by no means alone in seeing value in these facilities.

My experience in these debates is that people argue against things like
secure boot and code metrics, not because these things don't do some of what
their advocates claim, but rather because people fear that these might
actually be rather effective.  And people see a high degree of of self
protection against vested interests in being able to run code on their
machines that is not subject to such less easily subvertible hardware
controls because they fear that the latter will not be under their own
control.

I understand and completely support this concern since loss of control is
loss of security.  But this should be argued in its own right, not turned
into an argument that those who do want these facilities don't understand
the security risks that they face (I am not suggesting that this is where
you are coming from).

  Brian