Hey all, I've been extremely frustrated with music stores/the music industry in general these past few days. After buying some music (from Real's music store), I found that it was DRM-protected and could only be played on my Windows machine. RealPlayer 10 for Linux did not include a DRM plugin. I see that this could possibly lead towards a DVD/CSS-type thing. I've been thinking about an open-source solution to this problem. Now, I can understand why people wouldn't want an open-source DRM library - programmers/hackers could easily look inside it and 'unprotect' music they bought. I've been thinking about how to stop that and I've come up with a preliminary plan for making a DRM library. However, I still haven't figured out how to stop hackers from exploiting the system and bypassing restrictions. I suppose that it could be turned closed-source if it was found that it is impossible to prevent the majority of people (over 90% shall we say) from hacking the system. And that's where I need ideas... how to stop hackers from bypassing restrictions put on by this system. There might even come a point where it's impossible to do so - and it would be necessary to make a closed-source library/component that would be inaccessible to hackers and would take care of the DRM-ming. OSS zealots would say that there's no need for a DRM solution cause we should encourage people to make 'free' music. But most artists probably wouldn't want to go directly to 'free' music, and current Linux users want to listen to current music too. I know this won't be adopted by anyone anytime soon, but it's just a plan. I'll propose it to whomever I can get and hopefully someone likes it [smile]. I've tried to take into account all the restrictions major places like Real put onto music. But it's not enough to cover everything without a closed-source player... But anyways, here goes. The situation - user is buying music from a music store. Music store wants to restrict playing of the music to a certain number of computers. That's the basic gist anyways: My plan First of all, the music-store side. There's a login server (key server), the web server (interface), and a data server (stores music, in unencrypted form). Each user that registers with the login server is assigned a unique key. When that user logs in and tries to buy music, the music is fetched from the data server and passed through an encryption module, where it is encrypted with the user's key. It is then downloaded to the user's machine (in encrypted form). So far so good. On the client-side, the user has a music player that has a unique music-player ID number. This ID number might be assigned when the player's downloaded (i.e. same technique as with the music - an ID number is attached as a resource to an EXE or tacked onto a Unix Makeself script), installed (fetches an ID from a server during 'registration'), or when the user creates an account on the music store. Anyways, the music player now has a unique ID number. This number is also stored in the music store's database (maybe in the login server, whatever). Each ID number will represent one separate 'computer' that the user can play his/her music on. Now, when the user goes to play the music, the player first sends the player ID to the server. The server checks this ID, and if it is correct (i.e. if the user has open 'computer-slots' left on the server), the server sends back the user's key. The player might cache that key (so dialup users can play when they're offline). The player then uses the key to decode the music and play it. Problems Now here's the open-source problem - at any point, a hacker could look into the system's source code and exploit the system. For example, when the player is assigned a player ID, the hacker could take that ID and put it on every other computer he owns, so the music store thinks it's one computer but he can play it on, say 5. He could also take the key and pass it around, allowing him to play it anywhere. So, solutions to this? You could obfuscate the location of the key/ID, but merely looking into the source code would reveal the location. You could obfuscate the source code, but a determined hacker could still figure it out and, it would kill the purpose of open-sourcing it anyways. I know some programs (i.e. 30-day trials) store the day information on the MBR or some other inaccessible area, is that a feasible solution? Ideas, please! Sorry for the long post! Cheers!

The second case is unpreventable as far as I am concerned. The current DRM scheme, and any for that matter, cannot stop this. Burning songs to a CD will also mitigate this.

But as for your first point, I'm looking for possible solutions to prevent the user from using the key illegitimately. I hope to have this affect average home users and not-so-experienced hackers (like myself). Experienced, determined hackers I have no hope of stopping.

But I don't need pessimistic comments like that, I'm looking for solutions, and I'm already aware of the problems (unless you care to present something which I haven't mentioned yet, which I am completely willing to accept).

Cheers!

Quote:Original post by fyhuang
Hey all,

I've been extremely frustrated with music stores/the music industry in general these past few days. After buying some music (from Real's music store), I found that it was DRM-protected and could only be played on my Windows machine. RealPlayer 10 for Linux did not include a DRM plugin. I see that this could possibly lead towards a DVD/CSS-type thing.

I've been thinking about an open-source solution to this problem. Now, I can understand why people wouldn't want an open-source DRM library - programmers/hackers could easily look inside it and 'unprotect' music they bought. I've been thinking about how to stop that and I've come up with a preliminary plan for making a DRM library. However, I still haven't figured out how to stop hackers from exploiting the system and bypassing restrictions. I suppose that it could be turned closed-source if it was found that it is impossible to prevent the majority of people (over 90% shall we say) from hacking the system.

And that's where I need ideas... how to stop hackers from bypassing restrictions put on by this system. There might even come a point where it's impossible to do so - and it would be necessary to make a closed-source library/component that would be inaccessible to hackers and would take care of the DRM-ming.

