Just when the party was ramping up over the emergence of the first DCI compliant digital cinema system, the hangover began. The issue is that the behaviors needed for DCI compliance and Interop compliance are different. The projection system needs to know which mode to be in, and the messenger for this information is the Key Delivery Message, or KDM. But therein lies the problem. The KDM wasn’t designed for this role, and we have to now intelligently craft some means to make the determination based on KDM use cases.
As one might expect, three different companies have placed three different proposals on the table, of which none are completely foolproof.
Cinecert first proposed a solution to the Interop / DCI switch problem a year ago on its blog The Dirty Laundry. The Cinecert solution looks for the presence of a particular element contained in the KDM called ContentAuthenticator. The DCI spec assumes the presence of the ContentAuthenticator element in KDMs, but the SMPTE standard S430-1 identifies this element as optional. The reason that ContentAuthenticator is optional in SMPTE is to introduce forward compatibility, so that the SMPTE KDM can be used with both Interop and SMPTE DCPs. Oddly, the DCI spec does not take into account the optional nature of the standard, and accordingly mandate that this element. That leaves a hole to be filled.
Doremi proposes to base the Interop/DCI decision on the KDM DeviceList element, based on the element value called the “assume trust” certificate thumbprint. The DCI spec, version 1.2 errata #22, defines this value. DCI/SMPTE compliant KDMs contain a “trusted device list” identifying the projectors that a server can securely operate with.
As a side note, the purpose of the DeviceList feature is to prevent servers containing content and keys from being used in a malicious manner. The DeviceList is present to tell the server which projectors it can operate with. The concern is that tight control is needed so that the server doesn’t playout to a recording device. But the utility of DeviceList relies on accurate knowledge of which projectors are in the projection booth. If that information is wrong, then the movie won’t play. Some studios see this mechanism as a ticket to dark screens. To get around it, the DCI spec “errata” was issued to introduce the “assume trust” feature, which keeps the movie playing regardless of the projector that’s used.
The challenge for the Doremi solution is that use of the “assume trust” value is based on a business decision, not a technical specification. It’s questionable that Doremi’s proposal will be accepted as a suitable choice. However, it appears that this is how Doremi servers work today.
Sony suggests a different solution by looking at the XML namespace of the KDM. Notably, this proposal appears to be based on a misunderstanding of KDM usage in Interop. There is no longer such thing as an “Interop KDM” having an Interop namespace. All KDMs today are based on the SMPTE standard, even for Interop content.
John Hurst of Cinecert points out that there are four valid formulations of SMPTE 430-1 KDM:
1. “Transitional 1” — No ContentAuthenticator element, DeviceList contains only the recipient’s certificate thumbprint.
2. Modified “Transitional 1” — No ContentAuthenticator element, DeviceList contains only DCI “assume trust” certificate thumbprint.
3. “DCI any” — ContentAuthenticator element is present, DeviceList contains only DCI “assume trust” certificate thumbprint.
4. “DCI specific” — ContentAuthenticator element is present, DeviceList contains one or more valid remote SPB or projector SPB thumbprints. (SPB stands for Secure Processing Block, which in this case, refers to the secure input module of the projector.)
Both Doremi and Sony have stated that their systems will not operate with “Transitional 1” KDMs, and that only “Modified Transitional 1” KDMs will work. That leaves only Types 2, 3, and 4 of the above list for application in the field. According to Cinecert, the “assume trust” certificate thumbprint is present in all three types, which removes Doremi’s proposal from the list.
Not surprisingly, the Cinecert proposal appears to have legs, albeit DCI may need to add yet another errata to strengthen the case. But not everyone agrees. Nor is there an alternative implementation in use that appears to have gotten it right. While this step may not appear critical today, it’s important. Else it will be difficult to play Interop content on DCI-compliant systems, and DCI upgrades will simply lead to dark screens.
