Re: A Media Distribution Problem

From: AE (hidden_at_nospam.com)
Date: 05/31/04 

Date: Mon, 31 May 2004 09:20:57 +0200

What about that:

A user downloads the software from internet.

Software logs on to your payment-server using this software. Connection
is protected using SSL.

Depending on the modality of payment he types in the number from a phone
type card or does the credit card transfer.

The software sends the computer's hostid.

The server registers the payment for the computer's hostid.

When starting a session the computer once again accesses the payment
server using SSL, sends the computer's hostid and receives a sessionkey
(for a single film or show, for example) from the server.

This key is used to decrypt the film.

> ...
> 1. People may try and watch his shows without paying.

This is equal to "People may try to decrypt the data stream without
using the provided software".

As long as encryption is stong enough it's only the problem to protect
your software from getting reverse-engineered.

While an encrypting hardware dongle solves this problem for sure it
might as well be enough to change software from time to time so people
extracting the key from your program have to repeat this every month or
every few months.

> 2. Groups of people may take a single subscription and
> send copies of the key variable to the rest of the group.

The software only provides the computer's hostid and receives the key
for a single session using an encrypted connection.

I don't see what way they could distribute the key if they aren't able
to replace your software.

> 3. People may try and logon using someone else's identity.

Since all payment-related transfers are protected by SSL this is
possible only if an attacker gets access to the client's computer and is
able to fake the computer's hostid.

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

SSL is frequently used for this purpose - it should be good enough.
Authentication is at least server-side.

> 5. Interference and lost packets may require the subscribers
> to individually resynchronise the signal.

You can't use a synchronous stream cipher.

Use AES in CTR mode with the packet number as part of the counter or in
OFB, CBC or CFB mode with a unique IV in every packet to encrypt the
stream or use CBC or CFB mode and accept the fact that not only one
packet will get lost but as well the first block of the next packet.

What recovery means in case of an mpeg data stream is beyond my scope.

> 6. User with single subscription decrypts shows, records them on other
> media (DVD, VHS Tape) and redistributes shows for profit.

As long as the software can't get circumvented but sends the decrypted
datastream directly to the hardware it's not an easy task to do that.

Of course it's always possible to intercept the data stream between
computer and monitor, but that's a problem you simply can't solve if you
aren't able to provide monitors with hardware-decryption.

   7. Hostid changes

In case of credit cards being used an additional credit card transfer is
necessary to inform the server that accesses using hostid A are to be
denied from now and instead accesser from hostid B will get permitted.

In case of anonymous money transfer like phone type cards only one
hostid can be used and for a new computer a new payment is necessary.

If you are using hardware dongles you chould use the dongle's id instead
of the hostid.

> ...