1、 The attached document is a Registered Disclosure Document prepared by the proponent identified below. It has been examined by the appropriate SMPTE Technology Committee and is believed to contain adequate information to satisfy the objectives defined in the Scope, and to be technically consistent.
2、This document is NOT a Standard, Recommended Practice or Engineering Guideline, and does NOT imply a finding or representation of the Society. Errors 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,
3、 including inquiries as to intellectual property requirements that may be attached to use of the disclosed technology, should be addressed to the proponent identified below. Proponent contact information: Lee Pedlow Sony Electronics INC 16530 Via Esprillo, San Diego, CA. 92127 E-mail: Page 1 of 100
4、 pages RDD 10-2006 Copyright 2006 by THE SOCIETY OF MOTION PICTURE AND TELEVISION ENGINEERS 3 Barker Avenue, White Plains, NY 10601 (914) 761-1100 Approved September 6, 2006 SMPTE REGISTERED DISCLOSURE DOCUMENT An Open Transport and Navigational Specification, Optionally Supporting Multiple Conditio
5、nal Access Systems RDD 10-2006 Page 2 of 100 pages Introduction This specification is in two parts: Part 1 deals with the transportation and management syntax of a tool kit that providing basic access control and optionally allowing for multiple Conditional Access (CA) systems to coexist; Part 2 of
6、the specification deals with the navigational tools. This technology was developed to provide basic management of devices accessing basic-tier program content, optionally coexisting in the presence of one or more conditional access systems. Unlike other attempts to address this issue, the basic acce
7、ss control and one or more CA systems operate within a common MPEG-2 transport stream without any direct or indirect interaction between the CA systems. Much of the syntax and data structure is based upon the ETSI-DVB model and related standards. Applications of this specification are potentially an
8、y point to multi-point content distribution requirement such as network program distribution, theater content distribution, as well as applications in the cable and Satellite industries. RDD 10-2006 Page 3 of 100 pages Part 1 Transport and Basic Access Control System Specification Table of Contents
9、Page 1 Scope 6 1.1 Overview 6 1.2 All-Digital Content Carriage . 6 1.3 Reference Documents . 6 1.4 Acronyms and Abbreviations . 7 2 Content Access Control 8 2.1 Basic Access Control Concept Overview. 8 2.2 Architecture 9 2.3 Encryption Keys . 10 2.3.1 EMM Keys. 10 2.3.2 Download Keys . 10 2.3.3 Cont
10、ent Keys. 10 2.3.4 Content Key Delivery 11 2.4 Signatures 12 2.5 Device Addressability. 12 2.5.1 Global Address 12 2.5.2 Unit Addresses 13 2.5.3 Group Addresses 13 2.6 Content Access Management 13 2.6.1 Channel Maps. 13 2.6.2 Service Access Authorization . 14 2.6.3 Service Access Process Flow. 14 3
11、Entitlement Management Messages. 16 3.1 EMM Carousels, Carousel Nesting and Group Usage 18 3.1.1 Address Priority. 18 3.1.2 EMM Descriptor Hierarchy 19 3.1.3 Provisioning Process 19 3.1.4 Global Group Address Usage. 22 3.1.5 Super Group EMM Address Usage 22 3.1.6 Unique EMM Address Usage 22 3.2 EMM
12、Descriptors 22 3.2.1 Software Download Command Descriptor 22 3.2.2 EAS Message Descriptor 24 3.2.3 Key Data Descriptor 26 3.2.4 Signature Data Descriptor. 26 3.2.5 Fingerprint Message Descriptor 27 3.2.6 Program Authorization Descriptor. 27 3.2.7 Group Assignment Descriptor. 28 3.2.8 FIPS Assignment
13、Descriptor 29 3.2.9 OSD Descriptor. 30 3.2.10 Key Index List Descriptor. 31 3.2.11 Operation Mask Descriptor 31 3.2.12 Service Mask Descriptor 32 RDD 10-2006 Page 4 of 100 pages 3.2.13 Bouquet Descriptor.33 3.2.14 Version Descriptor33 3.2.15 EMM Descriptor35 4 Software Download .35 4.1 EUE Device Up
14、grade Process 40 4.1.1 Headend/source Signature Server 40 4.1.2 EUE Resident Signature Client .40 4.1.3 EUE Resident Upgrade Agent push_command_set Interface .40 4.1.4 Headend/source Carousel Support for FORCED, NORMAL and BETA Images40 4.2 Upgrade Image Types and Policies .41 4.2.1 FORCED Image Typ
15、e .41 4.2.2 NORMAL Image Type .41 4.2.1 BETA Image Type .41 4.3 Upgrade Process Overview42 4.3.1 Pull Software Upgrade Process 42 4.3.2 Push Software Upgrade Process 42 4.3.3 Bootloader Upgrade Detection Process and Policies .44 4.3.4 Image Corruption Checking.45 4.4 Upgrade Scenarios.46 4.4.1 EUE D
16、elivered to a Customer/Enduser46 4.4.2 EUE Image Corruption .46 4.4.3 Critical/Immediate Upgrade46 4.4.4 Normal Release Upgrade.46 4.4.5 Beta Users Upgrade.47 4.5 Provisioning Messages.47 4.5.1 Two-Way IP Provisioning Descriptor.49 4.5.2 DDC Message Descriptor50 4.6 Module Delivery Protocol53 4.7 Up
17、grade Stream Format.56 4.8 Upgrade Image Encryption.56 4.9 Upgrade Authentication56 4.10 Upgrade Agent to SBS-Client Interface56 4.11 EUE Version Information Storage 58 4.12 Boot-time Software Validity Checking 59 4.13 Download Image Preparation.59 4.13.1 Module Packing Process61 4.13.2 Conversion o
18、f Packed Files to MPEG-2 Format 64 4.13.3 Module Signing.64 4.14 Provisioning Message Preparation.65 4.14.1 DDC Message Creation66 4.14.2 DDC Message Signing .69 4.14.3 Provisioning Message Descriptor Creation 70 4.14.4 Conversion of Provisioning Message to MPEG-2 Format72 5 EUE Fingerprint .72 5.1
19、Fingerprint Process 73 Annex A Part 177 Part 2 Navigation Data Specification . 78 RDD 10-2006 Page 5 of 100 pages List of Figures Part 1 Figure 1 Typical Cable BAC System Architecture . 8 Figure 2 Content Key Structure . 10 Figure 3 Association of Content Key to a Service . 11 Figure 4 Program Autho
20、rization Table Structure . 14 Figure 5 Channel Access Process Flow 15 Figure 6 Group and Message Relationship . 18 Figure 7 EMM Processing Flow . 21 Figure 8 SBS-Client Invocation 36 Figure 9 Module/Descriptor Relationship. 38 Figure 10 SBS-Client Upgrade Logic. 43 Figure 11 Module Creation Process
21、60 Figure 12 Provisioning Message Creation Process. 65 Figure 13 RF Fingerprint System. 73 Figure 14 EUE Challenge/Activation Process . 74 Figure 15 Digital Cable Appliance Location Audio Process at Reboot 75 RDD 10-2006 Page 6 of 100 pages 1 Scope The intent of this specification is to provide deta
22、iled system-level specifications for the basic access control subsystem and algorithms for application in both the source equipment and EUE devices. This technology is applicable wherever an MPEG-2 transport stream is used for content delivery. 1.1 Overview The purpose of the initiative, promoted by
23、 Sony, is to facilitate competition in an open marketplace by providing a means to deploy non-legacy source equipment, subscriber devices and services on existing legacy networks or distribution channels. The navigation data specification forms part of a tool kit allowing content owners and network
24、operators to implement a method for digitally distributing content that was previously analog and to optionally choose alternative CA vendors while still preserving legacy choices. Migration paths to up-grades are also possible. Having the capability to support the coexistence of multiple CA systems
25、 without the need for content replication can be a bandwidth saver in many installations. 1.2 All-Digital Content Carriage The enabled all-digital system implements a standards-based method to provide basic access control, to implement remote authorization and management of the EUE/receivers. This a
26、chieves the objective for centralized connection management, something that is common with network distribution and in the cable industry. The basic access control system can operate in conjunction with traditional 3rd party CA systems, thereby enabling open-market alternative devices to be employed
27、. 1.3 Reference Documents Unless a specific version or revision number is included, the following references are non-specific, and the latest version applies. 1 ISO/IEC 13818-1, Information Technology Generic Coding of Moving Pictures and Associated Audio Information: Systems Part 1: Systems, ISO, 4
28、/02 2 ETSI EN 300 468 v1.4.1 (2000-11), Digital Video Broadcasting (DVB); Specification for Service Information (SI) in DVB Systems 3 ETSI ETR 289 ed.1 (1996-10), Digital Video Broadcasting (DVB); Support for Use of Scrambling and Conditional Access (CA) within Digital Broadcasting Systems 4 Specifi
29、cation of the Macrovision Copy Protection Process for EUE/IRD Products, v7.1.S1, 1999, Macrovision Corporation 5 ETSI TS 103 197, Head-end Implementation of DVB Simulcrypt, v1.3.1 (2003-01) 6 ETSI EN 301 192, DVB Specification for Data Broadcasting, v1.3.1 (2003-05) 7 ANSI J-STD-042-2002, Emergency
30、Alert Message for Cable, American National Standards Institute, 12/3/02 8 FIPS PUB 180-2, Secure Hash Standard, Information Technology Laboratory, National Institute of Standards and Technology, August 1, 2002 9 FIPS PUB 198, The Keyed-Hash Message Authentication Code (HMAC), Information Technology
31、Laboratory, National Institute of Standards and Technology, March 6, 2002 RDD 10-2006 Page 7 of 100 pages 10 FIPS PUB 6-4, Counties and Equivalent Entities of the United States, Its Possessions and Associated Areas, National Institute of Standards and Technology, January 24, 2002 11 Fowler/Noll/Vo (
32、FNV) Hash, 12 EUI-48,http:/standards.ieee.org/regauth/index.html 1.4 Acronyms and Abbreviations ANI Automated Number Identification AV BOOLEAN key_phase; UINT64 content_keykey_index, 2; if (transport_scrambling_control = 10) key_phase = 0; else if (transport_scrambling_control = 11) key_phase = 1;
33、The maximum possible storage requirement for this structure is 1 MByte, though it is highly unlikely that a system would have 65,536 unique keys. The same content key shall be used for both audio, metadata and video elements of a particular service. The association of a particular key pair (even and
34、 odd phase) to a specific service is done through data contained in the table delivered through the program authorization descriptor, mapping a logical channel to a key_index value, which is then used to find the corresponding content key pair in the content key array. This relationship is illustrat
35、ed in Figure 3. The table containing the list of logical channels and the associated key indices shall also be securely stored in nonvolatile memory within the EUE. Figure 3 Association of Content Key to a Service The content keys may be delivered dynamically. The content key array structure shall b
36、e implemented as described above and could optionally be pre-loaded with static data as part of the software image downloaded to the device. For these elements, the content key array may be physically located in a different memory resource or a different portion of a memory resource. Likewise, the d
37、ata structure containing the logical_channel, key_index and service_mask values shall be a hardcoded table organized in the same manner as if a channel authorization descriptor had actually been received in an EMM. This data shall be embedded in the downloaded software image. The same caveats as ind
38、icated for the content key structure apply regarding storage of this structure. 2.3.4 Content Key Delivery Content key delivery is performed through the receipt of an EMM containing a valid key data descriptor. Content key data is organized as a table containing the pair of content key values coveri
39、ng both MPEG-2 encryption phases (even and odd). These content key pairs are associated with an index identifying a RDD 10-2006 Page 12 of 100 pages particular content key pair. The key data descriptor structure allows for the en masse replacement of the entire column of content keys in the table as
40、sociated with a particular encryption phase. A single descriptor cannot replace both the content keys in a particular key pair. Two independent messages must be sent to populate or refresh the entire content key table, one identified as associated with the even encryption phase and then one identifi
41、ed as associated with the odd encryption phase. The order of these messages is unimportant. Additionally, an optional third element may be employed to increase the level of indirection in transmitted data. The key index descriptor allows the key index to be transmitted separately from the program au
42、thorization table and the key data tables. This descriptor overwrites index data in the program authorization table and can be used to initially provision index data separately or to rekey a system solely through transmission of new indices without transmitting key data or program authorization tabl
43、es. The EMM carrying the complete indices for a program tier would be very small and is likely contained in a single packet, being 1/3 the size of the authorization table and at a minimum 1/4 the size of the key data table. The EUE device shall never alter or modify in any way the format or contents
44、 of the data structures containing the program authorization and the key data tables, except to apply the appropriate descriptor data from a validated EMM. The EUE device shall place the data received from the relevant EMM in the exact form and order into the storage structure and in no event sort o
45、r alter the order of entries in the table. It shall be incumbent upon the BAC system to provide the logical channel entries in the program authorization table in a sorted fashion. Each program authorization table and the key data table shall be transmitted in a complete form and shall replace any ex
46、isting table in its entirety. In practice, the key data message shall be used to update only the future content key, which would be the keys associated with the phase opposite of the one currently being used to encrypt content. This method allows background provisioning of authorized s with the cont
47、ent keys for the next epoch without any impact upon current device operation. 2.4 Signatures Electronic signatures shall be employed to authenticate entitlement messages and software download messages. The signature method employed is the published SHA-1 hash 8. This process produces a unique 160-bi
48、t condensed cryptographic checksum of the evaluated message or image. The hash value is then encrypted using a published algorithm (HMAC) Error! Reference source not found., but employing a secret key. The combination of the one-way hash and the secret encryption prevents both alteration of the orig
49、inal message or image and substitution of both content and a corresponding hash. The secret 512-bit key value used for EMMs shall be different from the value used for software download. 2.5 Device Addressability The basic access control system architecture provides a simple yet powerful method for addressing EUE devices based upon the EUI-48 f
