/. [Intel Adds DRM to New Chips]

Eugen Leitl eugen at leitl.org
Thu Jun 2 00:27:39 PDT 2005


On Thu, Jun 02, 2005 at 11:05:30AM +0200, DiSToAGe wrote:

> I have read infos that say that audio and video drivers will be in the
> trusted chain. If your hardware system is used by an os (i.e. win) on
> which you can't create drivers, and only industry signed drivers can be
> used you can't bypass this by hacking drivers ...

The code running in the trusted sandbox isn't magic, so if it's complex
enough there will be vulnerabilities (not a problem in theory, but in
practice).

> My though is the hardware drm can be reverse engineered ? If you use

My thought is, can cryptosystems be broken? Not by 31337 h4x0rs, obviously.

> cert on your DRM you must put cert and private keys on your DRM chip ...

Not you -- somebody else. Generated on board, probably, or generated
externally, and loaded into the hardware.

> So you have somewhere memory (rom or else) where you have this private

So far, so good.

> and cert datas. So with good tools you can read what are the bits in
> this DRM. So you can make a "soft drm" that use all the instructions of

If you mean by good tools 100 k$ worth of hardware (and a skilled operator)
to read out the state of bits on die, after etching away the enclosing,
you're correct.

Why do you think a system designed to contain and keep a secret will contain
a convenient backdoor?

> the reverse engineered hard drm, you but the reverse engineered private
> key, certs on your soft drm. All this goes on a "emulated" drm part on
> your os emulator. So booting the os believe that it is hard, because all
> instructions are the same, certs is the same, and private key can be
> used by your soft drm to en/crypt drm files ...??? We see that with time
> almost all can be reverse engineered, can it be the same with hard drm
> systems ??

--
Eugen* Leitl <a href="http://leitl.org">leitl</a>
______________________________________________________________
ICBM: 48.07100, 11.36820            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]





More information about the cypherpunks-legacy mailing list