Slashdot Mirror
European DRM News
burgburgburg writes "Two new fronts opening in the battles over digital rights management. First: news.com is reporting how French authorities are investigating EMI France and music retailer Fnac over anticopying technology included on CDs that allegedly renders them unplayable on some systems. The investigation began after the Bureau of Competition's antifraud unit (DDCCRF) received complaints from a consumer group known as UFC-Que Choisir. Second: BusinessWeek reports that the EC is investigating Microsoft to make sure that they don't illegally dominate the field of digital rights management. Regulators have told Microsoft and its partner Time Warner that they are looking into their plan to acquire the company ContentGuard, which makes DRM software because of concerns that it will create or strengthen Microsoft dominance of the field."
For having the balls to stand up to the industry bigwigs.
Find Nearby Indie Events
The whole thing is completely speculative, anyway. There is no significant DRM market, no dominant player and at the moment, Microsoft doesn't even own anything. I'm inclined to agree with you that the content providers would be better off with a standard than with giving Microsoft control over them but, at the moment, this is just EU regulators grandstanding.
What I'm listening to now on Pandora...
The ones that break the redbook standard aren't called CDs (except by retailers). Look on the case, you won't find the Compact Disc logo on it.
I don't have time to search, but the consumer union UFC/Que Choisir previously won against record companies selling copyprotected CDs...
I guess this is some followup to this judgment
#include "coucou.h"
I recently bought a CD from Fnac - "Face A/Face B" by Axelle Red. It says right on it that it incorporates copy-protection technology, though it also carries the official CD logo.
The results:
Linux: plays.
Windows: loads their CD player without asking, crashes system.
Car CD player: plays.
Portable Discman-style CD player: doesn't play. Each track plays about 9 seconds in then gets stuck in a loop skipping back a couple of seconds.
"My name is L...Laura..."
Sorry. Friday afternoon. A bit punchy.
...laura
So how big a problem is this at this moment? On most supposedly-DRM'd albums the protection doesn't work most of the time; most of the people who want to play the CD are able to do so. Not to be a tinfoil-hat theorist, but why should the government step in now unless it's to set a precedent of some sort? i.e. "Software DRM is obviously not working, so we need hardwired anti-copying chips mandatory in all systems by 2010..."
I was half-asleep when I wrote this, so forgive me if I'm unclear or repeat stuff. I think I botched the order of some things, there are crucial facts/explanations towards the end that justify earlier parts. Mainly that the Trust chip tracks the program's "identity". Bear with me till the end if somethings seem wrong or unsupported.
power failure in my house or the battery dies in the computer the encryption key will explode
I've read detailed specs on the external Trusted Platform Modules, not embedded in the CPU. Blackouts are not a problem because of the built in battery. It only takes a trickle of power to maintain that RAM when there's no external power and nothing is running, so the battery is expected to last a couple of years.
Unfortunately there's *very* little information available of the CPU-embedded Trust chips. Micrographs of the new Intel Prescott CPU show about 20% of the chip used for a second internal Trust CPU, but they are not releasing any data. I guess I assumed they would have the battery deal too, but packaging a battery on a CPU does seem awkward. I can't say for sure how they plan to handle this.
install a program which has this technology on it and it shows me how to access the information on the chip my CPU will somehow know and blow itself up.
Such a program is not possible.
The chip is physically incapable of revealing the master encryption keys no matter what software you run. They are locked inside dedicated circuits with no instrictions or physical wiring to access, read, or directly use the master keys. For the most part the master keys are only used to encrypt/decrypt lower-level encryption keys and a handful of other operations. You send an instruction to the Trust circuitry to encrypt/decrypt something and *it* uses the master keys without revealing them to you or to the rest of the CPU.
As for encrypted music and other files, you can't read them either because you can never get at the lower level keys except with the original program. The Trust circutry watches the identy of the program that is allowed to read those DRM'd music files and it will only properly decrypt the music's encryption key for that *exact* program. If you run a different program or try to alter the approved DRM music player, the Trust circutry will see that is not the same software. The Trust circutry then returns a *different* key, and obviously you can't decrypt the music file with the wrong key.
Either the information can be accessed or it can't.
You cannot access the master key, you can only tell the Trust system to use it in certain restricted ways. The file encryption key can only be accessed *within* the CPU, and only by the approved and unmodified DRM program. The file itself can only be accessed using that key, and therefore only by that approved DRM program.
That program may then re-encrypt the video/sound inside the CPU and send it to the sound card/monitor. The sound card and monitor have their own chips and their own key, so you can't even access the data when it leaves the CPU. Only the sound card and monitor can decrypt it, and those keys never leave the sound card/monitor.
A program which watches what another program does (Anti-Virus Software anyone?) interrupts whatever the other program is doing to check it.
New hardware. When there's an interrupt the new program (the watchdog in this case) gets it's own key. The first program's data and CPU register values are unreadable under the new key. If the watchdog looks at RAM it sees encrypted garbage. If the watchdog looks at the cache, that's encrypted. If the watchdog tries to look at the old register vales, they are either not available or encrypted. And the first program's identity, it's key, is hidden in inaccessible circuitry. There is no instrution for the watchdog to read or copy the first progam's identity value/key. When the interrupt returns the old programs identity is restored. Note that since
- - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
Ok. I've read your entire post and here is what I have to say in response: I am not sure, if you have never done assembly language programming, system's programming, and worked on trying to implement security measures before that I can explain to you why DRM will never work no matter how hard they try to make it work.
I am not trying to talk down to you. This is not to say I am better than you or greater than you or god-like in my knowledge. Nor am I trying to make you mad/glad/happy/sad or anything else. I'm just trying to say that DRM will never work. Oh - it may work for a while. Maybe a few months - but then there will come workarounds and such at the least. And I've read up on DRM also and find it to be an interesting twist on older technology. But I will stand by my saying it won't keep the hackers out. I do not care how much they tout it to be impregnable, super collossus, made of Kryptonite, or whatever - it won't do it.
Now, by your very post you show that you do not get how a computer basically works. Sort of like how I understand how a car works but if my car breaks down I'd probably have to call a tow truck because I really don't want to actually DO the work (if you know what I mean) and probably do not have the right tools anyway. So I have some knowledge of cars (enough to be dangerous) but not a deep down knowledge of cars like a mechanic has.
Having said that, let me lay out some ground rules to go by and then look back at what you posted. You will (hopefully) see what I mean.
1. All computers run machine language. Zeros and ones.
2. All computers perform basically the same operations.
3. All compilers reduce instructions given to them to machine language eventually (either directly or through a linker or whatever).
4. On machines which have multitasking abilities, the CPU could care less what is going on. It is told to do X, then Y, then Z. It just executes the instructions given to it. (ie: It does not think per se and only does what it is told to do. Hardwired or otherwise.) If two programs are running it is the OS and not the CPU which makes the decisions on who gets to run when.
5. In order for there to be any semblance of normallacy between computers - all programs execute the same code. That is to say that the reason a JPEG image doesn't execute a program is only because as a program it contains meaningless garbage. Real programs, in order for them to run on your computer, must contain similar code which the CPU can recognize and execute.
5a. Thus, and therefore, you are doomed. Because you can not run an encrypted program unless the CPU recognizes this blob of meaningless garbage to actually be executable code. (Which is an oxymoronic statement because if the CPU recognizes encrypted programs as executable then people would only run encrypted programs which would make the encrpytion useless since everyone would know it.) Ever tried running a ZIP file without a ZIP decoder installed and without the auto-execute program as part of the ZIP file? It won't. The CPU goes "I don't know what kind of garbage you are trying to feed me, but I can't run it," and you get an error message from the OS (not the CPU). Thus, and therefore, all programs must follow a given path in order to be recognized as executable.
6. A debugger is a program which monitors all traffic from another program. The CPU could care less what the debugger is doing. The debugger catches all input and output as well as all other executions a program may perform. A watchdog is nothing more than a debugger with a different function. This means that a watchdog can, and will, catch all I/O that a program generates as well as all executions.
Ok - hopefully you have gotten this far. Now we just need to go one step further.
IF - we can run a watchdog program and capture the i/o and commands executed (Which: Why would Intel, the CPU, the OS, or anyone else care if we are running a program which acts like a debugger but really is catching all
Someone put a black hole in my pocket and now I'm broke.