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...)?"

Encrypting

[kzadot]

Surely if its multicast you only need one piece of encryption hardware per channel. And yes, if you want quality, you cant do it in software.

Quick Solution

[Nyhm]

I have a quick solution! Encrypting the stream is easy. Just pick some stream cipher (e.g., RC4), pick any key, send the data through the cipher prior to multicasting. In the clients, hard-code the key for decryption.

... Ohhh, but you probably also want it to actually be secure? You want to handle clients joining/leaving the multicast session, and need to change the key so they can't keep getting data? Real security is hard.

... Ohhh, and are you using the common best-effort (non-reliable) multicast, or are you using some type of reliability protocol? Stream ciphers do not fare well against lossy networks.

There is a lot of research on multicast security, but from your question, I don't think you're looking to do a thesis. So I don't really have a quick solution. Sorry, I was deliberately wasting your time.

Re:IPSec

[Curien]

Not true. MS's implementation of IPSEC doesn't support multicast because MS's implementation of IP filtering doesn't support it. But a proper IPSEC implementation /does/. See here [securityfocus.com] and here [gatech.edu].

Secure Multicast IETF and Secure Spread

[teqo]

Sometimes I wonder why people cannot come up with the same Google results [google.com] 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 [securemulticast.org] that is dealing with reserach and secure multicast standards. One of the bigger research platform seems to be Secure Spread [jhu.edu], a framework derived from the Spread Toolkit [spread.org] 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... .)

Live streaming DRM encryption

[sevinkey]

I happen to work for DRM Networks, a company providing Windows Media DRM services. I have run a live stream of an event for a trade show, encrypted on the fly. I did this using Windows Media Encoder (free download from microsoft.com) for the DRM encryption, a Windows Media Server to push the stream out, and our licensing server for authentication.

The video lagged about 30-60 seconds after an hour presentation, and the stream was available immediately.

This solution only works for Windows (I'm a mac and linux user so I'd love to point out something that works on those platforms, but it's just not easily available, yet).

http://www.drmnetworks.com/

Get back on your Lithium paranoia-boy

[mstorer3772]

DRM requires quite a bit more than crypto.

The suplicant wants to send out one stream with one encryption key. Not a zillion streams each with their own little DRM (rights? what rights?) key.

Down boy. Thou shalt chill.

All they need is a fast encrypt-decrypt with some way of allowing the clients to do the decryption FAST.

So what's wrong with SSL? Put the crypto in the network layer instead of the video app. User/pass protect the video stream URL and away you go... ... but SSL requires per-session data, doesn't it. Killed that.

A fast crypto algorithm? AES is fast, strong, good. It and several dozen other algorithms are available in the OS crypto library at:
http://www.eskimo.com/~weidai/cryptlib.html

I've used it's AES implementation in the past, no worries mate. Of course I wasn't concerned with performance either... but it's supposed to be Really Fast.

Encoding the outgoing stream shouldn't be too hard to code up. And the client end could be built as a custom CODEC in the media player of your choice. Just wrap some other CODEC in your encryption system, and throw up a password dialog when you first open the stream.

Sounds relatively simple... but then I've never written a CODEC before, so I'm pretty much just guessing here.

Good luck to ya.

The Problems

[Gilk180]

There are several problems to be solved and several questions that need to be answered first.

1. Are you looking for an OTS solution or are you willing to roll your own?

2. What scale is involved and what is the speed of the network?

The problems:

1. The packets to each end user will be exactly the same. Hence, a shared key algorithm is required for encrypting the mpeg stream.

2. There must be some way to boot (as in kick) users. Since we know a shared key stream will be required, the only way to boot users is to change the key.

3. Each user needs to authenticate individually.

I know nothing about the OTS products available, but if you are going to roll your own, here is a suggested framework.

Choose a stream encryption algorithm. Format your stream with a marker on each frame telling which key was used to encrypt that packet. This only means an extra bit or two depending on how often you rotate the key. One bit would be sufficient on many implementations.

For authentication, each client log into the server over ssh(or whatever secure method you choose) using whatever authentication method you choose(2 factor kerberos comes to mind if you want ultra security). Use this as a side channel to distribute keys. Each key will be distributed with an index. Once a new key has been pushed to all clients, the mpeg stream can be switched to the new key. If a client is to be removed, simply don't send them any new keys.

The problems with this is the scalability of the ssh connections. You could set up a seperate server for these and the video stream if load is a problem. Even with many connections, I doubt these connections would get in the way of bandwidth.

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 [myrio.com] - 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 [arnor.net]. 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.