4K Network Security Proposal Discussion with Studios. UXTC - Technical Planning Group Sony Electronics 8/10/2014

Transcription

1 4K Network Security Proposal Discussion with Studios UXTC - Technical Planning Group Sony Electronics 8/10/2014

2 Overview Sony s 4K Network Security Proposal: Our authentication protocol uses certificates checked against a white list that includes additional information for targeted renewability Robustness based on HDCP 2.2 with third party certification Compliance rules that can preclude outputs Outstanding Items: Start-up process for a market need ahead of appropriate licensing and certification DirecTV, Sony and others have expressed a desire to make an announcement at upcoming CES See Phase-in Slides White listing can be a process where content providers could determine their own list of approved devices

3 Authentication

4 Authentication Key Points: Authentication Summary Our proposed authentication approach starts by manufacturers supplying the Device IDs (and minimum software version number) of conforming Ultra High Definition (UHD), e.g. 4K, TVs to the service provider for inclusion in a list, which will be referred to as the authenticated white list. Inclusion in the white list can be based on criteria negotiated with the service and content providers. White list checking can be validated on a content provider-by-content provider basis and content-by-content basis. The approach uses existing, ordinary Digital Transmission Copy Protection (DTCP) certificates that are already present for link protection for premium content on the home network. The DTCP certificates supply the Device IDs for authenticated white list. Unique or common DTCP Device ID (from client certificates that are shared) are received by the set-top box server from the TV, and checked against a white list (securely delivered by the service provider). The authenticated white list will contain a device s minimum software version number and other information in order to address security concerns. We propose that a 3rd party certification process be implemented and built into the RVU Certification process and CVP-2 Certification process. (See slides on this topic) The authenticated white list approach can be used until a new version of DTCP is available that meets content providers Enhanced Content Protection (ECP) requirements. The white list may not be needed for devices implementing this new version of DTCP. Authentication Protocol: We propose using a modified version of the DLNA CVP-2 authentication (TLS with Supplemental Data). We enhanced the existing protocol to securely deliver additional signed information, including model # and the TV s current software version. Later, when link protection is established, the server can check to see if the Device ID (sent in the DTCP certificate) is the same.

