ATIS 0800039-2010 DRM Server-Side Application Programming Interfaces Interoperability Specification (v002 Includes Access to Additional Content).pdf

1、 Access to Additional Content for ATIS 0800039.v002 (Click here to view the publication) This Page is not part of the original publication This page has been added by IHS as a convenience to the user in order to provide access to additional content as authorized by the Copyright holder of this docum

2、ent Click the link(s) below to access the content and use normal procedures for downloading or opening the files. ATIS 0800039.v002 Additional Content Information contained in the above is the property of the Copyright holder and all Notice of Disclaimer the entity whose Content is being protected.

3、3.1.11 Content Protection: A combination of Access Control and Copy Control. 3.1.12 Content Provider: An entity that is either a Content Issuer or a Rights Issuer. 3.1.13 Content Subscription: A subscription that a User has with a Content Provider for the purposes of paying for Protected Content pur

4、chased from that content provider and played on a users Device. 3.1.14 Copy: To make a perfect reproduction of DRM Content or Rights. 3.1.15 Copy Control: The enforcement of conditions under which copyrighted content can be copied. Copy Control is one part of Content Protection. 3.1.16 Copy Protecti

5、on: A mechanism used to protect content from being copied in an unauthorized manner via analog and/or digital IPTV Receiving Device interfaces. Copy Protection is a combination of Access Control and Copy Control. 3.1.17 Cryptographically Robust: This term cryptographically robust is often used to de

6、scribe an encryption algorithm and implies, in comparison to some other algorithm (that is thus cryptographically weaker), greater resistance to attack. 3.1.18 Device: A device is the entity (hardware/software or combination thereof) within a users equipment that implements a DRM Client. The device

7、is also conformant to the specifications of the DRM it supports. 3.1.19 DRM: A collection of technologies that technically enable the definition of and the enforcement of secure content transportation as well as secure content licensing, including: Protection and control of the viewing of content th

8、at is delivered over IP transport. Rights management for the delivered content. 3.1.20 DRM Client: The entity in the device that manages permissions for content and media objects on the device. ATIS-0800039.v002 5 3.1.21 Entitlement: Information about the authorization level/s a user has to access t

9、o use certain services and to access, use, copy, and distribute certain content received in his/her IPTV Receiving Device. 3.1.22 Integrity: The property that data (Contents, Rights, etc.) has not been altered or destroyed in an unauthorized manner. 3.1.23 IPTV Device: IPTV Receiving Device or serve

10、r-side devices or equipment. 3.1.24 IPTV Receiving Device: IPTV Terminal Function (ITF) and Delivery Network Gateway (DNG) as defined in ATIS-0800002, IPTV Architecture Requirements represents the functionality within the consumer network that is responsible for terminating the IP signal and convert

11、ing the content into a renderable format (e.g., a set-top box). 3.1.25 ISS/A: The part of the ISS toolkit that deals with authentication functionality. See ATIS-0800014, Secure Download and Messaging Interoperability Specification. 3.1.26 ISS/E: The part of the ISS toolkit that deals with confidenti

12、ality functionality. See ATIS-0800014, Secure Download and Messaging Interoperability Specification. 3.1.27 ISS/S: The part of the ISS toolkit that deals with content scrambling. See ATIS-0800006, IIF Default Scrambling Algorithm. 3.1.28 Key Management: All of the provisions made in a secure IPTV sy

13、stem that are related to the generation, transport, exchange, storage, safeguarding, use, revocation, and renewing of cryptographic keys. 3.1.29 Message Integrity: The quality of a transmitted message, such that its recipient can be assured that the contents of the message have not been tampered wit

14、h or altered since the time it was transmitted by the sender. One common approach is to use a one-way hash function that combines all of the bytes in the message to produce a message digest that is impossible to reverse, and then make a digital signature of this hash value by the sender. Another met

15、hod involves combining message bytes with a key value known only to the sender and recipient in a hash function. 3.1.30 Native Security Solution: The hardware and software present at manufacturing time, designed to secure the execution environment of an IPTV Receiving Device. 3.1.31 Privacy: Confide

16、ntiality of user viewership and interactions with IPTV systems. 3.1.32 Protected Content: Media objects that are consumed according to a set of permissions in a Rights Object. 3.1.33 Revoke: A device has been revoked by a particular Rights Issuer if that Rights Issuer has decided it does not wish to

