UXTC - Technical Planning GroupSony Electronics

7/22/2014

4K Network Security

Addressing SPE Concerns about DTCP-IPThis 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.

SEL-UXTC 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 content4) 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

revocation5) User enjoys streaming 4K content on TV

SONY 4K TV with RVU2.0

DTCP-IP (Copy No More)

NDSConditional

Access

Uplink 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 3SEL-UXTC

Sony TV SecuritySony 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 4SEL-UXTC

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 5SEL-UXTC

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

Cable Headend System

Service Providers

Proprietary and Confidential 6SEL-UXTC

Primary Issue – What Client is trying to Connect?

UplinkSet-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 7SEL-UXTC

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 “3rd 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 8SEL-UXTC

Sony Electronics Authentication ProposalSony 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 3rd 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 9SEL-UXTC

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 TVSet-top Box (STB) DTCP

Revocation ListDTCP

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 10SEL-UXTC

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)

– http://tools.ietf.org/html/rfc5878

• 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 11SEL-UXTC

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 againstwhitelist

Verification Failed: Error MsgTLS Messages Cert. SKE, CR, SHD

Verification Passed

UI Client

TLS Renegotiate (prevent Man-in-the-Middle attack)

ServerSuppData=nonce2+X.509+serverDTCPCert+DTCPSigverifyServerCert/SignatureVerification Failed: Error Msg

Verification PassedClientSuppData=nonce2+clientDTCPCert+Make+Model+DTCSig

Verify nonce2, signature and MAC Address againstwhite list

Initiate Authentication Req: Connect using TLS

Authentication success

DTCP Lib

Secure Network Transactions

Proprietary and Confidential 12SEL-UXTC

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 3rd Party (tbd)

13Proprietary and ConfidentialSEL-UXTC

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, 65536 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?

14Proprietary and ConfidentialSEL-UXTC