DRM Video encryption

Question

I had some work where I needed to secure streaming. So I looked over all DRM protections that are currently available, and then I found out that I had 3 opinions, first to use very expensive DRM (Adobe) that would cost fortune, second one was to use some cheap one which require installation of some bad quality plugins and doesn't have support for all browsers and third one was to use AES-128 encription which is not really DRM, but can handle some things. Then I start thinking, and here is what I did.

I created streaming server that will: Create separate key for EVERY chunk in EVERY session, that means that key never repeats. chunks are relatively small 1chunk per 3 seconds. then I encoded key by base64 and got 24 bytes that were exactly 192 bits which is same length as AES-192, After that I shifted every byte for specific number of spaces, for each character different shift and replaced padding of 64 with some random chars. As a result I got unrecognizable base64 which looks like random key. Then after that I did reverse in the flash player. and as a result I got player working pretty good. And changed player to fake aes 192 by m3u8 playlist information.

So basically site is intended for small language group of people (around 12mil) and generally doesn't have very valuable content (videos that are valuable for students). Now What do you think, what is possibility for someone to find out what is goung on and how to decrypt (basically i believe they will try to decode first as AES-192 because of key length and m3u8 info)? Do you thinkthis is enough secure for low budget in low salary country?

Answer 1

Let's get this out of the way first: DRM is not a solvable problem.

Simply loading the flash player into a reverse engineering tool and reading the code will reveal what you did, and since you're giving them the key they can just decrypt the video. It's something anyone familiar with Flash reverse engineering could do, and it's probably something you could pick up from Google if you've got a background in general code and security concepts.

If you're looking for something more solid, you could look into solutions which use HDCP, which essentially provides end-to-end encryption of content up to the actual display device (e.g. a computer monitor). However, this may limit your userbase, as the HDCP feature was designed primarily for use in devices like BluRay players where TVs are known to support HDCP, rather than cases like computer monitors which may not (though many do).

All in all, you just have to decide how much effort you want to put in as a deterrant. If someone wants your video, they can capture it just fine using a screen capture application (e.g. Fraps) or exploit the analog hole.

Answer 2

This is a "security by obscurity" design which is wrong because it's based on secrecy of protocol rather than secrecy of an encryption key. As long as there is a motivation to dump the stream, someone (especially students) will break this. On the other hand, if there is no motivation to dump the stream, there is no reason for DRM.

Personally, I think DRM is a bad idea and is never going to work the way it is supposed to (i.e. prevent piracy). In all cases I came across clients either don't care for DRM since it isn't bothering them or they find their way to non-drm content (paid or otherwise) since they don't want to be bothered by restrictions imposed by DRM (like installing Silverlight or such). In either case, piracy is not prevented - the first group isn't going to pirate while the other one may, if the content is not available easily for a reasonable price without DRM.

Security-wise speaking - a DRM only works if the entire chain is secured, therefore all of your 12mil clients would need a DRM-enabled devices, OSes, browsers, graphics cards and displays and you need to pay for DRM to someone who can guarantee the integrity of its data throughout this chain. Anything less isn't a DRM.