DRM technology and policy

bear bear at sonic.net
Mon Apr 21 19:46:47 EDT 2003



On 21 Apr 2003, Derek Atkins wrote:

>Ok, let's start from the beginning.  Let's be engineer here.
>What are the requirements of such a system.  Let's get DEEP
>into details.  What are the constraints?  What is the threat model?
>I don't think we've seen a good requirements document (from
>either side) that details the issues, concerns, and wants
>from a DRM system.  They all start with the a priori solution
>("DRM Good" or "DRM Bad") and work backwards.  Let's work forwards
>and see where it takes us, and let's leave the fear behind.

Okay, I'll start with the big problems as I see them. I have
basically six problems with the DRM systems that have been
proposed so far.  These are public-policy requirements, that
a DRM system has to meet in order to benefit society at all.
So far, no systems proposed have met more than one or two of
them.  In order to be a good idea, a DRM system must:

1) Empower individuals to use its protection for their private
   information.  That means that if some company wants my email
   address, I should be able to give them an email address that
   they *CANNOT* turn around and sell to a spammer.   Likewise if
   my attorney wants my financial records I should be able to
   satisfy the requirement by giving him or her financial
   records which he *CANNOT* forward without my knowledge to
   someone else.  If the DRM system has legal support, then
   accepting "protected" information should be a legal
   requirement for businesses - otherwise they'll just insist
   on plaintext and the DRM will not protect individuals.

   Frankly, I don't think this is possible - especially given
   that a lot of these businesses will have budgets to pay for
   hardware circumvention devices.

2) A DRM system must not freeze small producers out of the
   information marketplaces.  It must be equally accessible to
   all information producers, regardless of whether they have
   a budget to spend on an "authenticated" key.  Joe Blow's
   garage band must have the same protection as Metallica,
   and neither may have a key that can be authenticated
   through a "shortcut" that won't work for the other.  That
   means the root certs have to be public and there cannot be
   a list of root certs that get built into machines or installed
   by default in software unless  at least one of them represents
   an agency that gives out certs for free.

3) A DRM system must not freeze cooperatively-developed systems
   like Linux out of the player market just because there's no
   specific software supplier who has a budget for certs.  That
   means _EQUAL_ footing with commercial operating systems, not
   just a theoretical possibility that will never see use in
   practice.

4) A DRM system must not prevent me from accessing files which I
   have a legal right to access, even on a machine that is never
   hooked up to any network  This is not theoretical, by the way;
   I work with several natural-language databases on my development
   box, which for security reasons is never hooked up to any
   network.  If I were required to hook it up to a network in
   order to use those databases, I would not be able to meet
   security demands due to lack of budget for proving an
   operating system secure.

5) A DRM system must allow legal fair use, such as printing a
   few pages of a copyrighted document, quoting, time-shifting
   of broadcast content, and editing one's personal copy or
   producing derivative works if done without redistributing
   the edited or derivative version.

6) A DRM system must not introduce some "unknowable" part of
   my computer or operating system wich could be used to house
   code which cannot be examined.  This is particularly true if
   that code may or must run with sufficient priveleges to
   destroy information, facilitate compromise of the system, or
   transmit private information (such as what programs I'm
   running and when I'm on my machine) to other parties.




				Bear


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list