5 Authentication Protocol Proposal Two Step 1) (Step 1) Device ID is obtained from TLS with Supplemental Data Auth as part of DTCP client certificate that is exchanged. Other information will be securely exchanged (Make/Model #/Serial #/MAC/UUID/SW Version, etc.) 2) Set-top box checks for Device ID in the service operator s white list, and performs other verifications: SW version, etc. 3) Set-top box and TV perform Authenticated Key Exchange (AKE) 4) (Step 2) During, DTCP AKE, Set-top box checks for Device ID in the revocation List (service Renewability Message) 5) Device ID from Authentication must be the same as in AKE DirecTV White List (e.g. new format) , SW Version , SW Version , SW Version Conditional Access , SW version , SW version , SW version Step Step 1 2 TLS with Supp Data Authentication (Cert Device ID: ) + Make/Model #/Serial #/MAC/SW Version DTCP Authenticate Key Exchange (AKE) (Cert Device ID: ) DTCP-IP (Copy Never) Ethernet or Wi-Fi Manufacturers supply service provider with list of conforming Device IDs (from DTCP certificates). Service provider must integrated them into a sequential list. This is a new protocol a version is being standardized for the DLNA CVP2 Project DTCP Revocation List (SRM Format) DirecTV Set-top Box DTCP Revocation List (SRM Format) Sony 4K TV SEL-UXTC 5

6 Authentication Approach Two Step IETF has already reviewed the cryptography associated with TLS with signed supplemental data that was used for CVP-2. And our approach will build on top of that. A general advantage of using DTCP certificates is that the service provider can confirm that the device from authentication is also the same one in link protection. DTCP allows the use of both unique and common certificates. Use of unique as opposed to common DTCP certificates may help differentiate an imposter from real devices. The reporting of the same unique Device ID by different devices, e.g. different locations at the same time, probably means that something is amiss. A combination of Common Device ID and MAC address can be used to uniquely identify a device. MAC ranges may be implemented on the authenticated white list. Common Certificates must be replaced (renewed) once a year. MovieLabs Enhanced Content Protection (ECP) specifications require a forward movement of software releases that fix security and compliance breaches. The TV must securely report its software version number (during authentication step 1) so that it can be checked against the white list data and if necessary denied service. All devices, including those in the cabin-in-the-woods, should be able to receive updated key (DTCP certificates) and software if need be.

7 Authentication Phase-in

8 Phase-in DirecTV has proposed a phase-in that is a longer term (see next slide) - starting with its current white list implementation, migrating to the simple Device ID check (described below), and then finally the modified CVP2-protocol. Sony believes that Simple Device ID white list checking or One Step could use the low-level DTCP AKE to great advantage. Devices can t lie about the Device ID because it is in the DTCP certificate Device ID can be tied to a range of security robust UHD TVs Device IDs can also be tied to software versioning (just requires proper management and the ability to securely update certificates/keys in the field

9 DIRECTV Proposed AWL Implementation Timeline Launch Launch 3Q Q Q Q Q Q 2017 For example: Inserts Unique DTCP Certs at manufacture Genie HR44 Current White List - UPnP based - Confirms TV is DIRECTV Ready & RVU Certified Authenticated WL - One step - Checks for valid DTCP Cert ID No change to TV - Sony provides DIRECTV its DTCP Cert ID ranges Authenticated WL - Two step - Checks for valid DTCP Cert ID and Supp. Data TV adds Authentication - Two step protocol Sunset of support for AWL Phase 1 Renew SW & update DTCP Certs as needed to remain on AWL For example : Inserts Common DTCP Certs at manufacture No change to TV - LG provides current & next Common Cert IDs TV adds Authentication - Two step protocol Update Common Cert ID Renew SW as needed & update DTCP Certs annually to remain on AWL For example : Inserts NO DTCP Certs at manufacture No change to TV - Samsung provides Cert IDs (either ranges for Unique, or current & next for Common) TV adds Authentication - Two step protocol Update Cert ID, if common type Renew SW as needed & update DTCP Certs annually (if common) to remain on AWL DIRECTV Proprietary 9

10 Authentication Protocol Phase-in - Proposal 1) Device ID is obtained from the existing Low Level DTCP AKE as part of the client certificate 2) Set-top box checks for Device ID in the DTCP Revocation List 3) Set-top box checks for Device ID in the DirecTV White List (possibly the same format as revocation list) - Perform in lower level or higher level DirecTV Authenticated White List (SRM Format) Conditional Access Simple Device ID Check or One Step Step 1 DTCP Authenticate Key Exchange (AKE) (Cert Device ID: ) DTCP-IP (Copy No More or Copy Never) Ethernet or Wi-Fi Manufacturers supply service provider with list of conforming Device IDs (from DTCP certificates). Service provider must integrate them into a sequential list. DTCP Revocation List (SRM Format) SEL-UXTC DirecTV DTCP Revocation List (SRM Format) Set-top Box Sony 4K TV (STB) Proprietary and Confidential 10

11 Compliance and Robustness Rules

12 Robustness Rules Summary Our goal is to get DTCP added to the studios list of approved Ultra High Definition (UHD), e.g. 4K, content outputs. Studios seem to have blessed HDCP 2.2 robustness. As you probably know, HDCP robustness rules were originally derived from DTCP robustness rules. They follow the same general format and contain much of the same language, and thus are easy to compare sideby-side with the DTCP robustness rules. HDCP 2.2 robustness is detailed the HDCP 2.0 Addendum: Our approach is to go through the HDCP 2.0 Addendum and apply everything that is pertinent to DTCP, e.g. compressed as opposed un-compressed content. An advantage to this approach is that there is no fundamental change to the PKI and cryptography 160-bit elliptic curve. Old and new DTCP certificates will work together which addresses a serious legacy issue.

