|
search / subscribe / upload / contact |
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
| RSS-Feed Depeschen |  |
|
|
||
|
||
Date: 2001-02-17
Festplatten: Das Kopierschutz-Komplott-.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- sich nicht auf Flash-Bausteine beschränken wird und Festplatten mit eingebautem Kopierschutz - IBM, Intel, Toshiba and Matsushita treiben das voran - die nächste Stufe des Coypright-Wahnsinns sind, erklärt Bruce Schneier. Cryptome wiederum hostet seit gestern ein US-Urteil zum Copyright-Komplex, die Kläger wurden von Lawrence Lessig vertreten http://cryptome.org/eldred-v-reno.htm related http://www.quintessenz.at/archiv/msg01411.html -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- 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/> -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- - -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- edited by Harkank published on: 2001-02-17 comments to office@quintessenz.at subscribe Newsletter - -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- -.-. --.- 
|
|
|
 |
related topiqs |
 |
CURRENTLY RUNNING |
q/Talk 1.Juli: The Danger of Software Users Don't Control
|
|
|
!WATCH OUT! |
bits4free 14.Juli 2011: OpenStreetMap Erfinder Steve Coast live in Wien
|
|