4K Network Security Proposal UXTC - Technical Planning Group Sony Electronics 8/5/2014
Key Points: Overview Our proposed security approach uses existing, ordinary DTCP certificates that are already present for link protection. Unique/common DTCP Device ID (from client certificates) are received by the set-top box server from the TV, and checked against a white list (securely delivered by the service provider). In order to address security concerns, the white list will also list the software version number which the client should be at or greater. Manufacturers supply the certificate IDs (and minimum software version number) of conforming 4K TVs to the service provider for inclusion in the list. Inclusion in the white list can be based on objective [I understand the intent but the criteria we use may include factors difficult to quantify. Our hope is that 3rd party certification may be used] criteria at the discretion of the service provider. In addition, white list checking can be on a programmer-by-programmer [do you mean content provider by content provider?] and even content-by-content basis. White list approach can be used until a new type of DTCP certificate is created new version of DTCP is available that meets content providers Enhanced Content Protection requirements that confirms greater robustness, perhaps based on HDCP 2.X. At that time, The white list will not be needed for devices implementing this new version of DTCP will not that conform to that higher level of robustness could be updated to use this new DTCP certificate and the white list discontinued. Authentication Protocol: We propose using a modified version of the DLNA CVP-2 authentication (TLS with Supplemental Data). We modify the existing protocol, that currently just verifies the client and server certificates, to securely deliver additional information, such as including model # and the TV s current software version, in a secure TLS encrypted tunnel. Later, when link protection is established, the server can check to see if the Device ID (sent in the DTCP certificate) is the same.
Manufacturers supply service provider with list of conforming Device IDs (from DTCP certificates). Service provider must integrated them into a sequential list. DirecTV White List (e.g. SRM Format) 0102030405, SW Version 1122334455, SW Version 2122232425, SW Version Conditional Access 0102030405, SW version 1122334455, SW version 2122232425, SW version Authentication Proposal Step Step 1 2 DTCP Authenticate Key Exchange (AKE) (Cert Device ID: 0102030405) DTCP-IP (Copy Never) 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 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 TLS with Supp Data Authentication (Cert Device ID: 0102030405) + Make/Model #/Serial #/MAC Ethernet or Wi-Fi This is a new protocol a version is being standardized for the DLNA CVP2 Project DTCP Revocation List (SRM Format) SEL-UXTC DirecTV DTCP Revocation List (SRM Format) Set-top Box Proprietary and Sony 4K TV (STB) Confidential 3
Security Approach A general advantage of using DTCP certificates is that the service provider can confirm that the device that was authenticated is the same one in link protection. Studios may not be very comfortable with common DTCP Certificates. There is a belief that it may be difficult to differentiate an imposter from real devices. Cloning into a non-compliant devices is a real threat. 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. But the same common Device ID will be reported in many locations making clone detection difficult. Studios would ideally like to enforce MovieLabs ECP specifications require a forward movement of software releases that fix compliance security breaches problems. There is a concern that older software that is properly signed, but out-of-date, could be manually reflashed into devices and boot properly. Unmodified Software should The device must securely report its software version number so that it can be checked against the white list data and if necessary denied service. We propose to have the TV share its current software version number with the set-top box during the authentication phase (Step 1). And the set-top box can check this against the minimum software version number in the white list. Devices using common certificates must be able to receive updated key material every year. It should be possible to also upgrade unique DTCP certificates as needed - possibly not only to update key information, but other information contained in the certificate.
Scenario 1: White List current (unique cert + SW Version) + next (unique cert + SW Version) {Make/Model #/Serial #} Scenario 2: current (common cert + SW Version) + next (common Cert + SW Version) {Make/All Model #s} Scenario 3: current (common cert + SW Version) + next (common Cert + SW Version) {Make/Model#} current (common cert + SW Version) + next (common 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, the old certificate/version # pair can be phased out, e.g. deleted from the white list while the new pair is phased-in. The previously certificate/software version # is now the new pair. Software versions could also know which is the latest 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. [Not sure I understand]