ATIS 0800024-2009 Security Robustness Rules Interoperability Specification.pdf

1、 ATIS-0800024 SECURITY ROBUSTNESS RULES INTEROPERABILITY SPECIFICATION The Alliance for Telecommunication Industry Solutions (ATIS) is a technical planning and standards development organization that is committed to rapidly developing and promoting technical and operations standards for the communic

2、ations and related information technologies industry worldwide using a pragmatic, flexible and open approach. Over 1,100 participants from over 300 communications companies are active in ATIS 22 industry committees and its Incubator Solutions Program. Notice of Disclaimer the entity whose Content is

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

4、ected Content purchased from that Content Provider and played on a Users Device. 3.1.12 Copy: To make a perfect reproduction of DRM Content or Rights. 3.1.13 Copy Control: The enforcement of conditions under which copyrighted content can be copied. Copy Control is one part of Content Protection. 3.1

5、.14 Copy Protection: 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. ATIS-0800024 5 3.1.15 Cryptographically Robust: This term cryptographi

6、cally robust is often used to describe an encryption algorithm and implies, in comparison to some other algorithm (which is thus cryptographically weaker), greater resistance to attack. 3.1.16 Device: A Device is the entity (hardware/software or combination thereof) within a users equipment that imp

7、lements a DRM Client. The Device is also conformant to the specifications of the DRM it supports. 3.1.17 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 con

8、trol of the viewing of content that is delivered over IP transport. Rights Management for the delivered content. 3.1.18 DRM Client: The entity in the Device that manages Permissions for Content and Media Objects on the Device. 3.1.19 Entitlement: Information about the authorization level/s a user ha

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

10、Device or server-side devices or equipment. 3.1.22 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 si

11、gnal and converting the content into a renderable format (e.g., a STB). 3.1.23 ISS/A: The part of the ISS toolkit that deals with authentication functionality. See ATIS-0800014, Secure Download and Messaging Interoperability Specification. 3.1.24 ISS/E: The part of the ISS toolkit that deals with co

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

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

14、mpered with 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. A

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

16、y: Confidentiality of user viewership and interactions with IPTV systems. 3.1.30 Protected Content: Media Objects that are consumed according to a set of Permissions in a Rights Object. ATIS-0800024 6 3.1.31 Revoke: A Device has been Revoked by a particular Rights Issuer if that Rights Issuer has de

17、cided it does not wish to issue Rights Objects to that Device (for example, because it has concerns about the robustness of the Devices implementation). 3.1.32 Rights: The ability to perform a pre-defined set of utilization functions on a content item. These utilization functions are the permissions

18、 (e.g., to view/hear, copy, 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 conte

19、nt and provide liberty of use granted to the end-user. 3.1.33 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.34 Rights Holder: Indicates the entity that is entitled to grant rights. 3.1.35 Separ

20、able 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.36 Server-Side Middleware: This is the system external to the Server-Side DRM System that is interacting with the Server-Side DRM System

21、to facilitate the delivery of secure content to the IPTV Receiving Device. 3.2 Acronyms and 2) keys cannot be directly read by hardware means. Part of the mitigation strategy of this vulnerability is complying with the robustness rules described in this document. The next figure shows the attack tre

22、e for content theft by impersonating a valid IPTV Receiving Device. ATIS-0800024 12 ContentTheftContentSplicingCapture Clear ContentDecrypt Encrypted ContentDuplicate IPTV Receiving Device with key informationDeter any duplicate IPTV Receiving Devicesby providing robustnessUse ofRevokedCertificateFi

23、gure 6: IPTV Receiving Device Content Theft - Duplicate Device with key information - Attack Tree Part of the mitigation strategy of this vulnerability may also involve various levels of tamper proofing. ContentTheftContentSplicingCapture Clear ContentDecrypt Encrypted ContentDuplicate IPTV Receivin

24、g Device with key informationUse revocation status-checking services(OCSP/CRL)Use ofRevokedCertificateFigure 7: IPTV Receiving Device Content Theft Use of Revoked Certificate - Attack Tree ATIS-0800024 13 4.2.1.2 Service Theft Service theft involves the viewing of video content which the attacker ha

25、s not paid for; the next figure shows this attack tree. This service theft vulnerability has three attack branches that are decomposed in further figures: IPTV Receiving DeviceContentTheftInformationTheftServiceTheftServiceDisruptionAddEMMsIgnore EMM removalDuplicate IPTV Receiving DeviceFigure 8: I

26、PTV Receiving Device - Service Theft - Attack Tree The next figure shows the attack tree for service theft by manipulating EMMs. This attack tree has three more sub-branches as shown: ATIS-0800024 14 ServiceTheftManipulateEMMsIgnore EMM removalDuplicate IPTV Receiving DeviceSend ForgedEMMsRe-send Co

27、piedEMMsAdd entitlements by manipulating softwareSolution proprietaryTo DRM systemUse secure time sourceSecure Execution EnvironmentUse of revoked CertificatesFigure 9: IPTV Receiving Device - Service Theft - Manipulate EMMs - Attack Tree In the above attack tree, a single mitigation strategy may no

28、t be sufficiently robust, and multiple mitigation measures may be required. The next figure shows the attack tree for service theft by failure to ignore EMM removal: ATIS-0800024 15 ServiceTheftManipulateEMMsIgnore EMM removalDuplicate IPTV Receiving DeviceDRM specific solutionsUse of revoked certif

