ATIS 0800006-2010 IIF Default Scrambling Algorithm (IDSA) IPTV Interoperability Specification (Version 002).pdf

上传人:eveningprove235 文档编号:541345 上传时间:2018-12-08 格式:PDF 页数:26 大小:421.27KB
下载 相关 举报
ATIS 0800006-2010 IIF Default Scrambling Algorithm (IDSA) IPTV Interoperability Specification (Version 002).pdf_第1页
第1页 / 共26页
ATIS 0800006-2010 IIF Default Scrambling Algorithm (IDSA) IPTV Interoperability Specification (Version 002).pdf_第2页
第2页 / 共26页
ATIS 0800006-2010 IIF Default Scrambling Algorithm (IDSA) IPTV Interoperability Specification (Version 002).pdf_第3页
第3页 / 共26页
ATIS 0800006-2010 IIF Default Scrambling Algorithm (IDSA) IPTV Interoperability Specification (Version 002).pdf_第4页
第4页 / 共26页
ATIS 0800006-2010 IIF Default Scrambling Algorithm (IDSA) IPTV Interoperability Specification (Version 002).pdf_第5页
第5页 / 共26页
亲,该文档总共26页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述

1、 ATIS-0800006.v002 IIF DEFAULT SCRAMBLING ALGORITHM (IDSA) IPTV INTEROPERABILITY SPECIFICATION ATIS is the leading technical planning and standards development organization committed to the rapid development of global, market-driven standards for the information, entertainment and communications ind

2、ustry. More than 250 companies actively formulate standards in ATIS 18 Committees, covering issues including: IPTV, Service Oriented Networks, Energy Efficiency, IP-Based and Wireless Technologies, Quality of Service, and Billing and Operational Support. In addition, numerous Incubators, Focus and E

3、xploratory Groups address emerging industry priorities including “Green”, IP Downloadable Security, Next Generation Carrier Interconnect, IPv6 and Convergence. ATIS is the North American Organizational Partner for the 3rd Generation Partnership Project (3GPP), a member and major U.S. contributor to

4、the International Telecommunication Union (ITU) Radio and Telecommunications Sectors, and a member of the Inter-American Telecommunication Commission (CITEL). For more information, please visit . Notice of Disclaimer IPTV Receiving Device DRM Component; Broadcast Content Server; COD Repository; COD

5、Server (including all types of content - e.g., video, games, music); Server Side Middleware (Subscriber, Service, Asset Management System); IPTV Receiving Device (e.g., set-top box); and 3 IPTV Receiving Device Software. This document supports interoperability by specifying a default scrambling/de-s

6、crambling algorithm for the MPEG-2 Transport Stream and the scrambling algorithm signaling, which is part of the content flows that are highlighted in yellow in Figure 1 below. Figure 1: High-Level DRM Architecture The default scrambling/de-scrambling algorithm(s) is defined in more detail below. 1.

7、3.1 Scrambling Algorithm(s) To provide for the highest levels of security and performance, encryption and decryption are generally performed in hardware; therefore, there are generally a small number of scrambling algorithms deployed on a typical receivers hardware platform. To ensure compatibility

8、between different IPTV Receiving Device hardware platforms on an operators network, and to minimize the impact to the hardware, only a small number of scrambling algorithms will normally be utilized. The network operator will get maximum choice of IPTV Receiving Device platforms with the adoption an

9、d implementation of a standardized scrambling/de-scrambling algorithm(s). 4 1.3.2 Scrambling Algorithm Signaling For delivery of IPTV content, the ATIS IIF specifies the use of the standard DVB mechanism 5 for identification of the scrambling algorithm used to protect the associated elementary strea

10、ms of an MPEG-2 Transport Stream. The IPTV security solution specifies a single IIF Default Scrambling Algorithm for MPEG-2 Transport Streams, as well as permits the use of alternative scrambling algorithms such as those that require licensing or hardware-only implementation. All profiles of the IDS

11、A are known collectively as the IPTV Security Solution/Scrambling (ISS/S). In order to ensure interoperability, the ISS/S provides a signaling mechanism for the use of alternative scrambling algorithms. 2 ANALYSIS FOR INTEROPERABILITY 2.1 Introduction The IDSA MPEG-2 Transport Stream Profile has bee

12、n analyzed according to the following categories: Algorithm; Stream handling; and Implementation. 2.1.1 Analysis Criteria The following criteria were considered in the analysis of the ISS/S. 2.1.1.1 Algorithm The IDSA is based upon Advanced Encryption Standard (AES) as its basic building block which

13、 is a widely-accepted, standardized cryptographic algorithm that has had a thorough and expert design review to ensure cryptographic robustness. Base: The selected algorithm is AES, which is a publicly available cryptographic algorithm that has been standardized by the National Institute of Standard

14、s and Technology (NIST) as FIPS-197 1. Key Length: The entropy of the key selected is 128-bits, which is sufficient to protect the content fully from plausible threats. Mode: The cipher-block chaining (CBC) mode selected is sufficient to protect the content fully from plausible threats and covert ch

