Cacheing encrypted objects

I was thinking about the problems of pay-per-view applications in
relation to cache. As I understand things, transactions to a secure server
must not be cached, which is fine for talking to your bank or getting a
stock quote. But what if you want to buy a magazine or video ?
The object may be both large and popular, and thus benefit from cacheing.

One method I thought of was where the vendor serves an encrypted object
on an insecure server. The purchaser then buys the product on
a secure server, and is given a key to decrypt the object. Supposing that
the viewing agent is some kind of impenetrable (to regular users)
black-box rights-control engine, this might work, though it would be possible
for someone to finess the agent, steal the key and resell it.
Rolling over the encryption key in concert with a cache lifetime
might render this uneconomic.

Lewis McCarthy on sci.crypt tells me about a paper by
Ernst and Yuval, "Heraclitean Encryption", MSR-TR-94-13, available as
<ftp://ftp.research.microsoft.com/pub/tech-reports/Summer94/TR-94-13.ps>
In this technique, the product is encrypted with one key and
may be decrypted with a range of different, traceable keys, allowing
many identical copies of the encrypted product to be distributed on
open media such as CD-ROM, while selling the right to use the product
over the telephone, etc. using unique passwords.

This method could be used together with insecure servers, software
mirrors and public cache to distribute popular objects without
requiring a high bandwidth path to the origin for all purchasers.
Whether it could function within the current paradigm of HTTP servers,
MIME types, plugins and viewers is unclear to me.

The technique described in the paper doubles the size of the
encrypted object, though it might be feasible to encrypt only enough of
the object to render it unwatchable.

Andrew Daviel
TRIUMF, Vancouver Webpages
mailto:andrew@vancouver-webpages.com
Received on Thu Mar 13 1997 - 23:35:46 MST