Ways of protecting media-content. Is DRM possible on the web?

A fairly large portion of our projects have to do with storing and publishing video content on the Internet. One of the many questions clients ask is that of protecting content from illegal reproduction and distribution. There is a wide-spread belief that there exist programs and technologies which are capable of guaranteeing that the reproduction and redistribution of licensed-content is impossible. In our report, we sought to discuss existing technologies, their vulnerabilities, and free and open-source equivalents which grant the same level of protection as proprietary and very expensive products.
Who: Denis Eldandi, Aleksandr Kistanov
Where: RIT 2011
When: 25-26 April, 2011

Denis Eldandi: Hello, everyone! So, I am going to talk about everything that’s wrong with DRM technologies, and Aleksandr Kistanov is going to talk about how to live with it. Let’s start with a short introduction on the streaming video and DRM. The idea behind streaming video is to play video or audio from a network, with fairly little delay and little buffering, without completely downloading the file beforehand. This is called “streaming”. Streaming saves the user’s time and nerves, as well as traffic. In actuality, this doesn’t happen at all in non-streaming media. We will talk about stream broadcasting in regards to video-hosting on the Internet, and in the same fashion, about streaming technologies, like RSTP, RTMP and HTTP pseudo-streaming.

With the arrival of licensed-content on the Internet, especially high quality content, copyright holders are beginning to worry about protecting content from illegal reproduction. Thus, they are offered copy protection - DRM (Digital Rights Management).

All in all, DRM is capable of prohibiting and limiting the creation of digitally-spread reproductions. However, several DRM system vendors are now saying their purpose is just to complicate the creation of these reproductions. The majority of DRM systems use fairly strong encryption. A secret key is needed for reading encrypted information. However, there’s no point to this since the key you need for legally reading information and watching films, for example, is the same for making illegal copies. In fact, DRM systems try hiding the key from the user one way or another, but since the user-side of DRM systems rests entirely in the hands of the user system, it is completely possible to get the specified key using the so-called “trusted client problem”.

Another vulnerability, granted a less interesting one, is that a film will at one point or another end up in analog format, and not in the cable to the TV, but on the very screen, and from there it can always be written to a disk, albeit some loss of quality. The so-called analog hole is extremely vulnerable. And of course, very few complete DRM systems exist which wouldn’t provide media in an open (digital) format. For example, there is a rather wide-spread DRM “bypass” method—copying the stream from the computer’s video-buffer (provided you made a screencast). On the other hand, Windows Media Player, for example, uses various techniques so that this couldn’t happen. But developers burn the midnight oil and get around them one way or another. I haven’t actually said anything new here; this is all well-known information. There is an organization, a movement, which talks about this on screen. But DRM system providers still insist that everything is fine with them.

RTMP developers roughly thought about this. Initially,the RTMP protocol was developed by Macromedia for transferring audio and video over the Internet between Flash applications and CRM. It uses TCP port 1235 and works on a request and response structure: the client requests a URL and the server returns a video clip. There are various kinds of RTMP protocols. For example, RTMPT uses HTTP for transfers, but RTMPS uses HTTPS/SSL for encryption.

Then there is the RTMPE protocol, which was introduced for protecting licensed-content, and is now called “protected streaming” by its producer. Ideally, it should have “immediately killed two birds” – protect (encrypt a stream), and verify clients. The idea was that only the right client, who would perform a verification check on his side, could receive the video clip. The protocol would not show it to the wrong people, and it would have been impossible to intercept a stream between the server and client. RTMPE does not use SSL for encryption. Developers decided that this was quite costly on the side of the server–that is, costly in terms of performance–and decided to develop a homemade “hack”, which would use temporary keys and encrypt data using them. In reality, since there’s no kind of server authenticity verification on the client side, one could easily set up a man-in-the-middle attack, whereby the “attacker” receives content in an open format and saves it on their hard drive.

Also, their so-called client verification is based on a fairly strange algorithm: a flash application calculates its own hash and size and sends it to the server. The server supposedly knows these values, and if the data that arrives is incorrect, it will not return the video. But in all actuality, it’s not that big of a deal to write your own client that can download and save data onto a disk. Of course, saving an RTMPE stream is a bit more complicated than right-clicking the mouse and saying “save as”. At the same time, there are client programs that download anything via RTMPE. And of course, if developers set their sights on complicating illegal copying, then they could probably achieve their goal one way or another, but it would be an exaggeration to say that their content is protected. How can we get out of this situation? This is what Alexander will tell us about.

Alexandr Kistanov: As it was said, there is no real way out of this. Practically no existing DRM solution offers a 100% guarantee that content will be protected and safe. So what should we do? As it turns out, there is no need to use any one specific DRM solution. The thing is that all existing DRM solutions for web-applications have their shortcomings. For example, it’s the platform’s limitations in particular for some of these; for others, it’s that these solutions only work on Windows and are resource-intensive. Additionally, DRM solutions often cost a significant amount of money, and again, they are quite difficult to develop.

But as we’ve demonstrated, there isn’t a particular reason to use them. And one can practically achieve the same thing using a simpler solution. We, for example, don’t usually use RTMP on our systems, instead returning video files via an HTTP-protocol. This allows us, for example, to return a gigabyte of traffic and even more with a fairly weak server. But how can you make file copying more difficult with this approach?

There is actually a possibility for this. In Adobe Flash, for example, starting with version 10.1, a function appeared which allowed you to form a video-stream that is playable in a media player on the fly. . This method is append_bytes(). . Using this, you can quite easily write a simple solution to complicate file saving. The video returns simply through HTTP. On the server side, it is coded on the fly with any kind of stream encryption; on the client’s side, it is encrypted using a hard-coded key. It would not be difficult for a programmer to write this, and it’s not much worse than any other existing DRM solution. Thus, file copying will be made more difficult.

