Two announcements were made by DCI this month that indicate it is taking heed of commercial needs. First, DCI posted a new policy change on its website regarding the compliance process:
Publication of a new version of the DCI Compliance Test Plan (CTP) will take effect in two stages as determined solely by DCI in consultation with the licensed testing facilities in operation at the time.
Stage 1 will include changes that remedy errors to tests, clarify existing tests, or are required to facilitate the testing procedure. Stage 1 changes will take effect immediately upon publication of the CTP revision on the DCI website.
Stage 2 changes will include all other changes to the CTP not included in Stage 1. Stage 2 changes will take effect one hundred twenty (120) days after publication on the DCI website.
When a new version of the CTP is published and has taken effect based on the above, any device undergoing actual compliance testing or re-testing, as defined by an executed testing agreement, the described device being in the possession of the DCI-licensed testing facility, and at least one test has been initiated, may continue to test or re-test to completion using the version of the CTP in effect when that device’s testing or re-testing began.
[Approved September 30, 2010 Digital Cinema Initiatives, LLC, Member Representatives Committee]
The policy change points to a new version of the DCI Compliance Test Plan (CTP). DCI is due changes as errors are inevitably found in the DCI test plan, and as it decides on how to proceed with NIST. Up until now, DCI’s policy required a product to be compliant to the current specification. The specification, of course, has been a moving target to manufacturers, who have loudly complained in recent years. The more realistic approach announced by DCI shows that the organization is being responsive to commercial demands.
DCI is walking a fine line, however, between commercial needs and its own security policies. While the new policy for backwards compatibility sounds good, it doesn’t address the problem posed by the continually evolving NIST-managed FIPS security standards to which DCI also mandates compliance. A FIPS-compliant device will retain its FIPS compliance thoughout time, regardless of specification changes made by NIST, as long as the design of the device remains unchanged. This may sound good to lawyers, but it’s an impossible task for manufacturers, who face regular changes in parts by component manufactuers, and must also incorporate bug fixes along the way. If DCI continues to require compliance to NIST standards, and NIST continues to move the needle on those standards, then the tiniest of updates could lose compliance status and launch a complete overhaul of a media block design. DCI’s new policy does not solve the substantial problem imposed by NIST.
Then there’s the substantial problem posed by NIST’s most recent changes. In October’s ISDCF meeting, a few DCI members, who normally are placed under a gag order by DCI, hinted that they intend to continue to require NIST compliance, despite recent changes in the FIPS standards that are not currently compatible with DCI. This, in response to a suggestion by your author that this is a good time to break from NIST to nurture stability in the DCI spec. The hint indicates that the attorneys are winning in digital cinema. In a world where digital download and piracy are the hot topics for nearly every industry seminar, no studio CTO interested in keeping their job will argue that their studio should break from a US national standard for security.
The love affair with NIST will eventually impose pain in the distribution channel. Currently, NIST has imposed new rules for FIPS 140-2 that will require the introduction of a 2nd digital security certificate in the digital cinema media block. In its 2nd announcement made this month, abeit a quiet one, DCI (finally) proposed potential solutions that may allow backwards compatibility. (DCI’s proposals are explained later in this report.)
But there will be a day where NIST-imposed changes will not allow for backwards compatibility. As changes in specifications occur, all flavors of equipment will continue to require support in the field. It will not be possible for studios to simply stop distributing to equipment designed to older security standards. Even a studio were to try, it would surely risk the wrath of governments interested in protecting the investments and businesses of citizens. If the deprecation process for such equipment takes as long as 15 years – which is not unreasonable – it would require each studio to be comfortable with the security technology of 15 years prior. The political impact of that thought might be greater than the actual threat of a security breach.
Multiple distribution standards leads to other problems, as well. During the deprecation period, older equipment and newer equipment will operate side-by-side. If movies can’t be moved from one projector to the next, then the studio has to send two different movie packages to each site, each with its own KDM. Bandwidth and storage requirements grow, accordingly. If two cycles of change occur within a 15-year deprecation period, that would necessitate three flavors of distribution.
Assuming security changes are inevitable, the primary concern for studios should be how frequently these changes are imposed. If allowing NIST to set the schedule, changes could become more frequent as time goes on, assuming Moore’s law remains relevant. It would seem wise to want to manage this process, rather than be a victim of it.
Another difficulty in allowing NIST to set the schedule is that its does not always allow much time to respond. NIST changed FIPS 140-2 in January of 2010, with the intent to transition after the 31st of December, 2010. DCI’s first pro-active proposal to address the problems imposed was issued this month. DCI says it does not believe that the current changes will go into effect soon, and hopefully they are right. However, DCI’s security consultant says that its belief is not based on a direct conversation with NIST. NIST continues to maintain a document on its web site that propose the changes go into effect after December 31 of 2010. It could announce a new revision of FIPS 140-2 Annex A this coming January, this time with no reference to FIPS 186-2, which would make official the requirement for dual keys. The inability to communicate directly with NIST only shows how difficult future changes are likely to be.
Apparently, there is no single authority within NIST that governs how its standards are applied. NIST relies on its accredited testing laboratories and a network of accredited consultants who sell their expertise to manufacturers. But not all accredited parties interpret FIPS documents in the same way. For example, a German manufacturer of media blocks was recently told by its NIST-accredited consultancy that it must make more changes in its product than DCI is now proposing to be compliant with the updated FIPS 140-2. At least one of the changes stated by the accredited consultancy will eliminate backwards compatibility. And such is the world of NIST.