The problem posed by NIST is discussed at great length in earlier reports. (A search on this site for NIST will reveal them.) As much as DCI-imposed compliance to frequently-changing NIST standards poses a problem, DCI itself has caused angst by remaining silent about what it intends to do about it.
That intent came through loud and clear this month. A hint was dropped in this month’s ISDCF meeting that some members of DCI did not find it desirable to unhinge the DCI specification from NIST/FIPS-compliance. Later in the month, DCI’s long-time security consultant, Tony Wechselberger, posted a one-page document concerning the dual security certificate problem in the SMPTE 21DC Study Group for FIPS Revisions. The group has only 22 members from the digital cinema community, and the document is not posted on the DCI web site.
DCI’s proposal is to require two digital certificates in newly-designed media blocks. But rather than track these certificates individually, DCI proposes to only track the primary certificate used for the encryption of the KDM. The secondary certificate is needed, per the new NIST rule, to separately conduct secure communication with the projector and to sign security logs. These secondary tasks are currently handled by the primary certificate in existing media block designs. To track the secondary certificate, DCI proposes that a reference to the secondary certificate be placed within the primary certificate. The method for doing so is the subject of debate, but all of the methods proposed can work. The diagram below illustrates the concept.
The solution proposed by DCI is clever. It is backwards compatible, as it only requires security key management entities to collect one certificate for the encryption of the KDM, as is done today. It ties the signature in the security log to the KDM-related certificate, so that such signatures can be associated with the known primary key of the media block. It does require more work to learn and track this association, but it is doable.
There is one more issue posed by NIST that SMPTE must address, and that is the disuse of the SHA-1 hash algorithm for digital signatures in SMPTE/DCI-compliant security logs, in favor of SHA-256. SHA-1 message digests are called for in SMPTE 430-4 Log Record Format and SMPTE 430-5 Log Event Class and Constraints. The extent to which changes are required in the specifications remains to be seen. If the transition period for dual-certificate media blocks is substantially far away (much later than 1 January 2011), it is likely that both transitions will be timed together.
It’s not clear, however, that these steps are all that are needed. German media block manufacturer Mikrom was posed a difficult problem by the NIST-accredited consultancy guiding their product design for FIPS 140-2 compliance. The consultancy claims that the changes imposed in FIPS 140-2 Annex A require further changes than those that DCI claims that could impact backwards compatibility. DCI, of course, is operating under the guidance of a US-based NIST-accredited consultant. The winner in this debate has yet to be decided.
Assuming no complications, DCI has taken steps that will allow it to continue to require NIST/FIPS compliance without posing major impacts on workflow. That’s the good news. The bad news is that DCI is getting away without addressing how security changes are managed in the future.
