DCP's do not have to be encrypted, but they can be. This chapter discusses the basic principles of DCP encryption, and how DCP-o-matic can create encrypted DCPs and KDMs for them.
DCPs can be encrypted. This means that the picture and sound data are encoded in such a way that only cinemas ‘approved’ by the DCP's creators can read them. In particular, this means copies of the DCP can be distributed by insecure means: if a bad person called Mallory obtains a hard drive containing an encrypted DCP, there is no way that he can play it. Only those cinemas who receive a correct key delivery message (KDM) can play the DCP.
This section attempts to summarise how DCP encryption works. You can skip it if you like. You may need some knowledge of encryption methods to understand it.
We suppose that we are trying to send a DCP to Alice's cinema without a third party called Mallory being able to watch it himself.
There are two main families of encryption techniques. The first, symmetric-key encryption, allows us to encode some data using some numeric key. After encoding, no-one can decode the data unless they know the key.
The first step in encrypting a DCP is to encode its data with a random key using symmetric-key encryption. The encrypted DCP can then be sent anywhere, safe in the knowledge that even if Mallory got hold of a copy, he could not decrypt it.
Alice, however, needs to know the key so she can play the DCP in her cinema. A simple approach might be for us to send Alice the key. However, if Mallory can intercept the DCP, he might also be able to intercept our communication of the key to Alice. Furthermore, if Alice happened to know Mallory, he could just send her a copy of the key.
The clever bit in the process requires the use of public-key encryption. With this technique we can encrypt a block of data using some ‘public’ key. That data can then only be decrypted using a corresponding private key which is different to the public key. The private and public keys form a pair which are related mathematically, but it is extremely hard (or rather, virtually impossible) to derive the private key from the public key.
Public-key encryption allows us to distribute the DCP's key to Alice securely. The manufacturer of Alice's projector generates a public and private key. They hide the private key inside the projector where no-one can read it. They then make the public key available to anyone who is interested.
DCP-o-matic has a similar arrangement except that it stores its private keys in the user's configuration file. See the section called “Decrypting encrypted DCPs” for details of how to share DCP-o-matic's certificate so that others can make encrypted DCPs for DCP-o-matic.
We take our DCP's symmetric key and encrypt it using the public key of Alice's projector. We send the result to Alice over email (using a format called a Key Delivery Message, or KDM). Her projector then decrypts our message using its private key, giving the symmetric key which can decrypt the DCP.
If is fine if Mallory intercepts our email to Alice, since the only key which can decrypt the message is the private key buried inside Alice's projector. The projector manufacturer is very careful that no-one ever finds out what this key is. Our DCP is secure: only Alice can play it back, since only her projector knows the key (even Alice does not).