[Discussioni] [claudio a telmon.org: [Fwd: CRYPTO-GRAM, February 15, 2001]]

Mer 21 Feb 2001 12:31:51 CET

Lungo, ma secondo me interessantissimo.  Non direttamente legato al
software libero, ma se una parte significativa del mercato finale dei PC
usasse software libero, proposte del genere non potrebbero neanche
nascere.

------- Start of forwarded message -------
From: Bruce Schneier <schneier a counterpane.com>
Subject: CRYPTO-GRAM, February 15, 2001
To: crypto-gram a chaparraltree.com

                  CRYPTO-GRAM

               February 15, 2001

               by Bruce Schneier
                Founder and CTO
       Counterpane Internet Security, Inc.
            schneier a counterpane.com
          <http://www.counterpane.com>

A free monthly newsletter providing summaries, analyses, insights, and 
commentaries on computer security and cryptography.

Back issues are available at 
<http://www.counterpane.com/crypto-gram.html>.  To subscribe or 
unsubscribe, see below.

** *** ***** ******* *********** *************

In this issue:
      Hard-Drive-Embedded Copy Protection
      Crypto-Gram Reprints
      News
      Counterpane Internet Security News
      An Intentional Backdoor
      The Doghouse: NASA and eTrue
      A Semantic Attack on URLs
      E-mail Filter Idiocy
      Air Gaps
      Internet Voting vs. Large-Value e-Commerce
      Comments from Readers

** *** ***** ******* *********** *************

     Hard-Drive-Embedded Copy Protection

CPRM (Content Protection for Recordable Media) is a system for enforcing
copy protection on personal computers.  The basic idea is to enforce
digital rights management -- copy-prevention, limited use, whatever --
in electronic media.

In more detail, the scheme requires specially designed copying software.
This software communicates directly to the disk drive, bypassing the
operating system.  To write a document, first the drive and the software
authenticate to each other.  Then the drive sends the software keying
material that is stored in a nonstandard place on the drive that's
unique to the medium, and also reads back an increment-only counter in
the medium.  The user-level application -- or, more likely, a server
somewhere on the Web -- encrypts the file using that keying material.
The encrypted object is written as an ordinary file on the medium.  An
intermediate key file is written as a second ordinary file.

The "player" for these encrypted objects will pull an increment-only
counter out of the drive, use it and the keying material to decrypt the
intermediate key-file, and then extract the document key from that file.
It will then play the document.

To move (as opposed to copy) the document to another disk, the software
will check to determine if this is permissible.  (Perhaps the
permissions will be embedded in the file; perhaps the software will
query another computer over the Internet.)  If the move is allowed, the
software will re-encrypt the document for the new medium (only allowing
it to be stored in a copy-protected medium), increment the
increment-only counter in the old medium, generate a new key-file key
with the new counter value, and rewrite the old key-file, deleting the
key that would allow the old copy to be played.  After moving the
document, even if the user keeps a copy of the encrypted bits, it won't
play on the original medium because its key won't be in the key-file on
that medium.

If a user copies the encrypted object to another medium without going
through the approved procedure, its key won't be in the key-file on the
new medium, so the reader can't play it.  If the user copies both of
them to another medium, the key-file won't be decryptable since its key
depends on the medium-specific keying info.  If the user makes a backup
copy of his entire disk, "moves" the encrypted song onto another medium,
then scrubs and restores the entire original disk, the restored key-file
won't be decryptable, since the increment-only counter (that is hashed
with the medium-specific keys to produce the key-file key) will have
changed.

There are other tricks built into the system.  There's no single global
secret to steal, and there's a mechanism to recover security if some of
the many global secrets get out.  The system is based on something
called "broadcast encryption," developed by Amos Fiat and Moni Naar in
1993.

The technology will be ineffective, but that may not matter.

Broadly speaking, there are three classes of people who copy documents.
There are average users, who just want a second copy for whatever reason
but won't use hacker tools.  There are more savvy users, who are willing
to download programs that break copy-protection schemes.  And there are
professionals, who are prepared to spend serious money to break
copy-protection schemes.

Against the first group, any security measure works.  This hardware
scheme is overkill.  Against the second group, any scheme that involves
software fails.  I've written about this extensively both in _Secrets
and Lies_ (see pp. 250-253) and in a previous issue of Crypto-Gram.
Basically, the scheme described above has a key stored in hardware and a
software decryptor.  To break the scheme, you don't need to extract the
hardware key.  You can let the decryption software do it normally, and
then grab the document after decryption and before play.  Someone will
write software do to this, just as someone has written software to get
around every other similar scheme.  The hardware component doesn't
matter.

Where it will make a difference is in devices that don't expose the
decrypted document.  The reason the computer embodiment fails is because
the document exists unencrypted in the computer, and a hacker can write
a program to take advantage of that.  If this copy protection is brought
forward to the video monitor, or the speakers, then the document never
exists in the computer in unencrypted form.  If the scheme only runs on
DVD players or MP3 devices or anything else where you can't run custom
software, this is much more effective.

But it still doesn't work against the third class of attackers: the
professionals.  These are people willing to invest in custom hardware.
They will always be able to break these schemes and extract the
documents.  And they will always be able to produce and sell bootlegs,
at least to the limits of law enforcement in whatever country they're
in.

There is another angle here, making this even more complicated.  Content
providers are no longer relying on technology to enforce copy
protection, they're relying on laws.  The algorithms used in this scheme
will be patented, so anyone who writes a hacked decoder will be
infringing on the patent.  And any software designed to circumvent this
mechanism will be illegal under the Digital Millennium Copyright Act.
Not only can the authors of this software be prosecuted, but so can
people who "traffic" in this software: e.g., post or link to it on their
Web site.

This will not make it any harder to find such circumvention software --
notice how easy it is to find DeCSS today with your search engine -- but
it will have a chilling effect on the whole idea.  2600 Magazine was
successfully prosecuted for linking to DeCSS; similar pressure will be
brought to bear against anyone who publicizes any DeCPRM software.

So, what do we have here?  We have a serious threat to civil liberties:
large entertainment companies are allying themselves with the computer
industry to dictate what can and can't happen on your hard drive.  (CPRM
is only supposed to be for flash memory.  This is a lie, of course.
Already it is planned for IBM's tiny hard drive, and larger drives
aren't far behind.)  We have a technology that will, in some
circumstances, make backups impossible.  Compatibility problems between
disk drives that have CPRM and those that don't will force networks to
completely upgrade their mass storage.  We have a technology that forces
users to buy proprietary decoding software forever.  We have a
technology that won't really work unless it extends to computer output
devices; you may find yourself forced to upgrade your monitor as well to
watch movies on your computer.  And we have an increased reliance on
legal harassment by media companies.  It's that last bit that scares me
the most.

The proposal:
<http://www.theregister.co.uk/content/2/15620.html>
<http://www.lmicp.com/4centity/data/tech/cpsa/cpsa081.pdf>
<http://www.lmicp.com/4centity/data/tech/4cspec.pdf>
<http://www.theregister.co.uk/content/2/15718.html>
<http://www.theregister.co.uk/content/2/15797.html>

What's Wrong with Copy Protection, by John Gilmore:
<http://www.toad.com/gnu/whatswrong.html>

Copy protection and why it doesn't work:
<http://www.counterpane.com/crypto-gram-9811.html#copy>

EFF's archives on the topic:
<http://www.eff.org/IP/>

The 4C Entity (IBM, Intel, Toshiba and Matsushita), which owns and 
advocates CPRM:
<http://www.dvdcca.org/4centity/>
------- End of forwarded message -------