Re: DRM, Intel, Sony, virtualization and backdoors

From: Peter Grandi (pg_nh_at_0502.exp.sabi.UK)
Date: 06/12/05


Date: Sun, 12 Jun 2005 15:10:06 +0100


[ ... ]
>>> In this fine picture of a happy future there is also an
>>> added bonus: the ''all your bases are belong to us'' effect,
>>> where ''us'' is whoever has the ''keys'' to the hypervisor,
>>> especially if the hypervisor is remotely accessible as in
>>> Intel's AMT (and most likely also in the case of the Cell
>>> hypervisor).
[ ... ]

>> Heh, wait until "hackers" get hold of the hypervisor 'keys'
>> and the technology to exploit them. That'll likely put a
>> quick stop to Hollywood's dreams of media monopolism.

> The chips would have the public keys. (I expect that each
> agency would have its own key.)

Here ''key'' does not necessarily mean a crypto key, even if for
example it is such in an Xbox etc. It is whatever ''knowledge''
allows one control over the hypervisor in the CPU or the chipset.
It could be a carefully designed ''flaw'', even if that risks
discovery, much less so though in a chip than in sw.

The sort of ''keys'' corporate IT managers would users are
likely to be configurable, a bit like setting the BIOS password
(while the Xbox ''key'' is factory set). They will then probably
be stored in some non volatible memory in the CPU or chipset or
some other chip attached to it.

The big problems are:

* The extraordinary amount of power over the CPU/chipset given
  to the owner of the ''keys'' thanks to the AMT backdoor.

* That operation of that backdoor most likely is or can be made
  essentially undetectable by the user, because I guess that it
  is designed to be transparent to the OS, both on the CPU and
  in the chipset.

* That it can be made undetectable _who_ has the keys to operate
  the backdoor, as short of extraordinary effort it is hard to
  exclude that there may be more keys than officially announced,
  as correctly inferred here:

> It might even be manageable to give each chip its own secretly
> hidden public keys, as well as publicly acknowledged private
> keys for which the public key for DRM is available, thus
> limiting the damage.

[ ... ]



Relevant Pages

  • Special function (Fn) keys problem on Evesham laptop
    ... function keys for display on/off, brightness control and wireless ... the chipset" - unfortunately, I don't know which chipset they mean, or ... whether there are linux drivers available. ... It seems strange that the keys should sometimes work. ...
    (alt.os.linux.suse)
  • Re: SSH2 question?
    ... is sufficiently well secured that keys cannot be modified by anyone other ... Public keys and the authorized_keys ... file must be stored relative to the home directory of the account they ... Note that this location is relative to the home directory of the account ...
    (freebsd-questions)
  • Re: SSH2 question?
    ... is sufficiently well secured that keys cannot be modified by anyone other ... file must be stored relative to the home directory of the account they ... You can certainly add as many public keys as you want to an authorized ... Note that this location is relative to the home directory of the account ...
    (freebsd-questions)
  • Re: SSL Question
    ... > To the best of my knowledge, the encryption keys and signing keys are the ... You have private keys and public keys. ...
    (Security-Basics)
  • Re: Fw: [FreeBSD-Announce] FreeBSD Security Advisory FreeBSD-SA-06:23.openssl
    ... prohibiting the use of exceptionally large public keys. ... I wouldn't have allowed this change into the security branches if I was not ... Thanks for the quick response, and all the work you do. ...
    (freebsd-questions)