Encrypting a Multicast Video Stream?

Samhain138 asks: "My company streams video via multicast in a pretty large network. They have a client program for viewing this video stream. Everything works fine, and since the stream is ISMA MPEG-4, almost any player would be able to view it. Lately, they've been looking for a solution for encrypting the video on-the-fly with minimal delay, however all of the solutions they've come across require something physical (dongle, smart-card) which may cause a problem (we can't physically reach all the viewers and it might also become expensive when we have a lot of viewers). Can Slashdot readers suggest anything that is simple to implement (or buy...)?"

Comments

Hi!

[base3]

We'd like to lock up a video stream and charge for it. I figured Slashdot would be the perfect place to ask how to use DRM, and that I'd receive lots of free advice to benefit my corporate masters.

PLONK.

Secure Multicast IETF and Secure Spread

[teqo]

Sometimes I wonder why people cannot come up with the same Google results and other information that needs just a couple of minutes and a few braincells to research, especially when it seems part of their jobs to do so.

Anyway, this is an interesting question and problem, and I had to research this topic a few months ago myself, and came up with the Secure Multicast IETF that is dealing with reserach and secure multicast standards. One of the bigger research platform seems to be Secure Spread, a framework derived from the Spread Toolkit for reliable muticast. These are good places to start with the problem of secure multicast I think, although Secure Spread seems not to be under heavy development since 2002.

Since the original poster mostly talked about means to provide secure authentication and/or key distribution (dongle and smart-cards), I would like to point out that the main problem of secure multicast is rather providing

• a secure way of authentication and authorization of clients trying to join a multicast group
• a secure way to distribute shared keys for members of the same multicast group
• a secure way to re-key shared keys for all members of a multicast group
• a way of stopping access to the multicast data for specific members of a multicast group that should be rejected further data access (due to administrative decision) while maintaining the rest of the multicast group members and functionality

Neither IPSec, the number one secure IP protocol, provides for that, nor do IGMP or multicast routing protocols which are used for multicast group management. If you manage to solve this, the actual problem of distributing and managing account data to customers will be a bliss. (Oh, and since you involved the /. community in this problem, I expect you to provide your solution as free software, or at least open source, to the public... .)

I did exactly this.

[Azog]

This might be your lucky day, when an Ask Slashdot turns up exactly what you're looking for.

I have written the code you might need - since I needed to solve exactly the same problem. I work at Myrio - we do software for set top boxes for playing digital television over IP networks, typically VDSL.

Anyway - the video encoders stream out MPEG-2 encapsulated multicast IP, but sometimes the content providers get antsy about the possibility that someone could just put a packet sniffer on the network and get top-quality DTV video. (It's easy to play back the streams with open-source software.)

So, I modified the Linux ethernet bridge software to encrypt each ethernet packet crossing the bridge using 128-bit AES encryption. By doing it in-kernel, maximum speed and minimum latency is achieved. The source and destination addresses are untouched since it's an ethernet bridge. So you don't need to modify the video encoders, or the DSL head end or any other components of the network. You stick the encrypting bridge between the output of the encoders and your head-end router.

Streams can be encrypted by the destination address (useful for unicast VOD) or by the source address (useful for multicast DTV).

On the linux-based set top box client, we did the AES decryption in user-space, inside our proprietary application and libraries.

The key exchange was done at a higher level, using Java crypto services. You're on your own for that, our implementation was not GPL.

The code never entered production, however - it was done as a proof of concept and demonstrated at the SuperComm 2002 conference. It worked pretty well - IIRC a 733 Mhz Pentium 3 could encrypt over 10 5-megabit MPEG2 streams simultaneously with some CPU power left over for key negotiation, etc.

Lucky for you, it's GPL'ed. You can grab the patches and other useful info from
my website. It is a little out of date though, the patches are for an older 2.4 kernel. I'd be happy to answer questions about it if you want to work on it.

As for the wisdom of doing stuff like this... well, I have mixed feelings. I don't think that encrypting content to protect it is wrong, as long as fair use is preserved. And it is, in this case - anyone can hook up a VCR to the output of the set top box and record, just like recording shows off cable or satellite or anything else. So we didn't take away anyone's rights. Also, no one is forced to buy this service - if they don't like it, they have alternatives.

On the other hand I do think it's just stupid. Content companies are way, way too paranoid about the internet.

We have the technology to put the whole back catalog of shows on our service using video-on-demand - imagine if you could watch any Simpson's episode, any time you want, for maybe 50 cents each. Or buy in bulk - 10 bucks gets you 25 shows any time you want, with full fast-forward & rewind capability, your choice of any episode of Simpsons / Family Guy / Star Trek / Friends / NYPD Blue / Seinfeld Show / whatever.

It's so frustrating. Customers want it, we have the technology to deliver it, but studios won't do it because they're scared and stupid. If they had the guts we could all make a lot of money, and no-one would ever say "there's nothing on TV" again.