Encrypting a live feed

[Razorholt]

Hi there,

I've been asked to find a solution for encrypting a live feed (Television) over IP. I suggested Verimatrix but I'm sure there are OS projects out there. Any idea?

Thanks,
- Dan

[NeonMan]

Maybe you can stream the data over apache/icecast/videolan server.
Once it is working (non encrypted) it's possible to use ssl with stunnel (or https directly with apache) so you get the stream encrypted

<edit>
Verimatrix is a pay-tv scheme isn't it? so I supose you want something like it.
with apache you can authenticate every user and give/restrict him access to any stream but you wont be able to prevent your users from recording the stream (if so it woul make it a DRM system and open-source and DRM are mutually exclusive)
</edit>

[Razorholt]

Thanks NeonMan for your answer.

What they want is a way to protect the feed. They sure can use https but that will not fix the authentication process, nor will it prevent any viewer to share URLs of the live content over the Internet.

Thanks,
- Dan

[NeonMan]

Yes, It's possible to encrypt the feed (over https) [This prevents snooping and account stealing]
I'ts possible to authenticate the user, preventing link-sharing and multiple viewers per account and viewing unsuscribed channels* (ie http basic auth)
But it's not feasible to prevent an authenticated user from copying and reditributing the stream since it's quite esay to re-broadcast a live http(s) stream.
Also most users lack the knowledge or motivation to do that so even with basic http authentication, most people wont re-broadcast or even record the feed.

Your best option is some propietary solution but keep in mind that ALL drm systems are flawed one way or another and thath if the stream can be viewed it can be copied.

Good luck anyway!

*my own server has some folders this way, once you enter it, the server will ask you for username and password, if unsuccesfull it will trow a 403 error.

[Razorholt]

Thanks again NeonMan for your answers. I talked to someone yesterday who recommended the new Microsoft DRM option (Ready Play DRM, or something like that). Since you can't use ssl on their Media Encoder 08 you have to use the DRM for securing the feed - $30k for the server side, $10k for the client side + $0.10 per subscriber. I need to double check the pricing but this is what I've been told.

I'm also looking at the simple AES option but the question is: how to encrypt the live feed on the server side? This whole IP security business is becoming complicated because my client doesn't even use WMP. He picked MPlayer...

[NeonMan]

He picked MPlayer
If using WM-DRM (whatever it's called) he wont be able to use mplayer (Wow! 30k+10k+users!), only windows media player on windows, plus video (I think) must be re-encoded to WMV then repacked on the ASF container plus encryption, one of your servers must be quite resourcefull to do re-encoding on real time.


Btw, what is the exact scenario of the system? is a server-to-end-user, or server-to-server feed (or both). On a server-to-server feed, standard protocols are more than enough, on the end-user aproach, you can only hope your users wont complain with the DRM. Imho if the user base is small enough, contractual obligations should be enough.

As a matter of fact... http://forum.doom9.org/showthread.php?t=127943

[Razorholt]

Well, we all know that DRMs are completely useless, including the major studios. Thing is, content providers do want to see some security around their video.

Regarding my client, they have access to raw IP feeds from the TV networks. They have a CDN in place and a streaming software that uses mplayer. The goal is to broadcast the content to end-users. Oh, and the servers have win08 loaded. And the protocol can be HTTP or RTSP. I'm personnally not in favor of DRM but what are the other options? Each viewer must be authenticated and the urls must be secured.

Did I answer all your question?

Thanks,
- Dan

[NeonMan]

content providers do want to see some security around their video.
True. (Sadly) The only readily available option here is using any drm. Setting up a scheme similar to the one described above would require some server-side programming to implement all the subscription & payment stuff.

I'm against the drm limiting what you do with the content once you have paid for it but I woul be willing to sign for a service which delivers drm-free content. I think there is a misconception around the DRM-Free content, this doesn't mean revenueless. You could grant users a feed provided they keep paying, once they sign off, they're unauthorized on the system.

Since content providers seem to be making pressure, drm could be a temporal solution (a temporal annoyance for the user) for you until you could find a better one. (the problem is that this temporal is likely to become permanent)

Anyway good luck with your service!

[Razorholt]

And I totally agree with you but just let me offer you my point from another angle, the broadcaster's angle or the one that supports the bandwidth costs. Although it's true that the TV networks will not suffer any losses when a "bad" user spead the links of a live feed on public forums, it's not true for the broadcasters - I experienced that first hand. So, restricting viewers from distributing content is a way to protect the broadcaster (or bandwidth provider) more than the content owner.

Now, if DRM is the best solution to avoid the scenario described above then so be it - unfortunately. I'm still looking for an alternative to the Microsoft DRM but so far... nada!

[Reimar]

I'm also looking at the simple AES option but the question is: how to encrypt the live feed on the server side? This whole IP security business is becoming complicated because my client doesn't even use WMP. He picked MPlayer...

_Please_ do yourself a favour and get a proper specification, in particular what _exactly_ the purpose is, in particular some example scenarios that you can tolerate and some examples that you can't.
There are a lot of options, ranging from simple IP filters (only allowing specific IP addresses to connect) over ticketing systems (a user can somehow request an URL that will only be valid once, for a specific time, as used in mailing list management) to HTTP auth with or without SSL (possibly just some kind of SSL secured authentication that will allow access from one specific IP for some time, this was often used for controlling WLAN access e.g. in universities) to encryption in the media (MXF + AES e.g. is supported for MPlayer, but not suitable for streaming, MPlayer also supports the encryption used by ASF / WM DRM, it just needs the encryption key which is why you can not use it directly for WM DRM secured systems) and lastly there a full-blown DRM systems, which are for protecting yourselves against your very own client, thus can not be OpenSource.