Tag Archives: ISO

Certificate Authorities and DCinema

Another has been found to have introduced a man-in-the-middle attack vector, meaning that once a legitimate user opened the door by giving the correct credentials, someone slipped in and assumes the identity of that user with all their rights (usually kicking them off the system – something that should arouse suspicion but which happens so often, seems normal.

Last week the Big Kahuna of CAs, Verisign, had to admit that they also were hacked into and that data was stolen from their systems. Coming so long after the break-in and after people got used to the news that smaller sites were hacked (relatively smaller sites…still significant to the system though), this isn’t getting a lot of play. When Belgian CA GlobalSign was broken into the hue and cry approached ChickenLittle-ish. This week I see articles on Verisign that don’t get any clicks.

Is it that all the tech geniuses at all the dcinema installers and installation and distribution sites double-triple checked their firewalls and decided they were nuke free and nuke-proof? Or perhaps we are complacent, feeling that the industry is not like the bank industry, with no immediate link to buckets of spendable cash, and no one really focusing the industry. Or, perhaps more logically, the dcinema industry is just hoping that the entire unbuilt fortress of SMPTE compliance will get together before the jewels that the studios need to protect get too exposed, because – “Hey, we’re pedaling as fast as we can, and see, you wanted all these updates put into legacy equipment with constant patching to the legacy InterOp format…”

For bettor or worse, there is no universal trusted device list in the industry, most likely due to potential liability issues. This has led to every company and their brother having a separate list – though there is enough interplay that these are presumed to have enough intercourse that if one list is polluted with a rogue ‘signed’ utensil, it would be disseminated throughout the lists. So, the best and the worse of all possible worlds.

Into this is a RFI from a company (last week) suggesting that they can build a system…

This article is a work in progress. Here are some of the industry articles that provoked the issue:

Who to trust after the VeriSign hack? | IT PRO

VeriSign admits 2010 hack | IT PRO

Trustwave issued a man-in-the-middle certificate – The H Security: News and Features

Break-ins at domain registrar VeriSign in 2010 – The H Security: News and Features

Backdoor in TRENDnet IP cameras – The H Security: News and Features

Certificate fraud: Protection against future “DigiNotars” – The H Security: News and Features

OpenPGP in browsers – The H Security: News and Features

Google researchers propose way out of the SSL dilemma – The H Security: News and Features

Google wants to do away with online certificate checks – The H Security: News and Features

Is the end nigh for Certificate Authorities? | IT PRO

Certificate issuing stopped at KPN after server break-in discovered – The H Security: News and Features

Certificate Authorities and DCinema

Another has been found to have introduced a man-in-the-middle attack vector, meaning that once a legitimate user opened the door by giving the correct credentials, someone slipped in and assumes the identity of that user with all their rights (usually kicking them off the system – something that should arouse suspicion but which happens so often, seems normal.

Last week the Big Kahuna of CAs, Verisign, had to admit that they also were hacked into and that data was stolen from their systems. Coming so long after the break-in and after people got used to the news that smaller sites were hacked (relatively smaller sites…still significant to the system though), this isn’t getting a lot of play. When Belgian CA GlobalSign was broken into the hue and cry approached ChickenLittle-ish. This week I see articles on Verisign that don’t get any clicks.

Is it that all the tech geniuses at all the dcinema installers and installation and distribution sites double-triple checked their firewalls and decided they were nuke free and nuke-proof? Or perhaps we are complacent, feeling that the industry is not like the bank industry, with no immediate link to buckets of spendable cash, and no one really focusing the industry. Or, perhaps more logically, the dcinema industry is just hoping that the entire unbuilt fortress of SMPTE compliance will get together before the jewels that the studios need to protect get too exposed, because – “Hey, we’re pedaling as fast as we can, and see, you wanted all these updates put into legacy equipment with constant patching to the legacy InterOp format…”

For bettor or worse, there is no universal trusted device list in the industry, most likely due to potential liability issues. This has led to every company and their brother having a separate list – though there is enough interplay that these are presumed to have enough intercourse that if one list is polluted with a rogue ‘signed’ utensil, it would be disseminated throughout the lists. So, the best and the worse of all possible worlds.

Into this is a RFI from a company (last week) suggesting that they can build a system…

This article is a work in progress. Here are some of the industry articles that provoked the issue:

Who to trust after the VeriSign hack? | IT PRO

VeriSign admits 2010 hack | IT PRO

Trustwave issued a man-in-the-middle certificate – The H Security: News and Features

Break-ins at domain registrar VeriSign in 2010 – The H Security: News and Features

Backdoor in TRENDnet IP cameras – The H Security: News and Features

Certificate fraud: Protection against future “DigiNotars” – The H Security: News and Features

OpenPGP in browsers – The H Security: News and Features

Google researchers propose way out of the SSL dilemma – The H Security: News and Features

Google wants to do away with online certificate checks – The H Security: News and Features

Is the end nigh for Certificate Authorities? | IT PRO

Certificate issuing stopped at KPN after server break-in discovered – The H Security: News and Features

DCI Talks NIST

There are many FIPS standards, since they are the codification for the use of all non-military computers allowed by the US government, which spans many fields. The security standards referenced by SMPTE and the DCI group are the 140 series which were passed in May of 2001 known as 140-2. There are four levels defined in this series beginning with Level 1, ascending with higher components of physical security to Level 4. Level 2 defines physical tamper evidence and role-based authentication, Level 3 adds tamper resistance, identity authentication and different physical and logical separations between different interfaces as data goes between them, complicated with security going back and forth. Level 4 adds more physical security, and focuses on attacks coming from the environment such as Side Channel and Cache attacks. 

Currently, Digital Cinema uses Level 3 of FIPS-2. But FIPS has begun the final steps of their process to supersede FIPS-2 with FIPS-3, expected to be finalized for implementation in 2011 or 2012. DCI specifications (and SMPTE and ISO (the International Standards Organization which incorporated the DCinema SMPTE standards note for note) require that DCI Compliant equipment move with the current FIPS standard. What came as a surprise though was an “Annex A” that was changed in advance of FIPS-3 which changed 3 salient points of the way that keys are utilized in the process.

There has been a DCI statement recently that allows a “grandfathering” of equipment that has passed compliance under the “old” rules. (Compliance Test Plan Change Policy Statement) But manufacturers are still preparing equipment for compliance that will not make it under the old rules. As of now there are several manufacturers of projectors who have passed through the DCI Compliance process, but there are no servers (though some have FIPS compliance already.)  

Michael Karagosian of MKPE Consulting points out: 

A surprise was introduced in January of this year when NIST changed Annex A of FIPS 140-2, the NIST specification for which DCI currently requires compliance.  The transition period for this revision is taking place right now, in this calendar year.  NIST says that after December 31 of 2010, it will no longer accept test results from products that comply with the older version of FIPS 140-2.  

There are some notable exceptions to this deadline that benefit the digital cinema community.  But one very significant issue remains regarding dual use of the asymmetrical key-pair in the media block, for which the December 31 deadline is still intact.  The primary use of the media block key-pair is to encrypt and decrypt the KDM.  But the DCI spec calls for other uses of this key-pair, as well.  The dilemma presented by FIPS 140-2 is discussed in my report in the September issue of the SMPTE Journal, which is online at http://mkpe.com/report/.

To summarize the problem:  SMPTE 430-5, one of the standards that establishes the DCI-compliant Security Log, requires that the media block certificate (public key) be used to digitally sign the media block security logs.  This behavior is mandated by the DCI specification, in addition to other DCI-specified uses. The older version of FIPS 140-2 allows this multi use of the media block key-pair through its normative reference to FIPS 186-2.  However, the newer FIPS 186-3 forbids the multi-use case.  FIPS 140-2 Annex A was updated in January 2010 to now require conformance with FIPS 186-3.  Further, a NIST discussion paper on their website requires compliance to FIPS 186-3 after December 31, 2010.

Below is the relevant text taken from SMPTE 430-5, FIPS 186-3, and the NIST discussion paper:

* From SMPTE 430-5 Security Log Event Class and Constraints, Section 6.2:
“Each Signature shall be signed with the Digital Cinema Certificate of the Security Device that generates the Log Record or sequence of Log Records.”
(A copy of SMPTE 430-5 can be purchased from the SMPTE web site at http://store.smpte.org/product-p/smpte%200430-5-2008.htm.)  Note that the other uses mandated in the DCI spec of the media block’s Digital Cinema Certificate is to create the KDM and to establish a TLS session between media block and projector.

* From FIPS 186-3, page 11 (http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf):
“However, a key pair used for digital signature generation and verification as specified in this Standard shall not be used for any other purpose.”

* From NIST DISCUSSION PAPER: The Transitioning of Cryptographic Algorithms and Key Sizes (http://csrc.nist.gov/groups/ST/key_mgmt/documents/Transitioning_CryptoAlgos_070209.pdf):
“New implementations designed to conform to FIPS 186-2 may be tested by the labs until December 31, 2010, after which only implementations claiming conformance to FIPS 186-3 will be tested for validation.”

If no action is taken by DCI, the result will be that the DCI specification will be in conflict with itself after December 31.  The DCI spec will call for compliance to FIPS 140-2, which will no longer allow the media block key-pair applications that are also required by the DCI specification, including the KDM as it is defined today.

That was written to the InterSociety Digital Cinema Forum on 3 October 2010.

Against that background, DCI issues a document on 11 November 2010:
DCI Informational Bulletin NIST Standards Evolution & FIPS 140-2 to FIPS 140-3 Transition 

Another analysis of FIPS-3: 
Federal Information Processing Standard (FIPS) 140-3