13 Robustness Rules Proposal We propose an addendum to the DTLA License Agreement that specifies UHD compliance and robustness. o Compliance rules similar to Digital Only Token (DOT), but where only UHD capable DTLA devices can manage/handle UHD content o Robustness rules modified to HDCP2.2 level (discussed on previous slide) and called UHD Robustness Rules The DTCP specification is updated to add: o UHD content indicator to the Copy Management Indicator (CMI) o UHD compliance indicator to the device certificate A source device can check for the UHD compliance indicator, if not present, could decide what to do. o For example, a decision could be made by the set-top box that while the TV is does not have the compliance bit in its certificate, it appears in a white list of known secure devices, and therefore does not represent a security risk.

14 Robustness and Compliance Certification Program

15 Certification Program 3rd Party Certification: o o It should be noted that service operators and CE companies alike are not accustomed to 3rd party security scrutiny. This step might be considered burdensome for the following reasons: o + Invasive disclosure of design information o + Time consuming and requiring personnel to address each issue o + Potentially causing a delay in product launch schedules Self reporting is still very desirable and should be considered after a successful implementation where 3rd party certification was used. This is a scenario of the Trusted Implementer. Certification Proposal: o o For the DirecTV UHD service, RVU alliance handles RVU certification. They could be enlisted to perform an additional step, e.g. security analysis of the each implementation or platform. For US cable, CVP-2 compliance requires DLNA certification. Either DLNA, or, perhaps, CableLabs could be enlisted to perform security analysis as part of the overall CVP-2 program.

16 BACK-UP SLIDES

17 Hacker Scenario 1???? Pirate Assumptions: (Compliance Rule) 1) The software of a certain TV does not properly handle UHD content 2) UHD content is improperly output to another device via an interface. 3) Content is mishandled in the other device 4) UHD content is recorded to a Hard Disk Drive, and later published on the Internet SEL-UXTC Proprietary and Confidential 17

18 Hacker Scenario 2???? Pirate Assumptions: 1) Through great effort and reverse engineering, the certificate and public/private key of a certain TV is obtained 2) The proposed authentication protocol is known 3) The identity is infused into a premium ripper product allowing content to be recorded by a downloaded application to a PC or ipad. 4) A PC or ipad is able to spoof the identity of a TV 5) UHD content is recorded to the Hard Disk Drive SEL-UXTC Proprietary and Confidential 18

19 Hacker Scenario 3???? Pirate Assumptions: (Worse Possible Case) 1) The certificate public/private key of a certain TV is leaked Robustness rules were not implemented correctly 2) The proposed authentication protocol is known 3) The data exchanged between devices is known and specific device data is knowable outside the device 4) A laptop is able to spoof the identity of a TV 5) UHD content is recorded to the Hard Disk Drive, and later published on the Internet SEL-UXTC Proprietary and Confidential 19

20 Client authentication against X.509 only server Dewey CVP-2 App Opera CVP-2 Server Provide nonce1 Connect using TLS TLS extended Hello messages SupplementalData message includes nonce1 GetDTCPlocalCert() returns c_dtcpcert SignDataDTCP (nonce1 + c_dtcp Cert) returns psignature result = (nonce1+c_dtcp Cert+pSignature) SupplementalData message includes result TLS Tunnel established Verify signature c_dtcp Cert : Client DTCP Certificate nonce1 : reference number (eg counter or random)

21 Client authentication against a DTCP based server and untrusted X.509 Dewey CVP-2 App Opera CVP-2 Server verifydtcpremotecert(s_dtcp_cert) returns boolean verifydtcpsignature(sd, sig) returns boolean Connect TLS extended Hello messages using TLS SupplementalData message includes nonce1+s_dtcp Cert + X.509 Cert+ DTCP Sig SD=nonce1+s_DTCP Cert + X.509 Cert+ DTCP Sig GetlocalDTCPCert() returns c_dtcpcert SignDataDTCP (nonce1 + c_dtcp Cert) returns psignature result = (nonce1+dtcp Cert+spSignature) SupplementalData message includes result TLS Tunnel established Verify signature s_dtcp Cert : Server DTCP Certificate c_dtcp Cert : Client DTCP Certificate nonce1 : reference number (eg counter or random) Optional Method if we support server authentication

22 New DTCP Cert format Certificate Type Format Dev Gen Reserved (zero) C 2 AL AP Device ID Device ID continued (Total 40bits) Device EC-DSA Public Key (320 bits) DTLA EC-DSA signature of all preceding fields (320 bits for c and followed by d value) Change: C2 = CVP-2 bit

