Purpose Our intent is to discuss proposed new capabilities of DTCP - PowerPoint PPT Presentation

DTCP+ For discussion with 3S April 14, 2010 1

Purpose • Our intent is to discuss proposed new capabilities of DTCP which have been referred to as DTCP+ • We have had two previous reviews and have prepared a near-final draft specification based on these meetings • We intend to share this draft with you in the near future, and hope we can reach agreement on the proposals 2

Three Elements of DTCP+ • New “media agnostic” way to carry Content Management Information (CMI) • New Copy Count CMI • New Remote Access capability 3

CMI Carriage Requirement • Background – CMI is term used for the set of DTCP Content Management Information such as CCI, AST, DOT, APS, etc. – Currently DTCP has a Descriptor for MPEG-TS only – For DTCP-IP there is an optional media agnostic Protected Content Packet-Usage Rule (PCP-UR) • PCP-UR is not extensible and only 8 bits remain • Requirement – There are many new media formats without CMI carriage support – To carry CMI for existing and new media formats, DTLA is creating an extensible media agnostic carriage of CMI 4

CMI Carriage General • The CMI carriage capability is available to all DTCP transports but its use is optional – DTCP-IP was primary target but DTLA TWG was able to make it available to all DTCP transports • CMI Field is cryptographically linked to transmitted content to prevent spoofing 5

CMI Carriage Format • Source devices will compose and transmit along with associated content a CMI Field • The CMI Field consists of one or more CMI descriptors. Each CMI descriptor has an identifying number. • Sink device will use one of the CMI Descriptors which the sink device supports CMI ID=0 CMI Descriptor 0 Body CMI ID=1 Length Length CMI Descriptor 1 Body CMI Field CMI ID=2 CMI Length Descriptor 2 Body 6

CMI Descriptors • Currently three CMI Descriptors are defined. • CMI Descriptor 0 – Mandatory for both Source and Sink. – This mode will be used if Source and Sink cannot communicate in CMI Descriptor 1 or 2 mode. – Sink displays content or makes further output by DTCP (i.e., perform bridge function). This mode won’t be used in most cases because all transmissions are expected to be made in either CMI Descriptor 1 or 2. • CMI Descriptor 1 – Mandatory for Sinks that support CMI, and optional to Source (we expect nearly all Sources adopting CMI will support this mode). – Contains : Retention_Move_mode, Retention_state, EPN, CCI, AST, ICT, APS, DOT, Copy Count • CMI Descriptor 2 – Optional for both Source and Sink. – Permits only MPEG-TS transport using DTCP_Descriptor. – Contains: Copy Count only. For other CCIs, use DTCP_Descriptor. 7

DTCP-IP CMI Usage • In case of DTCP-IP, CMI is transmitted as CMI Packet while content is encapsulated as PCP2 (Protected Content Packet version 2). • Sink devices shall apply the usage rule indicated by the most recently received CMI packet to the following PCP2 until they receive the next CMI packet. • Content is cryptographically bound with CMI. Thus if CMI is changed during transmission, sink devices CANNOT get the correct key to decrypt the content. Example 1 CMI PCP2 PCP2 PCP2 CMI PCP2 1 2 3 4 5 6 CMI PCP2 CMI PCP2 CMI PCP2 Example 2 Source Sink 8

Copy Count (CC) • Requirement – Enable DTCP to correctly carry and manage content that has been encoded with a Copy Count. • Definition of CC(X) – When a copy is made from content marked with Copy Count (CC) the count is decremented by 1 and the copy is remarked as NMC. – Examples: • CC(3) = 3 copies permitted • Start CC(3): make copy; End: CC(2) and NMC • Start CC(1): make copy; End: NMC only • Will likely require both Source and Sink compliance rules. 9

Copy Count Content Transport • DTCP must ensure that a single sink device receives content marked with Copy Count. • Session Exchange Key ( K s ) – Session Exchange Key ( K s ) is used for establishing a unique pair of devices between a source device and a sink device. – Source devices must ensure that the Session Exchange Key used for each authenticated sink device is unique. 10

CC Transport Examples (1) • Given CC(5) a single copy is made and transported to a connected sink. – Copy is marked as No-More-Copies (NMC) – Source decrements CC count by one. Before CC(5) Source Sink After NMC CC(4) Source Sink • Simple transport of CC marked content from one content AV server to another. Before CC(5) Source Sink After CC(5) Source Sink 11

CC Transport Examples (2) • Given CC(5) the source has been requested by consumer to make a copy and send it to two different devices – Each copy is remarked as NMC – The Source decrements the CC by two Before Sink 1 CC(5) Source Sink 2 Transmission Sink 1 CC(1) CC(3) Source Sink 2 CC(1) After Sink 1 NMC CC(3) Source Sink 2 NMC 12

CC Transport Examples (3) • Permit DTCP source functions to manipulate CC marked content and split it between sinks at consumer request via a move function – Example 1, CC(3) where • Sink 1 receives NMC • Sink 2 receives CC(2) After Transport NMC Sink 1 No content Source Sink 2 – Example 2, CC(5) where CC(2) • sink 1 receives CC(3) • sink 2 receives CC(2) After Transport CC(3) Sink No content Source Sink CC(2) 13

Remote Access (RA) • Note: We previously reviewed these slides with you. The few text additions made in response to your comments are highlighted – Basic Rules – Remote Connection AKE – RA Encoding Rules 14

Remote Access Basic Rules • Source devices may permit remote access to content by 1 and only 1 sink device at any one time. Source Sink 15

Remote Access Basic Rules • Local access and remote access may be performed simultaneously Source Sink 16

Remote Access Basic Rules • A product that is actively remotely connected can be a source to other sinks on home/personal network in the remote location … Source Sink 17

Remote Access Basic Rules RA RA RA RA RA • However, no further simultaneous remote connections from local or remote sinks are allowed (no “ daisy chaining ” ) Source Sink 18

Remote Access Basic Rules • Source devices may add a sink device to their remote sink registry using “ local remote registration ” – Source devices perform DTCP authentication and register sink devices locally, before the sink may gain remote access. RA Device Registry Source Sink 19

Remote Access Basic Rules • “ Local remote sink registration ” process includes – Successful local authentication of device with source – Passing current additional localization checks (RTT, TTL) – Remote sink registry is limited to 32 devices. Consumer can remove any devices from the list but additions are permitted only if the connected device successfully concludes the remote sink registration process. 20

Remote Access • Source device will check to see if the sink device requesting remote access is on its remote sink registry – Remote access is rejected/aborted; • If there is already a sink device with remote access connected • If the sink device requesting remote access device ID is not on the source device’s remote sink registry – A unique remote access exchange key (Kr) is generated for each individual remote access connection – Remote Access AKE does not include localization checks since the remote device has already passed the “Local remote sink registration” 21

RA Encoding Rule Cases • Live Content • DTCP Bound Recording • Other Recorded Media • Received from DTCP Source Function 22

Live Content Case For live content directly received by DTCP source: • RA is permitted in all cases for EPN marked content, regardless of any RA indicator that may be in the content • For CN and COG content, there may be an RA indicator in the live stream (upstream of DTCP source function) – If RA Indicator is present and is “Yes” then • RA is permitted for CN or COG – If RA Indicator is present and is “No” then • RA is not permitted for CN or COG – If RA Indicator is NOT present then • RA is NOT permitted for CN • RA is permitted for COG • Where a regulation of a government or quasi-governmental body is inconsistent with the above rules for CN or COG content, the regulation will apply for any DTCP Licensed Products made for sale in the jurisdiction subject to the regulation • Note: NMC is not an applicable marking for this situation 23

Example 1 – Live Content Remote Authentication CN Stream COG Stream, copy EPN Stream, copy Home Server Remote Location 24

DTCP Bound Recording Case • This refers to content that has been copied by a Bound Recording method by a DTCP Sink Device and has been marked NMC or EPN – NMC or EPN marked content can be remotely accessible • Note: – CN and COG are not applicable marking for Bound Recordings – RA indicator is not carried forward – DTLA will adopt “anti-schmuck” language to prohibit RA where a live transmission marked COG is “copied” to an HDD (and, hence, is remarked NMC) and is then simultaneously sent for RA from the “copy” on the HDD, effectively overriding the live transmission rules 25