My take on Trusted Computing and DRM

[Joseph Pingenot <trelane@digitasaru.net>]

Weighing in.  Whee!  This is gonna be long!  I read a little bit on the
  Trusted Computing Platform Association's website, and it has had me
  thinking.

I believe that, if there were ever a DRM implementation to be trusted, it
  would have to be Free Software.  For example, look at Microsoft's
  source code access program for governments.  You may look, but not touch,
  may not discuss, and especially may not compile.
Yay.  Now, how exactly can we even *begin* trusting that the code we *saw*
  was the code we're *running*?!

In Free Software, it's transparent; what you see *is* indeed what you get.
  No hidden gimmicks or surprises (unless Richie did your C compiler.  ;)

It should be noted that we need to talk about two *separate* issues:
  Digial Rights Management, and Trusted Computing.  As a quick executive
  overview, I believe that Digital Rights Management, if implemented,
  should be handled in the programming equivalent of a full environmental
  suit--much, much harm can come from it.  Unfortunately, given the
  direction music and movie labels here in the 'States (which, unfortunately,
  counts for at least the very large majority of the movies and music seen/
  heard at leat in the 'States and in Europe, in my experience).  Thus,
  it is somewhat forced upon us, and we should have an optional(!)
  implementation of it, so that we can continue to interact with the
  complacent world.
Trusted Computing, on the other hand, holds a wealth of security enhancement
  possiblities for the educated user and for the enterprise, and should
  most definitely be embraced, although the non-toxic/carcinogenic
  equivalent of programming asbestos should be used, as it also carries with
  it the danger of abuse.  We *absolutely* need to get full disclosure on
  the hardware, and need to sit in on the industry steering committees, e.g.
  TCPA.  See also my Linux-NG posting at http://lists.debian.org/debian-devel/2002/debian-devel-200212/msg01719.html
  (the big section on security torwards the end) for some of what I'd like
  to see/implement.

DRM:
I am extremely cautious about Digital Rights Management.  Although there is
  a little good to be extracted from it (for instance, the ability to make
  sure that people can't revise a document one's written); there is much,
  much more harm in it.  The most obvious of these is the removal of the
  fair use rights (although not law, fair use ought to be!).  It is
  extremely possible and plausible to have DRM or software under the guise
  of DRM deny you the right to make a backup copy, change format, or even
  select a different player or create your own player!  I'm sure we're all
  familiar with the Content Scrambling System, yes?
That said, it is somewhat inevitable at this time.  The MPAA, RIAA, and
  others are forcing it down our throats at the CD and movie stores.  Yes,
  it can usually be broken, but that's a) illegal in the States, and
  b) just a workaround.  We should concentrate on elevating bit players to
  the foreground, and try to avoid putting any more money in the MPAA/RIAA/
  whoever coffers.  That's the long-term solution; promote business that
  doesn't try to screw us over (as much).  I know it's hard; I like to buy
  DVDs and CDs too.  In fact, I feel like a hypocrite, 'cause I will most
  definitely be purchasing CDs and DVDs in the future.  *sigh*  Any
  suggestions on how to not support them (legally!) would be most welcome.

Trusted Computing:
There is actually quite a bit of good that I can see coming from trusted
  computing, _provided_ that some things are in place.  *If* the user
  can set up the signatures herself, this can be a great boon to security.
  Imagine being able to ensure that the kernel you're booting was indeed
  the one you compiled and signed, and that it's not been rootkited.  Even
  better, envision signed modules and binaries, making rootkits much, much
  harder.  How?  Well, sign the modules.  The kernel then has the public
  key and can verify that the module hasn't been tampered with.  Even
  better, it can refuse to load modules you've not signed, so that crackers
  can't set up a module so that not even your low-level tools can pick up
  the DoS daemon they've got running on port 666.
Programs, already signed by you or the distro, could be kept signed on disk,
  and the kernel, having the appropriate public key supplied by you and/or
  the distro, could then verify that the binary hasn't been tampered with.
  Extend this to files, so that, for example, the cracker can't edit
  inetd.conf to make a bash instance listen in on port 1337, since inetd
  could ask the kernel to verify the signature of the file.  And, even
  better, distribution updates can still be transparent, so long as the
  keys haven't changed.  The package system just updates the signatures
  automatically with the files.  This would require adding metadata to the
  file to store the signature, but it'd work and do quite a bit to make
  rootkits that much harder to implement.
Can this be abused?  Absolutely.  StarOffice 8 could ask the kernel to
  ensure that the StarWriter file has not been modified.  But, nobody's
  forcing you to use StarOffice 8; use AbiWord instead.  Indeed, aside
  from asking the kernel to verify the file's integrity, nothing is there
  that can't be done with existing cryptographic routines.  The difference
  is that the kernel is Linux, and doesn't care *what* the word processor
  is, so long as it's carrying a trusted signature (by you and/or the
  distro).  Remember, this is Linux, and you can get the source, and make
  it go yourself.  It's not Windows, which is closed and has Microsoft's
  business plan and Microsoft's interests behind it.  Effectively, it's
  *your* kernel, and it has *your* interests behind it, because the
  hardware only cares that you signed it.
SO LONG as the hardware gives you that right.  This is why it's imperative
  that we get people on the steering committees.  Do we already?  It's
  extremely unfortunate that one has to be a *business* in order to join
  a standards group and steer the future of technology.  Unless you happen
  to have thousands, if not tens of thousands of dollars lying around that
  can't be put to better use.  Hopefully, our corporate backers can help
  get us in to these meetings; it's imperative that we (the users) can tell
  the hardware what to do; not for the hardware to tell *us* what we can do.
  We *must* be able to set the signatures via *some* method.  This doesn't
  need to circumvent the system if designed properly [for instance, requiring
  physical access + special knowledge (e.g. password)].  Won't stop
  everything, but neither will anything else [for instance, FBI could force
  chipmaker to make special chips with special keys to allow them to load,
  say, a keysniffer, even if it's embedded into a chip and not otherwise
  settable].
There's more that could be done with a trusted architecture [fast hardware
  encryption, storing keys so that not even the kernel knows them nor can
  get at them; mutual distrust between the key/user credential storage and
  the kernel, etc.] to make it a very secure system *if* we can hack on it
  too, and ensure that the user is in control.  Essentially, we (linux, BSD,
  and others) are the ones working for the users.  We are extremely 
  necessary in the fixating the digital future for the users.

This last part was the last part of my debian-devel posting; I think I've
  covered it all.  I hope that we can adopt the good parts of Trusted
  Computing, and I really hope we can help steer it to make sure it goes
  in a way that's not constrictive.  It's a fine line, but, maybe with
  corp. backing (Transmeta, Sun, IBM, Red Hat), we might be able to get
  some developers in to the TCPA and others.

After all, if Microsoft can do it, we can do it *better*.  (and freer ;)

-Joseph


-- 
Joseph===============================================trelane@digitasaru.net
"Isn't it illegal for Microsoft to tie any of its software products to its
  OS?"  --Rob Riggs on slashdot (www.slashdot.org) about Microsoft's order
  to cease and decist using Visual Fox Pro on Linux, a non-Microsoft OS.
"Yes. The penalty is dinner with no dessert." --Alien Being, response