On Wednesday 31 October 2007 14:19, Andy wrote: ... > All I have to do to prove this false
False != lies. It can simply be wrong. There's many possible reasons there. > , is to demonstrate that 1 Open > Source DRM solution exists. > You must therefore disprove that all the following exist: > http://www.sidespace.com/products/medias/ > https://dream.dev.java.net/ > http://sourceforge.net/projects/openipmp You say the word "solution" here. A solution is only a solution if it solves a problem. If it solves a problem that problem can be defined as requirements. We then get into "petty" details of whether the phrase "no open source DRM" is the one or "no open source DRM solution", or whether it means "no open source DRM that can be trusted because if one did exist attacking it would be easy because the source is there, which means it would either have to be classed as weak DRM, broken DRM or not DRM". We also get into who gets to set requirements etc. (petty is used here as tongue in cheek :) ) Afterall ROT13 could be viewed is a simple DRM mechanism. It's also open source. Is it even valid? Yes, if you don't *know* I'm doing ROT13. However, we could chase our own tails as has happened month after month on this list :-). So I've spent my evening doing something more productive which hopefully you'll find interesting, and any (constructive) comments you have would be welcome. OK, here goes.... OK, why the reply? I said I'd step out the conversation earlier. Well, figured I'd spend some of my own time looking at the options you've put forward to look at the following: * Can it really protect the keys from the user/person who wants to watch the content. (required to protect the content) (The trusted parties (by the content producer) need to be the distribution system and the decode/display equipment. The user is the untrusted party. This is of course extremely different from the usecases where encryption is normally used. * Can it really protect the playback chain? (If you can _easily_ intercept after decode it's not useful) (nb in both cases protect means "to a reasonable extent preventing relatively obvious attacks") * Sheer codebase size. One thing that almost all code metrics show is that bugs are related to lines of code, almost irrespective of language. In a security system bugs == attack vectors. As a result a security system that is small enough (but no smaller) is likely to have a lower number of attack vectors, generally speaking. * Able to adhere to the rights model hard fought for. (Remember the biggest achievement[*] of iPlayer is to change the public discussion from whether the BBC should even be allowed to provide *any* form of download service into a big argument regarding how much more it should be providing. After all there was huge political opposition to a download service. The rights agreed were as far as I can tell very hard fought...) [*] In my personal opinion only * An obvious evaluation criterion is whether it supports (or could be made to support) appropriate audio/video codecs, and potentially also interactive content, subtitling and so on. (Since, yes, there are rights associated even with subtitles...) * Have some form of support mechanism in existence. * Adaptability and potential to be embedded easily into other systems of various kinds. (Obviously has bonus points if there's an existing demo) I'm using the view "how easy would this be to integrate into Kamaelia without an obvious attack vector" as being my metric for the last bullet point. Also, since I'm doing this on my own time, please don't flame me -- I'd far rather be spending more time on Kamaelia related stuff :-) I'm not likely to slavishly follow this list, but its what I'm looking at. I know you were simply looking to debunk the phrase "No open source DRM", but its worth seeing if the options you put forward are viable and if so why/why not. I don't expect to do all of them tonight :-) OK, let's start with this one, since it was the most accessible. > http://www.sidespace.com/products/medias/ A cursory looking at this DRM solution suggests it doesn't support this: (from the iPlayer pages) "This means that most programmes are licensed to be kept in your Library for up to 30 days. When you first playback a downloaded programme, it will expire and be deleted from your Library within a set number of days. This is usually up to seven days depending on its licence " (The license vault appears to store licenses with permissions, however expiry times/dates are absolutes not relative. It's nice though that the license file can set different sorts of rights expirations.) Being an open source system, this could be worked around. However it has a clear attack vector: "4. License Vault, a DBM file that stores and manages user licenses. Its contents are manipulated by the Media-S client library." ... "LICENSE VAULT OVERVIEW Working hand-in-hand with the Media-S decoding mechanism (such as the oggs123 player) is the license vault. The license vault is a local encrypted database that stores content provider and license information for each file. This DBM file itself is not encrypted, " Which makes it easily accessible. (It also has the potential for file corruption I note) "however by default each of the key values is encrypted using 1024-bit 3DES encryption using a key generated from specific user and machine information. The use of machine-specific information ties a specific license vault to a particular user on a particular machine, and it is this encryption that provides the tethering aspect of Media-S." However, it's also this that probably makes this removeable. (esp given access to source makes figuring out how to do this alot simpler. After all, you want to attack the key storage, something very difficult for an attacker in something like ssh because they don't have access to the machine, but a lot simpler if you own the machine. Looking at the code, decrypting these encrypted keys should be pretty simple, since the tether id (which the above text refers to) is generated (if you're not on windows) as follows: int getTetherID(char **cTetherID) { int ret = 0; int s = socket(AF_INET, SOCK_DGRAM, 0); struct ifreq req; int err, nRet; char cTemp[100]; if (*cTetherID) free(*cTetherID); strcpy(req.ifr_name, "eth0"); err = ioctl(s, SIOCGIFHWADDR, &req); if (err == -1) { //just use user id if no eth0 snprintf(cTemp, 100, "%d", getuid()); *cTetherID = strdup(cTemp); return 0; } snprintf (cTemp, 100,"%02x:%02x:%02x:%02x:%02x:%02x", req.ifr_hwaddr.sa_data[0], req.ifr_hwaddr.sa_data[1], req.ifr_hwaddr.sa_data[2], req.ifr_hwaddr.sa_data[3], req.ifr_hwaddr.sa_data[4], req.ifr_hwaddr.sa_data[5]); *cTetherID = strdup(cTemp); close(s); return ret; } (we are allowed to discuss code on backstage? ;-) :-) </tongue-in-cheek> ) Aside from anything else, this means that most Mac users would be have the tetherid. (the first ethernet device is not eth0 on a Mac, and many Macs have one user - and hence the same uid). Similarly Solaris boxes would also have issues. The other interesting issue here is that changing your network card would lock you out of the content you've paid for. Even under linux the labels eth1 & eth0 can be reassigned, and some modern distros *do* do this. *NOTE* _Because_ this is open source I've been able to examine it to find out the appropriate way to attack the DRM mechanism. With customisation however and a license to close this, the concept of a tether id is potentially useful, so this cuts both ways. (bad in that it made it attackable, good in that it opens up a line of thinking) Being tied to a single data format (a relatively impractical one at that), not supporting the rights model needed, a fairly obvious attack vector, having been in beta for 4 years with no updates in CVS over the same time period are all problems. Furthermore an analysis of the system at the time said this: "Both Media-S and OpenIPMP require lots of further development before their functionalities become of interest for mass deployment," - http://www.drmwatch.com/drmtech/article.php/3094761 (April 2003) >From a support perspective, there is none. But from a code size perspective, Media-S wins hands down: ~/Incoming> du -sh openipmp2/ dream/dream/DReaM/ Media-S/medias-1-0-beta-2 354M openipmp2/ 13M dream/dream/DReaM/ 580K Media-S/medias-1-0-beta-2 Is that too small though ? Based on the missing functionality across the board (rights model, media/format support, key protection, ability to move between machines/cope with NIC changes) I suspect it is. It gets bonus points though for adaptability. It's clear thought has gone into the fact that this needs to tie in with other systems, and being a relatively clear & straightforward set of C files is quite refreshing. Unfortunately it seems problematic to build. (Even though I regularly build lots of things with this machine) OK, so summarising this based on the things I mentioned I'd look at: * Can it really protect the keys from the user/person who wants to watch the content? NO. In my view they're not the least bit safe. They may as well be stored in the clear. (I haven't looked at how the vendor key plays a part here though, so that may need review.) * Can it really protect the playback chain? No, I don't think so based on the basic look tonight. I could be wrong there. It *could* be extended to do so though. The small codebase size would help here. * Sheer codebase size. This is pretty manageable. The codebase is pretty small. It's also pretty clear. * Able to adhere to the rights model. No, the library would need to be extended to deal with this. How it deals with relative time is completely undefined here. This is however potentially an opportunity. * An obvious evaluation criterion is whether it supports (or could be made to support) appropriate audio/video codecs Only supports ogg vorbis, though with work (perhaps significant) could be made to do so. At present I'd guess its just too niche there. * Have some form of support mechanism in existence. The codebase hasn't been touched in 4 years. As a project goes, its stone cold dead. (mind you, open source software don't die, they just starting resting & pining for the fjords) * Adaptability and potential to be embedded easily into other systems of various kinds. I think due to sheer size and clarity of code this is actually relatively realistic. If a better mechanism was found to protect the license vault, this could be a nice stating point. It could probably be embdeded in Kamaelia for example with effort. (like most pure C libraries can) Being GPL rather than LGPL or BSD is a pain though. Though they will sell you a license to be able to close the code. (which may be necessary to add an extra layer of protection onto the keys) Overall, its a nice try, but in no way matches the criterion I'd personally set, though there is a core there. I'll look at DReaM or openipmp tomorrow evening hopefully. (the former is a "look again" - I looked at it last when it was in early spec stages) (and no, I can't do the same for windows media DRM. I'm not privvy to the details, and I'd probably have to sign NDA to get them :) Apologies if that's all a little random - and also, improvements on this summary (and on criterion) welcome. :-) Regards, Michael. -- (NB I'm doing this in my own time to see whether the options you put forward seem reasonable so it's entirely personal - DRM isn't my day work, and incidentally this is typed on a Linux box, which means yes, I can't use iPlayer either :-) Also, there are people who DO have this as their day work, and I believe are looking at options. ALSO important to note:: __NONE__ of this is a BBC opinion) - Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html. Unofficial list archive: http://www.mail-archive.com/[email protected]/
