1、 Copyright 2011 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Approved September 24, 2011 Table of Contents Page Foreword . 2 Intellectual Property 2 Introduction 2 1 Scope 3 2 Conformance Notation 3 3 Normative References 3 4 Overvi
2、ew (Informative) . 4 5 Definitions . 5 5.1 Definition of Terms . 5 5.2 Definition of Processes and Validation 6 5.2.1 Composition Playlist Validity 6 5.2.2 Frame Playback Process . 6 5.2.3 Complete CPL Playback 6 5.3 Security Event Class 6 5.4 Security Class Namespace 6 5.5 Namespace Prefixes 6 5.6
3、Reference Architectures 7 6 Security Application Requirements . 7 6.1 Security Constraints . 8 6.1.1 Log Record Header 8 6.1.2 Log Record Body . 8 6.1.3 Log Record Signature 9 6.2 Security Log Record Authentication and Chaining 10 7 Security Event Definitions . 10 7.1 ReferenceID Scope 10 7.2 Event
4、Types . 11 7.3 Event SubTypes . 12 7.3.1 Playout Event SubTypes 12 7.3.2 Validation Event SubTypes 14 7.3.3 Key Event SubTypes . 15 7.3.4 ASM Event SubTypes 16 7.3.5 Operations Event SubTypes 18 7.4 Exception Tokens and Definitions 22 8 Examples (Informative) 23 8.1 Example 1 . 23 9 Glossary of Acro
5、nyms 23 Annex A Proxy Logging (Informative) 24 Annex B Security Log Report Filtering (Informative) . 25 Page 1 of 25 pages SMPTE ST 430-5:2011 Revision of SMPTE 430-5-2008 SMPTE STANDARD D-Cinema Operations Security Log Event Class and Constraints SMPTE ST 430-5:2011 Page 2 of 25 pages Foreword SMPT
6、E (the Society of Motion Picture and Television Engineers) is an internationally-recognized standards developing organization. Headquartered and incorporated in the United States of America, SMPTE has members in over 80 countries on six continents. SMPTEs Engineering Documents, including Standards,
7、Recommended Practices and Engineering Guidelines, are prepared by SMPTEs Technology Committees. Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineer
8、ing Documents are drafted in accordance with the rules given in Part XIII of its Administrative Practices. SMPTE ST 430-5 was prepared by Technology Committee 21DC. Intellectual Property At the time of publication no notice had been received by SMPTE claiming patent rights essential to the implement
9、ation of this Standard. However, attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. SMPTE shall not be held responsible for identifying any or all such patent rights. Introduction A general specification for D-Cinema Log Records and
10、Log Reports is specified in LogRecord. This Security Class standard defines a class, and an associated namespace, for Log Records for security logging. Additionally, this standard constrains the use and application of that format to Security Log Records and Reports. More specifically, this document
11、specifies the format of Log Records produced by security devices within D-Cinema systems. Typically these records are produced by the Security Manager component of the system, which produces records of security events for consumption by systems external to the security system. When the Security Mana
12、ger produces these records, they are constructed to support authentication and non-repudiation by and for the device that produces them. Support is included for authenticating chains of records in a manner that reduces the overhead that would otherwise result if each record were to be authenticated
13、individually. SMPTE ST 430-5:2011 Page 3 of 25 pages 1 Scope The purpose of this document is to specify a Security Event Class and namespace for Security Log Records; and to constrain individual Log Records and sequences of such records (Log Reports) as they are used for security event logging purpo
14、ses in D-Cinema applications. The items covered contain descriptions of events logged by the security system, which are intended to provide forensic information regarding security critical events. This document does not specify the means of communication or the format of messaging between security d
15、evices in a system. Neither does this document define the format for storage of Log Events within the protected storage of a security device. The Security Log Records and Security Log Record Sequences (Log Reports) described herein are intended for reporting of Security Events previously recorded by
16、 the security system to consumers of that information which are external to the security system. 2 Conformance Notation Normative text is text that describes elements of the design that are indispensable or contains the conformance language keywords: “shall“, “should“, or “may“. Informative text is
17、text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added editorially without affecting interoperability. Informative text does not contain any conformance keywords. All text in this document is, by default, normative, except: the Introduction, any se
18、ction explicitly labeled as “Informative“ or individual paragraphs that start with “Note:” The keywords “shall“ and “shall not“ indicate requirements strictly to be followed in order to conform to the document and from which no deviation is permitted. The keywords, “should“ and “should not“ indicate
19、 that, among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain possibility or course of action is deprecated but not prohib
20、ited. The keywords “may“ and “need not“ indicate courses of action permissible within the limits of the document. The keyword “reserved” indicates a provision that is not defined at this time, shall not be used, and may be defined in the future. The keyword “forbidden” indicates “reserved” and in ad
21、dition indicates that the provision will never be defined in the future. A conformant implementation according to this document is one that includes all mandatory provisions (“shall“) and, if implemented, all recommended provisions (“should“) as described. A conformant implementation need not implem
22、ent optional provisions (“may“) and need not implement them as described. 3 Normative References Note: All references in this document to other SMPTE documents use the current numbering style (e.g. SMPTE ST 433:2008) although, during a transitional phase, the document as published (printed or PDF) m
23、ay bear an older designation (such as SMPTE 433-2008). Documents with the same root number (e.g. 433) and publication year (e.g. 2008) are functionally identical. The following standards contain provisions which, through reference in this text, constitute provisions of this standard. At the time of
24、publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent edition of the standards indicated below. RFC 3280 Internet X.509 Public Key Infrastructur
25、e Certificate and Certificate Revocation List (CRL) Profile URL: http:/www.ietf.org/rfc/rfc3280.txt SMPTE ST 430-5:2011 Page 4 of 25 pages DCMLTypes SMPTE ST 433:2008, D-Cinema XML Data Types LogRecord SMPTE ST 430-4:2008, D-Cinema Operations Log Record Format Specification KDM SMPTE ST 430-1:2006,
26、D-Cinema Operations Key Delivery Message; and Amendment 1-2009 to SMPTE ST 430-1:2006 D-Cert SMPTE ST 430-2 :2006, D-Cinema Operations Digital Certificate ETM SMPTE ST 430-3:2008, D-Cinema Operations Generic Extra-Theater Message Format ASM SMPTE ST 430-6:2010, D-Cinema Operations Auditorium Securit
27、y Messages for Intra-Theater Communications TFE SMPTE ST 429-6:2006, D-Cinema Packaging MXF Track File Essence Encryption CPL SMPTE ST 429-7:2006, D-Cinema Packaging Composition Playlist PKL SMPTE ST 429-8:2007, D-Cinema Packaging Packing List TRK SMPTE ST 429-3:2007, D-Cinema Packaging Sound and Pi
28、cture Track File RFC 4051 Additional XML Security Uniform Resource Identifiers (URIs) http:/www.ietf.org/rfc/rfc4051.txt RFC 2253 Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names. URL: http:/www.ietf.org/rfc/rfc2253.txt 4 Overview (Informative) The funda
29、mental purpose of security logging in D-Cinema systems is to assure that access to clear-text content, and the use of decryption keys to accomplish this, can be tracked in trusted reports from the security system. An important corollary of this requirement is to record that the security system itsel
30、f is functioning properly. The Security Manager component of the security system is the trusted device, which collects information as the system operates, then processes that information to compose Security Log Records and potentially Log Reports. While communication of Log Event data between device
31、s in a security system must be performed securely, such communications are outside of the scope of this document. This document does not specify any particular security system architecture, and so uses the term “Security Device“ to refer to components of the security system generically. The general
32、requirements for Security Log Records external to the security system are that the records be verifiable as to the integrity of their content, verifiable as to the completeness of a report, and verifiable as to their source. An additional requirement is that sequences of log records must support fil
33、tering of potentially sensitive information, while maintaining sequential integrity, i.e. the filtering of an individual record must leave verifiable evidence of the records existence and position in the sequence. Filtering is described in LogRecord. When a system external to the security system, su
34、ch as a general-purpose log management system, is instructed to retrieve records from the security system, this standard describes how those records should be generated and represented. The LogRecord standard is constructed to support filtering of log records by omitting the body part of a record. T
35、he security system may support the generation of pre-filtered log record sequences (with selected record bodies omitted), or filtering may be performed after the log records are retrieved. The Security Application Requirements section of this document constrains the application of the log format def
36、ined in the Log Record Specification for D-Cinema LogRecord. These constraints ensure that this format is applied to the expression of Log Records and Reports in a manner that provides for authentication of the log data. SMPTE ST 430-5:2011 Page 5 of 25 pages It is important to note that LogRecord d
37、oes not actually specify the Event Types, Event SubTypes, Parameters, or scopes for the Event Classes that it denotes, but provides a framework for doing so. The Security Event Definitions section of this document defines the “security” Event Class as called for in LogRecord, including all of the de
38、tail necessary to create fully defined Log Records for security. 5 Definitions 5.1 Definition of Terms Security Log Event Any event that has security implications or forensic value. Such an event results in the recording of log data. Security Log Data Security event information that is recorded and
39、stored within a security device, where such an event took place or was observed. Security Log Record A Log Record, containing Security Log Data, describing a Security Log Event. Security Log Report - A sequence of Log Records as specified in LogRecord and subject to the constraints specified in this
40、 document. Security Device A generic term, which refers to a physical or logical device which contains or uses a D-Cinema security certificate, and which performs a D-Cinema security function. Security Entity (SE) A logical entity that implements one or more d-cinema security-related processes. (e.g
41、. a media Decryptor or a forensic marker) Secure Processing Block (SPB) A tamper-resistant, -evident and -responsive perimeter associated with a Digital Certificate around security-critical information. The specific characteristics of the perimeter are outside the scope of this specification. Image
42、Media Block (IMB) The combination of Image Decryptor, Audio Decryptor, Forensic Marker(s), Security Manager and (optionally) Link Encryptor Security Entities contained within a single Secure Processing Block. Remote Secure Processing Block (Remote SPB) A Secure Processing Block other than the Image
43、Media Block. Security Manager (SM) A Security Entity responsible for parsing Key Delivery Messages and generating Log Records. It is implemented within the Image Media Block. There is a single Security Manager associated with each auditorium within an exhibition site. Screen Management System (SMS)
44、A logical entity associated with a Digital Certificate responsible for content management and validation within an auditorium. SPB Marriage and Divorce SPB Marriage and Divorce consist in the creation and termination, respectively, of a persistent, monitored connection (electrical and physical) betw
45、een two Secure Processing Blocks. Forensic Marking Forensic Marking (FM) is the embedding of tracking information into sound and/or image essence by the Image Media Block during playback. SPB Shutdown and Initialization SPB Shutdown and Initialization mean that execution of the firmware on the SPB h
46、as been terminated or started, respectively. Sequence Number refers to a count of KLV encrypted triplets in a track file, counted using the method defined in Section 7.9 “Sequence Number” of TFE (2006). SMPTE ST 430-5:2011 Page 6 of 25 pages Main Asset The Main Asset in a CPL shall be the Main Pictu
47、re asset if present. If the Main Picture asset is not present, the Main Asset shall be the picture related asset that references the picture elements to be projected on the main screen. If no main screen picture related asset is present in the CPL, the Main Asset shall be the first asset according t
48、o the Reel assets sequence order defined in SMPTE ST 429-7 that is used in the CPL Reels. 5.2 Definitions of Processes and Validation 5.2.1 Composition Playlist Validity A Composition Playlist is valid if all of the following conditions are satisfied. The message digest of all assets referenced by t
49、he Composition Playlist matches the corresponding message digest stored in the Hash element of the CPL, as defined in Section 8.2.2 of SMPTE ST 429-7. The digital signature recorded in the Signature element, including the certificates contained therein, is valid per the provisions of D-Cert. 5.2.2 Frame Playback Process The Frame Playback Process consists of The decryption of essence according to TFE; followed by
