Slashdot Mirror

← Back to Stories (view on slashdot.org)

Encrypting a Multicast Video Stream?

Posted by Cliff on from the scrambling-the-signal dept.

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

34 comments

  1. Encrypting by kzadot · · Score: 2, Informative

    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.

  2. IPSec by Curien · · Score: 3, Insightful

    What about using IPSEC to encrypt the transmission?

    --
    It's always a long day... 86400 doesn't fit into a short.
    1. Re:IPSec by gl4ss · · Score: 1

      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..

      huhhuh.

      ask slashdot, aka "I need to find a magic solution to my work problem"

      --
      world was created 5 seconds before this post as it is.
    2. Re:IPSec by Hubert_Shrump · · Score: 1

      not if it's multicast.

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

      --
      Keep your packets off my GNU/Girlfriend!
    3. Re:IPSec by Curien · · Score: 2, Informative

      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.

      --
      It's always a long day... 86400 doesn't fit into a short.
    4. Re:IPSec by teqo · · Score: 2, Interesting
      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 management etc.

      To my knowledge, the secure multicast concepts and potential implementations haven't left the research labs (except Secure Spread which I mentioned in another post and isn't based on IPSec).

      I would be glad to be wrong and it would be nice if you could provide us with some implementation links... .)

  3. Quick Solution by Nyhm · · Score: 2, Informative
    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.

    1. Re:Quick Solution by JohnFluxx · · Score: 1

      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.

    2. Re:Quick Solution by swillden · · Score: 2, Insightful

      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.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  4. -- DRM paranoia rant -- by samrolken · · Score: 2, Insightful

    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

    --
    samrolken
  5. How secure do you want it to be? by John+Harrison · · Score: 2, Insightful
    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.

    --
    Lasers Controlled Games!
    1. Re:How secure do you want it to be? by dinodrac · · Score: 1

      > 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 change the keys, but once someone has learned to extract the keys from the hardware, the keys will continue to be leaked. Software systems suffer from the same problems, and are easier to tamper with but the cost of changing the system is at least lower.
      Regardless, you should design your protective measures with the assumption that anything not under your direct physical control is definantly insecure.

    2. Re:How secure do you want it to be? by John+Harrison · · Score: 1
      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 you are going to send out new cards.

      This system doesn't suffer from the drawbacks that DirecTV has though. Delivering content over the internet they can have two-way communication with the smart card, so each card can have its own key and you can verify that there aren't duplicate cards being used. If a key is leaked then you revoke that key and contact the single customer that has that key. If you design the system correctly then the break of a single card, or even a large number of cards isn't a break of the entire system.

      --
      Lasers Controlled Games!
  6. Smartsight by Jjeff1 · · Score: 1

    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.

    1. Re:Smartsight by Anonymous Coward · · Score: 0

      If you do business with verint, do realize you are doing business with a very very scary company. They are the last company on earth you want to go to for closed source crypto if you are doing more then entertainment over that video multicast session.

  7. Hi! by base3 · · Score: 4, Funny
    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.

    --
    One CPU cycle wasted on digital restrictions management is ONE TOO MANY.
    1. Re:Hi! by Zork+the+Almighty · · Score: 1

      Here's a slashdot suggestion. Broadcast porn on a competing channel. Nobody will ever see your real broadcasts.

      --

      In Soviet America the banks rob you!
  8. Secure Multicast IETF and Secure Spread by teqo · · Score: 5, Informative
    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... .)

  9. DRM for MPEG4 by scotti · · Score: 1

    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 system since the source for the DRM would have to be publicly available and under the GPL. The best thing you can do is write your own DRM using the ISMA standard and then NOT storing the key/license on the users system. Once you have to store/hide the key on their system for offline playback your in a whole lot of hurt. Just ask Apple about Hymn.

  10. I have your answer right here: by Anonymous Coward · · Score: 1, Insightful

    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.

  11. Live streaming DRM encryption by sevinkey · · Score: 3, Informative

    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/

  12. Get back on your Lithium paranoia-boy by mstorer3772 · · Score: 2, Informative

    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.

    --
    Fooz Meister
    1. Re:Get back on your Lithium paranoia-boy by Anonymous Coward · · Score: 0

      Fair enough--but I don't see how this isn't just multicast as it already exists but with an encryption wrapper (like you said)--the hard part would probably be managing the keys.

  13. The Problems by Gilk180 · · Score: 3, Informative

    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.

  14. Over looking the obvious by pvt_medic · · Score: 1

    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.

    --
    30% Troll, 50% Underrated, 10% Interesting
    Score:5, Troll
  15. I did exactly this. by Azog · · Score: 5, Informative

    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.

    --
    Torrey Hoffman (Azog)
    "HTML needs a rant tag" - Alan Cox
    1. Re:I did exactly this. by Anonymous Coward · · Score: 0

      Mod UP!! Mod UP!!
      Myrio... What a screwed up name for a company.

    2. Re:I did exactly this. by Samhain138 · · Score: 1

      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?

  16. FYI: For the DRM/kill crowd by mritunjai · · Score: 3, Interesting

    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!

    --
    - mritunjai
    1. Re:FYI: For the DRM/kill crowd by Samhain138 · · Score: 1

      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!

  17. And in other news by ACNeal · · Score: 1

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

  18. Tahya al-Moqawama al-Iraqiya! by Moqawama · · Score: 1

    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!