Incidentally, why then, if it is so easy to copy content, do services which in fact duplicate already existing content so rarely pop up?

This is because returning the same quantity of files like on Youtube requires the creation of the same kind of expensive and complicated infrastructure that they have. The temptation arises for potential culprits to use content that’s already situated on legal servers, but on their own site. This is possible if they buy a paid account, receive access to a high-quality video, and afterwards, create their own site where they use the video for their own purposes. However, it is quite easy to get around this problem with a simple solution that uses so-called URL verification access tokens, which are supported in one form or another by practically every HTTP server. The thing is that when we create links to content, we generate a token that contains information about the life span of the link and the client IP address it’s valid for. That approach practically eliminates the use of linking content for illegal purposes.

Thank you all for your attention!

Audience questions:

- Does Warner Brothers know that DRM can be cracked? Why do they require DRM?

Denis Eldandi: Warner Brothers knows everything about this perfectly well. They require DRM because they rarely heed the advice of technical experts. Their decisions are usually made by some management that grew out of the “old school”, the old kind of information distribution model. They’re a bit used to doing things the old fashioned way and “turn a blind eye” to several problems.

- Could you talk about Flash Access 2.0: how can it be “opened” and what are its weak points?

Denis Eldandi It uses a different principle of operation—a license check is performed on the server. Our content is always sold in an encrypted format, and the key is like the one in your example.

At the same time, Man in the middle attack could easily be avoided. It would be enough to check the server’s authenticity like in SSL/HTTPS. The problem is that the client always has the key needed for decrypting the content, and he would always be able to use it.

- Unfortunately, I’m not really a specialist when it comes to Access. But from the bit of information I’ve read: if content isn’t downloaded but watched on-line, then we request a license from the content owner’s server before receiving the stream. This key also has a limited “life span”. It’s as if it affirms that if I don’t use a “bootleg” copy of a movie, in principle, I won’t be able to watch it a second time without obtaining a new license?

Denis Eldandi: What if you’re made a “client” who uses a good, proper key, but saves everything onto a disk?

- This isn’t about saving a video onto a disk, but how to play it.

Denis Eldandi: You are saving a decrypted byte stream onto a disk. That is to say, instead of sending it to the video card, you save it to a file. And the person who writes the program automates all of this. Where’s the problem?

- Tell me please, what’s the work structure for all of this? I want to watch a movie, so I go to the ticket window and buy a ticket. The ticket works only for my IP address for 5 minutes. I send a request to the license server and receive a license to watch content that is encrypted along the way. Orhow should I do this?

Denis Eldandi: You decrypt the content. But instead of watching it, you save it to a disk in an open format. Then you’ve watched it 3 times and gave it to all of your friends and family.

- Tell me, is Google Widevine a winner?

Denis Eldandi: Do you mean winner in terms of business or technology? You see, from a business standpoint, the winner is more of a marketing question. From a technology standpoint, there is no winner, because the idea behind DRM is initially strange.

- Hello! I have already been in the content market for a long time, and I wanted to say that all copyright holders have qualified personnel. They all know that stealing is possible, but little by little, small steps are being made so that their solutions somehow work at protecting information. I understand that your average Joe wants to watch a video for free, and that copyright holders want to get money from this. This is a normal struggle, and my only question is where it will lead to. It was properly said that that any given copyright owner will either impose a method that will more or less work for them, or they’ll reject DRM, which already happened several years ago when Warner, Sony and other major labels turned down DRM in regards to music. They said, “guys, we’re not ready because we have a high percentage of failures from people who said they couldn’t hear anything at all, or that the price was too high.”

It all depends on the trackers when all of the fresh seeds are shut down. It seems to me that several operating departments on trackers shutting down fresh seeds is by far a simpler and more effective battle than implanting a DRM chip into the brain of every user, which will still need to be upgraded. (laughter in the audience)

Denis Eldandi: How’s that? Administrative methods are far from working everywhere. In America, for example, they can ban and dispatch a police squad. But normal people have already moved to different countries.

- Look: on the site, for example, there are no fresh seeds. What’s playing in a movie theater can’t appear on the site, despite the fact that that they can come to an agreement with the operator that he take down a digital copy of the film, because there’s an administrative server barrier. As a result, it’s extremely inconvenient that a tracker can never get fresh content, and copyright holders need at least some time to sell their movie before all of this business with trackers goes away.

I am in no way defending DRM as a user, because it’s obvious to me that this is a problematic system. Besides the fact that you need to pay money, even though I’m quietly paying to see a movie at the theater, DRM has a multitude of problems: it’s bad, and at the same time, it only works on Windows. Another question: people come up to me like they do to technology providers and say: “we have the option to distribute ‘Avatar 2’ over the Internet 2 days before it’s in theaters, but we can only allow that if DRM is present.” And I say: “Sorry guys, there’s no DRM”. As a result, the contract and the money is lost.

Denis Eldandi: Yes, that’s why it’s easier to say: Adobe promised that RTMPE is secure, that’s why we do all of this.

And everything does just that, they’re just present: don’t tell copyright holders anything that we talked about here and everyone will be okay. (laughter in the audience)

Denis Eldandi: No more questions? Thank you, everyone!

Адрес: 119021, Moscow, Russia, Pugovishnikov pereulok, 11, office#4
Park Kultury, Frunzenskaya
Ask a questionClose
Your name
Your email address
Your question

Fill up the captcha