Weekly Edition
Return to the Security page
| |||||||||||||
|
| |||||||||||||
Sun's "open source DRM" specifications released
Sun has announced the release of the first set of specifications for its "open source DRM" effort. It is an exercise in Orwellian naming: we have "Project DReaM" for "DRM/everywhere available," a system called "Mother May I," and the whole thing is found at OpenMediaCommons.org. Nonetheless, they got Lawrence Lessig to add a favorable statement. Code for a prototype "conditional access system" implementation has been posted.
(Log in to post comments)
Sun's "open source DRM" specifications released Posted Mar 22, 2006 19:18 UTC (Wed) by mtaht (subscriber, #11087) [Link] Joseph Stalin said: "When we hang the capitalists they will sell us the rope we use." Paraphrased for this instance: "When we lock up all the IP, the hackers will write the all the code we use." Working on DRM or not working on DRM is a moral choice. Me, I'd rather work on creating better tools for creating music.
Sun's "open source DRM" specifications released Posted Mar 22, 2006 19:25 UTC (Wed) by pbardet (guest, #22762) [Link] I guess I'll have to read more about this, but I just can't see how you can publish source code that decrypts DRM content, without forbidding someone from using the source code to bypass the DRM features.
Sure, you may violate the license of the source code, but who cares ?
How "open source" DRM can work Posted Mar 22, 2006 19:38 UTC (Wed) by JoeBuck (subscriber, #2330) [Link] It's simple enough. You put the code that checks DRM permissions in ROM, in the boot loader. Or alternatively, if you use flash, you check the permissions before you allow the flash to be re-burned. People can read the source code and see what it is doing. But they can't change what it is doing. The only thing we get is that the policies of the jailer are transparent, which is better than trusting a mysterious black box, but not by much. The source is only open in that you can look at it. If you change it and recompile it, you can't load the new code onto your device, unless you find a security flaw that allows you to bypass the DRM. And if you find that flaw and tell anyone, you risk jail time, thanks to the DMCA and similar laws in other countries.This is why Stallman wants the anti-DRM language in GPLv3, to put the brakes on efforts like this (though it may be too late). It is disappointing that Prof. Lessig is signing on; maybe he thinks that a combination of forcing the DRM-enforcing code to be available in source form, and government regulation, would allow DRM to be acceptable.
How "open source" DRM can work Posted Mar 22, 2006 21:16 UTC (Wed) by man_ls (subscriber, #15091) [Link] Lessig's quote is specially flagrant.In a world where DRM has become ubiquitous, we need to ensure that the ecology for creativity is bolstered, not stifled, by technology. We applaud Sun's efforts to rally the community around the development of open-source, royalty-free DRM standards that support "fair use" and that don't block the development of Creative Commons ideals.Once more, Stallman is proven right. If all Creative Commons proponents share these ideals, like in "DRM is ubiquitous so let's join in with a good one", then we will have to find another acceptable license for digital media.
Whose rights in DRM ? Posted Mar 23, 2006 11:03 UTC (Thu) by copsewood (subscriber, #199) [Link] If a scheme intended to prevent modification of software for security purposes without special action by the end user is based on what is in a standard plugin ROM or flash chip component which can be relatively easily and legally reprogrammed and/or replaced by the end user I have fewer problems with this concept than otherwise. If physical access to the device is needed to reprogram it, and the source code is available, and the hardware programming facilities are available on the market and end user modifiable this suggests a more potentially useful facility than otherwise. If DRM means digital rights management in the wider sense, doesn't an end user who retains the right to hack a product he/she has purchased have the right to manage the security of the programmable device from unwelcome remote exploitation by this means ?
DRM becomes a problem if and only if this technology is used for protecting the assumed but contested rights of those other than the owner and user of the programmable device concerned. Without having studied this in great detail, my impression is that the FSF intention behind the GPLV3 clause is not to prevent the development of DRM as such, but to ensure that when this occurs in respect of GPLV3 licensed code, the end user, by having access to the key used to protect his/her specific purchased device, retains the right to modify his/her own purchased system. Or have I got this wrong ?
How "open source" DRM can work Posted Mar 23, 2006 14:53 UTC (Thu) by pbardet (guest, #22762) [Link] For you, that Open-Source DRM is limited to "non-hackable" devices. But what happens if you can load a file with that DRM in it on your computer ? Since you have the source code, you can decrypt the file and encode it into another file format.
I just don't see how DRM can work if the source code is not closed, unless you provide both the software and the hardware used for such content and make sure you can't leak the content on another piece of hardware. But when you download a tune from any commercial service, you'll need a computer to do so and therefore, you can compile the source code on that computer to get rid of the DRM.
Even when source code is closed, DRM can be removed. Look at AAC.
I'm not Anti-DRM, I just don't believe it can stand the time and that it is useless. At some point or another, it will be broken. And it's not laws like DMCA that will prevent this. It seems it was easy to make the pill swallowed by US citizen for 911 reasons, but people in other countries dont't seem to accept that kind of crap.
There will always be people who want to cheat the system, especially if they feel the system is cheating them. Currently, I'm starting to be one of them since I need to constantly buy the same items again and again, whether it's music, clothes... Now they want to put restriction as to where I put my music... I think Open-Source movement is wasting time by exploring this route.
How "open source" DRM can work Posted Mar 24, 2006 18:08 UTC (Fri) by giraffedata (subscriber, #1954) [Link] But what happens if you can load a file with that DRM in it on your computer? Since you have the source code, you can decrypt the file and encode it into another file format. No serious DRM scheme today relies on people not having the source code (i.e. they are designed so you can't crack any of them by disassembling the access software). when you download a tune from any commercial service, you'll need a computer to do so and therefore, you can compile the source code on that computer to get rid of the DRM. What if the open source player code takes as an input a encryption key? The key is built into your player hardware, but you don't know it. You can't rewrite the open source code so that it can decrypt the music without the key.
Sun's "open source DRM" specifications released Posted Mar 22, 2006 21:04 UTC (Wed) by jmorris42 (subscriber, #2203) [Link] Read their FAQ people. Real security implementations can and should be openly published, which is what makes this one a bigger threat to the people who oppose ALL drm technology on principle; i.e. this one would probably actually work.
But, again from their FAQ, all drm isn't always evil. Raise your hand if you object to drm limiting access to your medical records. Or limiting distribution of internal company documents. Or limiting access to classified information. And so on and so on. Think beyond locking up Britney Spears drivel for the next century and there are good reasons for having this technology available, even if it will almost certainly spark a fight to prevent the 'content industry' from misusing it.
Sun's "open source DRM" specifications released Posted Mar 22, 2006 21:18 UTC (Wed) by sir99 (guest, #3286) [Link] But DRM is neither sufficient nor necessary to do any of these things. On a single computer system, well-designed software can do anything DRM can do for the hardware owner. And on a network, DRM doesn't live up to its promise: if I can see/hear it, I can copy it, even if the quality is degraded.
Note: when I say DRM, I'm thinking hardware-enforced restrictions. Actually, I have no real objection to DRM, provided the hardware owner has access to all secret keys used by the device. But in that case, software should be able to do the job just as well, so why bother with hardware?
DRM limits Posted Mar 22, 2006 23:08 UTC (Wed) by man_ls (subscriber, #15091) [Link] Raise your hand if you object to drm limiting access to your medical records. Or limiting distribution of internal company documents. Or limiting access to classified information.I object to the three of them. DRM is not used for this, nor should it be. Can you picture the US government distributing classified information using Digital Restrictions Management, designed for consumer level music and films? Protected company documents will be fun to see, since probably everyone will end up with access except those poor souls who for some reason need to use them. Me, I don't want DRM limits for my medical records; I would prefer a sensible policy instead. If need be, a PKI is bad enough. If you are still not convinced, picture this. A doctor is looking at your medical records on a PDA; an evil nurse looks over her shoulder and takes notes. How is DRM going to help with this?
Sun's "open source DRM" specifications released Posted Mar 22, 2006 23:55 UTC (Wed) by ikm (subscriber, #493) [Link] No, DRM is about stuff that you can actually do, but restrain yourself from doing -- enforced by the devices you use. Compare these two cases: 1) you have an access to someone's medical data but don't allow yourself to look into it; 2) you don't have an access to that data, no matter how hard you actually want to have it. The first one -- if enforced by technical means -- is DRM, and the second one is just proper security and access control.
DRM is only about restraining yourself, nothing more.
Sun's "open source DRM" specifications released Posted Mar 23, 2006 1:16 UTC (Thu) by mmarq (guest, #2332) [Link] "" Raise your hand if you object to drm limiting access to your medical records. Or limiting distribution of internal company documents. Or limiting access to classified information. And so on and so on.. ""
Ok.. that is the good excuse, and votes in favor of DRM, though there are other ways to achieve the same exact effects without using this technology.
The problem isn't exactly the server side, and nor exactly media or document protections, which could always resort to heavy encryption technologies.
The problem IMHO, would be one of interoperability in the client side...
Think of it as in case of people needing to have protocols and DRM schemes which are not open in any way, and which in the time to choose client OSes would *force* them to decide for ' commercial covered solutions' even if those OSes are essentially Open Sourced from tip to to toe.
It wont be about Britney Spears (thank god), nor about personal data protection, taste fights or personality clashes. It *could* be simply the termination of an idea !...
Would Mozilla need to pay royalties to the IP owners of some 'very closed' protocols and DRM schemes, not only to be able to install and work in OSes protected that way, but also to be able to load a lot of 'sites' protected the same way ?
Would Apache also need the same *IP cost* to be able to serve clients which only *trust* services with those same especific 'closed' DRM measures ?
DRM denies humans making decisions. Posted Mar 23, 2006 5:19 UTC (Thu) by bignose (subscriber, #40) [Link] > Raise your hand if you object to drm limiting access to your medical> records. Or limiting distribution of internal company documents. Or > limiting access to classified information.
Yes, I object to all those being under DRM. Those are decisions for humans to make at the time a request for access is made, not for the equipment to make based on what the media-writers or equipment-designers decided in the past.
Yes, I object Posted Mar 23, 2006 5:44 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] Raise your hand if you object to drm limiting access to your medical records. Or limiting distribution of internal company documents. Or limiting access to classified information.Consider my hand raised. If the internal company documents reveal that a horrendous crime is being covered up, or the classified information reveals that the basis for a country going to war was completely fraudulent, then DRM is an excellent way to shut down any whistleblowers. Or, rather, it would be if it worked, but if someone can see information on a screen, but cannot print it or forward it, she can still write the information down, take a photograph of the screen, etc. We can deny the worker any pen and paper, cameras, etc. Then one day some future Winston Smith will see an incriminating photograph, and his boss will tell him that there is no way he can show that photograph to anyone else, and laugh. Those of you who've read "1984" will get the references.
Sun's "open source DRM" specifications released Posted Mar 23, 2006 9:54 UTC (Thu) by job (subscriber, #670) [Link] I most certainly object.
First and foremost, I wouldn't want my medical records leaked at all, whether in DRMed documents or not.
If there are attack vectors that can retrieve the data files in their stored form (which I hope not, it being on a separate network and all) I would very much prefer the data to be properly encrypted and *not* just set a DRM bit and rely on laws and obscure formats to make sure the attacker won't read the files.
Sun's "open source DRM" specifications released Posted Mar 23, 2006 19:06 UTC (Thu) by ekj (subscriber, #1524) [Link] DRM has nothing to do with protecting medical records.The first choise for protecting medical records is to arrange it so that people who shouldn't have access to it, never get their hands on the physical file at all. The second choise is to have the file be encrypted, so that *even* if the "bad guys" gets the file, they still can't read it. This still ain't DRM. DRM is when you deliberately distribute the file. *and* you deliberately distribute the key, in millions of copies. Still, you try to make the device containing the key (be it software or hardware) be so securely designed that even though you distribute it by the millions, noone will be able to *extract* the key. That's *certainly* not how you protect anyting you care to keep secret. It's about something else: trying to keep the control over a file and what is done with it while at the same time selling the file to millions of people all over the world.
Exercise in futility. Posted Mar 22, 2006 21:16 UTC (Wed) by flewellyn (subscriber, #5047) [Link] Open source or not, I can see no way that DRM would actually work. I am not a cryptographic expert (amateur enthusiast at best), but to me the problem boils down to one of key distribution. It's very easy to build open source cryptographic tools without compromising the security, because knowing the algorithm does not necessarily help you break the encryption by itself; you need the keys, or a means of producing those keys. As you all no doubt know, symmetric key cryptography (such as DES) has the small problem that the same key is used for both encrypting and decrypting, which means that key has to be secret at both ends. Public key cryptography, which is asymmetric, was designed to alleviate this problem.
My understanding of public key cryptography is that, basically, you distribute the encrypting "public" key far and wide, while keeping the decrypting "secret" key to yourself. Thus, anybody can encrypt a message to the holder of the secret key, but only the holder of that key can decrypt those messages. This is a very elegant solution to the basic problem of key distribution, assuring that the messages are kept private for the intended recipient.
But here's where the problem comes in. DRM is about locking down content, not about ensuring privacy of messages; it flips around the usual case in cryptography by distrusting the recipients. In order to make sure content is only decryptable by authorized people, you'd have to ensure that only those authorized people had access to the keys needed to decrypt. If it's public key, asymmetric cryptography, you'd have to distribute those keys somehow to the authorized people.
And any way you do that, whether by embedding them in the content or by separately enabling them, NOTHING prevents those authorized people from redistributing the keys to other people! Since, in DRM, the recipient is NOT trusted, this means that key distribution becomes a catch-22: if you don't distribute keys, then nobody can read your content, and they have no reason to buy it; but if you do distribute keys to purchasers, then they can redistribute them, EVERYONE can read your content, and they have no reason to buy it.
Locking down the spec for DRM, requiring it in ROM, building it into the operating system...none of these things will help. The core issue is, the keys have to exist on the recipient's machine in order to read the content, and once there, they can be discovered and put to "unauthorized" use. Granted, 9 out of 10 computer users may not have the knowhow to do this, but it only takes one or two to discover the method and propagate it. DRM as a content restriction method is doomed to fail.
(The technology could be put to legitimate, useful purposes, mind you, as a way for the OWNER of the machine to secure it against running untrusted binaries; I think this is one reason why Linus does not hate the technology itself.)
Exercise in futility. Posted Mar 22, 2006 22:56 UTC (Wed) by khirsha (guest, #21843) [Link] But, i tink they can crypt with your public key when you buy some content, so that only you can decrypt with your private key. And probably you have no advantage to distribute your private key with the content you want to "share".
Exercise in futility. Posted Mar 22, 2006 23:15 UTC (Wed) by anselm (subscriber, #2796) [Link] DRM is not about encrypting stuff so only you can read it; DRM is aboutencrypting stuff so that only your monitor (and speakers) can read it and you can't.
DRM is mostly driven by the fear of Hollywood companies that people will
Anselm
Exercise in futility. Posted Mar 23, 2006 9:16 UTC (Thu) by khirsha (guest, #21843) [Link] The problem is: who as the control on the management of the keys? Not the tecnology. But i agreed with the fact that in these times it would be better to don't use that thecnology, as probably the various content provider would gain that control.
Exercise in futility. Posted Mar 23, 2006 1:38 UTC (Thu) by mmarq (guest, #2332) [Link] Brilliantly explained !
Exercise in futility. Posted Mar 23, 2006 7:07 UTC (Thu) by efexis (guest, #26355) [Link] No, you can send your encrypting key to the content provider, who will encrypt the content with it before sending it to you. However, your decryption key is locked in a controller chip, that will decrypt the content, but not release the key (with laws in place to make it illegal to even try and extract the key).
The controller can be made to only accept decrypt data instructions from software that has it's binary image signed with another locked key, locking down your system. You can't remove the hardware, as that contains the key to your content, and you can't run different software (that, for example, lets you save the unencrypted data to disk) because the controller won't obey it unless it's signed by the very people who don't want you to be able to do that.
It can work, but only if people let it... and I have a feeling enough of them will.
Exercise in futility. Posted Mar 23, 2006 19:02 UTC (Thu) by ekj (subscriber, #1524) [Link] Yes. *assuming* you can design a chip so well that millions or billions of them can be produced and sold without a single one of them somehow leaking the key, this would work for the first part of the problem.That's a pretty tall assumption by the way, so called tamper-proof hardware never is -- at best it's tamper-resistant to a higher or lower degree, 100% proof is nothing, if it can be assembled, it can also be disassembled. And remember that only *one* person needs to remove DRM, it's not required that everyone does, it's sufficient that *one* person breaks it, and distributes the resulting unencumbered file. But it doesn't touch on thhe second part of the problem at all: What exactly is this chip going to *do* with the content, once it's decrypted it ? The only answer is that for the decrypted content to be useful, it must send it to some sort of output-device. For sound, for example, this will typically ultimately be a speaker. You cannot drive the magnetic coil of a speaker with an encrypted signal. (well, you could, but it'd sound like white noise) so clearly the signal *HAS* to be unencrypted and in the clear at the very least the last few cms to the coils. Yes it's analogue. No it doesn't matter. People who are satisfied with crappily encoded 128 Kbps mp3s will be *perfectly* happy with a high-quality resampling of the signal sent to the speakers. Video ain't much better -- it's sligthly harder to resample in a good way, but only sligthly, and like mentioned: only one person or group needs to do this, the rest go on sharing the unencumbered work like usual.
Exercise in futility. Posted Mar 25, 2006 11:09 UTC (Sat) by job (subscriber, #670) [Link] A better scheme is to produce billions of chips with individual keys, then you can revoke all leaked keys.
Exercise in futility. Posted Mar 23, 2006 18:31 UTC (Thu) by jmorris42 (subscriber, #2203) [Link] > Open source or not, I can see no way that DRM would actually work.
As a software only implementation I'd agree, it can't be 100% secure. Enter TCPM. It can be secure, whether we want to live in a world with it's implications is another question. But it is coming so we need to be thinking about scenarios we can live with. In a nutshell, here is how it would work in a perfect world:
I buy a computer with a TCPM module. It ships with a couple of keys preloaded and immutable. It identifies itself as an IBM made module embedded in an IBM computer (or Dell, HP, etc). It also has a certification key from Verisign and probably some other certifying authorities that this is indeed a verified hardware design. It also has an individual identity. On first boot I add an identity for myself and my organization.
Next I drop in a RHEL DVD. I tell the machine I want it to trust RedHat Inc. when it refuses to run their code. And indeed the TCPM, upon examining the crypto block on RH's kernel finds that it deigns to run on the computer by virtue of the Verisign key promising a secure hardware platform. So now with RedHat's keys installed the boot kernel can execute and installation proceed.
With RHEL up and running I want to open a document. OO.o is signed with RH's and OO.o's key. My document is only signed with my own key but my key trusts RH's key so the document is readable and since I trusted RH not to sign a version of OO.o that can violate the security model I should be ok. Nobody else will be able to get at my plans for world domination. Add the key for SPECTRE and my minions will also be able to read and annotate them.
Next I insert a next gen DVD movie. The movie only trusts the DVD-CCA's key. But that is OK because RedHat shipped a player (yea right) signed with both the RH key and the DVD-CCA's key, which now gets downloaded into the TCPM by because it already trusts RH's key. The DVD plays. Of course the DVD-CCA only signed on because they could trust (or trusted the results of a third party code audit) RH to ship a DVD player that won't rip the bits to a Divx;) file and probably reencrypts the video down a HDMI plug.
Later, a small flaw allows a leet script kiddie to get an executable onto my machine, but it doesn't run because he can't get it signed with a key I trust. Because in this world even bash scripts have to be signed.
Now I install my own white box enterprise linux distro into another partition. Again I have to approve that key. Of course while that kernel is running I can't run any of the RH binaries because they won't trust my kernel. My dvd player won't be signed by the DVD-CCA so I can't play commercial movies, but home movies still play. I can still open my own documents because I trust my own key. But I can at least open up the security enough to be able to write/compile/execute code I have written, the downside being that I am leaving myself open to the script kiddie when he tries me again.
Now let us examine a commercial stack. When I insert the Windows DVD I again tell the system that Microsoft is OK. It then boots and begins installation. But soon stops to ask for a license. It shipped on a seperate media, locked to either the individual serial number for the machine or to the manufacturer key (or more likely a key for the model) in the case of a major OEM. Other than that detail everything else works as above.
Not the most appealing future, huh. Software development on the lower parts of the software stack slows to a crawl or stops outright. Because the only way this stuff works is if EVERYTHING in ring0 is signed by someone every process running in userland trusts.
Exercise in futility. Posted Mar 23, 2006 18:43 UTC (Thu) by flewellyn (subscriber, #5047) [Link] This is where hardware hacking comes in. Logic probe, soldering iron, EEPROM reprogrammer.
Exercise in futility. Posted Mar 24, 2006 5:16 UTC (Fri) by nlucas (subscriber, #33793) [Link]
Did you know 64 bit Windows Vista forces every driver to be signed by Verisign? This until someone finds a way to get around the driver install thing, off course.
Exercise in futility. Posted Mar 24, 2006 22:20 UTC (Fri) by mmarq (guest, #2332) [Link] " > Open source or not, I can see no way that DRM would actually work. "
Lets suppose that someone on a next generation computer fires up this VM(virtual machine) on this special VMM. It emulates in "perfection" the present hardware, TCPM, BIOS, everything relevant.
*Pretty good* changes are that even if the security is build around unique pairs of hardware/OSes and or /applications relationships, it surely means that it isnt uncrackable... only that black hats have to do it twice for the same piece. Probably it will be exponetially more difficult, cant tell exactly, but computer's power is also groing exponetially!... and most important there wont be the needing of soldering irons, or EEPROM reprogrammers.
It also means that data protected that way is only decryptable and editable in one specific machine. It also means that on the fly *backup and restore* is going to be tremendously more complicated, if some piece of hardware enters next live or get stolen.
If the relevant factor is the *trust* on a 3d part certification authority, obviously residing elsewhere outside, then those have been faked in the pass and nothing indicates that it couldnt be done in the future. Nevertheless in this case, i dont know if the secrecy of those "world domination documents" wouldnt happen to be available *pronto* to the spy industry.
If other of the intented effects is to track on the fly the "point of presence" of an attacker, then nothing prevents some jocker black hat to put on a CD or other portable medium, his VM attacking environment, and run it from a White House or a FBI office compatible computer, if he as acess to them... or even distribute it!... it *could* be a hell of a dynamic point of presence!
It also means that upon hardware or OS upgrade, if back data portability is an issue, like in entreprises, it means they(entreprises) can only resort to the original vendors, charging certainly *some* extra for the service. while some startup or a more flexible entreprise can resort to the networks of the local mafia, to get cracked stuff for half the price.
Honestly no punt intended, if i say that a technology could be good if it intends business, even if it gets tears on the face of some D.Corleone for the wrong reasons, but for the exploding world of new Linux Distros every year with possible commercial focus, it *could* mean do it now *hard* or do it *never*.
Yes things could be much more safe for the layman, than today, but all in all this DRM thing, is going to be much more a expensive annoyance than a real feature.
Sun's "open source DRM" specifications released Posted Mar 25, 2006 20:58 UTC (Sat) by jayorke (guest, #10685) [Link] Developers of "open" software should be focusing on other more useful projects other than DRM. DRM is not just an encryption project, DRM is copy protection. DRM is not needed in healthcare; locking down I/O based on user_id and making sure people don't walk out of the building with papers and hard drives is not improved by DRM. There are other projects for preventing access to files, encrypting files, and limiting access to computer peripherals. Currently the only way to fully prevent someone at home from copying a music and video is to keep them from having it. This is the way it will be until our ears, eyes, and/or mind can accept personalized encrypted content (i.e. probably never). I don't see how someone could ever fully prevent me from copying what I can see and hear without preventing me from accessing hardware that can record what I see and hear exactly as I see and hear it. I would seriously fear the day we can't access recording devices to record what we see and hear.
|
|
||||||||||||