MS Patent for DRM OS

[Jonathan Care]

Alex Butcher wrote:
>
> On Thu, 13 Dec 2001, Matthew Byng-Maddick wrote:
>
> > The other question that comes to mind is: isn't this a bit like the holy
> > grail of "tamper-proof" hardware, that you could, in theory, trace the
> > operating system code path, on a non-DRM system, and find where it keeps
> > the public-key, replacing it with your own, thus allowing you to control
> > what "Rights Managed Software" was allowed to run. This would make it
> > possible for the user to circumvent every protection that the software
> > wanted, because they could then just sign their own...
>
> Thinking about it, I wonder if it's possible to run gdb on VMware whilst
> *it's* running Windows 2003/XXP/whatever??? :)
>
> Let's see 'em detect *that*!

My understanding is that VMWare would infringe a DRM-OS "System High"
condition. Thus, I doubt that the OS would permit it to run unless all
DRM-controlled material was rendered inaccessible.

DRM is a hard problem to solve, and I will watch the progress of this with
interest. I wonder how much resistance there will be to  a content
controlled computing device - in essence, the DRM requires that the user not
be able to perform operations at kernel level, nor to run code that does not
execute in a small, tight sandbox unless sanctioned by the DRM licensing
authority. This means that PC's running this OS will move towards the
"appliance" model - you will have a word processor/spreadsheet
calculator/web&email browser on your desk, a la the good old days of Wang.
Developers will be strictly licensed, and will require a special build of
the OS - the "developer's edition", issue of which I would expect to be
controlled and audited. If I were the maker of the OS, I would register each
compiler with an ID stamp, which would identify the developer concerned. As
we know, all of the above is fallible - security seals can be broken,
licensing programs subverted, and CD's get copied and distributed very fast,
despite the efforts of BSA, FAST, and the like. Imagine what happens when a
cracker finds a way of putting another developer's ID stamp into their
compiler.

It should be noted that this does not stop connection of external devices
into taps in the audio out/visual out feeds. In fact, one of the hardest
parts of DRM is that however is that fundamentally, the information must be
rendered into a clear form (decrypted audio, decrypted video, or decrypted
text/XML/HTML/Insert your favourite format here) in order for it to have any
value.

As the cryptographic processes and the operating system controls become
tighter (and by the way, one of the known flaws with Bell-LaPadula is that
over time, every information classification migrates to requiring a Top
Secret label) then it becomes more attractive to the ambitious copier to
build a t-plug, connect to a good processor unit (you can build one for
about £150) and record the processed information onto VCD or CD-audio.

>
> I guess this scheme, like all other copy protection schemes, will be
> enough to deter casual rights-infringement, until some moderately clued
> and well resourced cracker reverse-engineers it and posts a crack. And
> that's when the DMCA or EUCD takes over...

I think the best solution to this so far is still the levy on cassette
tapes, to compensate the producers of LP records for the "inevitable loss
suffered" when an LP record is copied to tape, and distributed amongst ones
friends. All this DRM hand-waving has yet to demonstrate any success (not to
mention acceptance - look at the farce caused by CD's that will not play in
certain CD-spec drives).

With kind regards,
Jonathan Care
Tel/Fax: +44 7092 016192
Technical Director, Omnes Ltd.