1、 ATIS-0800014.v003 SECURE DOWNLOAD AND MESSAGING 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 industry. More tha
2、n 200 companies actively formulate standards in ATIS Committees and Forums, covering issues including: IPTV, Cloud Services, Energy Efficiency, IP-Based and Wireless Technologies, Quality of Service, Billing and Operational Support, Emergency Services, Architectural Platforms and Emerging Networks.
3、In addition, numerous Incubators, Focus and Exploratory Groups address evolving industry priorities including Smart Grid, Machine-to-Machine, Connected Vehicle, IP Downloadable Security, Policy Management and Network Optimization. ATIS is the North American Organizational Partner for the 3rd Generat
4、ion Partnership Project (3GPP), a member and major U.S. contributor to the International Telecommunication Union (ITU) Radio and Telecommunications Sectors, and a member of the Inter-American Telecommunication Commission (CITEL). ATIS is accredited by the American National Standards Institute (ANSI)
5、. For more information, please visit . Notice of Disclaimer e.g., video, games, music). 6. Server-Side Middleware (Subscriber/Service/Asset Management System). 7. IPTV Receiving Device. 8. IPTV Receiving Device Software. This document specifies functionality and methodology for authentication (ISS/A
6、) and encryption (ISS/E) used for securing persistent and non-persistent data in order to meet the objectives stated in section 1. Data is non-persistent when it is used only at reception time. Data is persistent when it is retained after reception time. Typical examples of persistent data that may
7、require authentication include: Secure download of executable software. Secure download of DRM code. Secure delivery of operational data (e.g., configuration files). Updates to the certificate hierarchy. Typical examples of non-persistent data that may require authentication include: Secure delivery
8、 of EAS messages. Secure delivery of operational data (e.g., one-time commands). Secure end-to-end communications. Figure 1 illustrates the basic components involved in the IPTV Security Solution and DRM interoperability. ATIS-0800014.v003 5 Server Side DRM SystemVOD RepositoryBroadcastContentServer
9、 VOD ServerIPTV NetworkServer Side MiddlewareOff-line EncryptionReal-Time EncryptionIPTV Receiving DeviceIPTVReceiving DeviceDRMComponentKey Management DRM system Management ServerScrambling AlgorithmEncryptedDe-Scrambling AlgorithmScrambling AlgorithmApplication Level InterfacesDRM Interoperability
10、 Application Level Interfaces Content Flow (Video/Audio Packets)LEGENDSDRM Black Box ComponentsIPTV Receiving DeviceSoftwareFigure 1: Basic DRM Components Block Diagram This specification defines an IPTV Security Solution/Authentication (ISS/A) and an IPTV Security Solution/Encryption (ISS/E) functi
11、on. The ISS/A specified in this document defines the authentication functionality required to enable secure download and reception of messages. The specification of the ISS/E within the IPTV Security Solution is motivated by the requirement to provide confidentiality of messages and secure downloads
12、. Confidentiality is provided by a security process called encryption. The encryption keys used to provide confidentiality must be securely managed. ISS/A and ISS/E together provide a complete solution for messaging and secure download to IPTV Devices by providing authentication, integrity, and conf
13、identiality. Aspects of ISS/A and ISS/E may be implemented in both server-side and client-side devices. 4.1 Secure Download The operator wants the capability to securely download various executable software images into IPTV Devices. This leads to the need to ensure the authentication, confidentialit
14、y, and integrity of software images downloaded into the IPTV Device. Note that video, audio, and data service content are not executable software images for the purposes of this specification. 4.2 Authenticated Messaging In order to verify that system messages are received unmodified from legitimate
15、 sources, there is a need to ensure the authentication and integrity of the content and the source of system messages. Note that an EAS message, which could include text and audio portions, can be made secure by mechanisms in this specification. The ISS/A is implemented following Robustness Rules es
16、tablished in ATIS-0800024 10. ATIS-0800014.v003 6 4.3 Encryption ISS/E uses an open, standardized encryption method to protect downloads or messages intended for the IPTV Devices. The ISS/E is implemented following Robustness Rules established in ATIS-0800024 10. 4.4 Secure Environment of the IPTV D
17、evice To characterize the security environment of the IPTV Device, this document defines the concepts of the Native Security Solution (NSS) and the ISS Security Profile. 4.4.1 Native Security Solution (NSS) The NSS of an IPTV Device comprises the hardware and software that is present at manufacturin
18、g time and is designed to secure the execution environment of that IPTV Device. ATIS-0800024 10 defines Secure Execution Environment (SEE) elements and their robustness levels. Because IPTV Devices will be designed and manufactured by different vendors for a variety of different applications, the ac
19、tual implementation of the SEE, its robustness, and the security capabilities afforded to an IPTV Device NSS can vary. This specification expects the ISS/A and the ISS/E to be incorporated into the NSS when present. There are two methods by which the ISS/A and the ISS/E may be incorporated into the
20、NSS of an IPTV Device. They are: 1. Incorporated at the manufacturing time of the IPTV Device. 2. Downloaded and authenticated using the capabilities of the NSS. 4.4.2 ISS Security Profiles The ISS/A and the ISS/E are vulnerable to subversion or imitation if the execution environment of the IPTV Dev
21、ice is not sufficiently secure. This document introduces the concept of an ISS Security Profile as a means to classify security characteristics of a specific implementation of an IPTV Device. In particular, these profiles define the characteristics of the execution environment in which the NSS and h
22、ence the ISS/A and the ISS/E operate. Some of these profiles depend on the existence of a SEE. ATIS-0800024 10 defines robustness levels for SEE elements. 5 ANALYSIS FOR INTEROPERABILITY 5.1 Analysis of Authentication The following subsections outline considerations for: Downloading DRM code to the
23、IPTV Receiving Device. Downloading middleware and application software to the IPTV Receiving Device. Securing messages and operational data sent to the IPTV Receiving Device. The secure download and messaging security functions will operate in a manner independent of the specific download or message
24、 transport mechanism. This specification defines mechanisms for assuring the authenticity, confidentiality, and integrity of downloads/messages. ATIS-0800014.v003 7 5.1.1 DRM Code Download This section lists examples of the downloading of DRM executable code into the IPTV Receiving Device. The purpo
25、se of the analysis is to identify functionality necessary to ensure that the secure download of the IPTV Receiving Device DRM code is interoperable with the overall IPTV Security Solution. The DRM code received by the IPTV Receiving Device is received from an approved sender. The DRM code received b
26、y the IPTV Receiving Device is unaltered from that sent by the approved sender. The DRM code received by the IPTV Receiving Device is communicated in a manner which preserves integrity and confidentiality. 5.1.2 Middleware and Application Code Download This section lists examples of the downloading
27、of the middleware and application code into the IPTV Receiving Device. The purpose of the analysis is to identify the functionality necessary to ensure that the secure download of the IPTV Receiving Device middleware and applications is interoperable with the overall IPTV Security Solution. The midd
28、leware and/or applications received by the IPTV Receiving Device are received from an approved sender. The middleware and/or applications received by the IPTV Receiving Device are unaltered from that sent by the approved sender. The middleware and/or applications received by the IPTV Receiving Devic
29、e are communicated in a manner which preserves integrity and confidentiality. 5.1.3 Messaging and Operational Data This section lists examples of the transfer of messages and/or operational data into the IPTV Receiving Device. The purpose of the analysis is to identify the functionality required to
30、ensure that the secure transfer of the IPTV Receiving Device messages and/or operational data is interoperable with the overall IPTV Security Solution. The messages and/or operational data received by the IPTV Receiving Device are received from an approved sender. The messages and/or operational dat
31、a received by the IPTV Receiving Device are unaltered from those sent by the approved sender. The messages and/or operational data received by the IPTV Receiving Device are communicated in a manner which preserves integrity and confidentiality. 5.2 Analysis of Encryption and Key Management The follo
32、wing sections outline considerations for: Use of Content Encryption Key. Encrypting data targeted to an individual IPTV Device using device keys. Encrypting data targeted to multiple IPTV Devices using a pre-provisioned key. ATIS-0800014.v003 8 Also, the following sections outline considerations inv
33、olving key management with these mechanisms: Factory-installed encryption keys. Distribution of keys to deployed IPTV Devices. The secure download and messaging functions operate in a manner independent of the underlying transport mechanism. 5.2.1 Use of Content Encryption Key (CEK) The analysis in
34、this section identifies flexible key management methods that allow for the download/message to be targeted to single or multiple recipients. It is possible to encrypt downloads/messages with a permanent global or permanent device-specific CEK, however, such schemes may not be practical for these rea
35、sons: If the CEK is compromised, a new CEK needs to be randomly generated by a key server. If the CEK is compromised, the newly generated CEK needs to be provisioned in the IPTV Devices. If device-specific CEKs are used, the data must be re-encrypted with a new CEK specifically assigned to each reci
36、pient. The more frequently the same CEK is used on different data sets, the probability of success of cryptanalytic attacks increases, since more data can be analyzed. Using a CEK to encrypt a single download/message has the following advantages: If the key is compromised, only the single download/m
37、essage is compromised. Cryptanalytic attacks are not effective. Single-use CEKs, although having strong security characteristics and benefits, present a key management challenge because the single-use CEK needs to be delivered confidentially while achieving efficiency and scalability. The following
38、sections describe two key management approaches for delivering CEKs. 5.2.2 Encrypting Data Targeted to an IPTV Device Using Device Keys One situation that needs to be considered is when the encryption function is used to target a single IPTV Device. One possible solution for this situation is to enc
39、rypt the CEK using the target IPTV Device public key. The public key can be provided to the sender via an online exchange or it can be retrieved from a database of known devices. In either case, the certificate containing the public key should be chained back to a trusted CA or root certificate befo
40、re the public key is used to encrypt the CEK. The IPTV Device Certificate and corresponding private key are defined in ATIS-0800015 2 and ATIS-0800016 4. The encrypted CEK can then be included with the encrypted message and delivered to the intended recipient. The recipient device uses its securely
41、stored private key to decrypt the encrypted CEK, and then uses the CEK to decrypt the encrypted download/message. Following this approach, only the recipient device that holds the proper private key can decrypt the encrypted CEK. ATIS-0800014.v003 9 When using this method, it is important to identif
42、y which device key was used to encrypt the CEK. This can be done by using an identifying field from the device certificate. This approach may also be used for a small number of recipient devices. In this case, the same CEK is encrypted individually with each recipient devices public key and the down
43、load/message is encrypted only once with the single CEK. 5.2.3 Encrypting Data Targeted to Multiple IPTV Devices Using a Pre-Provisioned Key Another situation that needs to be considered is when the encryption function is used to target a large population of IPTV Devices. A solution for this situati
44、on is to encrypt the CEK using a pre-provisioned key that is common for all those devices. The encrypted CEK can then be included with the encrypted message and delivered to the intended recipients. The recipient devices use the securely stored pre-provisioned key to decrypt the encrypted CEK, and t
45、hen use the CEK to decrypt the encrypted download/message. Following this approach allows any recipient device that holds the proper pre-provisioned key to decrypt the encrypted CEK. One advantage of using a pre-provisioned key to encrypt the CEK, is that the download/message needs to be encrypted o
46、nly once for the entire recipient device population, as long as all the recipient devices are pre-provisioned with the same secret key. This pre-provisioning makes this approach suitable for use in a multicast scenario, for example, when a prepared software image is made available for download to mu
47、ltiple recipient devices or when a system-wide message needs to be encrypted and sent to a large population of IPTV Devices. Note that it is possible to use multiple pre-provisioned keys in any single recipient device. Therefore, when using this approach, it is important to identify which pre-provis
48、ioned key was used to encrypt the CEK. A key name or identifier must be included with the encrypted download/message to identify the pre-provisioned key used to encrypt the CEK. 5.2.4 Key Provisioning Procedures The following subsections outline considerations involving key management for factory-in
49、stalled encryption keys and for distribution of keys to deployed IPTV Devices. 5.2.4.1 Manufacturing Time Key Provisioning The simplest method of deploying keys into devices is to provision the keys at manufacture time. An advantage of manufacturing time provisioning is that controls over physical access to key generation: transport and installation can be enforced in the manufacturing facility. A scenario similar to the factory case is when the network operator has physical control over the d
