Please create an account to participate in the Slashdot moderation system


Forgot your password?
Encryption Security

Encrypting a Multicast Video Stream? 34

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...)?"
This discussion has been archived. No new comments can be posted.

Encrypting a Multicast Video Stream?

Comments Filter:
  • Encrypting (Score:2, Informative)

    by kzadot ( 249737 )
    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.
  • IPSec (Score:4, Insightful)

    by Curien ( 267780 ) on Tuesday June 15, 2004 @08:33AM (#9428388)
    What about using IPSEC to encrypt the transmission?
    • well.

      they want it to be easey, but they don't want there to be any extra trouble to the end user. also they want it to be secure..


      ask slashdot, aka "I need to find a magic solution to my work problem"
    • not if it's multicast.

      IPSec is for unicast, as it (supposedly) helps prevent MITM attacks.

      • Re:IPSec (Score:3, Informative)

        by Curien ( 267780 )
        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 [] and here [].
        • Re:IPSec (Score:2, Interesting)

          by teqo ( 602844 )
          Having read on secure multicast before, I wonder which implementation actually provide complete multicast support? I checked KAME [], and they don't seem to, neither does the infamous FreeS/WAN or it's follow ups, and I guess the IP filtering problem with MS's stuff isn't the only problem, since their are no secure multicast extension implemented AFAIK.

          Maybe you don't consider these as proper, so I would really like to know which IP implementations support secure multicast via IPSec, including group key manag

  • Quick Solution (Score:2, Informative)

    by Nyhm ( 645982 ) *
    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 ar

    • The best way to do this would be to apply random fourier transforms against the images. Then it degrades nicely under lossy conditions, and streams well.

      Contact me for more info on this, it's what a friend of mine is doing.

    • Re:Quick Solution (Score:3, Insightful)

      by swillden ( 191260 ) *

      Stream ciphers do not fare well against lossy networks.

      Stream ciphers are just fine in lossy networks, as long as your stream carries synchronization data in plaintext.

  • Encrypting a video stream? Encrypting media content? What are you talking about, some kind of DRM system? On Slashdot? Seriously though, Windows Media supports ISO MPEG4 and some good DRM.... I mean... encryption. -- Sam Kennedy
  • If your keys aren't in hardware such as a smart card then you aren't secure, you are just making people jump through hoops.

    Even if your keys are in hardware you aren't secure since someone could just grab the stream after it is decrypted. So you probably need to decide what it is that you want to protect against and what it is that you aren't going to worry about stopping.

    • > If your keys aren't in hardware such as a smart card then you aren't secure, you are just making people jump through hoops.

      I'll respectfully disagree with this. As companies such as DirectTV can probably tell you, even a hardware solution can be compromised. Assume that any device an attacker can physically control can potentially be compromised. Hardware solutions may be more difficult to tamper with, but once a hardware system is cracked, for all practical purposes, it stays cracked. Sure, you can c
      • I agree that DirecTV has a problem. They giving the same key to millions of people, which they have to do since they don't have constant two-way communication.

        I also agree that keys can be extracted from a smart card. Newer cards have protections against many of the extraction methods. The idea is to make the cost of extraction more than the value of what you are protecting. Occasionally there will be a breakthrough that drops the cost of extraction significantly at which point you need to decide if y

  • Smartsight Networks [] has a product called nDVR. It's designed as a digital security camera system, but offers encrypted video multicasted from a central server.
  • Hi! (Score:5, Funny)

    by base3 ( 539820 ) on Tuesday June 15, 2004 @10:03AM (#9429209)
    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.


    • 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
    • Here's a slashdot suggestion. Broadcast porn on a competing channel. Nobody will ever see your real broadcasts.
  • by teqo ( 602844 ) on Tuesday June 15, 2004 @10:37AM (#9429585) Journal
    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'm looking for a "lightweight" DRM for MPEG4 myself. We have a need to offer "copy protected" educational video's to students on Mac's and Windows. Right now its easy to do DRM with WMP9 but we'd love to move to a MPEG4 solution. The closest thing we've found is Apples Fairplay and they don't have a publicly available version of it like MS offers. Ultimatly we would like to have plugins for Quicktime or use some other cross platform player like Videolan. If we used Videolan the DRM would be on the honor sy
  • by Anonymous Coward
    Three letters: VPN. It will encrypt and decrypt everything automatically w/o making any changes to the viewing program. Kind of a pain, but if you REALLY want/think it needs to be encrypted, it'll do the job.
  • by sevinkey ( 448480 ) on Tuesday June 15, 2004 @12:13PM (#9430835)
    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 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).
  • The Problems (Score:4, Informative)

    by Gilk180 ( 513755 ) on Tuesday June 15, 2004 @12:22PM (#9430975)
    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.
  • If you want true security build a seperate netowrk indipendant of the internet and stream it over that. Physical security will beat software secuirty anyday.
  • I did exactly this. (Score:5, Informative)

    by Azog ( 20907 ) on Tuesday June 15, 2004 @01:30PM (#9431919) Homepage
    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.

    • Ok, I will contact you tomorrow.
      I just need to see how decryption could be handled from the client side.
      We can basically only install software, and also, people might use Windows...
      We use Linux.

      I assume AES decryption should be more or less easy.
      How can I write software that transparently decrypts everything that gets in the ethernet card?
      How can it separate my stream from other packets?
  • by mritunjai ( 518932 ) on Tuesday June 15, 2004 @01:42PM (#9432068) Homepage
    Okay, I have the mod points, but this is one of the best questions I've seen in a while on /., and seriously, this problem is NOT simple! Multicast + encryption = can of worms!

    For good points see one the post "Secure Multicast IETF and Secure Spread" in replies.

    DRM crows, hold on. Multimedia streaming is not just used for movies and ripped TV serials. Inside corporations it is used for webcasting (to intranet) meetings, training talks, company policies and LOT more... at a given time there might be THOUSANDS of employees world wide tuned in to the webcast (say, Taiwan mfgr office, US HQ dev office and India dev office in a 24hr development + manufacturing setup).

    Now you DO NOT want outsiders and even unauthorized employees to sneek in on the sales report meeting webcast! Its plain and simple. Its NOT DRM, its access control!

    Multicasting in such an environment is a bitch. You need to devise a secure mechanism of distributing keys, administrating and monitoring the listeners. Multicasting has multicasting groups, so you need to provide some kind of scalable encryption accesscontrol mechanism that works at least across few main stream OSs (Windows 2k/XP/2k3, OSX, Linux and FreeBSD).

    Trust me kn this, this *is* a fairly new problem and very good one at that. Three cheers to anybody coming up with a *proper* FREE SPEECH solution for that!
    • You understood my problem.
      This is about a conference being viewed only by people who should view it.

      There's a need to multicast it over the internet.
      Sometimes we can't send physical things (dongles, etokens, smart cards) to people (clients and staff will not wait for DHL to come if they're expecting an important conference).

      I will continue reading your answers tomorrow, thanks a lot!
  • Bill Gates asks, on behalf of the RIAA, "Is there a way that /. readers could think of to upgrade our present efforts at DRM? We'd like to be able to impliment some security that wouldn't get cracked in a matter of days. We thought /. would be the perfect place to find such help."
  • Tahya al-Moqawama al-Iraqiya!

    Death to the Americans in our lands and death to the Zionists in the lands of our brothers in Palestine!

    Tahya al-Moqawama al-Iraqiya!

    11 September was nothing compared to what awaits the Americans. The burning of the World Trade centers will be forgotten when they see what we will release upon them soon!

    Tahya al-Moqawama al-Iraqiya!
    Tahya al-Moqawama al-Iraqiya!

What this country needs is a good five cent ANYTHING!