SMPTE RDD 20-2010 Cinelink 2 Specification《Cinelink 2规范》.pdf

1、 Copyright 2010 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue., White Plains, NY 10601 (914) 761-1100 Approved April 12, 2010 The attached document is a Registered Disclosure Document prepared by the proponent identified below. It has been examined by the appropriate SMPT

2、E Technology Committee and is believed to contain adequate information to satisfy the objectives defined in the Scope, and to be technically consistent. This document is NOT a Standard, Recommended Practice or Engineering Guideline, and does NOT imply a finding or representation of the Society. Erro

3、rs in this document should be reported to the proponent identified below, with a copy to engsmpte.org. All other inquiries in respect of this document, including inquiries as to intellectual property requirements that may be attached to use of the disclosed technology, should be addressed to the pro

4、ponent identified below. Proponent contact information: Reiner Doetzkies Texas Instruments 6550 Chase Oaks Blvd. Plano, TX 75023 Email Page 1 of 20 pages SMPTE RDD 20:2010 SMPTE REGISTERED DISCLOSURE DOCUMENT Cinelink 2 Specification SMPTE RDD 20:2010 Page 2 of 20 pages Table of Contents Page Intro

5、duction 3 1 Scope 3 2 Conformance Notation 3 3 Normative References 3 4 Glossary of Terms and Acronyms 4 5 System Description . 4 5.1 AES Counter Definition . 7 5.2 AES Stream to Plaintext/Ciphertext Mapping Definition 7 5.3 Link Encryption Key Message Definition 11 5.4 Link Encryption Metadata Defi

6、nition . 12 5.5 Encryption Modulator and Decryption Demodulator Definition 16 Annex A LUT Definition (Normative) 18 Annex B LUT Data (Normative) 19 Annex C Bibliography (Informative) 20 SMPTE RDD 20:2010 Page 3 of 20 pages Introduction Cinelink 2 is a protocol used to protect copyrighted images betw

7、een a playback server and DLP Cinema projector system. The images are protected on a local video data link via an AES key stream generator operating in counter mode. 1 Scope This document provides details of the implementation of the Cinelink 2 Link Encryption from Texas Instruments. 2 Conformance N

8、otation 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 text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added edito

9、rially without affecting interoperability. Informative text does not contain any conformance keywords. All text in this document is, by default, normative, except: the Introduction, any section explicitly labeled as “Informative“ or individual paragraphs that start with “Note: The keywords “shall“ a

10、nd “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 that, among several possibilities, one is recommended as particularly suitable, without mentioning or excluding

11、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 prohibited. The keywords “may“ and “need not“ indicate courses of action permissible within the limits of the document.

12、 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 addition indicates that the provision will never be defined in the future. A conformant implementation according to this

13、document is one that includes all mandatory provisions (“shall“) and, if implemented, all recommended provisions (“should“) as described. A conformant implementation need not implement optional provisions (“may“) and need not implement them as described. Unless otherwise specified, the order of prec

14、edence of the types of normative information in this document shall be as follows: Normative prose shall be the authoritative definition; Tables shall be next; followed by formal languages; then figures; and then any other language forms. 3 Normative References The following standards contain provis

15、ions which, through reference in this text, constitute provisions of this registered disclosure document. At the time of 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 t

16、he possibility of applying the most recent edition of the standards indicated below. SMPTE 291M-2006, Television Ancillary Data Packet and Space Formatting SMPTE 292-2008, 1.5 Gb/s Signal/Data Serial Interface SMPTE RDD 20:2010 Page 4 of 20 pages SMPTE 372-2009, Dual Link 1.5 Gb/s Digital Interface

17、for 1920 1080 and 2048 1080 Picture Formats AES, FIPS PUB 197, Advanced Encryption Standard. U.S. Department of Commerce/National Institute of Standards and Technology. http:/csrc.nist.gov/publications/fips/fips197/fips-197.pdf 4 Glossary of Terms and Acronyms 292: SMPTE interface specification for