29、icatesFigure 10: IPTV Receiving Device - Service Theft - Ignore EMM removal - Attack Tree In the above attack tree, a single mitigation strategy may not be sufficiently robust and multiple mitigation measures may be required. The next figure shows the attack tree for service theft by the presence of

30、 a duplicate IPTV Receiving Device: ServiceTheftAddEMMsIgnore EMM removalDuplicate IPTV Receiving DeviceDeter and detect duplicate IPTV Receiving Device and deny serviceUse of revokedcertificatesFigure 11: IPTV Receiving Device - Service Theft - Duplicate Device - Attack Tree ATIS-0800024 16 Part of

31、 the mitigation strategy of this vulnerability may also involve various levels of tamper proofing. Detection of duplicate devices can be very difficult for devices with one-way links. Detection would likely be possible only for 2-way devices. 4.2.1.3 Information Theft Service refers to initial deliv

32、ery of content to IPTV Receiving Device. Information theft involves the acquisition of information about subscribers which the attacker is not entitled to. The next figure shows the information theft attack tree. This attack tree has four more sub-branches as shown: InformationTheftCapturesubscriber

33、s personal detailsCapture subscribers information fromcommunicationpathsSecuresubscribers personal infowhile stored Securesubscribersinformation duringtransportFigure 12: IPTV Receiving Device - Information Theft - Attack Tree In the above attack tree, a single mitigation may not be sufficiently rob

34、ust and multiple mitigation measures may be required. 4.2.1.4 Service Disruption Service Disruption involves either denying rightful access to services or making the experience poor. The next figure shows the attack tree for service disruption. This attack tree has three more sub-branches as shown.

35、4.2.1.4.1 Rogue Network Disruption Rogue network device sends offending code to headend, which sends code to all other devices and creates disruption of service. Mitigation is accomplished through authentication and secure execution of all downloads. ATIS-0800024 17 Service DisruptionDuplicate IPTV

36、ReceivingDeviceBroadcast EMM removalBroadcast channel change/leaveProvide deviceidentity uniquenessand protection DRMspecificDisallow IGMPFor other IPsAuthenticateIGMPmessagesRogue networkdevice placesoffending codeon serversAuthenticatedownloads and SecurelyexecuteFigure 13: IPTV Receiving Device -

37、 Service Disruption - Attack Tree This classic denial of service (DOS) attack is another vulnerability that must be mitigated. In the above attack tree, a single mitigation method may not be sufficiently robust and multiple mitigation measures may be required. 4.3 Threats to IPTV Devices 4.3.1 Threa

38、ts to Outputs and Paths Decrypted IPTV content data should not be available on outputs other than those intended by the design of the IPTV Receiving Device (e.g., viewing screen). For devices that have multiple components that are connected via user-accessible connectors or buses, confidentiality pr

39、otection needs to encompass such connections. In other words, confidential data such as DRM-related keys cannot be present on any user-accessible bus in unencrypted form, whether the data is in memory or in transit, including transit within the device. The definition of a user-accessible bus should

40、be defined by a trust authority and is therefore out of the scope of this document. 4.3.2 Device Information Integrity The identity of the IPTV Receiving Device, as defined at the time of manufacturing and recorded in device certificate, must be unique and protected from modification. This means the

41、 device identity in the certificate subject name is unique to the pool of all IPTV devices. Although not a direct security robustness requirement, the identities included within ATIS device certificates and all other identities required for the network to authenticate, recognize, and authorize the d

42、evice for ATIS-defined services must be unique. For instance, this could be accomplished by ATIS-0800024 18 establishing an IPTV Receiving Device identity naming convention in which the identity can be formed as a combination of a company- or organization-unique ID and a device-unique ID. 4.4 Genera

43、l Scope of Robustness Rules In order to address the threat analysis of the preceding sections, security robustness rules may be developed, and should consider, at the least, the following capabilities: Accurate identification of a valid IPTV Receiving Device. Tamper evidence and/or resistance. Prote

44、ction of content in motion and at rest. Enforcement of content authorization. Security renewability. 5 DESIGN FOR INTEROPERABILITY This section describes the IPTV Security Solution Interoperability Specification for the Security Robustness Rules. 5.1 Secure Execution Environment Elements The element

45、s that comprise a SEE are as follows: 1) Execution Engine 2) Storage 3) Trusted Paths 4) Algorithms 5) Secure Time Generation 6) Physical Security Any specific instance of a SEE will have a combination of different robustness levels of the above elements, and thus, this document specifies several le

46、vels of SEE robustness in section 5.2. 5.1.1 Execution Engine The execution engine is the computing element that performs the security functions embodied in the SEE. 5.1.2 Storage SEE storage consists of both the volatile and non-volatile memory used to implement the security functionality. There ar

47、e at least two ways to protect information while in this storage: 1) Use hardware-based secure memory protection, enabling the hardware to provide a proprietary method for memory protection without performing encryptions. ATIS-0800024 19 2) In the case of a lack of hardware-based secure memory prote

48、ction, reliance can be made on a unique, per-device secret that is protected by hardware and is used to encrypt all the other values to be protected and then decrypt them when needed. 5.1.3 Trusted Paths Trusted paths consist of all input and output ports from the SEE as well as all communication in

49、terfaces internal to the SEE. 5.1.4 Physical Security Physical security, as defined in FIPS 140-2 7, is the external indication that an attempt has been made to compromise a cryptographic module (i.e., the SEE) and possibly includes the capability of responding to that compromise attempt. In this document, physical security levels are described as follows: Low Physical Security: Having only the ability to show local evidence of tampering. High Physical Security: Having the ability to show local evidence of tamper