17、 issue Rights Objects to that device (for example, because it has concerns about the robustness of the devices implementation). 3.1.34 Rights: The ability to perform a pre-defined set of utilization functions on a content item. These utilization functions are the permissions (e.g., to view/hear, cop

18、y, modify, record, excerpt, sample, translate in another language, keep for a certain period, distribute), constraints (e.g., play/view/hear multiple times, play/view/hear certain number of hours), and obligations (e.g., payment, tracking information) that apply to the content and provide liberty of

19、 use granted to the end user. 3.1.35 Rights Expression: The statement of utilization functions that can be performed on a Content Item and the conditions in which they can be performed. 3.1.36 Rights Holder: Indicates the entity that is entitled to grant rights. ATIS-0800039.v002 6 3.1.37 Separable

20、Security Element: The module providing operator based conditional access, which is not an integral part of the IPTV Receiving Device at manufacture time. 3.1.38 Server-Side Middleware: This is the system external to the Server-Side DRM System that is interacting with the Server-Side DRM System to fa

21、cilitate the delivery of secure content to the IPTV Receiving Device. 3.2 Acronyms & Abbreviations API Application Programming Interface APS Analog Protection System ATIS Alliance for Telecommunications Industry Solutions CA Certificate Authority CAS Conditional Access System CCI Copy Control Inform

22、ation CIT Constrained Image Trigger COD Content on Demand DRM Digital Rights Management IPTV Internet Protocol Television IIF IPTV Interoperability Forum IP Internet Protocol ISO International Organization for Standardization ISS IPTV Security Solution ISS/A IPTV Security Solution/Authentication ISS

23、/C IPTV Security Solution/Certificate ISS/CA IPTV Security Solution/Certificate Authority ISS/E IPTV Security Solution/Encryption ISS/R IPTV Security Solution/Root ISS/S IPTV Security Solution/Scrambling ITF IPTV Terminal Function OAM Operations And Management QoS Quality of Service SSDRM Server-Sid

24、e DRM TCP Transmission Control Protocol XML eXtensible Markup Language 4 ANALYSIS FOR INTEROPERABILITY The purpose of the analysis is to identify any functionality that needs to be specified to achieve interoperability between the Server-Side DRM System and the Server-Side Middleware as shown in Fig

25、ure 1. ATIS-0800039.v002 7 ENCRYPTION: 1. For Linear Broadcast, the Server-Side Middleware tells the Server-Side DRM System that there is a specific broadcast stream for the Server-Side DRM System to process. The following information may be set, removed, or updated: a. Service ID/Program ID. b. Typ

26、e of encryption. c. Copy-control information (or copy protection information). d. Time program or service starts. e. Time program or service ends. 2. For off-line encrypted assets such as COD, the asset management system tells the Server-Side DRM System that there is a COD asset for the Server-Side

27、DRM System to process. In typical industry usage, the following information may be set, removed, or updated: a. Asset ID. b. Type of encryption. c. Copy-control information (or copy protection information). d. Beginning time of asset availability. e. End time of asset availability. ENTITLEMENTS: 3.

28、The Server-Side Middleware needs to be able to tell the Server-Side DRM System which IPTV Receiving Devices are entitled to decrypt content. REPORTING: 4. The Server-Side DRM System needs to pass its Quality of Service (QoS) and Operations and Management (OAM) messages to the Server-Side Middleware

29、for processing by other components of the IPTV solution. The following information may be exchanged: a. Server-Side DRM System QoS messages/parameters: i. Constrained image trigger. ii. IPTV Receiving Device rights status. iii. Asset status. b. Server-Side DRM System OAM messages: i. Entitlement del

30、ivery status. ii. Query of DRM system entities. iii. Query of current encryption and copy control states. 4.1 Use Cases for DRM Server-Side API 4.1.1 Adding IPTV Receiving Devices The Server-Side Middleware adds an IPTV Receiving Device (IPTVRxDevice) to the Server-Side DRM System in this example. T

31、he Server-Side DRM System sends a response back to the Server-Side Middleware regarding the results of the request. ATIS-0800039.v002 8 Steps: 1. The Server-Side Middleware provides the DeviceID to the DRM system. The CAS ID of the DRM system to which the device is being added may be included in the

32、 message. The devices MAC address, IP address, and/or TCP port may be provided. 2. The Server-Side DRM System responds with a two-level status: the high-level status called ReturnStatus, and a detailed status called ReturnStatusDetail. The status informs the Server-Side Middleware about the success

33、or failure of the operation. Additional details for informational or trouble-shooting purposes are provided in the ReturnStatusDetail. All DeviceIDs that were in the request are reported back in the response. The DeviceIDs are grouped together with the appropriate ReturnStatus and ReturnStatusDetail

