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

1

DTCP+

For discussion with 3S April 14, 2010

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

• n these meetings
• We intend to share this draft with you in the near

future, and hope we can reach agreement on the proposals

2

3

Three Elements of DTCP+

• New “media agnostic” way to carry Content

Management Information (CMI)

• New Copy Count CMI
• New Remote Access capability

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

Length CMI Field CMI ID=0 CMI ID=1 Length Body Body CMI ID=2 Length

CMI Descriptor 0 CMI Descriptor 1 CMI 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

8

CMI PCP2 CMI PCP2 CMI PCP2

Source Sink

CMI PCP2 PCP2 CMI PCP2 PCP2

Example 1 Example 2 1 2 3 4 5 6

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

9

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.

Copy Count Content Transport

• DTCP must ensure that a single sink device

receives content marked with Copy Count.

• Session Exchange Key (Ks)

– Session Exchange Key (Ks) 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.

• Simple transport of CC marked content from one content

AV server to another.

11

Sink Source Sink CC(4) NMC Source CC(5) Before After Sink Source Sink CC(5) Source CC(5) Before After

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

12

Sink 1 Source Sink 2 CC(5) Sink 1 Source Sink 2 CC(3) CC(1) CC(1) Before Transmission Sink 1 Source Sink 2 CC(3) NMC NMC After

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)

– Example 2, CC(5) where

• sink 1 receives CC(3)
• sink 2 receives CC(2)

13

Sink 1 Source Sink 2 CC(3) CC(2) Sink Source Sink NMC CC(2) No content No content After Transport After Transport

14

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

15

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

16

Remote Access Basic Rules

• Local access and remote access may be

performed simultaneously

Source Sink

17

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

18

Remote Access Basic Rules

• However, no further simultaneous remote

connections from local or remote sinks are allowed (no “daisy chaining”)

RA RA Source Sink RA RA RA

19

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.

Source Sink RA Device Registry

20

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.

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
• n 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

22

RA Encoding Rule Cases

• Live Content
• DTCP Bound Recording
• Other Recorded Media
• Received from DTCP Source Function

23

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

24

Example 1 – Live Content

Home Server Remote Location

Remote Authentication

CN Stream EPN Stream, copy COG Stream, copy

25

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

26

Other Recorded Media Case

• This refers to content on removable media that

device plays back, or content that has been recorded to any media other than by the DTCP Bound Recording method

• RA is permitted in all cases for EPN and NMC

marked content, regardless of any RA indicator that may be in the content

• For content marked CN

– If RA Indicator is present and is “Yes,” then RA is permitted – If RA Indicator is present and is “No,” then RA is not permitted – If RA Indicator is NOT present, then no RA is permitted

• Note: COG is not an applicable marking.

27

Example 2 – Recorded Content

Home Server Remote Location

Remote Authentication

NMC Stream, move EPN Stream, move, copy

28

Received From DTCP Source Function

• No RA is permitted of any content during its

reception from a DTCP source function.

• This prevents daisy chaining when receiving

content from a DTCP Source function via:

– an RA connection (Remote) – a normal connection (Local)

29

DTCP+

For discussion with 3S April 14, 2010 Thank you!