Re: A Media Distribution Problem

From: Lassi Hippeläinen (lahippel_at_ieee.orgies.invalid)
Date: 06/01/04 

Date: Tue, 01 Jun 2004 10:30:17 GMT

AE wrote:
>
> Lassi Hippeläinen wrote:
> > ...
> > Hiding the key from the subscriber is not possible if you cannot trust
> > the end user's equipment. That is in the usual threat model: the end
> > user has full control of her terminal.
>
> True in theory.
>
> In practice it's good enough to make it hard for the user to get the key.
>
> All software-based DRM systems are working that way.

That's why DRM systems cannot be made watertight. The goal is to make
protection good enough, so that the subscribers pay honestly, rather
than spend resources in breaking the system. The price of the service is
one of the parameters.

> > Therefore the suggested solution is to chop the stream to small pieces
> > that are encrypted separately. The key distribution protocol delivers
> > new keys at proper times, if the subscriber pays for more service. This
> > reduces the encrypted delivery problem from data to keys, which is much
> > easier to handle. There are further optimizations in hierarchical key
> > systems, where another key is used to encrypt the key delivery session,
> > and a third key is used as a shared secret for authentication.
>
> Since you are refusing security by obscurity I don't see what way yet
> more keys would be useful: If one gets the key that protects the key
> delivery session the whole system is broken.

The key of the key management session is subscriber-specific. Two
subscribers fetching the stream keys with the same session key can be
dropped.

> > These systems do have a possibility of leaking at least some of the
> > material. It is a cost vs. benefit issue. It is assumed that the
> > frequent key refreshes frustrate rogue users who would want in real time
> > pirated copies of the keys. Therefore they rather pay for the keys.
>
> Maybe I'm simply missing something, but what way does more frequent
> change of keys solve the problem?
>
> If keys are changed too frequently to be delivered individually, the
> encrypted keys have to be part of the broadcast - in that case one
> knowing the key-decryption-key gets the key and is able to decrypt the
> data stream without having to use the software.

If the stream key changes every five minutes, and transferring the key
to a rogue receiver takes even ten seconds, the other receivers might
think that paying for the service is worth it. Note that the key
transfer can't be immediate. if it were, it would be better to transfer
decrypted content rather than keys.
 
> If keys are changed less frequently and the payment server has to be
> accessed by every single subscriber there's enough time for a malicious
> subscriber to distribute the key since this user doesn't have to spend
> time for authentication, paypal or credit card transfers and so on.

One possibility: the keys are fetched from the key server, which
generates a bill. The key management session is authenticated when it is
set up. There are other key management schemes that scale better to
large groups, like LKH.

> > Another possibility for them is to give up real time, and get a
> > decrypted copy afterwards. That alternative can be a big issue as well,
> > but it falls outside the scope of the problem statement.
>
> I think it's quite well within the scope of the problem statement if
> this can be used to dump the encrypted datastream and the key can be
> distributed with delay.
>
> This breaks the system as efficiently as too slow key distribution -
> it's addressed by point 2 of the problem description.

Simultaneous encrypted multicast to a closed group makes sense only if
real-time delivery has value (e.g. news or stock tickers). Non-RT
services fall outside the scope, because they can use existing
mechanisms, like IPSec, SSL, and DRM.

BTW, if you have lots of time, visit http://www.securemulticast.org/.

-- Lassi

Relevant Pages

  • Re: A Media Distribution Problem
    ... > new keys at proper times, if the subscriber pays for more service. ... > systems, where another key is used to encrypt the key delivery session, ... but what way does more frequent ...
    (sci.crypt)
  • Re: Looking for Design Input
    ... Delivery transport options -- such as how what email addressto sent to, ... DeliveryOptions attached to each Subscriber (or perhaps for even one per ... server is different for different options. ... or if one server handles several mailing lists. ...
    (comp.lang.smalltalk.dolphin)
  • Re: Fanfare Magazine: Going Postal?
    ... the urgency being rather less than usual because as a subscriber I had ... other subscribers enquiring as to why the delay. ... technical/financial difficulty delayed publication. ... delivery has become substandard lately. ...
    (rec.music.classical.recordings)
  • Re: OT: Whos running the NYT [was Re: If I Were the Copy Editor...]
    ... >> I recently subscribed to home delivery of the Sunday NYT ... ... I was not a subscriber. ... I get the local paper and the NYT. ... Sometimes the local paper ...
    (alt.usage.english)
Quantcast