18、HD-SDI (used interchangeably with HD-SDI) AES: Advanced Encryption Standard DLP: Digital Light Processing DVI: Digital Visual Interface HD-SDI: High Definition Serial Data Interface (used interchangeably with 292) LE keys: Link Encryption keys TLS: Transport Layer Security 5 System Description A sys

19、tem block diagram of a typical Cinelink 2 system is given in Figure 1. Figure 1 Cinelink 2 Typical Application SMPTE RDD 20:2010 Page 5 of 20 pages A Cinelink 2 system consists of an encryption engine in the server, a channel, and a decryption engine in the projector. The encryption engine is depict

20、ed in Figure 2. Figure 2 Encryption Engine The basic structure of the encryption and decryption engine is symmetric. The decryption engine is depicted in Figure 3. SMPTE RDD 20:2010 Page 6 of 20 pages Figure 3 Decryption Engine The encryption/decryption engine structure consists of an AES stream gen

21、erator block and three modulator/demodulators. The AES stream generator creates two or three (depending on the mode) 10-bit streams of random numbers at the input pixel rate based on an AES core operating in counter mode with an input of the 128-bit AES key and the 128-bit AES counter. The AES rando

22、m number streams then modulate/demodulate the incoming input pixels to encrypt/decrypt them. A HD-SDI link has a set of 8 prohibited codes not for use other than sync words. These hex values are 000h, 001h, 002h, 003h, 3FCh, 3FDh, 3FEh, and 3FFh. Thus, the encryption engine must not generate any of

23、these invalid codes. The structure of the engine allows for invalid codes to be detected and discarded in the AES random number stream before modulating/demodulating the incoming data. The presence and discarding of invalid codes will require the AES core to operate 0.8% faster than the source data

24、bit stream. For dual-link HD-SDI, each channel is encrypted/decrypted independently. For DVI source data streams, invalid code detection and discarding is not required and will be disabled. A secured TLS Ethernet connection is used for key exchange between the server and projector. The details of th

25、is connection are beyond the scope of this specification. All SMPTE image formats defined by the normative references are supported by Cinelink 2. SMPTE RDD 20:2010 Page 7 of 20 pages 5.1 AES Counter Definition Table 1 defines the AES counter. Note that the least significant bits of the counter are

26、the cipher block count. The definition of the AES counter is given Table 1. Table 1 AES Counter TI AES COUNTER DEFINITION AES INPUT BIT AES INPUT NAME DESCRIPTION 127:126 LINK_NUMBER_1:0 0=SINGLE LINK OR LINK A OF DUAL LINK, 1= LINK B OF DUAL LINK, 2-3= RESERVED 125:120 RESERVED 0=DEFAULT 119:56 LE_

27、ATTRIBUTE_DATA_63:0 ATTRIBUTE DATA EXTRACTED FROM LE KEY 55:32 FRAME_COUNT_23:0 NUMBER OF FRAMES FROM THE PREVIOUS KEY CHANGE, RESET TO ZERO AT KEY CHANGE 31:16 LINE_COUNT_15:0 ACTIVE VIDEO LINE NUMBER, RESET TO ZERO FOR THE FIRST LINE OF EVERY FRAME 15:0 CIPHER_BLOCK_COUNT_15:0 NUMBER OF CIPHER BLO

28、CKS, RESET TO ZERO FOR THE FIRST BLOCK OF EVERY LINE 5.2 AES Stream to Plaintext/Ciphertext Mapping Definition The AES core generates a 128-bit output for each AES key and AES counter input. These 128-bit output blocks are called cipher blocks. The conversion of these 128-bit cipher blocks into 10-b

29、it random number streams in the presence of invalid codes is illustrated for 10-bit data words in the following Figure 4. In the AES stream invalid codes are defined to be 3FFh, 3FEh, 3FDh, 3FCh, 3FBh, 3FAh, 3F9h, and 3F8h. When an invalid code in the AES stream is detected, it is simply discarded a

