3

Here's a situation.

I am the author of an app that allows my customers to stream videos on their local android device. I also allow them to download the video and store it locally on their android device itself.

But now I want to restrict the distribution of the downloaded video somehow. I want to ensure that the downloaded video can not be simply distributed to another user, who is not even registered with my app.

How can I achieve this ?

Some solutions that I could think of :

Encrypting the video with a key that's bound to my registration ID. The problem is that the key will need to be stored on the device itself. And if the device is rooted/compromised the key can be retrieved. Making an auth request before every time the video is allowed to be played locally. The problem is that is defeats the intended purpose of the offline playing of the video. Hence, not something very desirable.

qre0ct
  • 1,492
  • 3
  • 19
  • 30
  • You could tie a key to a video_id + user_id and store the key on a server. To view the video the user would reach out to the server with their credentials and video_id to retrieve the correct key for decryption. – RoraΖ Apr 15 '15 at 11:14
  • Yes, reaching out to the server sounds like to only (near) acceptable approach to solve the problem. But without any sort of server interference, it is seems very difficult. But then server interference kind of defeats the objective of pure offline playback itself. Don't you think so ? – qre0ct Apr 15 '15 at 13:16
  • Yeah I agree it defeats the purpose of offline play, but if you're on a mobile device you're most likely able to reach some sort of data. And I'm assuming you don't want the videos to be transferred to other devices period. – RoraΖ Apr 15 '15 at 13:18
  • What are your that model? Why are you worried about restricting access? Copyright violations? Sensitive PII? Government Top Secret? Technologically, you cannot completely prevent redistribution of streamed videos; you can make it harder, and you can plant the data with identifying marks to track leakages. All these can be circumvented by a sufficiently sophisticated attacker. – Lie Ryan May 14 '15 at 01:40

4 Answers4

5

You've answered the question yourself. You're trying to implement DRM to prevent users from getting the video off the device. In practice there is little you can do to prevent this. There will always be ways to copy the stream, even intercepting the stream (it has to be displayed on the device at some point right?).

So the only thing you can do is make it harder, but not impossible to copy it. You can also include some meta data to the video when streaming or when downloaded to identify the user which leaked the video.

Lucas Kauffman
  • 54,169
  • 17
  • 112
  • 196
  • I agree. But a little something with the meta data part - I guess on if at all I am leveraging metadata to figure out the leak of the source, that would still not help, because it is still prone to manipulations. Right ? – qre0ct Apr 15 '15 at 13:14
  • 1
    yep, but at least it can give some indication. another option is watermarking (invisible watermarks are possible I think) but then you need to render each video seperately. So this causes tons of overhead. – Lucas Kauffman Apr 15 '15 at 13:15
  • Ok, so could you please explain a little more, I mean what exactly do you mean rendering each video separately. And secondly, is it not possible to spoof a watermark. Apologies if it doesn't make a lot of sense- have limited exposure to watermarks. – qre0ct Apr 15 '15 at 13:18
  • 1
    Yep spoofing a watermark or blurring it (e.g. latest leak with GoT was caused by that) is possible. A watermark is included as part of the video ontop of the images. It's not a seperate set of data. – Lucas Kauffman Apr 15 '15 at 13:19
  • Great. That makes sense. But lets wait for some more time to see if there is someone in the community with a varied approach ! – qre0ct Apr 15 '15 at 13:27
2

Google has the Widevine DRM mechanism (Video DRM solution). A tool that can play with the Widevine internals (libwvcdm) can be found here -- https://github.com/EiNSTeiN-/chromecast-widevine-tools

There is also the Stagefright multimedia framework to supply DRM -- https://source.android.com/devices/media.html -- Josh Drake is doing a prezo on it at BlackHat US this year

UPDATE: ... and here is a fuzzer to mess with Stagefright -- https://github.com/fuzzing/MFFA

atdre
  • 18,885
  • 6
  • 58
  • 107
1

You don't have many options to solve this really:

  1. If you remove offline playback, then you can just use HLS with encryption, with the stream hosted in the server.
  2. Allowing offline playback, as you said, will need to somehow encrypt/decrypt the video. You could always leave the public key (encryption key) stored locally for encryption, but you need to protect the private key (decryption), so it could be stored in a server, and fetched right before local playback. But in this scenario you would need to be online in order to fetch the decryption key. Also to protect against key leakage, you will also have to add a root-protection mechanism.
alecxe
  • 1,515
  • 5
  • 19
  • 34
Gaspar de Elias
  • 11
  • 1
0

As other answers mentioned, this issue seems very close to DRM issues, with the sole but notable exception that as per my understanding you do not need the video file to be playable by any other software than your own.

To avoid any stored key, I would imagine the actual key to be deduced (like a hash) from several parameters defining your restriction (video ID, registration ID, some other information identifying the mobile for instance, etc.), thus providing a unique key per file, the actual key being stored nowhere but calculated upon file opening.

A bit the same principle as Windows generating an activation key deduced from the computer hardware in order to tie this installation to this hardware, the idea here would be to generate this key to tie this video file to this mobile and user.

Of course, the issue remains that some user may reverse engineer your application, deduce the key construction algorithm and publish a special app offering to decrypt your video. To counter that you may involve some obfuscation techniques, but as with the DRM you have to define a trade-off between the effort made to protect the content and the actual content value.

For instance, depending on your content and your app popularity, most users may not think it would worth to sacrifice their phone's safety by installing the decryption app from some obscure store, given that someone competently enough found it worth to create this decryption app in the first place and to maintain it to match your algorithm updates.

WhiteWinterWolf
  • 19,082
  • 4
  • 58
  • 104