At a dinner party recently, I found myself discussing the difficulties
of DRM (and software that is intended to implement it) with a rather
intense and inquisitive woman who was very knowledgeable about what
such software is supposed to do, but simultaneously very innocent of
the broad experience of such things that security people have had.
She was eager to learn, and asked me to summarize what I said to her
in an email. So I did
And it turns out that she is an executive in a small company which is
now considering the development of a DRM product. I just got email
from her boss (the CEO) offering to hire me, for a day or two
anyway, as a consultant. If I understand correctly, my job as
consultant will be to make a case to their board about what hurdles
of technology and credibility that small company will find in its
path if it pursues this course.
So now I need to go from Dinner party conversation mode to
consultant mode and that means I need to be able to cite specific
examples and if possible, research for the generalities I explained
over dinner. I'll be combing Schneier's blog and using Google to
fill in details of examples I've already cited to get ready for
this, but any help that folks could throw me to help illustrate
and demonstrate my points (the paragraphs below) will be much
appreciated.
I explained to her that the typical experience of monitored or
protected software (software modified for DRM enforcement) is that
some guy in a randomly selected nation far outside the jurisdiction
of your laws, using widely available tools like debuggers and hex
editors, makes a cracked copy and distributes it widely, and
that current efforts in the field seem more focused on legislation
and international prosecutions than on software technology. Software-
only solutions, aside from those involving a Trusted Computing Module
(which their proposed project does not - She seemed unaware of both
the Trusted Computing Platform and the controversy over it) are no
longer considered credible. I cited the example of DeCSS, whose
crack of players for DRM'd movies used techniques generally
applicable to any form of DRM'd software.
I explained that in the worst case, such software works by making
unacceptable compromises of security or autonomy on the machines where
it is installed, citing the infamous and widespread Sony Rootkit, (and
IMO also the TCM system, but I didn't go into that messa worms at
dinner) and that these compromises usually become public and do
serious damage to both the credibility of DRM systems generally and
the cash flow of the companies that perpetrate them (ISTR Sony wound
up losing something over 6 million in the US judgement alone on that
one, and spent considerably more than that on legal fees in the US
and several other nations).
Finally, I explained the cheap attacks available to a sysadmin who
does not want his DRM'd software reporting its usage statistics; for
example having a firewall that filters outgoing packets.
Does anyone feel that I have said anything untrue?
Can anyone point me at good information uses I can use to help prove
the case to a bunch of skeptics who are considering throwing away
their hard-earned money on a scheme that, in light of security
experience, seems foolish?
Ray Dillinger
-
The Cryptography Mailing List
Unsubscribe by sending unsubscribe cryptography to majord...@metzdowd.com
