DRM technology and policy
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
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.
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography