UXTC - Technical Planning Group
Sony Electronics
8/10/2014
4K Network Security Proposal
Discussion with Studios
1
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
Authentication
Authentication Summary
Authentication 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 Version
1122334455, SW Version
2122232425, SW Version
Sony 4K TV
DirecTV Set-top
Box
DTCP 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
5
SEL-UXTC
DTCP-IP (Copy Never) 0102030405, SW version1122334455, 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
Version
1
2
Step Step
This is a new protocol – a version is being standardized for the DLNA
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. CommonCertificates 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.Authentication Phase-in
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 Timeline
Launch 3Q 2015 3Q 2016 3Q 2017
Current White List
- UPnP based
- Confirms TV is DIRECTV Ready & RVU Certified Authenticated WL
- “One step”
- Checks for valid DTCP Cert ID
Authenticated WL
- “Two step”
- Checks for valid DTCP Cert ID and Supp. Data
Sunset of support for AWL Phase 1
No change to TV
- Sony provides DIRECTV its DTCP Cert ID ranges For example:
Inserts Unique DTCP Certs at manufacture
Genie HR44
TV adds Authentication - “Two step” protocol
Renew SW & update DTCP Certs as needed to remain on AWL
No change to TV - LG provides current & next Common Cert IDs For example :
Inserts Common DTCP Certs at manufacture
TV adds Authentication
- “Two step” protocol Update Common Cert ID
Renew SW as needed & update DTCP Certs annually to remain on AWL
No change to TV
- Samsung provides Cert IDs (either ranges for Unique, or current & next for Common) For example :
Inserts NO DTCP Certs at manufacture
TV adds Authentication
- “Two step” protocol Update Cert ID, if common type
Renew SW as needed
& update DTCP Certs
annually (if
common) to remain on AWL
Conditional Access
Ethernet or Wi-Fi
Authentication Protocol – Phase-in - Proposal
DirecTV Authenticated White List (SRM Format) 0102030405 1122334455 2122232425
Sony 4K TV
DirecTV
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 certificate 2) Set-top box checks for Device ID in the DTCP Revocation List
3) 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
10
SEL-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”
1
Compliance and Robustness Rules
11
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, HDCProbustness 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 andcryptography – 160-bit elliptic curve. Old and new DTCP certificates will work together which addresses a serious legacy issue.
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 securedevices, and therefore does not represent a security risk.
Robustness and Compliance Certification
Program
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:
o + Invasive disclosure of design information
o + Time consuming and requiring personnel to address each issue o + 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.
BACK-UP SLIDES
Hacker Scenario 1
????
Pirate Assumptions: (Compliance Rule)
1) The software of a certain TV does not properly handle UHD content2) 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
17
Hacker Scenario 2
????
Pirate Assumptions:
1) Through great effort and reverse engineering, the certificate and public/private key of a certain TV is obtained2) 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
18
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 correctly2) 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
19
Client authentication against X.509 only
server
Opera
Dewey
CVP-2
App
CVP-2 ServerTLS extended Hello messages Connect
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 Certificate
nonce1 : reference number (eg counter or random)
Verify signature
Client authentication against a DTCP based server
and untrusted X.509
Opera
Dewey
CVP-2
App
CVP-2 ServerTLS extended Hello messages Connect
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 Certificate c_DTCP Cert : Client DTCP Certificate
nonce1 : 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
Certificate
Type Format Dev Gen Reserved (zero) C2 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 List
Scenario 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.
Baseline Device Certificate Format
DTCP Certificate
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 DTLA
EC-DSA public key (320 bits) – Public Key of the device
EC-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
System Renewability Message
Structure of the First Generation System Renewability Message
Format of the CRL Entry Type Block
26
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).
System Renewability Message
Example CRL