23 Scenario 1: Possible Elements in White List (unique cert + SW Version) + (unique next cert + SW Version) {Make/Model #/Serial #} Scenario 2: (common current cert + SW Version) + (common next Cert + SW Version) {Make/All Model #s} Scenario 3: (common current cert + SW Version) + (common next Cert + SW Version) {Make/Model#} (common current cert + SW Version) + (common next Cert + SW Version) {Make/Model#} All scenarios can exist at the same time unique with common certificates in the white list. There are two sets of common certificates ones currently being used and ones being phased-in. When most units have upgraded, updated, the old certificate can be phased out, e.g. deleted from the white list while a brand new certificate is phased-in. The previously phased-in certificate is now the new current certificate. Software versions could also know which is the latest common DTCP certificate in use. The firmware can check the DTCP certificate device ID to see if it is the correct one. However, operationally it might be nice to de-link these upgrading each out of sequence from each other.

24 DTCP Certificate Baseline Device Certificate Format

25 Inside the DTCP Certificate Certificate Type (4 bits). The only encoding which is currently defined is 0, which indicates the DTCP certificate. All other encodings are currently reserved. Certificate Format (4 bits). This field specifies the format for a specific type of certificate. Currently three formats are defined: - Format 0 = the Restricted Authentication device certificate format. - Format 1 = the Baseline Full Authentication device certificate format. - Format 2 = the Extended Full Authentication device certificate format (NOT ESTABLISHED ). - Other encodings are currently reserved. Device Generation (XSRMG, 4 bits). This field indicates the non-volatile memory capacity and therefore the maximum generation of renewability messages that this device supports. The encoding 0 indicates that the device shall have a non-volatile memory capacity for storing First- Generation SRM. The encoding 1 indicates that the device shall have a non-volatile memory capacity for storing Second-Generation SRM. Reserved Field (9 bits). These bits are reserved for future definition and are currently defined to have a value of zero. AL flag (1 bit). Additional Localization flag. The AL flag is set to value of one to indicate that the associated device is capable of performing the additional localization test, otherwise shall be set to value of zero. AP flag (1 bit). Authentication Proxy flag. A device certificate with an AP flag value of one is used by a DTCP bus bridge device, which receives a content stream using a sink function and retransmits that stream to another bus using a source function. The procedures for processing this field are specified in Appendix C. C2 flag (1bit). CVP2 flag. The C2 flag is set to a value of one to indicate that the associated device is DLNA CVP2 certified. Note the certificate when C2 is set can be used for either the DTCP authentication process or CVP Authentication process. Device ID (40 bits). Number assigned by the DTLA EC-DSA public key (320 bits) Public Key of the device EC-DSA signature (320 bits). Signature from the DTLA Certificate Authority of the components

26 System Renewability Message Structure of the First Generation System Renewability Message Format of the CRL Entry Type Block

27 Inside System Renewability Message Type - message Type field (4 bits). This field has the same encoding as is used for the certificate type field in device certificates. Generation - A message Generation field (SRMM) (4 bits). This field specifies the generation of the SRM. It is used to ensure the extensibility of the SRM mechanism. Currently, the only encodings defined are 0 and 1. The maximum size is specified in the DTCP specification available under license from DTLA. Other encodings are currently reserved. The Generation value remains unchanged even if only part of the SRM can be stored by the device (e.g. XSRMC <=SRMM). Reserved field (8 bits). These bits are reserved for future definition and are currently defined to have a value of zero. Version Number - A monotonically increasing system renewability message Version Number (SRMV) (16 bits). This value is exchanged as XSRMV during Full Authentication. This value is not reset to zero when the message generation field is changed. Certificate Revocation List (CRL) Length (16 bits). This field specifies the size (in bytes) of the CRL including the CRL Length Field (two bytes), CRL Entries (variable length), and DTLA Signature (40 bytes). CRL Entries (variable sized). The CRL used to revoke the certificates of devices whose security has been compromised. Its format is described in the following section. DTLA Signature - DTLA EC-DSA signature of these components using L-1 (320 bits).

28 System Renewability Message Example CRL