KDM (Key Delivery Message)

The track files inside a commercial DCP are encrypted with AES-128. The content keys that undo that encryption are not shipped with the package. They are sent separately, wrapped so that exactly one piece of hardware can open them.

Every compliant media block carries a certificate with a public key and a serial number. When a distributor issues a KDM they encrypt the content keys against that specific certificate. The result is a file of a few kilobytes that is worthless on any other device in the world — which is why a KDM can safely be emailed while the DCP itself cannot be.

This is also why KDM requests need your device certificates, not your address. A booking is made per screen, and the key is cut per screen. Four screens playing the same title on the same weekend need four KDMs.

A KDM does not simply work or not work. It works between two timestamps, and both ends matter.

Keys usually open a little before the first booked performance and close a little after the last one, with some slack on each side. Two failure modes follow from that, and between them they account for most of the emergencies:

The show that will not start. Either the key has not arrived, or it arrived for a different screen, or the booking was extended and nobody asked for a new key. Extending a run is a commercial decision that silently creates a technical task.

The show that stops. The window closed mid-performance. This happens on late sessions at the end of a run, and it is why the end time of the last key of a run is worth checking rather than assuming.

A third, rarer one: the playback device's real-time clock has drifted or been reset after a power event. The key is fine; the device thinks it is a different date. Nothing about the error message will tell you that.