UXTC - Technical Planning Group Sony Electronics 7/22/2014 4K Network Security

Addressing SPE Concerns about DTCP-IP This presentation seeks to address issues raised by Spencer Stephens (CTO, Sony Pictures Entertainment): –The DTCP compliance and robustness rules allow for implementations that are not up to the MovieLabs specifications. –There is no third party certification or trusted implementer requirement. –DTCP’s revocation is inadequate on many levels. –DTCP allows for outputs that are not secure enough – e.g. HDCP 1.4. –The DTCP protocol itself may not be secure enough. Sony Pictures Entertainment (SPE) is not worried about Sony devices, but rather other manufacturers that may be sacrificing quality and security for cost. SPE believes that compliance and robustness rules may not be strictly followed. DirecTV believes that identifying a client device and using a service provider white list could add the desired level of additional security on top of DTCP link protection. Sony Electronics proposes a spoof resistant way to authenticate devices in order to make a white list feasible. Proprietary and Confidential 2

Distribution Scenario 1)User has RVU2.0 service on Sony 4K BRAVIA TV RVU is a native application 2)User has subscription to super-premium 4K service 3)From the RUI, user selects 4K content 4)DirecTV set-top box tunes the 4K program, sets- up a DTCP-IP connection with TV TV DTCP certificate is checked for revocation STB DTCP certificate is checked for revocation 5)User enjoys streaming 4K content on TV SONY 4K TV with RVU2.0 DTCP-IP (Copy No More) NDS Conditional Access DirecTV Set-top Box (STB) 6)TV receives and renders 4K content TV is DTCP sink device TV cannot retransmit or record No HDMI output from TV No means to externally access compressed or decoded content Ethernet and USB interfaces are disabled for A/V output Ethernet or Wi-Fi DTCP Revocation List Home Network DTCP Revocation List Proprietary and Confidential 3

Sony TV Security Sony uses a layered security approach in its TVs: Secure Boot – Software image is signed using a hardware root-of-trust – If signature does not match, then software does not execute – Sensitive algorithms are encrypted in FLASH storage area and decrypted as needed in RAM execution space Debug ports as well as “easy access” connectors are disabled on production units Downloaded Applications – Applications are signed – Applications do not have access to security functions No access to DTCP, HDCP and other cryptographic keys Local RAM/FLASH memory scrambling (transparent to application) Proprietary and Confidential 4

DTCP-IP DTCP uses state of the art cryptography: – Elliptic Curve – DTCP-IP Baseline Cipher with session keys: AES-128 – Authentication and Key Exchange (AKE) – Revocation List called “System Renewability Message” – delivered via package media or transmission SRM Size Field is 16 bits which allows for a file size of 65,536 bytes. – Localization (Time to Live <=3, WEP/WAP), Round Trip Time <= 7 milliseconds – Digital Only Token – New Content Management Descriptor Allows services to tailor content delivery to new business models – Robustness and compliance rules designed to frustrate hacking attempts Proprietary and Confidential 5

Expanded Use Scenario DirecTV In the future, 4K content will stream from many different sources (and not just DirecTV or Comcast) EchoStar Comcast Time Warner … Cable Operator Roaming/Mobile TV Manufacturer Cable Headend System Service Providers Proprietary and Confidential 6

Primary Issue – What Client is trying to Connect? Set-top Box SPE does not feel comfortable releasing content to all devices DTCP was designed to be device agnostic. The DTLA certificate does not contain manufacturer or model # information. The cert device ID offer no clues. DirecTV has proposed using a “white list” to figure out which devices should receive 4K content. But how to prevent a device from lying? See next slide. –A secure method is needed to trust a device (and to securely share the Manufacturer and Model #) –An Authentication method should be standardized and ideally work for all service operators and devices ???? Ethernet or Wi-Fi ???? Proprietary and Confidential 7

Hacker Scenario Possible Countermeasure Hack Scenario above: Device certificate requires authenticated information, e.g. one or more of the following: –Certificate with a bit that signals “MovieLabs” or “3 rd party” robustness compliance Service operators will be able to trust the certificate as one coming from a real device This is only supplied to manufacturer’s of devices that meet this robustness compliance. –Certificate that can be used to identify Make/Model # ???? Pirate Assumptions: (worse 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 implementing the authentication protocol is able to spoof the identity of a TV on a service provider’s white list 5)4K content is recorded to the Hard Disk Drive, and later published on the Internet Proprietary and Confidential 8

Sony Electronics Authentication Proposal Sony Electronics (UXTC group) proposes to use the DLNA CVP-2 Authentication mechanism to deliver authenticated information from the TV to the set-top box The following are key features: –Standard TLS authentication with supplemental data protocol –DTCP or X.509 client (and server TBD) certificates Bit for MovieLabs or 3 rd Party robustness compliance Possible ID that can be correlated to Manufacturer and Model # –Data payload sent by TV to set-top box (secured by private key) Possible redundant information: Manufacturer, Model # Unique MAC or serial # Possible other non-security information: screen resolution, browser support, decoder supported Authentication can be: Automatically triggered by https link to authenticating server Authentication requirement conveyed in protocolInfo Proprietary and Confidential 9

