1

UXTC - Technical Planning GroupSony Electronics

8/10/2014

4K Network Security ProposalDiscussion with Studios

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 SummaryAuthentication Key Points:• 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.

Conditional Access

Ethernet or Wi-Fi

Authentication Protocol Proposal “ Two Step”

DirecTV White List

(e.g. new format)

0102030405, SW Version1122334455, SW Version2122232425, SW Version

Sony 4K TVDirecTV Set-top BoxDTCP Revocation List

(SRM Format) DTCP Revocation List

(SRM Format)

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

5SEL-UXTC

DTCP-IP (Copy Never)

0102030405, SW version

1122334455, SW version

2122232425, SW version

Manufacturers supply service provider with list of conforming Device IDs (from DTCP certificates). Service provider must integrated them into a sequential list.

DTCP Authenticate Key Exchange (AKE) (Cert Device ID: 0102030405)

TLS with Supp Data Authentication (Cert Device ID: 0102030405) +

Make/Model #/Serial #/MAC/SW Version1

2

Step

Step

This is a new protocol – a version is being standardized

for the DLNA CVP2 Project

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

DIRECTV Proprietary 9

DIRECTV Proposed AWL Implementation TimelineLaunch 3Q

20153Q

20163Q

2017

Current White List- UPnP based- Confirms TV is

DIRECTV Ready & RVU Certified

Authenticated WL- “One step”- Checks for valid

DTCP Cert IDAuthenticated WL- “Two step”- Checks for valid DTCP

Cert ID and Supp. Data

Sunset of supportfor AWL Phase 1

No change to TV- Sony provides DIRECTV its DTCP Cert ID ranges

For example:Inserts Unique DTCP Certs atmanufacture

Genie HR44

TV adds Authentication- “Two step” protocol

Renew SW & updateDTCP Certs as neededto remain on AWL

No change to TV- LG provides current & next Common Cert IDs

For example :Inserts CommonDTCP Certs atmanufacture

TV adds Authentication- “Two step” protocolUpdate Common Cert ID

Renew SW as needed& update DTCP Certsannually to remain on AWL

No change to TV- Samsung provides Cert IDs(either ranges for Unique, or current & next for Common)

For example : Inserts NODTCP Certs atmanufacture

TV adds Authentication- “Two step” protocolUpdate Cert ID, if common type

Renew SW as needed& update DTCP Certsannually (if common) to remain on AWL

Launch 3Q 2015

3Q 2016

3Q 2017

Conditional Access

Ethernet or Wi-Fi

Authentication Protocol – Phase-in - Proposal

DirecTV Authenticated White List

(SRM Format)

010203040511223344552122232425

Sony 4K TVDirecTV

Set-top Box (STB)DTCP Revocation List

(SRM Format) DTCP Revocation List

(SRM Format)

DTCP Authenticate Key Exchange (AKE) (Cert Device ID: 0102030405)

1) Device ID is obtained from the existing Low Level DTCP AKE as part of the client certificate2) Set-top box checks for Device ID in the DTCP Revocation List3) 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

Proprietary and Confidential 10SEL-UXTC

DTCP-IP (Copy No More or Copy Never)

0102030405

1122334455

2122232425

Manufacturers supply service provider with list of conforming Device IDs (from DTCP certificates). Service provider must integrate them into a sequential list.

Simple Device ID Check or “One Step”

1Step

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 side-by-side with the DTCP robustness rules.

• HDCP 2.2 robustness is detailed the HDCP 2.0 Addendum: http://www.digital-cp.com/files/static_page_files/62BFCBA3-1A4B-B294-D09C885021187455/HDCP%202%200%20Addendum_Clean_FINAL2_04_30_11_ver2.pdf

• 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 contento 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 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:

+ Invasive disclosure of design information+ Time consuming and requiring personnel to address each issue+ Potentially causing a delay in product launch schedules

o 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 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.

o 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

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

Proprietary and Confidential 17SEL-UXTC

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

Proprietary and Confidential 18SEL-UXTC

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

Proprietary and Confidential 19SEL-UXTC

Client authentication against X.509 only server

OperaDewey CVP-2 App CVP-2 Server

TLS extended Hello messagesConnect using TLS

SupplementalData message includes nonce1

Provide 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

c_DTCP Cert : Client DTCP Certificatenonce1 : reference number (eg counter or random)

Verify signature

Client authentication against a DTCP based server and untrusted X.509

OperaDewey CVP-2 App CVP-2 Server

TLS extended Hello messagesConnect using TLS

SupplementalData message includes nonce1+s_DTCP Cert + X.509 Cert+ DTCP Sig

SD=nonce1+s_DTCP Cert + X.509 Cert+ DTCP Sig

result = (nonce1+DTCP Cert+spSignature)

SupplementalData message includes result

TLS Tunnel established

verifyDTCPSignature(SD, sig) returns boolean

verifyDTCPRemoteCert(s_DTCP_Cert) returns boolean

GetlocalDTCPCert() returns c_DTCPCert

SignDataDTCP (nonce1 + c_DTCP Cert) returns pSignature

s_DTCP Cert : Server DTCP Certificatec_DTCP Cert : Client DTCP Certificatenonce1 : reference number (eg counter or random)

Verify signature

Optional Method if we support server authentication

New DTCP Cert format

31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0

CertificateType 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

Possible Elements in White ListScenario 1:

(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

Baseline Device Certificate Format

DTCP Certificate

25

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 DTLAEC-DSA public key (320 bits) – Public Key of the deviceEC-DSA signature (320 bits). Signature from the DTLA Certificate Authority of the components listed above

The overall size of a Baseline Format device certificate is 88 bytes

Inside the DTCP Certificate

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