Matt's Blog

Encrypted blog entries again

Sat Oct 14 09:06:15 EST 2006

One of my friends read the blog entry from a couple of weeks ago about encryption/decryption in client side javascript, and pointed out that There already exist libraries for encryption between the client and the server eg using public key cryptography or similar.
This is of course true, and proabably what you would use in a secure web application where bi-directional communication is allowed.

His question clarified the idea in my mind further. The crux of the idea is unidirectional broadcast from a server to a set of clients. The messages broadcast contain plain text data, encrypted data, and code for the encryption machines. Keys to make the machines decrypt encrypted content are distributed through other channels, for example buying a decryption key in tamper-proof hardware token form from a vendor.

Is this starting to sound familiar?

Looks like I've just reinvented encyption for digital or satellite television. The broadcaster transmits a set of channels, some free-to-air and others requiring a subscription. The client has a decoder box consisting of a tamper-proof processing unit running a known operating system. The client purchases a decoder card containing a key. This decoder card is also tamperproof to prevent cloning of cards. The broadcaster also transmits the encryption machine to the decoder box, with this machine making use of the decoder card to decode the signal. This architecture has a number of advantages for scalable distribution of protected content, the primary one being that the broadcaster is able to alter the encryption machine if a weakness is found.

Contrast the approach taken by satellite TV broadcasters to the problem of cloned cards versus the approach taken by DVD producers. In the first case the encryption machine is in software and once too many cloned cards are available the broadcaster transmits a new encryption algorithm and sends registered subscribers new cards. In the DVD case each DVD player has the encryption machine in hardware, so once the DeCSS code was developed the encryption became useless. To re-enable encryption would require all DVD users to purchase new DVD players, and new encryption on all new DVDs (the new DVD players would have to be backwards compatible as well).

To solve this problem the DVD producers have attempted to control the computing technology by introducing the Trusted Computing platform, where digital rights management (DRM) is built into the hardware of the computer itself. The point of this is to prevent the computer user from accessing the decrypted bitstream and producing a copy of the content with the decryption removed, which can then be copied further. This solution is actually to a different problem than I have been considering hitherto in this article, which up to now has been the dissemination of the encryption machine. The trusted computer platform is focussed on control of the decrypted bitstream rather than control of access to the encryption algorithm. For the moment continue considering the case of access to the decryption algorithm, leaving the harder problem of control of the decrypted bitstream to another time.

The DVD encryption dissemination architecture could be made more robust by making each DVD player contain tamperproof processor and memory modules, with the memory module containing the encryption algorithm being updatable. If the current encryption algorithm becomes compromised the player can be given a new algorithm to use by a software update rather than a hardware upgrade. This is the approach used to provide copy protection on many games consoles, such as the Playstation or Xbox.

This nicely ties back to the original point, that of client side implementation of the encryption algorithm to avoid load on the central server or traffic analysis. Of course in the content protection problem there is the substantial difference that the client is not trusted, which leads to extra requirements on the playback device to avoid copying of the decrypted content.

[code] [ideas]


code (24)

erlang (5)
ideas (19)
lisp (1)
me (11)
notes (4)
ocaml (1)
physics (45)
qo (7)
unix (6)
vim (3)