DTCP-IP (Copy No More) Conditional Access Ethernet or Wi-Fi Sony Electronics Authentication Proposal TV to/from STB: TLS with Sup Data Auth: Special DTCP cert (with bit or ID) Sony Model 4K-XYZ STB check: Is Sony Model 4K-XYZ in the White List? STB check: Is client DTCP cert in Auth Protocol same as Link Protocol? White List Manufacturer, Model # Sony 4K-XYZ 4K TV Set-top Box (STB) DTCP Revocation List Device is in list OK √ Link Device same as Auth Device OK √ TLS with Sup Data Auth: Sony Model 4K-XYZ, DTCP cert Verification Procedure Note: Instead of white list, a Manufacturer and Model # “black list” might be used Proprietary and Confidential 10

TLS with Supplemental Data with White List Expanded Description Clients and servers announce support for the TLS supplemental data messaging extension through TLS clientHello and serverHello messages (RFC 5878) – Server sends a supplementalData message that is DTCP signed and includes –a random number (nonce1) –The server’s DTCP Cert (assumed to be present, but not necessary) –The server’s X.509 Cert (which can be self-signed if DTCP cert used) Client confirms the signature validates using DTCP Cert’s public key –Client knows it is talking to bona fide server Client sends a supplementalData message that is DTCP signed and includes the –original random number (nonce1) –The client’s DTCP Cert (with conformance bit set and/or Make/Model #) –Explicit Manufacturer, Model # and other data Server then verifies –Client DTCP cert is not revoked –The DTCP Cert contains the “conformance bit” (and Manufacturer/Model # if used) –The manufacturer/model # is in the white list –The signature validates DTCP Cert’s public key –The DTCP cert used with authentication is also the same one used for link protection Sequence repeats inside TLS Tunnel –Thus prevents a main-in-the-middle attack Proprietary and Confidential 11

TLS Authentication with Double Handshake and DTCP signed Supplemental Data AuthClient AuthServer TLS extended Hello messages ServerSuppData= nonce1+X.509+serverDTCPCert + DTCP Sig ClientSuppData=nonce1+clientDTCPCert+Make+Model+DTCPSig TLS Tunnel established verifyServerCert/Signature Verify nonce1, signature and Make Model against whitelist Verification Failed: Error Msg TLS Messages Cert. SKE, CR, SHD Verification Passed UI Client TLS Renegotiate (prevent Man-in-the-Middle attack) ServerSuppData=nonce2+X.509+serverDTCPCert+DTCPSig verifyServerCert/Signature Verification Failed: Error Msg Verification Passed ClientSuppData=nonce2+clientDTCPCert+Make+Model+DTCSig Verify nonce2, signature and MAC Address against white list Initiate Authentication Req: Connect using TLS Authentication success DTCP Lib Secure Network Transactions Proprietary and Confidential 12

TLS Auth with Supplemental Data and White List Pro: Each service provider could administer their own white list White list criteria could vary between service providers If Make and Model # are used only with protocol (and not in certificate), then the scheme is very flexible Con: White lists need to be managed. They weren’t before. DTLA may need to modify their adopter’s agreement to encompass general authentication techniques using the DTCP key information. Is a bit needed in the DTCP certificate? More types of certificates … more special handling. Bit means conformance to what ever criteria the service operators wish it to be. For example, it could signify: –Allowed for 4K content –Higher level of robustness (for example, to MovieLabs specification) –Compliance rules verified by 3 rd Party (tbd) 13 Proprietary and Confidential

Closing the Loop on SPE’s Concerns The DTCP compliance and robustness rules allow for implementations that are not up to the MovieLabs specifications. − As proposed in this presentation, using secure device information, a white list will allow service operator discretion in enabling devices on a case-by-case basis. There is no third party certification or trusted implementer requirement. − In order to get a bit in the certificate (and placed on the white list), service operator can request that a 3rd party review the implementation DTCP’s revocation is inadequate on many levels. − Can you elaborate? The revocation list can be quite large now, bytes. The service operator can ensure that the list is up-to-date and distributed to clients. DTCP allows for outputs that are not secure enough – e.g. HDCP 1.4. − The set-top box, under the control of a service operator, could perform selectable output control. Devices such as TVs are limited on the type of outputs that they have. Most of the interfaces are inputs. The DTCP protocol itself may not be secure enough. − Although designed years ago, DTCP is still state of the art. Is there any evidence as to any weakness in the protocol? 14 Proprietary and Confidential