30、nd replaced with the next code in the stream. Note that 8 bits from each cipher block are not used. Figure 4 illustrates the AES to data word mapping for SMPTE 292 source data. SMPTE RDD 20:2010 Page 8 of 20 pages Figure 4 AES to data word mapping for 292 Figure 5 illustrates the AES to data word ma

31、pping for DVI source data. Figure 5 DVI Mapping SMPTE RDD 20:2010 Page 9 of 20 pages The encryption/decryption engine is inherently a 10-bit engine and encrypts and decrypts in 10-bit words. To encrypt/decrypt 8-bit DVI video, the data must be mapped into the 10-bit words of the engine. The exact ma

32、pping between the AES cipher blocks and the incoming pixel data for DVI video is as follows in Table 2. Table 2 DVI Image Mapping AES INPUT BIT 8 BIT 4:4:4 DVI Video PIX # BIT 0 0 B_0 1 0 B_1 2 0 B_2 3 0 B_3 4 0 B_4 5 0 B_5 6 0 B_6 7 0 B_7 8 0 NOT USED 9 0 NOT USED 10 0 G_0 11 0 G_1 12 0 G_2 13 0 G_

33、3 14 0 G_4 15 0 G_5 16 0 G_6 17 0 G_7 18 0 NOT USED 19 0 NOT USED 20 0 R_0 21 0 R_1 22 0 R_2 23 0 R_3 24 0 R_4 25 0 R_5 26 0 R_6 27 0 R_7 28 0 NOT USED 29 0 NOT USED 30 1 B_0 31 1 B_1 32 1 B_2 33 1 B_3 34 1 B_4 35 1 B_5 36 1 B_6 37 1 B_7 38 1 NOT USED 39 1 NOT USED 40 1 G_0 41 1 G_1 42 1 G_2 43 1 G_

34、3 44 1 G_4 SMPTE RDD 20:2010 Page 10 of 20 pages AES INPUT BIT 8 BIT 4:4:4 DVI Video PIX # BIT 45 1 G_5 46 1 G_6 47 1 G_7 48 1 NOT USED 49 1 NOT USED 50 1 R_0 51 1 R_1 52 1 R_2 53 1 R_3 54 1 R_4 55 1 R_5 56 1 R_6 57 1 R_7 58 1 NOT USED 59 1 NOT USED 60 2 B_0 61 2 B_1 62 2 B_2 63 2 B_3 64 2 B_4 65 2

35、B_5 66 2 B_6 67 2 B_7 68 2 NOT USED 69 2 NOT USED 70 2 G_0 71 2 G_1 72 2 G_2 73 2 G_3 74 2 G_4 75 2 G_5 76 2 G_6 77 2 G_7 78 2 NOT USED 79 2 NOT USED 80 2 R_0 81 2 R_1 82 2 R_2 83 2 R_3 84 2 R_4 85 2 R_5 86 2 R_6 87 2 R_7 88 2 NOT USED 89 2 NOT USED 90 3 B_0 91 3 B_1 92 3 B_2 93 3 B_3 94 3 B_4 95 3

36、B_5 96 3 B_6 97 3 B_7 98 3 NOT USED 99 3 NOT USED SMPTE RDD 20:2010 Page 11 of 20 pages AES INPUT BIT 8 BIT 4:4:4 DVI Video PIX # BIT 100 3 G_0 101 3 G_1 102 3 G_2 103 3 G_3 104 3 G_4 105 3 G_5 106 3 G_6 107 3 G_7 108 3 NOT USED 109 3 NOT USED 110 3 R_0 111 3 R_1 112 3 R_2 113 3 R_3 114 3 R_4 115 3

37、R_5 116 3 R_6 117 3 R_7 118 3 NOT USED 119 3 NOT USED 120 NOT USED NOT USED 121 NOT USED NOT USED 122 NOT USED NOT USED 123 NOT USED NOT USED 124 NOT USED NOT USED 125 NOT USED NOT USED 126 NOT USED NOT USED 127 NOT USED NOT USED 5.3 Link Encryption Key Message Definition The Link Encryption Key (LE

38、 key) is a 128-bit pseudo-random number used as the key for AES stream generator operating in counter mode. The same LE key used for encryption is required for decryption. The Link Encryption Attribute Data (LE attribute data) is a 64-bit parameter of the AES counter. It is required to use a random

