Download DIRECTV_4K_Network_Security_07-22-14

4K Network Security
UXTC - Technical Planning Group
Sony Electronics
7/22/2014
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
NDS
Conditional
Access
Home Network
DTCP-IP
(Copy No More)
Ethernet or Wi-Fi
Uplink
DTCP
Revocation List
DirecTV
Set-top Box (STB)
DTCP
Revocation List
SONY 4K TV
with RVU2.0
1) User has RVU2.0 service on Sony 4K BRAVIA TV 6) TV receives and renders 4K
• RVU is a native application
content
2) User has subscription to super-premium 4K
• TV is DTCP sink device
service
• TV cannot retransmit or
3) From the RUI, user selects 4K content
record
4) DirecTV set-top box tunes the 4K program, sets• No HDMI output from TV
up a DTCP-IP connection with TV
• No means to externally
• TV DTCP certificate is checked for revocation
access compressed or
• STB DTCP certificate is checked for
decoded content
revocation
• Ethernet and USB interfaces
5) User enjoys streaming 4K content on TV
are disabled for A/V output
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
In the future, 4K content will stream from many different sources (and not
just DirecTV or Comcast)
Service Providers
DirecTV
EchoStar
TV Manufacturer
Comcast
Cable
Cable
Headend
Headend
System
System
…
Time Warner
Cable Operator
Roaming/Mobile
Proprietary and Confidential
6
Primary Issue – What Client is trying to Connect?
????
????
Ethernet or Wi-Fi
Uplink
•
•
•
????
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
Proprietary and Confidential
7
Hacker Scenario
????
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
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 #
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 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
9
Sony Electronics Authentication Proposal
Verification Procedure
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?
White List
Manufacturer, Model #
Sony 4K-XYZ
Device is in list
OK
√
STB check: Is client DTCP cert in Auth Protocol same as Link Protocol?
Link Device same as Auth Device
OK
√
TLS with Sup Data Auth:
Sony Model 4K-XYZ, DTCP cert
Conditional
Access
DTCP-IP
(Copy No More)
Ethernet or Wi-Fi
DTCP
Revocation List
Set-top Box (STB)
DTCP
Revocation List
4K TV
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
–
–
–
•
Client knows it is talking to bona fide server
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
–
–
–
–
–
•
(assumed to be present, but not necessary)
(which can be self-signed if DTCP cert used)
Client sends a supplementalData message that is DTCP signed and includes the
–
–
–
•
a random number (nonce1)
The server’s DTCP Cert
The server’s X.509 Cert
Client confirms the signature validates using DTCP Cert’s public key
–
•
http://tools.ietf.org/html/rfc5878
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
DTCP Lib
UI Client
AuthClient
Initiate Authentication Req: Connect using TLS
AuthServer
TLS extended Hello messages
ServerSuppData= nonce1+X.509+serverDTCPCert + DTCP Sig
verifyServerCert/Signature
Verification Failed: Error Msg
TLS Messages Cert. SKE, CR, SHD
Verification Passed
Verify nonce1,
ClientSuppData=nonce1+clientDTCPCert+Make+Model+DTCPSig signature and
Make Model
against
TLS Tunnel established
whitelist
TLS Renegotiate (prevent Man-in-the-Middle attack)
ServerSuppData=nonce2+X.509+serverDTCPCert+DTCPSig
Verification Failed: Error Msg verifyServerCert/Signature
Verification Passed
Authentication success
Secure Network Transactions
Verify nonce2,
ClientSuppData=nonce2+clientDTCPCert+Make+Model+DTCSig signature and
MAC Address
against
white list
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 3rd Party (tbd)
Proprietary and Confidential
13
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?
Proprietary and Confidential
14