34、 if more than one set of return statuses are returned. Server Side Middleware Server Side DRM SystemAddIPTVRxDeviceRequest()AddIPTVRxDeviceResponse()4.1.2 Entitling IPTV Receiving Devices to Programs, Services, Service Groups, and/or Assets The Server-Side Middleware requests the Server-Side DRM Sys

35、tem to entitle a device to access programs, services, service groups, or COD assets. The Server-Side DRM System sends back a response based on the outcome. Steps: 1. The Server-Side Middleware sends a request to the Server-Side DRM System to entitle one or more devices (DeviceID) to one, some, or al

36、l of the following: programs (PgmID), services (SvcID), service groups (SvcGrpID), and COD assets (AssetID). 2. The Server-Side DRM System processes the command and responds back to the Server-Side Middleware indicating the ReturnStatus and ReturnStatusDetail. All DeviceIDs that were in the request

37、are reported back in the response. The DeviceIDs are grouped together with the appropriate ReturnStatus and ReturnStatusDetail if more than one set of return statuses are returned. 4.1.3 Adding Services One or more services are added to the Server-Side DRM System for encryption and setting of copy p

38、rotection parameters with an add service request, and the DRM system sends back a response. ATIS-0800039.v002 9 Steps: 1. The Server-Side Middleware sends an AddServiceRequest to the Server-Side DRM System along with details such as the service IDs (SvcID), the type of encryption, and, optionally, a

39、ny copy protection parameters that need to be set. 2. The Server-Side DRM System processes the command and responds back to the Server-Side Middleware indicating the ReturnStatus and ReturnStatusDetail. All SvcIDs that were in the request are reported back in the response. The SvcIDs are grouped tog

40、ether with the appropriate ReturnStatus and ReturnStatusDetail if more than one set of return statuses are returned. Server Side Middleware Server Side DRM SystemAddServiceRequest()AddServiceResponse()4.1.4 Removing a Service from a Service Group Services that have been added to the Server-Side DRM

41、System may also be added to a service group within the Server-Side DRM System. A ServiceGroup is an entity that holds multiple services under one name. This example shows how one such service is removed from a service group. The service is not deleted from the DRM system, it is only removed from the

42、 particular service group. Steps: 1. The Server-Side Middleware sends a RemoveServiceFromGroupRequest to the Server-Side DRM System along with details such as the service ID (SvcID) of the service to be removed and the service group ID (SvcGrpID) of the service group from which to remove the service

43、. 2. The Server-Side DRM System processes the command and responds back to the Server-Side Middleware indicating the ReturnStatus and ReturnStatusDetail. The SvcGrpID of the service group is also returned along with the ReturnStatus and ReturnStatusDetail. ATIS-0800039.v002 10 Server Side Middleware

44、 Server Side DRM SystemRemoveServiceFromGroupRequest()RemoveServiceFromGroupResponse()4.1.5 Modifying Programs One or more programs that have been added to the Server-Side DRM System are modified by this API. The Server-Side Middleware sends the Server-Side DRM System a ModifyProgramRequest. The req

45、uest identifies the programs and provides the parameters that have to be modified, such as the type of encryption or copy protection settings. Steps: 1. The Server-Side Middleware sends a ModifyProgramRequest to the Server-Side DRM System along with details such as the program IDs (PgmID) of the pro

46、grams to be modified and parameters for each program that have to be modified. 2. The Server-Side DRM System processes the command and responds back to the Server-Side Middleware indicating the ReturnStatus and ReturnStatusDetail. All PgmIDs that were in the request are reported back in the response

47、. The PgmIDs are grouped together with the appropriate ReturnStatus and ReturnStatusDetail if more than one set of return statuses are returned. Server Side Middleware Server Side DRM SystemModifyProgramRequest()ModifyProgramResponse()ATIS-0800039.v002 11 4.1.6 Querying Assets The Server-Side Middle

48、ware will query the Server-Side DRM System about one or more COD assets. The Server-Side DRM System responds by providing all available details for those assets. Steps: 1. The Server-Side Middleware sends a QueryAssetRequest to the Server-Side DRM System by providing the asset IDs (AssetID) of the a

49、ssets to be queried. 2. The Server-Side DRM System processes the command and responds back to the Server-Side Middleware indicating the ReturnStatus and ReturnStatusDetail. For all requested valid assets, the Server-Side DRM System returns all the relevant information of those assets along with the response. All requested AssetIDs (whether valid or not) are returned with the response. Server Side Middleware Server Side DRM SystemQueryAssetRequest()QueryAssetResponse()5 DESIGN FOR INTEROPERABILITY This section specifies the design of the serv