DRM simple clone

Question

I have been trying to encrypt media(Video and audio content) from a nodejs server to a client like android or iOS. I heard of DRM but could not get a reliable implementation of DRM.

I wanted to make my own implementation of protecting my content, But am not sure issues i would have with my implementation.

THIS IS MY IMPLEMENTATION.

Clients like android would first get authenticated from my server, then my server would pass a token to the android client, then this android client would request for the protected media with some request like

/get/video/:id/:token

Where id is the video content id and the token in this case is like the key, if the client doesn't have a valid token then the data will not be given to client.

QUESTION: Will this implementation work, can it protect my content from unauthorised clients, what are some of the drawbacks of using this?

Answer 1

I heard of DRM but could not get a reliable implementation of DRM

There is a good reason for this: DRM is a hard problem, and a solution to it could be leveraged to obtain incredible amounts of money. Doing a cursory search for "why DRM doesn't work" yields an abundance of articles explaining the whats and whys.

To win at DRM, let's say you have some piece of information you want only particular clients to have limited/regulated access to. The problem is that information can be copied, so once a client has received the information in question, you need some way to prevent them from copying it. If they can copy it, then they can save the data for a later time, or share it with others en masse.

Assuming that clients have complete control over the device that receives/displays the information, there is little that you can do to prevent them from copying the information using the device itself.

Practical solutions to DRM include:

• Treacherous hardware (hardware that the user does not have complete control over)
• Physically restricted access to the information
  • Secure storage facilities and/or armed guards
• Legal recourse against clients who breach the terms/agreement regarding the data

Will this implementation work, can it protect my content from unauthorised clients, what are some of the drawbacks of using this?

If your goal is to be the exclusive provider of the protected information, then your implementation probably will not succeed - This not because authenticating clients and associating their permissions with session tokens is no good, but because preventing clients from sharing the information after it has been received is very difficult.

You can prevent unauthorized clients from capturing the content off the network as it streams to the the authorized client by encrypting the content - However, you are still trusting the client to not share/record the content, once it is decrypted.

Drawbacks of DRM measures generally may include a less positive user experience - Successful DRM measures are generally invasive.

Answer 2

To answer your actual question:

Will this implementation work? can it protect my content from unauthorised clients, what are some of the drawbacks of using this?

No, this implementation will not protect your work because even if the client hardware is "trusted" (or "treacherous", depending on your perspective) it's still very easy to intercept communication between two computer network endpoints and capture any content and keys that are exchanged - this is especially true on typical consumer-grade devices where, unless you're using certificate-pinning, it's trivial to install self-signed certificates and DNS or ARP-spoofing to set-up a MITM attack). Your post implies you're operating over HTTP and makes no mention of preventing replay attacks so it's a trivial wget call to download a private copy of the media - crucially you also don't mention ever encrypting the media, only limiting who can originally download it.

What are some of the drawbacks of using this?

Your approach doesn't have any real drawbacks besides being generally ineffective.

Audiovisual media encryption generally makes use of encrypted content, rather than restricted distribution (which is what you're proposing) - so anyone can download some video file, but access to the keys to decrypt it is actually tightly controlled - and because a crypto-key is generally very short (64-512 bits in length) it's much easier to protect than a multi-gigabyte MPEG stream.

Existing DRM systems built-in to computers generally rely on operating-system level (i.e. kernel-module/driver ) components to restrict the user in some way, or to hold secrets (such as decryption keys) from end-users - for example encrypted memory that the OS takes active steps to prevent userland, or even kernel-mode, debuggers from reading successfully. Note that as these are all software-based they can all be defeated eventually - usually by running the code in a virtual-machine and using the VM host to pick it apart.

Should i say DRM is only meant for the big players, i mean how does netflix protect it's content, there must be some huge amounts of money spent by these companies

While DRM is mathematically fundamentally broken (as Bob (the intended recipient) and Charlie (the attacker) are the same real-life person) it's still possible to use varying techniques to delay cracks to maximize profitability - one example is the DRM used in popular high-profile video games - which can be very aggressive (e.g. StarForce) or annoying (SecuROM, etc) - which arguably do harm sales - but the video game publishers know that these DRM systems will prevent a pirate release for at least a few weeks, and those few weeks of exclusivity will mean more sales - even though it will generate bad PR.

As for Netflix - for their web-based player they use whatever DRM is provided by the supported web-browser (the same as Hulu, etc). For Google Chrome this is provided by Widevine; Edge/IE use either Silverlight (like Flash) or Windows' built-in "PlayReady" DRM system which uses kernel-mode components to protect decryption keys. I don't know exactly how Widevine works as documentation is sparse online.