ATIS 0800054-2013 DRM APPLICATION LEVEL INTERFACES INTEROPERABILITY DRM Application Level Interfaces Interoperability Specification - Client-Side APIs (Includes Access to Additiona.pdf

《ATIS 0800054-2013 DRM APPLICATION LEVEL INTERFACES INTEROPERABILITY DRM Application Level Interfaces Interoperability Specification - Client-Side APIs (Includes Access to Additiona.pdf》由会员分享，可在线阅读，更多相关《ATIS 0800054-2013 DRM APPLICATION LEVEL INTERFACES INTEROPERABILITY DRM Application Level Interfaces Interoperability Specification - Client-Side APIs (Includes Access to Additiona.pdf（38页珍藏版）》请在麦多课文档分享上搜索。

1、 Access to Additional Content for ATIS-0800054, Dated: June 7, 2013 (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 hold

2、er of this document Click the link(s) below to access the content and use normal procedures for downloading or opening the files. ATIS-0800054.zip Information contained in the above is the property of the Copyright holder and all Notice of Disclaimer solicited and unsolicited events notifications. T

3、he interfaces from the DRM Component to the IPTV Receiving Device Software are: Client Notify API: Solicited and unsolicited events and notifications. Storage API: Provides the DRM Component with Read/Write persistent storage. Client applications in the IPTV Receiving Device Software interact with t

4、he DRM Component through these APIs. Activities may be triggered by local activity in the device or may be the result of server-side messaging. 1.2.2 Server Side Middleware to IPTV Receiving Device Software (Limited to DRM-Associated APIs) The definition of a simple interface between the IPTV Receiv

5、ing Device Software and the Server-Side Middleware will simplify the interconnection and integration effort of the IPTV network. The definition of a bi-directional API for messages that need to flow between the Server-Side DRM System and the IPTV Receiving Device Software through the Server-Side Mid

6、dleware is beyond the scope of this standard. 1.2.3 Secure Download Environment (SDE) The SDE is the portion of the Secure Execution Environment (SEE) of the DRM Component designed to securely receive and execute the Downloadable Security Client (DSC). See Figure 3. ATIS-0800054 4 IPTV Receiving Dev

7、ice DRM ComponentAPI APISecure Download Environment (SDE)APISecure Execution Environment (SEE)Downloadable Security Client (DSC)DRMNotifyDRMCommandDownloadSecure Part Hardware (SP-H)Secure Part Virtual (SP-V)ClientNotifyStorageIntrinsic DRM ClientSeparable Security Element (SSE)Secure Part Separable

8、 SP-SFigure 3: DRM Client Configuration There may be zero or more SDEs within the DRM Component, and each may be hosting a different DSC image. The SDE implementation may include hardware resources to provide additional protections for a stronger SEE. The API handlers within the DRM Component implem

9、ent the methods necessary to cross a SEE boundary. When additional hardware resources are used to increase the SEE level, the following terms are used: Secure Part Hardware (SP-H): Isolated RAM, CPU, busses. Secure Part Virtual (SP-V): Isolated RAM, shared CPU, and busses. Secure Part Separable (SP-

10、S): Separable Security Element (SSE). An Intrinsic DRM Client function is always assumed. The intrinsic functions implement the APIs and manage any hardware interfaces: SP-H, SP-V, or SP-S. Launch and management of the Intrinsic DRM Client software image is out of scope by definition. Collectively,

11、the mix of the Intrinsic DRM Client, executing DSC images, or an attached SSE implement the APIs defined in this document. 1.2.4 Separable Security Element (SSE) API Some instances of an IPTV Receiving Device may include a Separable Security Element (SSE). Some SSE implementations may follow the wel

12、l-known CableLabs CableCARD Interface 2.0 Specification (CCIF2.0) 4. In those cases where the ATIS IPTV Receiving Device uses the CableCARD SSE, there is no need to define a IPTV Receiving Device DRM Component API, since this CableLabs CableCARD Interface specification is sufficiently detailed with

13、respect to the messages that flow across the CableCARD interface and it meets most (if not all) interface requirements per ATIS-0800001 5. 1.2.5 Hosted Storage Service A Hosted Storage Service API is a service provided to the DRM Client by the IPTV Receiving Device Software. This API is used to read

14、 and write persistent storage blocks of a modest size. The DRM Client may use this storage to store state information, configurations, software images, etc. Any data encryption for storage takes place within the DRM Client before calling the Storage Service API. ATIS-0800054 5 NOTE This API is not i

15、ntended for media streams. 1.2.6 CAS ID (idCAS) The CAS ID is defined in ATIS-0800039 1 as a segregating type to differentiate different CAS/DRM instances running in the Server-Side DRM System in Figure 1. This same CAS ID is used to identify Security Client Instances (SCI) running in the IPTV Recei

16、ving Device DRM Component. 1.3 Abbreviations Part 1: CORBA Interfaces.21This document is available from the Alliance for Telecommunications Industry Solutions (ATIS), 1200 G Street N.W., Suite 500, Washington, DC 20005 . 2This document is available at . ATIS-0800054 8 4 Cable Television Laboratories

17、, Inc., CCIF2.0, OC-SP-CCIF 2.0 I13-080118 CableCARD Interface 2.0 Specification, January 18, 2008.35 ATIS.0800001.v003, IPTV DRM Interoperability Requirements.43 Analysis for Interoperability 3.1 Detailed Interoperability Architecture Components 3.1.1 User Initiated DRM Activity Use Cases The follo

18、wing use cases initiated by the user result in some information exchange on the interface between the software on the IPTV Receiving Device and the IPTV Receiving Device DRM Component: 1. The user changes the channel to an encrypted broadcast channel. 2. The user selects an encrypted COD movie for p

19、layback. 3. The user tries to watch a channel but does not have the entitlements/rights to view the channel (e.g., the user can be prompted to subscribe to the channel or a message can be displayed to tell the user to phone the customer care line). 4. The user changes a channel to a broadcast channe

20、l that is marked for blackout in the region where the user lives. 5. The user presses the DVR record button on an encrypted broadcast channel. 6. The user presses the DVR playback button to playback some previously recorded encrypted content. 7. The user switches the IPTV Receiving Device on for the

21、 first time or resets the box (e.g., the DRM Component needs to be initialized). 8. The user enters or resets a security code (e.g., parental control PIN). 3.1.2 The IPTV Receiving Device DRM Component Use Cases The following use cases are provided to assist in the analysis of the IPTV Receiving Dev

22、ice DRM Component in the IPTV Receiving Device. The purpose of the analysis is to identify any functionality that needs to be specified to assist in the interoperability of the IPTV Receiving Device DRM Component: 1. The IPTV Receiving Device DRM Component gets loaded in a secure manner. 2. The IPTV

23、 Receiving Device DRM Component securely loads all the locally stored persistent values needed for initialization. 3. The IPTV Receiving Device DRM Component is provisioned in an authenticated manner by the Server-Side DRM System, including the selection of the DSC to be downloaded. 4. The IPTV Rece

24、iving Device Software queries the IPTV Receiving Device DRM Component for its status (e.g., DSC version currently loaded, execution state). 5. The IPTV Receiving Device DRM Component communicates with the Server-Side DRM System to obtain keys and rights. 3This document is available at . 4This docume

25、nt is available from the Alliance for Telecommunications Industry Solutions (ATIS), 1200 G Street N.W., Suite 500, Washington, DC 20005 . ATIS-0800054 9 6. After selection of a service by a user, the IPTV Receiving Device DRM Component locates and obtains the associated access information for the st

26、ream to be decrypted (e.g., this can be a Linear TV or COD stream). 7. The IPTV Receiving Device DRM Component receives content packets and decrypts them within the SEE and then sends them back out to the IPTV Receiving Device software for storage or display. 8. The IPTV Receiving Device DRM Compone

27、nt requests the IPTV Receiving Device Software to configure the IPTV Receiving Device to receive and filter specific DRM messages so that they may be passed to the DRM Component (e.g., Entitlement Control Messages). 9. The IPTV Receiving Device DRM Component notifies the IPTV Receiving Device Softwa

28、re with an appropriate message in the case where the IPTV Receiving Device DRM Component does not have the appropriate rights to decrypt a stream. 10. The IPTV Receiving Device DRM Component provides cryptographic primitives to support authentication/privacy services for messages or files that are n

29、ot executable software (e.g., Electronic Program Guide, emergency alerts, etc.). 11. The IPTV Receiving Device DRM Component writes/reads data securely to/from the IPTV Receiving Devices direct storage (e.g., flash or hard disk). 12. The IPTV Receiving Device DRM Component retrieves unique identific

30、ation information from the IPTV Receiving Device (e.g., MAC address, serial number, unique identification number). 13. The IPTV Receiving Device DRM Component manages the installation, activation, suspension, resumption, deactivation, removal, and revocation of the DSC software. 14. The IPTV Receivi

31、ng Device DRM Component requires access to IPTV Receiving Device network services in a secure and coordinated manner. 3.2 Detailed Interoperability Architecture Interfaces 3.2.1 Server Side Middleware to IPTV Receiving Device Software DRM Messages Use Cases Messages that flow between the Server-Side

32、 Middleware and the IPTV Receiving Device Software that are DRM-specific utilize the services of the DRM Component. For these messages, the following use cases apply: The passing of messages between the IPTV Receiving Device DRM Component and the Server-Side DRM System may be proprietary to the DRM

33、system being used and may also be encrypted. These messages are carried opaquely in the session between the IPTV Receiving Device Software and the Server-Side Middleware. Examples of the dialogue between the IPTV Receiving Device DRM Component and the Server-Side DRM System include: o The updating o

34、f the IPTV Receiving Device DRM Component. o The passing of some initial conditions (e.g., selection of content decryption algorithm). o IPTV Receiving Device DRM Component diagnostic queries and replies. The passing of messages between the IPTV Receiving Device DRM Component and the Server-Side Mid

35、dleware may be needed for various management functions. For example, a message may represent: o Instructing the IPTV Receiving Device to load or remove a specific DSC. o Querying the IPTV Receiving Device regarding which DSC is present on the device. o Instructing the IPTV Receiving Device to revoke

36、 a specific DSC. ATIS-0800054 10 NOTE: This standard makes no implementable definitions for these use cases. 3.3 Software-to-Software API The interface between the IPTV Receiving Device Software and the IPTV Receiving Device DRM Component is a software-to-software interface. In order to promote inte

37、roperability, this API interface between components must have a well-defined command/response interface, argument/results passing, and control semantics. 3.3.1 API Semantics The control semantics of the API should indicate which operations are synchronous (produce an immediate result when called), w

38、hich operations are asynchronous (produce a result at a later time), and which are unsolicited (produce a result with no corresponding request). Methods should exist to query status or cancel in-progress operations. A standard set of error codes should also be defined to allow for consistent reporti

39、ng. However, the specification should not be limited to specific programming languages. For example, the API should be implementable in C, C+, Java, assembly language, or any other modern programming language. With a simple interface definition, such as IDL, the rules for language implementation are

40、 straightforward. For example, the following IDL interface shows how an interface encapsulates functional methods that pass arguments and receive results: interface DrmNotifications ErrCode ServerSideMessage( in MessagePtr msg , in long msgLen ) ; ; The IDL descriptions are compiled into source file

41、s for the selected computer language. The client side of the interface then invokes the functions listed in the interface and the handler on the other side of the interface carries out the requested function and returns the result. The handler is linked directly into the client application. The hand

42、ler may service the function directly, pass the request across a physical boundary, or engage dedicated threads to carry out the command and deliver a result notification at a later time. The convention adopted here is to start type names with upper case and value names with lower case. 3.3.2 Proces

43、ses, Threads, Libraries The use of the APIs may be scattered across multiple processes. For example, in an IPTV Receiving Device there may be several different client applications that wish to issue a command or notification event to the DRM Component. In addition, there may be multiple threads with

44、in a single process that invoke an API call. At the same time, threads within the DRM Component can be calling into API libraries that dispatch notifications to the IPTV Receiving Device Software or APIs that utilize the hosted storage services. Therefore, it is important to specify the process and

45、thread conditions under which the APIs are used and are expected to operate. ATIS-0800054 11 4 Design for Interoperability This section will outline the design of DRM Interoperability Application Programming Interfaces to achieve interoperability. There are Interface Definition Language (IDL) defini

46、tions that have been developed by ATIS in association with this document. The full IDL source code is in the form of an “.idl” file, which is contained in a ZIP file that accompanies the present document. In the event of any conflict, this “.idl” file takes precedence over the IDL definitions in the

47、 present document. The current list of normative .idl files is found below: ClientNotifications.idl DrmCommand.idl DrmNotifications.idl HostedStorageService.idl ISSTypes.idl SCI.idl 4.1 IPTV Receiving Device DRM Component typedef string String255Type ; / Type defined for ATIS-0800054 typedef String2

48、55Type Name ; typedef String255Type StoragePath ; typedef String255Type CasId ; typedef String255Type TxId ; typedef String255Type SdeId ; typedef sequence Buffer ; typedef sequence Handle ; typedef Handle SciHandle ; struct Message ATIS-0800054 12 long len ; Buffer data ; ; / Security Client Instan

49、ce (SCI) state enum ScInstanceState ScState_Unknown , ScState_ShutDown , ScState_Booting , ScState_Initializing , ScState_Ready , ScState_ShuttingDown , ScState_Suspending , ScState_Suspended , ScState_Resuming ; /- Interface Function return codes enum IssErr IssErr_None , IssErr_BadParameter , IssErr_NotImplemented , IssErr_InterfaceBusy , IssErr_ControlBadState , IssErr_SuspendNotAvailable , IssErr_StartupNoDscAssigned , IssErr_InvalidStoragePath , IssErr_CasID_Unknown , IssErr_PathAlreadyExists , IssErr_