OSS zealots would say that there's no need for a DRM solution cause we should encourage people to make 'free' music. But most artists probably wouldn't want to go directly to 'free' music, and current Linux users want to listen to current music too. I know this won't be adopted by anyone anytime soon, but it's just a plan. I'll propose it to whomever I can get and hopefully someone likes it [smile].

I've tried to take into account all the restrictions major places like Real put onto music. But it's not enough to cover everything without a closed-source player... But anyways, here goes. The situation - user is buying music from a music store. Music store wants to restrict playing of the music to a certain number of computers. That's the basic gist anyways:

My plan
First of all, the music-store side. There's a login server (key server), the web server (interface), and a data server (stores music, in unencrypted form). Each user that registers with the login server is assigned a unique key. When that user logs in and tries to buy music, the music is fetched from the data server and passed through an encryption module, where it is encrypted with the user's key. It is then downloaded to the user's machine (in encrypted form). So far so good.

On the client-side, the user has a music player that has a unique music-player ID number. This ID number might be assigned when the player's downloaded (i.e. same technique as with the music - an ID number is attached as a resource to an EXE or tacked onto a Unix Makeself script), installed (fetches an ID from a server during 'registration'), or when the user creates an account on the music store. Anyways, the music player now has a unique ID number. This number is also stored in the music store's database (maybe in the login server, whatever). Each ID number will represent one separate 'computer' that the user can play his/her music on.

Now, when the user goes to play the music, the player first sends the player ID to the server. The server checks this ID, and if it is correct (i.e. if the user has open 'computer-slots' left on the server), the server sends back the user's key. The player might cache that key (so dialup users can play when they're offline). The player then uses the key to decode the music and play it.

Problems
Now here's the open-source problem - at any point, a hacker could look into the system's source code and exploit the system. For example, when the player is assigned a player ID, the hacker could take that ID and put it on every other computer he owns, so the music store thinks it's one computer but he can play it on, say 5. He could also take the key and pass it around, allowing him to play it anywhere.

So, solutions to this? You could obfuscate the location of the key/ID, but merely looking into the source code would reveal the location. You could obfuscate the source code, but a determined hacker could still figure it out and, it would kill the purpose of open-sourcing it anyways. I know some programs (i.e. 30-day trials) store the day information on the MBR or some other inaccessible area, is that a feasible solution?

Ideas, please! Sorry for the long post! Cheers!

DRM is a flawed concept, at least from a security stand point, and can only be implemented most effectively in closed systems (something the PC is not). Even on closed systems it's subject to work arounds (like mod chips for the XBox and PS2). Reguardless of how elborate the system it all boils down to the fact that the encryption alogrithms we have weren't designed for this type of use.

Typically when encrypting a message or content there are three groups. The sender, the reciever, and the attacker. The sender being the person who creates the message or content and only wants the reciever to beable to have access to it in a usable form while keeping the attacker out. With DRM the reciever is also the attacker. Encryption only can only control who has access, not what one can do with the information once one has access. For the user of the content to have access he has to have the key to decrypt it, so the security of the content rests on the designers ability to hide the key.

If your going to try and design a DRM solution you best design it with failure in mind, because chances are it will fail. You probably should include features that minimize the damage of a crack like key revokation. So I wouldn't worry so much about make the protection scheme elborate so much as making the failures less damaging.

Bottomline if someone wants the content bad enough of their going to get it and with P2P and the internet it only takes one copy.

In the end DRM ends up punishing honest people and doing next to nothing to stop pirates. In otherwords it keeps on honest people honest.

How can you ever stop users from intercepting the signal sent to their sound card and recording that? If you can't stop that, then you can never win. The question becomes: Is it best to hold out and keep trying to make the "old order" function, or is it better to embrace the "new order"? In fact, that is a non-question. Someone will embrace the "new order", and if it's not you, you'll be out of business.

The only way to do DRM effectively is to do the decryption in hardware. You have a special decoder card in your PC (iPod, etc) hooked up to the sound output directly, and the PC sends the public key to the server, which encrypts the file so that only that once piece of hardware can decode it. This way you never have a decrypted stream in memory, ever.

You can still make analog copies, but that's not what the RIAA is up in arms about.

The only drawback with this scheme is that you can't give a user a license to play the song on 5 different machines without sending them 5 different files.

DRM'd music is a stupid idea. What am I paying for, exactly? The right to listen? That's like buying a watch that you need special glasses to read the time. If anybody could just look at your watch, why would they go out and buy their own? I mean, I could just stand up every few minutes and yell out the time and then nobody around me would ever need to buy a watch! And then how will the watchmakers make any money?

Tom

I'm a huge hater of DRM, but - the 'big guys' use it. I will always actively support Linux, OSS, non-DRM, Creative Commons, etc. but until everyone else switches, I still have to retain my Windows knowledge and development tools (damn Windows ports!), I still have to use DRM to listen to music, and so on.

I suppose you got a point there though... why should I personally make another version of DRM?

Cheers!