15、annel attacks. CBC mode is one of several standardized usage modes as specified in 2. Key Lifetime: The IDSA supports a flexible choice of key lifetime to ensure cryptographic robustness. 2.1.1.2 Stream Handling The IDSA is a self-contained, fully-specified algorithm that accepts as its input only a

16、 fixed Initialization Vector (IV), the content stream, and the key. Fully-specified means that all of the 5 parameters of this default scrambler are defined (e.g., IV generation, chaining mode, short-block handling, and residual bytes handling). Other than these parameters, no other external communi

17、cation or synchronization is required for interoperability. Residual Bytes Handling: The XOR method provides a cryptographically robust mechanism for protection of content data that arrives in length that is less than one full AES block size. o Short Block Handling: The XOR method provides a cryptog

18、raphically robust mechanism for protection of content data that arrives as the solitary data and has a length that is less than one full AES block size (i.e., 128-bits). o Initial Values: The IDSA defines a fixed or static IV of value 0 because: The IDSA provides cryptographic robustness against pla

19、usible threats in the context of dynamically streaming content. The use of a truly random IV, while providing enhanced entropy and thus security, is infeasible without putting external communications and synchronization demands and constraints on the IV solution. The IDSA solution enables the descra

20、mbling of content to begin at any MPEG-2 transport packet boundary which assures maximal random access. Packet Error Handling: In the IDSA, consideration of error propagation is limited to the context of transmission in MPEG-2 Transport Stream packets. The IDSA re-initializes the cipher block chain

21、at the beginning of each MPEG-2 Transport Stream packet to minimize error propagation, whether from packet loss or packet corruption. 2.1.1.3 Patent/Licensing The IDSA has been designed with the intent to produce a license and patent-free solution. Prior Art: The base algorithm, IV generation, and s

22、tream handling methods are well documented in textbooks and within existing standards. License: The algorithm was selected with the intent to be license-free. 2.1.1.4 Implementation The IDSA has been designed to utilize functionality that has been deployed in other contexts within other standards. H

23、owever, the IDSA in its present form is not known to have been deployed in any existing implementations. Use in other Standards: The XOR technique used in IDSA is used in conjunction with a similar block cipher used in the Advanced Television Systems Committee (ATSC) over-the-air scrambling standard

24、 6. Chipset Support: Although there are no currently commercially-available chipsets that implement the IDSA, most of the IDSA cryptographic elements probably exist in current silicon implementations. Software and Hardware Friendly: The IDSA has been designed to be efficiently implementable in both

25、hardware and software through the choice of AES, a fixed IV, and XOR block handling. 6 3 DESIGN FOR INTEROPERABILITY This section specifies the interoperability design of the IDSA and the scrambling algorithm signaling method that is part of the IPTV Security Solution for use with MPEG-2 Transport S

26、treams. 3.1 Scrambling Algorithm This section specifies a method for scrambling MPEG-2 Transport Stream packets using the AES in CBC mode. Only the payload of the MPEG-2 Transport Stream packet is scrambled; the header and the optional adaptation field are not scrambled. The scrambling method is ref

27、erred to as IDSA within the present document. 3.1.1 Convention The bit numbering convention used in FIPS documentation differs from the engineering notation as described below. The engineering notation is used within this document. FIPS Convention Engineering Notation bit 1: most significant bit bit

28、 n-1: most significant bit bit n: least significant bit bit 0: least significant bit n: total number of bits in field n: total number of bits in field 3.1.2 Scrambling of MPEG-2 Transport Stream Packets Figure 2 illustrates the scrambling of an MPEG-2 Transport Stream packet. In Figure 2, Ekdenotes

29、the AES encryption algorithm under the control of a scrambling key, K; IV denotes the initialization vector; and denotes bit-wise exclusive-OR operation. Both the scrambling key K and the Initialization Vector IV consist of 16 bytes or 128 bits. To scramble an MPEG transport stream packet, the paylo

30、ad is divided into blocks of 16 bytes. The last block may consist of less than 16 bytes. As shown in Figure 2, let P1, P2, , Pm, m1, denote the plaintext blocks of the payload of an MPEG-2 Transport Stream packet, where P1is the most significant block and Pmis the least significant block. Correspond

31、ingly, let C1, C2, , Cm denote the ciphertext blocks. Also, let denote the length of Pm i.e., the number of bits that Pmconsists of. Based on the value of , the scrambling procedure can be described mathematically as follows: If is equal to 128 bits, then: Ci = EK(Ci-1 Pi), for 1 i m, C0 = IV. If is

32、 less than 128 bits and m is greater than 1, then: Ci = EK(Ci-1 Pi), for 1 i 2This document is available from the NIST Computer Security Resource Center. 3This document is available from the International Organization for Standardization. 4This document is available from the ATIS Document Store at .

33、 5This document is available from the European Telecommunications Standards Institute (ETSI). 6This document is available from the ATSC. 13 5 REQUIREMENTS TO SPECIFICATION MAPPING This specification addresses, in whole or in part, the following requirements of ATIS-0800001 8. IIF.DRM.GENERAL.100 The

