Home Messages Index
[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index

Re: [Linux] AACS Has No Chance of Preventing HD-DVD Playback in Linux

In comp.os.linux.advocacy, nessuno@xxxxxxxxxxxxxxxxxxx
<nessuno@xxxxxxxxxxxxxxxxxxx>
 wrote
on 4 May 2007 08:24:56 -0700
<1178292295.776627.194150@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>:
> Being somewhat unfamiliar with the technical aspects of the issue,
> what I ask myself is this: Is this episode an example of poorly
> implemented DRM that would obviously be broken in short order, or is
> it in principle *impossible* to construct a DRM method that cannot be
> broken?  Whatever the answer to the second question, it certainly
> appears that the answer to the first question is "yes", if all you
> needed was one stupid 128-bit number, stored on the disks in question,
> to break the code.

I dunno, 2^128 is pretty darned big (it's equal to about
3.4 * 10^38; the mass of the Earth is only about
6 * 10^24 kg).  The second one, of course, is instructive;
one could contemplate various DRM implementations but all
appear, at least to me, flawed.

[1] Symmetric key, local hardware, local media.  Oops,
that's broken darned quickly once one gets the key!

[2] Public/Private key, local hardware, local media.
A little creative scanning of the hardware (or a leak
from a "trusted source" that actually happens to be right)
and the hardware becomes useless for the purposes of DRM.
Best I can do is to throw a thick layer of second layer
metal over a polysilicate wiring mask, and that could
probably be etched off.  (Yes, I worked as a software
engineer in a chip foundry.  I don't know a lot but one
does pick up things. :-)  Of course nowadays the transistors
are a lot smaller, and I didn't work in the fab proper.)
Then there's the issue of massproducing such keys.

[3] Public/Private key, comm server, local media.  Now one
has to prevent the key from leaking out of the server,
though at least that's vaguely possible.  However, the
local hardware also needs a way to get at that server,
either WiFi on a boom box or a network jack.  DivX (the
first one, that is) all over again.  Also, how is one to
prevent interception of the cleardata once it gets back
to the box?  Eavesdropping, at least, can be forestalled
with a shielded tunnel (a la SSL/TLS).  The issue can be
further complicated by the requirement that the comm server
look up the key in a database to see whether the given user
is authorized to own and play that media.

[4] Public/Private key, comm server, remote media.
This one might work for a little while until the black
hat types again figure out a way to capture the digital
signal while it's in the clear -- somewhere between the
receiver and the player, in the box.  Basically, one
sets up an SSL/TLS communication with a server, gets an
encrypted payload, decrypts, plays, and discards it on the
local end.  Of course, if one has an overloaded server,
one gets various skips, blocks, and goofs.

[5] P/P timed smartkey, comm server, remote media.  In this
scenario smartkeys (like mobile SIM cards or maybe RFIDs)
would be issued along with the media; the smartkeys
would be equipped with small synchronizable timers and a
pseudo-random number generator which cycles once every
15 seconds or so.  (The timers would be synchronized
using NTP.)  There are some technical issues that might
render such a key useless (e.g., power goes off and the
timers get out of sync), and of course the PRNG would
be compromisable if one destroys the SIM/RFID, but in
theory interception of the key would be nearly impossible.
Of course one could still intercept the cleardata, with
some not-so-creative hardware modifications, or one can do
it the old-fashioned way with a minijack cord and a tape
recorder or an ADC.  There's no real good way to prevent
it, and making audio patchcords illegal would get the US
laughed off the face of the planet.  (Of course we might,
anyway; our current Prez doesn't seem to have even half
a clue -- but that's best debated in another 'froup.)

>
> I guess the answer regarding the technical possibilities of DRM is
> that you can't make a really effective DRM method in software alone,
> you must also have control of the hardware.  Which is the trend, of
> course, with the help of Microsoft.  Another reason not to have a
> monopoly, in either software or hardware; another reason to be
> grateful that the DMCA is the law of one country only, etc.
>

I'm not sure hardware helps all that much, frankly, though
one could probably hide the key for awhile in a place
where the casual observer -- defined as anyone without an
electron microscope and/or fab equipment and/or a physical
key to get into the server cabinetry -- would not be able
to get at it.

-- 
#191, ewill3@xxxxxxxxxxxxx
Windows Vista.  Because it's time to refresh your hardware.  Trust us.

-- 
Posted via a free Usenet account from http://www.teranews.com


[Date Prev][Date Next][Thread Prev][Thread Next]
Author IndexDate IndexThread Index