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...)?"
Encrypting (Score:2, Informative)
IPSec (Score:4, Insightful)
Re:IPSec (Score:2)
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"
Re:IPSec (Score:2)
IPSec is for unicast, as it (supposedly) helps prevent MITM attacks.
Re:IPSec (Score:3, Informative)
Re:IPSec (Score:2, Interesting)
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)
Re:Quick Solution (Score:2)
Contact me for more info on this, it's what a friend of mine is doing.
Re:Quick Solution (Score:3, 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.
-- DRM paranoia rant -- (Score:2, Insightful)
How secure do you want it to be? (Score:3, Insightful)
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.
Re:How secure do you want it to be? (Score:1)
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
Re:How secure do you want it to be? (Score:2)
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 (Score:1)
Hi! (Score:5, Funny)
PLONK.
Get back on your Lithium paranoia-boy (Score:3, Informative)
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...
Re:Hi! (Score:2)
Secure Multicast IETF and Secure Spread (Score:5, Informative)
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
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... .)
DRM for MPEG4 (Score:1)
I have your answer right here: (Score:1, Insightful)
Live streaming DRM encryption (Score:3, Informative)
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/
The Problems (Score:4, Informative)
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.
Over looking the obvious (Score:2)
I did exactly this. (Score:5, Informative)
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.
Re:I did exactly this. (Score:1)
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?
FYI: For the DRM/kill crowd (Score:4, Interesting)
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!
Re:FYI: For the DRM/kill crowd (Score:1)
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!
And in other news (Score:1)
Tahya al-Moqawama al-Iraqiya! (Score:1)
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!