Re: A Media Distribution Problem
From: Michael Brown (see_at_signature.below)
Date: 05/27/04
- Next message: Giorgio: "Re: Working on ARC4-16 bit"
- Previous message: Alex Bell: "Re: P4-anybody tried this?"
- In reply to: Andrew Swallow: "A Media Distribution Problem"
- Next in thread: Lassi Hippeläinen: "Re: A Media Distribution Problem"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Thu, 27 May 2004 18:57:13 +1200
Andrew Swallow wrote:
> Here is a theoretical problem that is likely to become real in
> a few months time.
>
> A supplier wishes to sell his goods by realtime downloading
> over the internet. The goods could be a TV channel or "radio"
> broadcast or constantly changing data like stock market prices.
>
> Real time TV over internet becomes technically viable at
> about 1.5 Mbps when compressed using MPEG4. Many of
> the readers of this newsgroup already own modems that
> fast, the phone companies have simply chosen to limit the
> line's speed.
>
> The supplier wants to get paid so he wishes to encrypt
> his signal. To minimise bandwidth he wants to multi-drop
> the signal; that is a common broadcast which everyone
> listens to. He suspects that a second server will be
> needed to handle the payment of subscription fees and
> automatic distribution of daily/hourly key variables.
>
> The supplier is willing to download a player to his
> subscribers. One file of which can be unique to each
> subscriber.
>
> Threats
> 1. People may try and watch his shows without paying.
Assuming proper crypto is used, this one is a non-issue. If it's done
properly then someone without a key is out of luck.
> 2. Groups of people may take a single subscription and
> send copies of the key variable to the rest of the group.
This one is impossible without having each subscriber buy dedicated secure
crypto boxes. You can link each key to hardware (a MAC for example might be
good in this case, though it's not too hard to forge so you might want to do
a bit more) but there's nothing to stop someone cracking your decryptor and
using a general gey in that. One thing that would help is having the
broadcasts segmented, so that a key for one segment wouldn't work in
another. The ease of this depends on the network topology and the available
computing grunt and bandwidth.
> 3. People may try and logon using someone else's identity.
One way to solve this is to lock each login to a MAC address at the server
end. Not 100% bulletproof, but would certainly get rid of most casual
attackers.
> 4. Payment is to be via PayPal, credit card and phone
> type cards purchased at shops. These need transferring
> over the internet from the subscriber to the supplier in
> a secure manner.
PGP email, SSL login to a page, etc etc. Lots of options :)
> 5. Interference and lost packets may require the subscribers
> to individually resynchronise the signal.
As long as you have keyframes in your MPEG, this is a non-issue. The
subscriber may get brief drops in the stream, but hopefully nothing that
would be too bad. For other data, there may need to be buffering/resend
capability on the server.
A basic system could go something along these lines:
You have a MPEG stream being sent to the main distribution server. This
stream gets divided up into, say, 8kb chunks, and encrypted using AES in CTR
mode. The IV/counter/whatever-you-want-to-call-it is appended to the start
of each block so that the client can resync easily if something gets
dropped. These blocks are then sent via your transport of choice to the
clients. A MAC is probably not entirely necesary in this case, but it would
be good to use to avoid people disrupting the stream.
At the client end, each piece of software has a unique RSA private key. This
is secured in the software to make it hard to extract, which is not going to
be easy :) This key is also tied to the hardware in such a way that it is
unique to the computer. When the user subscribes to a broadcast, their
public key is sent to the broadcast authentication server. To receive a
stream, the clients log in (using SSL) to the authentication server. They
then send a request for a key for a particular broadcast, and the server
checks to see if they're allowed the key. If so, it's sent back to them
encrypted using their public key. The software then securely decrypts it to
get the real key for the stream, and uses that key to decrypt it. This key
request can happen as often as you like, though the software on the server
will have to be written so that it doesn't collapse when the key for the
stream changes (everyone watching will hit the server at once, so creating a
new key for each logged in user several minutes before the key change would
be a good idea). There could be a message in the transmitted stream to
indicate when the clients should request a new key, and another message for
when that key becomes active.
There's probably some gaping security hole in the above :) Depending on how
much money you're expecting to move using such a system, it may be a good
idea to hire a proper crypto/software-security guy. The biggest problem I
see is in the secure decrypting of the stream. There's a lot of very skilled
people out there who will attack your software if it becomes popular, and
it's quite hard to hide any sort of decryption function well. A breakpoint
in the key scheduler and they've got the key for the stream. Changing keys
every so often will help, as if you have 1 key per month, all you need is
one corrupt client and eeryone can watch free for a month. It's a lot more
of a pain (and a lot easier to trace) if someone is sending out the keys
every couple of hours.
-- Michael Brown www.emboss.co.nz : OOS/RSI software and more :) Add michael@ to emboss.co.nz - My inbox is always open
- Next message: Giorgio: "Re: Working on ARC4-16 bit"
- Previous message: Alex Bell: "Re: P4-anybody tried this?"
- In reply to: Andrew Swallow: "A Media Distribution Problem"
- Next in thread: Lassi Hippeläinen: "Re: A Media Distribution Problem"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
