/. [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