39、number for this parameter that changes when the LE key changes. Each LE key will be identified by a 12-bit key ID. A LE Key ID of zero is defined as no encryption. Note: SMPTE 430-6 ASM defines the LE key ID parameters of the LEKeyLoadMessage as a 32-bit word, however only a 12-bit word is supported

40、 by the process defined in this document. The upper 20 bits of the LE Key ID will therefore be ignored. Also, note that a LE Key ID of zero is not permitted by this document; thus, an error response shall be returned if a LE Key ID value of zero is sent via ASM. All LE keys and LE attribute data for

41、 a movie may be sent before the start of the movie, or each individual LE key and LE attribute data may be sent before its corresponding movie clip. It is required that the LE key and LE attribute data be sent a minimum of 1 second before use. The LE key and LE attribute data are sent from the serve

42、r to the projector in a Link Encryption Key Message (LE key message) via the Ethernet connection. See SMPTE 430-6 ASM. SMPTE RDD 20:2010 Page 12 of 20 pages The current LE key ID as well as the next LE key ID for each video clip will be sent from the server to the projector via metadata . The projec

43、tor must be able to change LE keys, as identified by a new LE key ID within metadata, at any video frame boundary. All LE keys and LE attribute data stored in the projector are stored in volatile memory. In the event of loss of power to the projector, the LE keys and LE attribute data must be re-loa

44、ded into the projector. The LE Key data received from the server is mapped to the AES Key register in Table 3: Table 3 LE Key Data Mapping ASM Message (Byte order received) 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 AES Key 12 13 14 15 8 9 10 11 4 5 6 7 0 1 2 3 The LE Attribute Data received from the ser

45、ver is mapped to the AES Counter register in Table 4: Table 4 LE Attribute Data Mapping ASM Message (Byte order received) 0 1 2 3 4 5 6 7 AES Counter 4 5 5 7 0 1 2 3 5.4 Link Encryption Metadata Definition The link encryption metadata is used to transfer unencrypted time critical data from the serve

46、r to the projector. The items required for the LE metadata are given in Table 5. SMPTE RDD 20:2010 Page 13 of 20 pages Table 5 LE Metadata LE KEY METADATA ITEM DESCRIPTION SIZE NEXT_LE_KEY_ID LE_KEY_ID OF THE NEXT KEY 12 BITS CURRENT_LE_KEY_ID LE_KEY_ID OF THE CURRENT KEY 12 BITS CURRENT_FRAME_COUNT

47、 NUMBER OF FRAMES FROM THE PREVIOUS KEY CHANGE, RESET TO ZERO AT KEY CHANGE 24 BITS VERSION CURRENTLY SET TO ZERO 6 BITS LINK_NUMBER 0=SINGLE LINK OR LINK A OF DUAL LINK, 1= LINK B OF DUAL LINK, 2-3= RESERVED 2 BITS AES_SYNC_WORD THE VALID 10-BIT AES WORD DIRECTLY FOLLOWING THE AES WORD USED TO ENCR

48、YPT THE LAST ACTIVE PIXEL OF THE LAST ACTIVE LINE OF THE PREVIOUS FRAME. THIS WORD IS USED BY THE PROJECTOR TO VERIFY SYNCRONIZATION OF THE SERVER AND PROJECTOR AES RANDOM NUMBER GENERATORS. 10 BITS This data is used to execute LE key changes and to supply the projector with frame count and link num

49、ber components of the AES counter. This data is also used to verify the synchronization between the server and projector AES random number generators by comparing the AES_SYNC_WORD from the server (metadata) and the projector. In a dual-link mode, there is no requirement on LE key change timing between the two links. In fact, each link may have a different key. The projector shall generate the following status information relating to LE metadata. A current LE key error if the current LE