34、 IPTV security solution shall be scalable to support protection of content that is distributed simultaneously to a very high number of subscribers. IIF.DRM.GENERAL.200 The IPTV security solution shall support protection of content that is transferred over multicast channels and/or over unicast strea

35、ms. IIF.DRM. GENERAL.0400 For certain content types (such as movies that are stored on a PVR) the IPTV security solution may provide stronger cryptographic measures to protect against theft. IIF.DRM. GENERAL.0600 The IPTV security solution shall support multiple DRM systems. o IIF.DRM.GENERAL.0600-0

36、100 The IPTV security solution shall support at least one standardized scrambling algorithm (hereafter referred to as “IPTV Common Scrambling Algorithm”) to protect video transport stream packets. o IIF.DRM.GENERAL.0600-0200 The specification of an IPTV scrambling algorithm shall not preclude activa

37、tion of the scrambling algorithm in the field. IIF.DRM.GENERAL.0600-0300 The IPTV security solution shall provide a mechanism to signal the IPTV Receiving Device to utilize a specified scrambling algorithm based on a standardized framework. IIF.DRM.General.0900 - The IPTV Security Solution shall sup

38、port protection from theft of content (confidentiality) while in transmission (e.g., from broadcast/VOD servers in TV operators headend office to IPTV Receiving Devices in customers premises), in storage, etc. IIF.DRM.General.1600 - The IPTV Security Solution shall support the securing of DVR conten

39、t. IIF.DRM.General.2700 - The IPTV security solution should not significantly degrade the performance of the IPTV services. IIF.DRM.Scrambling.0100-0100 - The IPTV security solution shall support, at a minimum, a single standardized scrambling algorithm (hereafter referred to as IPTV Common Scrambli

40、ng Algorithm) to scramble and descramble the content in order to protect the media transport stream packets and content files in storage. IIF.DRM.Scrambling.0100-0200 - The IPTV security solution shall support a mechanism to allow IPTV operators to select alternative scrambling algorithms other than

41、 the IPTV Common Scrambling Algorithm. This may be achieved by a pre-defined scrambling/descrambling algorithm identifier communicated between DRM Servers and DRM clients. IIF.DRM.Scrambling.0100-0300 - When an MPEG 2 transport stream structure is present, the IPTV Common Scrambling Algorithm shall

42、be applied to the payload but not to transport headers or adaptation fields. IIF.DRM.Scrambling.0100-0400 - The entropy of the key used with the IPTV common scrambling algorithm shall be sufficiently large to protect the content fully from plausible threats (e.g., at least 128 bits for the AES symme

43、tric algorithms). IIF.DRM.Scrambling.0100-0500 - The IPTV common scrambling algorithm shall be built using publicly-available cryptographic algorithms that have been standardized by other appropriate organizations and that have been openly vetted by competent cryptographic experts - e.g., the Advanc

44、ed Encryption Standard (AES). 14 IIF.DRM.Scrambling.0100-0600 - The specification of the IPTV common scrambling algorithm shall be publicly available. IIF.DRM.Scrambling.0100-0700 - The IPTV scrambling algorithm shall not preclude support for either Simulcrypt or Multicrypt approaches. The purpose i

45、s to enable multiple DRM vendors within a single network platform when required by the content distributor. IIF.DRM.Scrambling.0100-0800 - The IPTV Common Scrambling Algorithm shall not preclude a cryptographically robust crypto period (key lifetime). IIF.DRM.Scrambling.0100-0900 - The generation an

46、d distribution of the IPTV Common Scrambling Algorithm initial conditions (e.g. IV, counter value) shall be cryptographically robust. IIF.DRM.Scrambling.0100-1000 - The generation and distribution of the initial conditions of the IPTV Common Scrambling Algorithm shall ensure interoperability. IIF.DR

47、M.Scrambling.0100-1100 - The IPTV Common Scrambling Algorithm shall provide a cryptographically robust mechanism for short block scrambling. IIF.DRM.Scrambling.0100-1200 - The IPTV Common Scrambling Algorithm shall provide a cryptographically robust mechanism for residual bytes scrambling. IIF.DRM.S

48、crambling.0100-1300 - The IPTV Common Scrambling Algorithm shall handle loss of a single MPEG-2 TS packet without introducing error propagation in other packets. IIF.DRM.Scrambling.0100-1400 - The IPTV Common Scrambling Algorithm shall handle MPEG-2 TS packet corruption without introducing error pro

49、pagation in other packets. IIF.DRM.Scrambling.0100-1500 - The IPTV Common Scrambling Algorithm shall provide an efficient mechanism to generate, distribute, and acquire the initial conditions for the decryption of MPEG-2 TS packets so that synchronization with random access points is not delayed by the decryption algorithm. IIF.DRM.Scrambling.0100-1600 - The IPTV Common Scrambling Algorithm shall

展开阅读全文
相关资源
猜你喜欢
相关搜索

当前位置:首页 > 标准规范 > 国际标准 > 其他

copyright@ 2008-2019 麦多课文库(www.mydoc123.com)网站版权所有
备案/许可证编号:苏ICP备17064731号-1