1、 Reference number ISO 26430-6:2009(E) ISO 2009INTERNATIONAL STANDARD ISO 26430-6 First edition 2009-12-15 Digital cinema (D-cinema) operations Part 6: Auditorium security messages for intra- theater communications Oprations du cinma numrique (cinma D) Partie 6: Messages de scurit de salle pour les c
2、ommunications lintrieur du thtre ISO 26430-6:2009(E) PDF disclaimer This PDF file may contain embedded typefaces. In accordance with Adobes licensing policy, this file may be printed or viewed but shall not be edited unless the typefaces which are embedded are licensed to and installed on the comput
3、er performing the editing. In downloading this file, parties accept therein the responsibility of not infringing Adobes licensing policy. The ISO Central Secretariat accepts no liability in this area. Adobe is a trademark of Adobe Systems Incorporated. Details of the software products used to create
4、 this PDF file can be found in the General Info relative to the file; the PDF-creation parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In the unlikely event that a problem relating to it is found, please inform the C
5、entral Secretariat at the address given below. COPYRIGHT PROTECTED DOCUMENT ISO 2009 All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm, without permiss
6、ion in writing from either ISO at the address below or ISOs member body in the country of the requester. ISO copyright office Case postale 56 CH-1211 Geneva 20 Tel. + 41 22 749 01 11 Fax + 41 22 749 09 47 E-mail copyrightiso.org Web www.iso.org Published in Switzerland ii ISO 2009 All rights reserve
7、dISO 26430-6:2009(E) ISO 2009 All rights reserved iiiForeword ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies (ISO member bodies). The work of preparing International Standards is normally carried out through ISO technical committees. E
8、ach member body interested in a subject for which a technical committee has been established has the right to be represented on that committee. International organizations, governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the Internati
9、onal Electrotechnical Commission (IEC) on all matters of electrotechnical standardization. International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2. The main task of technical committees is to prepare International Standards. Draft International Standa
10、rds adopted by the technical committees are circulated to the member bodies for voting. Publication as an International Standard requires approval by at least 75 % of the member bodies casting a vote. Attention is drawn to the possibility that some of the elements of this document may be the subject
11、 of patent rights. ISO shall not be held responsible for identifying any or all such patent rights. ISO 26430-6 was prepared by the Society of Motion Picture and Television Engineers (as SMPTE 430-6-2008) and was adopted, under a special “fast-track procedure”, by Technical Committee ISO/TC 36, Cine
12、matography, in parallel with its approval by the ISO member bodies. ISO 26430 consists of the following parts, under the general title Digital cinema (D-cinema) operations: Part 1: Key delivery message equivalent to SMPTE 430-1 Part 2: Digital certificate equivalent to SMPTE 430-2 Part 3: Generic ex
13、tra-theater message format equivalent to SMPTE 430-3 Part 4: Log record format specification equivalent to SMPTE 430-4 Part 5: Security log event class and constraints equivalent to SMPTE 430-5 Part 6: Auditorium security messages for intra-theater communications equivalent to SMPTE 430-6 Part 9: Ke
14、y delivery bundle equivalent to SMPTE 430-9 ISO 26430-6:2009(E) iv ISO 2009 All rights reservedIntroduction This part of ISO 26430 comprises SMPTE 430-6-2008 and Annex ZZ (which provides equivalences between ISO standards and SMPTE standards referenced in the text). Copyright 2008 by THE SOCIETY OF
15、MOTION PICTURE AND TELEVISION ENGINEERS 595 W. Hartsdale Ave., White Plains, NY 10607 (914) 761-1100 Approved March 3, 2008 Table of Contents Page Foreword . 2 1 Scope 3 2 Conformance Notation 3 3 Normative References 3 4 Glossary 4 5 Overview (Informative) 4 6 Message Security, RRP Structure and Ge
16、neral Requirements 5 6.1 Message Security: Transport Layer Security (TLS) 5 6.2 Message Structure: Key-Length-Value (KLV). 5 6.3 General ASM Command Elements 6 6.4 General TLS and RRP Requirements for Auditorium Secutiry Messages 6 7 General Purpose ASM Commands. 7 7.1 BadRequest Response 8 7.2 GetT
17、ime . 8 7.3 GetEventList. 9 7.4 GetEventID. 10 7.5 QuerySPB 10 8 Link Encryption ASM Commands . 11 8.1 LEKeyLoad. 12 8.2 LEKeyQueryID . 13 8.3 LEKeyQueryAll. 14 8.4 LEKeyPurgeID . 14 8.5 LEKeyPurgeAll. 15 Annex A Auditorium Security Messages Variable Length Universal Label (UL) Key (Normative). 16 A
18、nnex B Bibliography (Informative) 18 Page 1 of 18 pages SMPTE 430-6-2008SMPTE STANDARD D-Cinema Operations Auditorium Security Messages for Intra-Theater Communications ISO 26430-6:2009(E) ISO 2009 All rights reserved 1SMPTE 430-6-2008 Page 2 of 18 pages Foreword SMPTE (the Society of Motion Picture
19、 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, Recommended Practices and Engine
20、ering 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 Engineering Documents are drafted in acc
21、ordance with the rules given in Part XIII of its Administrative Practices. SMPTE Standard 430-6 was prepared by Technology Committee DC28. ISO 26430-6:2009(E) 2 ISO 2009 All rights reservedSMPTE 430-6-2008 Page 3 of 18 pages 1 Scope The Auditorium Security Message (ASM) specification enables interop
22、erable communication of security- critical information (information necessary to ensure security of D-Cinema content) between devices over an intra-theater exhibition network. The specification uses Transport Layer Security (TLS) for authentication and confidentiality, and Key-Length-Value (KLV) cod
23、ing for message encoding. It defines a protocol, a general purpose request-response message set and a specific message set for link encryption keying. 2 Conformance Notation Normative text is text that describes elements of the design that are indispensable or contains the conformance language keywo
24、rds: “shall“, “should“, or “may“. Informative text is 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, b
25、y default, normative, except: the Introduction, any section 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 permi
26、tted. The keywords, “should“ and “should not“ indicate 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 possib
27、ility or course of action is deprecated but not prohibited. 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.
28、The keyword “forbidden” indicates “reserved” and in addition 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
29、described. A conformant implementation need not implement optional provisions (“may“) and need not implement them as described. 3 Normative References The following standards contain provisions which, through reference in this text, constitute provisions of this recommended practice. At the time of
30、publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this recommended practice are encouraged to investigate the possibility of applying the most recent edition of the standards indicated below. 336M SMPTE 336M-2007, Data Encoding
31、Protocol Using Key-Length-Value Dcert SMPTE 430-2-2006, D-Cinema Operations Digital Certificate IANA Internet Assigned Numbers Authority. See www.iana.org/assignments/port-numbers KDM SMPTE 430-1-2006, D-Cinema Operations Key Delivery Message Log SMPTE 430-5-2008, D-Cinema Packaging Security Log Eve
32、nt Class and Constraints TLS “The TLS Protocol, Version 1.0” RFC 2246 See www.ietf.org/rfc/rfc2246.txt TLS-AES “AES Cyphersuites for TLS” RFC 3268 See www.ietf.org/rfc/rfc3268.txt ISO 26430-6:2009(E) ISO 2009 All rights reserved 3SMPTE 430-6-2008 Page 4 of 18 pages 4 Glossary The following acronyms
33、are used in this specification: ASM Auditorium Security Message AES Advanced Encryption Standard BER Basic Encoding Rules (ASN.1) CBC Cipher Block Chaining IMB Image Media Block KLV Key Length Value LDB Link Decryptor Block LE Link Encryption RRP Request Response Pair RSA Rivest Shamir Adleman publi
34、c key encryption SHA-1 Secure Hash Algorithm revision 1 SM Security Manager SPB Secure Processing Block TLS Transport Layer Security Uintx Unsigned x bit integer UL Universal Label UTC Coordinated Universal Time UUID Universally Unique Identifier (ISO 11578) 5 Overview (Informative) Exhibition secur
35、ity equipment configurations which employ remote Secure Processing Blocks (SPBs) (i.e., SPBs which are remote from that which contains the Security Manager) require a secure method of communicating with such SPBs. The generic model for this is illustrated in Figure 1. Initiator Responder Figure 1 Au
36、ditorium Security Message Model Remote SPB Media Block SPB (End Point) (End Point) Security Manager TLS Link ISO 26430-6:2009(E) 4 ISO 2009 All rights reservedSMPTE 430-6-2008 Page 5 of 18 pages The communication security protection mechanism needs to provide (1) confidentiality, (2) integrity, (3)
37、authentication and (4) prevention of replay. In addition, the mechanism needs to be inexpensive to implement, and simple to support in secure silicon processors. Message descriptions are given in terms of the Initiator and Responder (and this specification makes no distinction between messages emana
38、ting from the Security Manager vs. the Image Media Block that contains it). As used herein the generic name for a “block” is SPB. 6 Message Security, RRP Structure and General Requirements The implementation of Auditorium Security Messages (ASM) shall be in the form of a “Request” from the Initiator
39、 followed by a “Response” from the Responder (recipient SPB). Each pair of messages is referred to as a Request-Response Pair (RRP). 6.1 Message Security: Transport Layer Security (TLS) Message security shall be provided by communicating ASMs under Transport Layer Security (TLS) (see TLS). During TL
40、S session establishment, the Initiator (which contains the Security Manager) and Responder exchange their X.509 certificates as part of the initial TLS handshake. This exchange shall be supported using D-Cinema compliant certificates as defined in the D-Cinema Digital Certificate specification DCert
41、. The TLS protocol is constrained to simplify implementation, facilitate interoperability and ensure predictable processing: The protocol shall be TLS 1.0. 2048-bit RSA using a public exponent value of 65537 shall be the only supported public key algorithm. AES-CBC 128-bit shall be the only supporte
42、d symmetric cipher (see TLS-AES). SHA-1 shall be the only supported hash algorithm. The CipherSuite shall be “TLS_RSA_WITH_AES_128_CBC_SHA” (0x00, 0x2F) (see TLS- AES). The TLS record size shall equal 512 bytes. The Compression Method shall be “null” (no compression). Other than as part of the openi
43、ng handshake, the ChangeCipherSpec message shall be ignored. 6.2 Message Structure: Key Length Value (KLV) Request and Response ASMs shall be Key Length Value (KLV) encoded using Fixed Length Pack encoding according to SMPTE 336M-2001 336M. The Fixed Length Universal Label (UL) Key is given in Annex
44、 A of this document. As a Fixed Length Pack, each individual item in the Value field comprises only an item value. The KLV Length field shall be a long-form BER value encoded with a fixed length of 4 bytes total. Example: For a KLV packet having a Value field that is 12 bytes in length, the Length f
45、ield would be encoded as the following 4 bytes, 0x83 0x00 0x00 0x0C (hexadecimal). Each ASM Request-Response Pair (RRP) represents two message types and thus KLV UL “value” registration is required twice for each defined RRP (see Annex A). Informative Note: The recipient of each RRP Request or Respo
46、nse command is implicit by virtue of the TLS socket (which is known at the applications level) that carries the messages. ISO 26430-6:2009(E) ISO 2009 All rights reserved 5SMPTE 430-6-2008 Page 6 of 18 pages 6.3 General ASM Command Elements For each message type, the following shall apply: The comma
47、nd type is denoted within the opening KLV “Key” field (16 bytes). “Length” is a BER-encoded four byte field which describes the length of the message in bytes. “Request_ID” shall be an application level tag for the Request, which shall be echoed by the corresponding Response. A non-zero Request_ID v
48、alue shall be set by the SM, which should select unique values (e.g. a sequencing counter) for each TLS connection it manages. (Request_ID generation means is left to implementers and is out of scope of this specification.) Multi-byte integer values shall be sent as big-endian data, meaning most sig
49、nificant byte first. General “Response” elements for each Response command are defined as follows: General Response Elements Element Meaning UInt8 Value RRP successful Request successfully processed 0 RRP failed Responder unable to process Request 1 RRP Invalid Invalid parameter or command structure 2 ResponderBusy Responder too busy to process Request 3 Messages defined in this document may contain batches. A batch is a compound data
