Digital Transmission Content Protection Specification Revision 1.

51 (Informational Version)
2007-10-01 (Informational Version) Page 1




Digital Transmission Content
Protection Specification
Volume 1
(Informational Version)




Hitachi, Ltd.
Intel Corporation
Matsushita Electric Industrial Co., Ltd.
Sony Corporation
Toshiba Corporation



Revision 1.51
October 1, 2007




Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 2 (Informational Version) 2007-10-01
Preface
Notice
THIS DOCUMENT IS PROVIDED "AS IS" WITH NO WARRANTIES WHATSOEVER, INCLUDING ANY WARRANTY OF
MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR ANY WARRANTY
OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE. Hitachi, Intel, MEI, Sony, and
Toshiba (collectively, the 5C) disclaim all liability, including liability for infringement of any proprietary rights,
relating to use of information in this specification. No license, express or implied, by estoppel or otherwise, to
any intellectual property rights is granted herein.
Some portions of this document, identified as "Draft" are in an intermediate draft form and are subject to
change without notice. Adopters and other users of this Specification are cautioned these portions are
preliminary, and that products based on it may not be interoperable with the final version or subsequent
versions thereof.
Copyright 1997 - 2007 by Hitachi, Ltd., Intel Corporation, Matsushita Electric Industrial Co., Ltd., Sony
Corporation, and Toshiba Corporation (collectively, the 5C). Third-party brands and names are the property
of their respective owners.
Intellectual Property
Implementation of this specification requires a license from the Digital Transmission Licensing Administrator.
Contact Information
Feedback on this specification should be addressed to [email protected].
The Digital Transmission Licensing Administrator can be contacted at [email protected].
The URL for the Digital Transmission Licensing Administrator web site is: http://www.dtcp.com.



Printing History:

J uly 25, 2000
Digital Transmission Content Protection Specification Volume 1 Revision 1.1 (Informational
Version)
February 25,
2002
Digital Transmission Content Protection Specification Volume 1 Revision 1.2a (Informational
Version)
J anuary 07, 2004
Digital Transmission Content Protection Specification Volume 1 Revision 1.3 (Informational
Version)
February 28,
2005
Digital Transmission Content Protection Specification Volume 1 Revision 1.4 (Informational
Version)
J une 15, 2007
Digital Transmission Content Protection Specification Volume 1 Revision 1.5 (Informational
Version)

Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 3
Table of Contents
PREFACE 2
Notice 2
Intellectual Property 2
Contact Information 2
CHAPTER 1 INTRODUCTION 11
1.1 Purpose and Scope 11
1.2 Overview 11
1.3 References 13
1.4 Organization of this Document 13
1.5 State Machine Notation 14
1.6 Notation 16
1.7 Numerical Values 16
1.8 Byte Bit Ordering 16
1.9 Packet Format 17
1.10 Treatment of Optional Portions of the Specification 17
CHAPTER 2 ABBREVIATIONS 18
2.1 Alphabetical List of Abbreviations and Acronyms 18
CHAPTER 3 THE DIGITAL TRANSMISSION CONTENT PROTECTION SYSTEM 20
3.1 Content Source Device 20
3.2 Content Sink Device 21
CHAPTER 4 FULL AUTHENTICATION 23
4.1 Introduction 23
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 4 (Informational Version) 2007-10-01
4.2 Notation 23
4.2.1 Defined by the DTLA 23
4.2.1.1 General 23
4.2.1.2 For Device X 23
4.2.2 Notation used during Full Authentication 24
4.2.3 Device Certificate Formats 24
4.2.3.1 Baseline Format 25
4.2.3.2 Extended Format Fields (Optional Components of the Device Certificate) 26
4.3 Manufacture of Compliant Devices 26
4.4 Cryptographic Functions 26
4.4.1 SHA-1 (Secure Hash Algorithm, revision 1) 26
4.4.2 Random Number Generator 26
4.4.3 Elliptic Curve Cryptography (ECC) 27
4.4.3.1 Elliptic Curve Digital Signature Algorithm (EC-DSA) 28
4.4.3.2 Elliptic Curve Diffie-Hellman (EC-DH) 29
4.4.3.3 Implementation of the Elliptic Curve Cryptosystem 29
4.5 Protocol Flow 30
4.5.1 Protocol Flow Overview 30
CHAPTER 5 RESTRICTED AUTHENTICATION 31
5.1 Introduction 31
5.2 Notation 31
5.2.1 Defined by the DTLA 31
5.2.1.1 General 31
5.2.1.2 For Device X 32
5.2.2 Notation used during Restricted Authentication 32
5.2.3 Device Certificate Format 33
5.2.4 Random Number Generator 33
5.3 Protocol Flow 35
5.3.1 Protocol Flow Overview 35
CHAPTER 6 CONTENT CHANNEL MANAGEMENT AND PROTECTION 36
6.1 Introduction 36
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 5
6.2 Content Management Keys 36
6.2.1 Exchange Keys (K
X
) 36
6.2.2 Content Key (K
C
) 36
6.2.2.1 K
C
For M6 36
6.2.2.1.1 M6 Related Key and Constant Sizes 37
6.2.2.2 K
C
for AES-128 37
6.2.2.2.1 AES-128 Related Key and Constant Sizes 37
6.3 Protocol Flow 38
6.3.1 Establishing Exchange Key 38
6.3.2 Establishing Content Keys 39
6.3.3 Odd/Even Bit 40
6.4 Copy Control Information (CCI) 40
6.4.1 Embedded CCI 40
6.4.1.1 DTCP_Descriptor for MPEG-TS 40
6.4.2 Encryption Mode Indicator (EMI) 41
6.4.3 Relationship between Embedded CCI and EMI 42
6.4.4 Treatment of EMI/Embedded CCI for Audiovisual Device Functions 43
6.4.4.1 Format-cognizant source function 43
6.4.4.2 Format-non-cognizant source function 43
6.4.4.3 Format-cognizant recording function 44
6.4.4.4 Format-cognizant sink function 44
6.4.4.5 Format-non-cognizant recording function 45
6.4.4.6 Format-non-cognizant sink function 45
6.4.5 Treatment of EMI/Embedded CCI Audio Device Functions 45
6.4.5.1 Embedded CCI for audio transmission 45
6.4.5.2 Relationship between Embedded CCI and EMI 45
6.4.5.3 Audio-Format-cognizant source function 46
6.4.5.4 Audio-Format-non-cognizant source function 46
6.4.5.5 Audio-Format-cognizant recording function 46
6.4.5.6 Audio-Format-cognizant sink function 47
6.4.5.7 Audio-Format-non-cognizant recording function 47
6.4.5.8 Audio-Format-non-cognizant sink function 47
6.5 Common Device Categories 47
6.6 Content Channel Ciphers 48
6.6.1 Baseline Cipher 48
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 6 (Informational Version) 2007-10-01
6.6.2 Optional Cipher 48
6.6.2.1 AES-128 Cipher 48
6.6.3 Content Encryption Formats 49
6.6.3.1 For M6 49
6.6.3.2 For AES-128 49
6.7 Additional Functions 50
6.7.1 Move Function 50
6.7.2 Retention Function 50
CHAPTER 7 SYSTEM RENEWABILITY 51
7.1 Introduction 51
7.1.1 SRM Message Components and Layout 51
7.1.1.1 Certificate Revocation List (CRL) 52
7.1.1.2 DTLA EC-DSA Signature 52
7.1.2 SRM Scalability 52
7.2 Updating SRMs 54
7.2.1 Device-to-Device Update and State Machines 54
7.2.1.1 Updating a Devices SRM from Another Compliant Device 54
CHAPTER 8 AV/C DIGITAL INTERFACE COMMAND SET EXTENSIONS 55
8.1 Introduction 55
8.2 SECURITY command 55
8.3 AKE command 55
8.3.1 AKE control command 56
8.3.2 AKE status command 58
8.3.3 AKE_ID dependent field (AKE_ID = 0) 60
8.4 Bus Reset Behavior 62
8.5 Action when Unauthorized Device is Detected During Authentication 62
8.6 Authentication AV/C Command Flows 63
8.6.1 Figure Notation 63
8.6.2 Full Authentication Command Flow 63
8.6.3 Enhanced Restricted / Restricted Authentication Command Flow 64
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 7
APPENDIX A ADDITIONAL RULES FOR AUDIO APPLICATIONS 65
A.1 AM824 Audio 65
A.1.1 Type 1: IEC 60958 Conformant Audio 65
A.1.1.1 Definition 65
A.1.1.2 Relationship between ASE-CCI and Embedded CCI 65
A.1.1.3 Usage of Mode A (EMI=11) 65
A.1.2 Type 2: DVD-Audio 65
A.1.2.1 Definition 65
A.1.2.2 Relationship between ASE-CCI and Embedded CCI 66
A.1.2.3 Usage of Mode A (EMI=11) 66
A.1.2.4 Additional rules for recording 66
A.1.3 Type 3: Super Audio CD 66
A.1.3.1 Definition 66
A.1.3.2 Relationship between ASE-CCI and Embedded CCI 67
A.1.3.3 Usage of Mode A (EMI=11) 67
A.2 MPEG Audio 67
APPENDIX B DTCP_DESCRIPTOR FOR MPEG TRANSPORT STREAMS 68
B.1 DTCP_descriptor 68
B.2 DTCP_descriptor syntax 68
B.2.1 private_data_byte Definitions: 69
B.3 Rules for the Usage of the DTCP_descriptor 71
B.3.1 Transmission of a partial MPEG TS 71
B.3.2 Transmission of a full MPEG TS 71
B.3.3 Treatment of the DTCP_descriptor by the sink device 71
APPENDIX C LIMITATION OF THE NUMBER OF SINK DEVICES RECEIVING A CONTENT
STREAM 72
C.1 Limitation Mechanism in Source Device 72
C.2 Limitation Mechanism in DTCP Bus Bridge Device 73
C.2.1 DTCP Bus Bridge Device Source Function 73
C.2.2 DTCP Bus Bridge Device Sink Function 74
C.2.3 Extra Key handling 74
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 8 (Informational Version) 2007-10-01
C.2.4 Implementation of DTCP bus bridge 75
C.2.4.1 Implementation of DTCP bus bridge device without Key Counter 75
C.2.4.2 Implementation of DTCP bus bridge device with Key Counter 76
C.2.5 Additional device certificate in a DTCP bus bridge device 77
C.2.6 Treatment of additional function in a DTCP bus bridge device 77
APPENDIX D DTCP ASYNCHRONOUS CONNECTION 79
D.1 Purpose and Scope 79
D.2 Transmission of Protected Frame 79
D.2.1 Overview 79
D.2.2 Protected Content Packet 79
D.2.3 Construction of Protected Frame 81
D.2.4 N
C
Update Process 81
D.2.5 Duration of Exchange Keys 82
D.2.6 Frame Transfer type 82
D.2.6.1 File-type Transfer 82
D.2.6.2 Stream-type Transfer 82
D.3 Embedded CCI 82
D.4 AKE Command Extensions 82

Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 9
Figures
Figure 1 Content Protection Overview 12
Figure 2 State Machine Example 14
Figure 3 8 Bit diagrams 16
Figure 4 Packet Format 17
Figure 5 Content Source Device State Machine 20
Figure 6 Content Sink Device State Machine 21
Figure 7 Baseline Device Certificate Format 25
Figure 8 Extended Device Certificate Fields 26
Figure 9 Full Authentication Protocol Flow Overview 30
Figure 10 Restricted Authentication Device Certificate Format 33
Figure 11 Key Selection Vector 33
Figure 12 Restricted Authentication Protocol Flow Overview 35
Figure 13 Content Channel Establishment and Management Protocol Flow Overview 39
Figure 14 Odd/Even Bit Location in the Packet Header 40
Figure 15 EMI Location 41
Figure 16 Structure of the First Generation System Renewability Message 51
Figure 17 SRM Extensibility 53
Figure 18 Security command 55
Figure 19 Security command category field 55
Figure 20 AKE Control Command 56
Figure 21 AKE Control Command Status Field 57
Figure 22 AKE Control Command Status Field Test Values 57
Figure 23 AKE Status Command 58
Figure 24 AKE Status Command Status Field 59
Figure 25 AKE Status Command Status Field Test Values 59
Figure 26 AKE_ID dependent field 60
Figure 27 Full Authentication Command Flow 63
Figure 28 Enhanced Restricted/Restricted Authentication Command Flow 64
Figure 29 Sink Counter Algorithm (Informative) 73
Figure 30 DTCP bus bridge State Machine without Key Counter (Informative) 76
Figure 31 DTCP bus bridge State Machine with Key Counter (Informative) 77
Figure 32 Structure of Protected Content Packet 79
Figure 33 Structure of Data Packet 80
Figure 34 Generic Construction of Protected Content Packet in the Protected Frame 81

Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 10 (Informational Version) 2007-10-01
Tables
Table 1 Length of keys and variables generated by the device (Full Authentication) 24
Table 2 Length of Keys and Constants created by DTLA (Restricted Authentication) 32
Table 3 Length of keys and variables generated by the device (Restricted Authentication) 32
Table 4 Size of M6 Related Content Management Keys and Constants 37
Table 5 Length of Keys and Constants (Content Channel Management) 37
Table 6 EMI Encoding 42
Table 7 Relationship between EMI and Embedded CCI 42
Table 8 Format-Cognizant Source Function CCI handling 43
Table 9 Format-Non-Cognizant Source Function CCI handling 43
Table 10 Format-cognizant recording function CCI handling 44
Table 11 Format-cognizant sink function CCI handling 44
Table 12 Format-non-cognizant recording function CCI handling 45
Table 13 Embedded CCI Values 45
Table 14 Audio-Format-Congnizant Source Function CCI handling 46
Table 15 Audio-Format-cognizant recording function CCI handling 46
Table 16 Audio-format-cognizant sink function CCI handling 47
Table 17 M6 Content Encryption Formats 49
Table 18 AES-128 Content Encryption Formats 49
Table 19 DV Format Move Function Modes 50
Table 20 DV Format Retention Function Modes 50
Table 21 AKE Subfunctions 60
Table 22 AKE_procedure values 61
Table 23 Authentication selection 61
Table 24 Exchange_key values 62
Table 25 Relationships between SCMS State and Embedded CCI 65
Table 26 DVD Audio, Relationship between ASE-CCI and Embedded CCI 66
Table 27 Super Audio CD, Relationship between ASE-CCI and Embedded CCI 67
Table 28 DTCP_descriptor syntax 68
Table 29 Syntax of private_data_type for DTCP_descriptor 68
Table 30 Move Function Modes 69
Table 31 Retention Function Modes 69
Table 32 Retention States 69
Table 33 EPN 70
Table 34 DTCP_CCI 70
Table 35 Image_Constraint_Token 70
Table 36 APS 70
Table 37 Content Type 80



Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 11
Chapter 1 Introduction
1.1 Purpose and Scope
The Digital Transmission Content Protection Specification defines a cryptographic protocol for protecting
audio/video entertainment content from unauthorized copying, intercepting, and tampering as it traverses
digital transmission mechanisms such as a high-performance serial bus that conforms to the IEEE 1394-1995
standard. Only legitimate entertainment content delivered to a source device via another approved copy
protection system (such as the DVD Content Scrambling System) will be protected by this copy protection
system.
The use of this specification and access to the intellectual property and cryptographic materials required to
implement it will be the subject of a license. The Digital Transmission Licensing Administrator (DTLA) is
responsible for establishing and administering the content protection system described in this specification.
While DTCP has been designed for use by devices attached to serial buses as defined by the IEEE 1394-1995
standard, the developers anticipate that it will be appropriate for use with future extensions to this standard,
other transmission systems, and other types of content as authorized by the DTLA.
1.2 Overview
This specification addresses four layers of copy protection:
Copy control information (CCI)
Content owners need a way to specify how their content can be used (copy-one-generation, copy-never,
etc.). This content protection system is capable of securely communicating copy control information (CCI)
between devices in two ways:
The Encryption Mode Indicator (EMI) provides easily accessible yet secure transmission of CCI via the
most significant two bits of the sy field of the isochronous packet header.
CCI is embedded in the content stream (e.g. MPEG). This form of CCI is processed only by devices
which recognize the specific content format.
Device authentication and key exchange (AKE)
Before sharing valuable information, a connected device must first verify that another connected device is
authentic. To balance the protection requirements of the content industries with the real-world requirements of
PC and consumer electronics (CE) device users, this specification includes two authentication levels, Full and
Restricted.
Full Authentication can be used with all content protected by the system.
Restricted Authentication enables the protection of copy-one-generation and no-more-copies
content only. Copying devices such as digital VCRs employ this kind of authentication.
Content encryption
Devices include a channel cipher subsystem that encrypts and decrypts copyrighted content. To ensure
interoperability, all devices must support the specific cipher specified as the baseline cipher. The subsystem
can also support additional ciphers, whose use is negotiated during authentication.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 12 (Informational Version) 2007-10-01
System renewability
Devices that support Full Authentication can receive and process system renewability messages (SRMs) created
by the DTLA and distributed with content and new devices. System renewability ensures long-term integrity of
the system through the revocation of compromised devices.
Figure 1 gives an overview of content protection. In this overview, the source device has been instructed to
transmit a copy protection stream of content. In this and subsequent diagrams, a source device is one that can
send a stream of content. A sink device is one that can receive a stream of content. Multifunction devices such
as PCs and record/playback devices such as digital VCRs can be both source and sink devices.
Encrypted content
stream with EMI set
Request Authentication
Device AKE
Encrypted Content Stream
1
3
4
2
Source Device Sink Device
Request for Content
Clear Text Content
Clear Text Content
Clear Text Content

Figure 1 Content Protection Overview
1. The source device initiates the transmission of a stream of encrypted content marked with the
appropriate copy protection status (e.g., copy-one-generation, copy-never, or no-more-copies) via
the EMI bits.
1

2. Upon receiving the content stream, the sink device inspects the EMI bits to determine the copy
protection status of the content. If the content is marked copy-never, the sink device requests that
the source device initiate Full AKE. If the content is marked copy-one-generation or no-more-copies
the sink device will request Full AKE, if supported, or Restricted AKE. If the sink device has already
performed the appropriate authentication, it can immediately proceed to Step 4.
3. When the source device receives the authentication request, it proceeds with the type of authentication
requested by the sink device, unless Full AKE is requested but the source device can only support
Restricted AKE, in which case Restricted AKE is performed.
4. Once the devices have completed the required AKE procedure, a content channel encryption key can be
exchanged between them. This key is used to encrypt the content at the source device and decrypt the
content at the sink.

1
If content requested by a sink device is protected, the source device may choose to transmit an empty content streamuntil at least one
device has completed the appropriate authentication procedure required to access the content stream.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 13
1.3 References
This specification shall be used in conjunction with the following publications. When the publications are
superseded by an approved revision, the revision shall apply.
1394 Trade Association, Specification for AV/C Digital Interface Command Set General Specification Version 4.1
December 11, 2001.
1394 Trade Association Document 2001003, Audio and Music Data Transmission Protocol 2.0, August 21, 2001.
1394 Trade Association Document 2001009, AV/C Compatible Asynchronous Serial Bus Connections 2.1, July
23, 2001
1394 Trade Association Document 1999037, AV/C Command for Management of Enhanced Asynchronous Serial
Bus Connections 1.0, October 24, 2000
1394 Trade Association Document 2006020, BT.601 Transport Over IEEE-1394 1.1a, October 02, 2006
Advanced Encryption Standard (AES) FIPS 197 November 26, 2001
ATSC, A/70 Conditional Access System for Terrestrial Broadcast
Cable Television Laboratories, HDND Interface Specification Version 2.2
Digital Transmission Licensing Administrator, DIGITAL TRANSMISSION PROTECTION LICENSE AGREEMENT,
Development and Evaluation License
ETSI EN 300 468, DVB, Specification for Service Information (SI) in DVB Systems
IEC 61834 Helical-scan digital video cassette recording system using 6.35 mm magnetic tape for consumer use
(525-60, 625-50, 1125-60 and 1250-50 systems)
IEC/ISO 13818-1:2000(E) Information Technology Generic coding of moving pictures and associated audio
information Systems, Second edition, 2000-12-01
IEEE 1363-2000, IEEE Standard Specification for Public-Key Cryptography
IEEE 1394-1995, Standard for a High Performance Serial Bus
ISO/IEC 61883, Digital Interface for Consumer Audio/Video Equipment
ITU-R Rec. BO.1516 System B Transport Stream
National Institute of Standards and Technology (NIST), Secure Hash Standard (SHS), FIPS Publication 180-2
August 1, 2002
NIST Special Publication 800-38A 2001 Edition (SP800-38A), Recommendation for Block Cipher Modes of
Operation
Toshiba Corporation, Scheme for Computing Montgomery Division and Montgomery Inverse Realizing Fast
Implementation, Japanese patent application number PH10-269060
1.4 Organization of this Document
This specification is organized as follows:
Chapter 1 provides an overview of digital transmission content protection.
Chapter 2 lists the abbreviations used throughout this document.
Chapter 3 describes the operation of the overall Digital Transmission Content Protection System as a
state machine.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 14 (Informational Version) 2007-10-01
Chapter 4 addresses the particulars of the Full Authentication level of device authentication and key
exchange.
Chapter 5 addresses the particulars of the Restricted Authentication level of device authentication and
key exchange.
Chapter 6 describes the details of content channel establishment after Full or Restricted Authentication
takes place.
Chapter 7 describes the System Renewability capabilities.
Chapter 8 covers AV/C command extensions.
Appendix A Additional Rules for Audio Application Types
Appendix B DTCP_Descriptor for MPEG Transport Streams
Appendix C Limitation of the Number of Sink Devices Receiving a Content Stream
Appendix D DTCP Asynchronous Connection
Volume 1 Supplement A DTCP Mapping to USB
Volume 1 Supplement B DTCP Mapping to MOST
Volume 1 Supplement C DTCP Mapping to Bluetooth
Volume 1 Supplement D DTCP Use of IEEE1394 Similar Transports
Volume 1 Supplement E DTCP Mapping to IP
Volume 1 Supplement F DTCP 1394 Additional Localization
1.5 State Machine Notation
State machines are employed throughout this document to show various states of operation. These state
machines use the style shown in Figure 2.
condition for transition from S0 to S1
S1: State 1
actions started on entry to S1
action taken on this transition
S0: State 0
actions started on entry to S0
condition for transition from S1 to S0
action taken on this transition

Figure 2 State Machine Example
State machines make three assumptions:
Time elapses only within discrete states.
State transitions are instantaneous, so the only actions taken during a transition are setting flags and
variables and sending signals.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 15
Every time a state is entered, the actions of that state are started. A transaction that points back to the
same state will restart the actions from the beginning.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 16 (Informational Version) 2007-10-01
1.6 Notation
The following notation will be used:
[X]
msb_z
The most significant z bits of X
[X]
lsb_z
The least significant z bits of X
S
X
-1
[M] Sign M using EC-DSA with private key X
-1
(See Chapter 4)
V
X
1
[M] Verify signature of M using EC-DSA with public key X
1
(See Chapter 4)
X || Y Ordered Concatenation of X with Y.
X Y Bit-wise Exclusive-OR (XOR) of two strings X and Y.
1 MB = 1024 x 1024 Bytes
1.7 Numerical Values
Three difference representations of number are used in this specification. Decimal numbers are represented
without any special notation. Binary number are represented as a string of binary (0, 1) digits followed by a
subscript 2 (e.g., 1010
2
). Hexadecimal numbers are represented as a string of hexadecimal digits (0..9,A..F)
followed by a subscript 16 (e.g., 3C2
16
).
1.8 Byte Bit Ordering
Data is depicted from most significant to least significant when scanning document from top to bottom and left
to right.

7 6 5 4 3 2 1 0
msb (MSB)

(LSB) lsb
Figure 3 8 Bit diagrams

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
msb

lsb


Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 17
1.9 Packet Format
313029282726252423222120191817161514131211109 1 0 2 3 5 4 6 7 8
Transmitted First
Transmitted Last

Figure 4 Packet Format
1.10 Treatment of Optional Portions of the Specification
Features of this specification that are labeled as optional describe capabilities whose usage has not yet been
established by the 5C.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 18 (Informational Version) 2007-10-01
Chapter 2 Abbreviations
This chapter lists abbreviations and acronyms used throughout this document.
2.1 Alphabetical List of Abbreviations and Acronyms
Advanced Encryption Standard (AES)
Advanced Television Systems Committee (ATSC)
Analog Protection System (APS)
Application Specific Embedded Copy Control Information (ASE-CCI)
Asynchronous Connection (AC)
Audio Video Control (AV/C)
Authentication and Key Exchange (AKE)
Automatic Gain Control (AGC)


Certificate Revocation List (CRL)
Copy Control Information (CCI)
Copy Generation Management System (CGMS)
Common Isochronous Packet (CIP)
Consumer Electronics (CE)
Converted Cipher-Block-Chaining (C-CBC)
Cyclic Redundancy Check (CRC)

Data Encryption Standard (DES)
Data Packet (DP)
Diffie-Hellman (DH)
Digital Signature Algorithm (DSA)
Digital Signature Standard (DSS)
Digital Transmission Content Protection (DTCP)
Digital Transmission Licensing Administrator (DTLA)
Digital Versatile Disc (DVD)
Discrete Logarithm Signature Primitive, DSA version (DLSP-DSA)
Discrete Logarithm Verification Primitive, DSA version (DLVP-DSA)
DTCP Asynchronous Connection (DTCP-AC)

Encryption Plus Non-assertion (EPN)
Elliptic Curve (EC)
Elliptic Curve Cryptography (ECC)
Elliptic Curve Digital Signature Algorithm (EC-DSA)
Elliptic Curve Digital Signature Standard (EC-DSS)
Elliptic Curve Diffie-Hellman (EC-DH)
Elliptic Curve Secret Value Derivation Primitive, Diffie-Hellman version (ECSVDP-DH)
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 19
Elliptic Curve Signature Schemes with Appendix (ECSSA)
Encoding Method for Signatures with Appendix on SHA-1 (EMSA-SHA-1)
Encryption Mode Indicator (EMI)

Federal Information Processing Standards (FIPS)
Function Control Protocol (FCP)

Home Digital Network Device (HDND)

Institute of Electrical and Electronics Engineers (IEEE)
International Electrotechnical Commission (IEC)
International Electrotechnical Commission Publicly Available Specifications (IEC-PAS)
International Organization for Standardization (ISO)

Key Selection Vector (KSV)

Least Significant Bit (lsb)
Least Significant Byte (LSB)

Menezes-Okamoto-Vanstone (MOV)
Most Significant Bit (msb)
Most Significant Byte (MSB)
Motion Picture Experts Group (MPEG)

National Institute of Standards and Technology (NIST)

Personal Computer (PC)
Program Management Table (PMT)
Protected Content Packet (PCP)

Random Number Generator (RNG)

Secure Hash Algorithm, revision 1 (SHA-1)
Secure Hash Standard (SHS)
Set Top Box (STB)
Source node ID (SID)
System Renewability Message (SRM)
Video Cassette Recorder (VCR)

Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 20 (Informational Version) 2007-10-01
Chapter 3 The Digital Transmission Content Protection System
3.1 Content Source Device
Figure 5 shows the various states of operation for a device that is a source of content.
A0: Unauthenticated
A1: Full Authentication
FullAuth(Sink_Device)
A3: Authenticated
Full Authentication Requested
Attach/Detach
to/from Bus
A2: Restricted Authentication
ResAuth(Sink_Device)
Restricted Authentication Requested
Failure
Success
Power Up
Failure
Success
A5: Initialize Device
Initialize()
Full_Auth_Successful(Sink_Device)=True
Restricted_Auth_Successful(Sink_Device)=True
Full_Auth_Successful(Sink_Device)=False
Restricted_Auth_Successful(Sink_Device)=False
Deauthenticate Device
Receive Request for Content Channel Key
A4: Send Content Channel Key
SendContentChannelKey(Sink_Device)

Figure 5 Content Source Device State Machine
A Power up or Attach/Detach to/from the bus event resets this state machine into State A5: Initialize Device.
State A5: Initialize Device. In this state, the device is initialized.
Transition A5:A0. This transition to State A0: Unauthenticated occurs following the completion of the
initialization process.
State A0: Unauthenticated. A device is in an unauthenticated state, waiting to receive a request to perform
the Full or Restricted Authentication procedure.
Transition A0:A1. This transition occurs when the device receives a request to perform the Full Authentication
procedure with a sink device (Sink_Device).
State A1: Full Authentication. In this state, the process FullAuth(Sink_Device) is performed. This process is
described in detail in Chapter 4.
Transition A1:A3. This transition occurs when FullAuth(Sink_Device) has been successfully completed.
Set Full_Auth_Successful(Sink_Device) = True
Transition A1:A0. This transition occurs when FullAuth(Sink_Device) is unsuccessful.
Transition A0:A2. This transition occurs when the device receives a request to perform the Restricted
Authentication procedure with a sink device (Sink_Device).
State A2: Restricted Authentication. In this state, the device executes the process ResAuth(Sink_Device).
This procedure is described in detail in Chapter 5.
Transition A2:A3. This transition occurs when ResAuth(Sink_Device) has been successfully completed.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 21
Set Restricted_Auth_Successful(Sink_Device) = True
Transition A2:A0. This transition occurs when ResAuth(Sink_Device) is unsuccessful.
State A3: Authenticated. When a device is in this state, it has successfully completed either the Full or
Restricted Authentication procedure.
Transition A3:A4. An authenticated device is requested to send the values necessary to construct a Content
Key to a sink device.
State A4: Send Content Channel Key. In this state, the source device sends values necessary to create a
content key to an authenticated sink device by executing SendContentChannelKey(Sink_Device). This process
is described in Chapter 6.
Transition A4:A3. This transition occurs on completion of the process SendContentChannelKey(Sink_Device).
Transition A3:A0.
Set Full_Auth_Successful(Sink_Device) = False
Set Restricted_Auth_Successful(Sink_Device) = False
3.2 Content Sink Device
Figure 6 shows the various states of operation of a device that is a sink for content.
A0: Unauthenticated
A1: Full Authentication
FullAuth(Source_Device)
A3: Authenticated
Full Authentication Initiated
Attach/Detach
to/from Bus
A2: Res. Authentication
ResAuth(Source_Device)
Restricted Authentication Initiated
Failure
Success
Power Up
Request Content Channel Key
A4: Request Content Channel Key
RequestContentChannelKey(Source_Device)
Failure
Success
A5: Initialize Device
Initialize()
Full_Auth_Successful(Source_Device)=True
Restricted_Auth_Successful(Source_Device)=True
Full_Auth_Successful(Source_Device)=False
Restricted_Auth_Successful(Source_Device)=False
Deauthenticate Device

Figure 6 Content Sink Device State Machine
A Power up or Attach/Detach to/from the bus event resets this state machine into State A5: Initialize Device.
State A5: Initialize Device. In this state, the device is initialized.
Transition A5:A0. This transition to State A0: Unauthenticated occurs following the completion of the
initialization process.
State A0: Unauthenticated. A device is in an unauthenticated state, waiting to initiate a request to perform
the Full or Restricted Authentication procedure.
Transition A0:A1. This transition occurs when the device initiates a request to perform the Full Authentication
procedure with another device(Source_Device).
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 22 (Informational Version) 2007-10-01
State A1: Full Authentication. In this state, the process FullAuth(Source_Device) is performed. This process
is described in detail in Chapter 4.
Transition A1:A3. This transition occurs when FullAuth(Source_Device) has been successfully completed.
Set Full_Auth_Successful(Source_Device) = True
Transition A1:A0. This transition occurs when FullAuth(Source_Device) is unsuccessful.
Transition A0:A2. This transition occurs when the device initiates a request to perform the Restricted
Authentication procedure with another device(Source_Device).
State A2: Restricted Authentication. In this state, the device executes the process
ResAuth(Source_Device). This procedure is described in detail in Chapter 5.
Transition A2:A3. This transition occurs when ResAuth(Source_Device) has been successfully completed.
Set Restricted_Auth_Successful(Source_Device) = True
Transition A2:A0. This transition occurs when ResAuth(Source_Device) is unsuccessful.
State A3: Authenticated. When a device is in this state, it has successfully completed either the Full or
Restricted Authentication procedure.
Transition A3:A4. An authenticated device needs to request a Content Key to gain access to copy protected
content.
State A4: Request Content Channel Key. In this state, an authenticated sink device requests the values
necessary to create a Content Key by executing the process RequestContentChannelKey(Source_Device). This
process is described in Chapter 6.
Transition A4:A3. This transition occurs on completion of the process
RequestContentChannelKey(Source_Device).
Transition A3:A0.
Set Full_Auth_Successful(Source_Device) = False
Set Restricted_Auth_Successful(Source_Device) = False


Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 23
Chapter 4 Full Authentication
4.1 Introduction
This chapter addresses the particulars of the Full Authentication level of device authentication and key
exchange. Full Authentication employs the public key based Elliptic Curve Digital Signature Algorithm (EC-DSA)
for signing and verification. It also employs the Elliptic Curve Diffie-Hellman (EC-DH) key exchange algorithm
to generate a shared authentication key.
4.2 Notation
The notation introduced in this section is used to describe the cryptographic processes. All operations in the
elliptic curve domain are calculated on an elliptic curve E defined over GF(p).
4.2.1 Defined by the DTLA
The following parameters, keys, constants, and certificates are generated by the DTLA.
4.2.1.1 General
E denotes the elliptic curve over the finite field GF(p) of p elements represented as integers modulo p. Elliptic
curve points consist of the x-coordinate and y-coordinates, respectively; for an elliptic curve point P = (x
P
, y
P
)
which is not equal to the elliptic curve point at infinity.
Description
Size
(bits)
p A prime number greater than 3 of finite field GF(p) 160
a, b The coefficients of elliptic curve polynomial
160
each
G The basepoint for the elliptic curve E 320
r The order of basepoint G 160
L
-1
DTLA private key of EC-DSA key pair which is an integer in the range (1, r1) 160
L
1
DTLA public key of EC-DSA key pair where L
1
=L
-1
G 320
These parameters, with the exception of L
-1
, are in DTCP specification available under license from DTLA.
4.2.1.2 For Device X
Description
Size
(bits)
X
-1
Device private key of EC-DSA key pair which is an integer in the range (1, r1) 160
X
1
Device public key of EC-DSA key pair where X
1
=X
-1
G 320
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 24 (Informational Version) 2007-10-01
4.2.2 Notation used during Full Authentication
The following additional values are generated and used by the devices during Full Authentication:
Key or
Variable
Description Size (bits)
X
n
Nonce (random challenge generated by RNG
F
) 128
X
K
Random value used in EC-DH key exchange generated by
RNG
F
in the device (integer in the range [1, r-1])
160
X
V

EC-DH first phase value (X
K
G) calculated in the device (point
on the elliptic curve E)
320
X
SRMV

Version number of the system renewability message (SRMV)
stored by the device (See Chapter 7)
16
X
SRMC

Indicates the number of SRM part(s) which are currently
stored in the non-volatile memory of the device. A value of
SRMC indicates that the first SRMC+1 generations of SRMs
are currently stored by the device (See Chapter 7)
4
K
AUTH

Authentication key which is the least significant 96-bits of
shared data created through EC-DH key exchange
96
Table 1 Length of keys and variables generated by the device (Full Authentication)
4.2.3 Device Certificate Formats
A device certificate is given to each compliant device X by the DTLA and is referred to as X
CERT
. This certificate
is stored in the compliant device and used during the authentication process.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 25
4.2.3.1 Baseline Format
The following Figure 7 shows the baseline device certificate 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) ALAP 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)

Figure 7 Baseline Device Certificate Format
Device certificates are comprised of the following Baseline Format fields:
Certificate Type (4 bits). The only encoding which is currently defined is 0, which indicates the DTCP
certificate. 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:
o Format 0 = the Restricted Authentication device certificate format (See Chapter 5).
o Format 1 = the Baseline Full Authentication device certificate format.
o Format 2 = the Extended Full Authentication device certificate format (Optional
2
).
o Other encodings are currently reserved.
Device Generation (X
SRMG
, 4 bits). This field indicates the non-volatile memory capacity and therefore the
maximum generation of renewability messages that this device supports (Described in Chapter 7). 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 (11 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
3
. The procedures for processing this field are specified in Appendix
C.
The devices ID number (X
ID
, 40 bits) assigned by the DTLA.
The EC-DSA public key of the device (X
1
, 320 bits)
An EC-DSA signature from the DTLA of the components listed above (320 bits)
The overall size of a Baseline Format device certificate is 88 bytes.

2
Features of this specification that are labeled as optional describe capabilities whose usage has not yet been established by the 5C.
3
To maintain consistency with the previous version of this specification, the value of AP flag for a device with a common device certificate
is set to one regardless of the DTCP bus bridge capability.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 26 (Informational Version) 2007-10-01
4.2.3.2 Extended Format Fields (Optional Components of the Device Certificate)
In addition to the Baseline Format fields, each device certificate may optionally include the following Extended
Format fields
2
:
A device capability mask indicating the properties of the device and channel ciphers supported. (X
Cap_Mask
, 32
bits)
An EC-DSA signature from the DTLA of all preceding components in the device certificate. (320 bits)
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
Baseline Full Authentication Device Certificate Fields (Figure 7)
Device Capability Mask (32 bits)
DTLA EC-DSA signature of all preceding fields (320 bits, c followed by d value)

Figure 8 Extended Device Certificate Fields
Device Capability Mask
The device capability mask is provided to describe the extensibility features supported by a given device.
bit[0] denotes AES-128
4
capability when b[0]=1 the device has optional cipher AES-128 capability and
when b[0]=0 then it does not.
bit[31..1] are reserved.
Devices that do not support the device capability mask are assumed to only support the baseline cryptographic
features defined by this content protection system (e.g., the 56-bit M6 Baseline Cipher).
4.3 Manufacture of Compliant Devices
All compliant devices that support Full Authentication (that is, each item manufactured, regardless of brand and
model) will be assigned a unique Device ID (X
ID
) and device EC-DSA public/private key pair (X
1
, X
-1
) generated
by the DTLA. X
-1
must be stored within the device in such a way as to prevent its disclosure. Compliant
devices must also be given a device certificate (X
CERT
) by the DTLA. This certificate is stored in the compliant
device and used during the authentication process. In addition, the compliant device will need to store the
other constants and keys necessary to implement the cryptographic protocols.
4.4 Cryptographic Functions
4.4.1 SHA-1 (Secure Hash Algorithm, revision 1)
SHA-1, as described in FIPS PUB 180-2
5
is the algorithm used in DSS to generate a message digest of length
160 bits. A message digest is a value calculated from message. It is similar in concept to a checksum, but
computationally infeasible to forge.
4.4.2 Random Number Generator
A high quality random number generator is required for Full Authentication. The output of this random number
generator is indicated by the function RNG
F
that is described in DTCP specification available under license from
DTLA.

4
Support for this feature is TBD.
5
National Institute of Standards and Technology (NIST), Secure Hash Standard (SHS), FIPS Publication 180-2
, August 1, 2002.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 27
4.4.3 Elliptic Curve Cryptography (ECC)
These cryptographic algorithms are based upon cryptographic schemes, primitives, and encoding methods
described in IEEE 1363-2000.
An Elliptic Curve Cryptosystem (ECC) is used as the cryptographic basis for DH and DSA.
The definition field classifies ECC implementations. For this system, the definition field used is GF(p) where p is
a large prime number greater than three. An elliptic curve E over the field GF(p), where p > 3, is defined by
the parameters a and b and the set of solutions (x, y) to the elliptic curve equation together with an extra point
often called the point at infinity. The point at infinity is the identity element of the abelian group, (E, +). The
elliptic curve equation used is
y
2
= x
3
+ ax + b where 4a
3
+ 27b
2
0,
Where a, b, x, y, are elements of GF(p). A point P on the elliptic curve consists of the x-coordinate and the y-
coordinate of a solution to this equation, or the point at infinity, and is designated P = (x
p
, y
p
).
For EC-DSA and EC-DH, a basepoint G on the elliptic curve is selected. All operations in the elliptic curve
domain are calculated on an elliptic curve E defined over GF(p). The public key Y
1
(a point on the elliptic curve)
and private key Y
-1
(a scalar value satisfying 0 < Y
-1
< r) for each entity satisfies the equation:
Y
1
= Y
-1
G
In specifying the elliptic curve used:
The order of basepoint G will have a large prime factor.
The system will be robust against MOV reduction attack, since super singular elliptic curves are avoided.



Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 28 (Informational Version) 2007-10-01
4.4.3.1 Elliptic Curve Digital Signature Algorithm (EC-DSA)
Signature
The following signature algorithm is based on the ECSSA digital signature scheme using the DLSP-DSA
signature primitive and EMSA-SHA-1 encoding method defined in of IEEE 1363-2000.
Input:
M = the data to be signed
X
-1
= the private key of the signing device (must be kept secret)
p, a, b, G, and r = the elliptic curve parameters associated with X
-1

Output:
S
X
-1
[M] = a 320-bit signature of the data, M, based on the private key, X
-1

Algorithm:
Step 1, Generate a random value, u, satisfying 0 < u < r, using RNG
F
. A new value for u is generated for
every signature and shall be unpredictable to an adversary for every signature computation. Also,
calculate the elliptic curve point, V = uG.
Step 2, Calculate c = x
V
mod r (the x-coordinate of V reduced modulo r). If c = 0, then go to Step 1.
Step 3, Calculate f = [SHA-1(M)]
msb_bits_in_r
. That is, calculate the SHA-1 hash of M and then take the most
significant bits of the message digest that is the same number of bits as the size of r.
Step 4, Calculate d = [u
-1
(f + cX
-1
)] mod r (note that u
-1
is the modular inverse of u mod r while X
-1
is the
private key of the signing device). If d = 0, then go to Step 1.
Step 5, Set first 160 bits of S
X
-1
[M] equal to the big endian representation of c, and the second 160 bits of
S
X
-1
[M] equal to the big endian representation of d. (S
X
-1
[M] = c || d)
Verification
The following verification algorithm is based on the ECSSA digital signature scheme using the DLVP-DSA
signature primitive and EMSA-SHA-1 encoding method defined in of IEEE 1363-2000.
Input:
S
X
-1
[M] = an alleged 320-bit signature (c || d) of the data, M, based on the private key, X
-1

M = the data associated with the signature
X
1
= the public key of the signing device
p, a, b, G, and r = the elliptic curve parameters associated with X
-1

Output:
valid or invalid, indicating whether the alleged signature is determined to be valid or invalid,
respectively
Algorithm:
Step 1, Set c equal to the first 160 bits of S
X
-1
[M] interpreted as in big endian representation, and d equal
to the second 160 bits of S
X
-1
[M] interpreted as in big endian representation. If c is not in the
range [1, r 1] or d is not in the range [1, r 1], then output invalid and stop.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 29
Step 2, Calculate f = [SHA-1(M)]
msb_bits_in_r
. That is, calculate the SHA-1 hash of M and then take the most
significant bits of the message digest that is the same number of bits as the size of r.
Step 3, Calculate h = d
-1
mod r, h
1
= (fh) mod r, and h
2
= (ch) mod r.
Step 4, Calculate the elliptic curve point P = (x
P
, y
P
) = h
1
G + h
2
X
1
. If P equals the elliptic curve point at
infinity, then output invalid and stop.
Step 5, Calculate c = x
P
mod r. If c = c, then output valid; otherwise, output invalid.
4.4.3.2 Elliptic Curve Diffie-Hellman (EC-DH)
The following shared secret derivation algorithm is based on the ECSVDP-DH primitive defined in IEEE 1363-
2000.
Input:
Y
V
= the Diffie-Hellman first phase value generated by the other device (an elliptic curve point)
p, a, b, G, and r = the elliptic curve parameters associated with X
-1

Output:
X
V
= the Diffie-Hellman first phase value (an elliptic curve point)
the x-coordinate of X
K
Y
V
= the shared secret generated by this algorithm (must be kept secret from
third parties)
Algorithm:
Step 1, Generate a random integer, X
K
, in the range [1, r-1] using RNG
F
. A new value for X
K
is generated for
every shared secret and shall be unpredictable to an adversary. Also, calculate the elliptic curve point, X
V
=
X
K
G.
Step 2, Output X
V
.
Step 3, Calculate X
K
Y
V
. Output the x-coordinate of X
K
Y
V
as the secret shared.
4.4.3.3 Implementation of the Elliptic Curve Cryptosystem
A range of implementations of the Elliptic Curve Cryptosystem can be realized which are compatible with the
IEEE 1363 primitives described in this section.
Efficient implementations of an elliptic curve cryptosystem can be realized by performing computations within
the Montgomery space using new definitions of the basic arithmetic operations of addition, subtraction,
multiplication, and inverse
6
.

6
J apanese patent application number: PH10-269060.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 30 (Informational Version) 2007-10-01
4.5 Protocol Flow
4.5.1 Protocol Flow Overview
The following Figure 9 gives an overview of the Full Authentication protocol flow.
Send random challenge and device B certificate
Return random challenge and device A certificate
Source Device [A] Sink Device [B]
Verify Bs device
cert
Examine SRM
Compute EC-DH
first phase value
Request Authentication
Verify As device cert
Examine SRM
Compute EC-DH first
phase value
Verify As signed msg
Compute Auth key
Verify Bs signed msg
Compute Auth Key
3a
3b
1
2

Figure 9 Full Authentication Protocol Flow Overview
During Full Authentication:
1. The sink device requests authentication by sending a random challenge and its device certificate. This can
be the result of the sink device attempting to access a protected content stream (whose EMI is set to
Copy-never, No-more-copies, or Copy-one-generation). The sink device may request authentication
on a speculative basis, before attempting to access a content stream. If a sink device attempts speculative
authentication, the request can be rejected by the source.
2. Device A then returns a random challenge and its device certificate. If the value of the other devices
certificate type or format fields is reserved, the authentication should be immediately aborted. After the
random challenge and device certificate exchange, each device verifies the integrity of the other devices
certificate using EC-DSA. If the DTLA signature is determined to be valid, the devices examine the
certificate revocation list embedded in their system renewability messages (see Chapter 7) to verify that the
other device has not been revoked. If the other device has not been revoked, each device calculates a EC-
DH key exchange first-phase value (See section 4.4.3.2).
3. The devices then exchange messages containing the EC-DH key exchange first-phase value, the
Renewability Message Version Number and Generation of the system renewability message stored by the
device, and a message signature containing the other devices random challenge concatenated to the
preceding components. The devices verify the signed messages received by checking the message
signature using EC-DSA with the other devices public key. This verifies that the message has not been
tampered with. If the signature cannot be verified, the device refuses to continue. In addition, by
comparing the exchanged version numbers, devices can at a later time invoke the system renewability
mechanisms (See Section 7.2 for the details of this procedure).
Each device calculates an authentication key by completing the EC-DH key exchange.
A detailed description of the Full Authentication protocol and associated state machine can be found in the DTCP
Specification available under license from DTLA.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 31
Chapter 5 Restricted Authentication
5.1 Introduction
This chapter describes the authentication and key exchange between source and sink devices that employ
asymmetric key management and common key cryptography for Copy-one-generation and No-more-copy
contents. These kinds of devices, which typically have limited computation resources, follow a Restricted
Authentication protocol instead of Full Authentication. Restricted Authentication relies on the use of shared
secrets and hash function to respond to a random challenge.
The Restricted Authentication method is based on a device being able to prove that it holds a secret shared with
other devices. One device authenticates another by issuing a random challenge that is responded to by
modifying it with the shared secret and hashing.
5.2 Notation
The notation introduced in this section is used to describe the cryptographic process and protocol used for
Restricted Authentication.
5.2.1 Defined by the DTLA
The following parameters, keys, constants, and certificates must be generated by the DTLA.
5.2.1.1 General
The parameters defined in Section 4.2.1 are also used during Restricted Authentication by Source devices that
also support Full Authentication.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 32 (Informational Version) 2007-10-01
5.2.1.2 For Device X
A device certificate (X
CERT
) given to compliant device X by the DTLA and used during the authentication
process (See the Section 5.2.3 for details).
Description
Size
(bits)
Copy-one-generation
Sink Device Keys
(X
Kcosnk1
X
Kcosnk12
)
Each device which is a sink of Copy-one-
generation content receives 12 64 bit keys from
the DTLA.
64
(Each)
Copy-one-generation
Source Device Keys
(X
Kcosrc1
X
Kcosrc12
)
Each device which is a source of Copy-one-
generation content receives 12 64 bit keys from
the DTLA.
64
(Each)
No-more-copies
Sink Device Keys
(X
Knmsnk1
X
Knmsnk12
)
Each device which is a sink of No-more-copies
content receives 12 64 bit keys from the DTLA.
64
(Each)
No-more-copies
Source Device Keys

(X
Knmsrc1
X
Knmsrc12
)
Each device which is a source of No-more-copies
content receives 12 64 bit keys from the DTLA.
64
(Each)
Key Selection Vector
(X
KSV
)
This key selection vector (KSV) determines which
keys will be used during the Restricted
Authentication procedure with this device. Only
one KSV is required for devices that can be both a
source and sink of content.
12
Table 2 Length of Keys and Constants created by DTLA (Restricted Authentication)
Devices contain the keys appropriate to the type of content and functions that they perform.
5.2.2 Notation used during Restricted Authentication
The following additional values are generated and used by the devices during Restricted Authentication:
Description Size (bits)
(A
n
, B
n
) Nonce (random challenge generated by RNG
R
) 64
(K
v
, K
v
) Verification Keys 64
(R, R) Responses 64
(K
AUTH
, K
AUTH
) Authentication Keys 96
Table 3 Length of keys and variables generated by the device (Restricted Authentication)
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 33
5.2.3 Device Certificate Format
A Restricted Authentication Device Certificate is used in the Restricted Authentication process. Each Restricted
Authentication device certificate is assigned by the DTLA and includes a Device ID and a signature generated by
the DTLA. All compliant sink devices that support only Restricted Authentication shall have this certificate.
Figure 10 shows this device certificate 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
reserved
(zero)
AL Key Selection Vector Device ID
Device ID continued (Total 40bits)
DTLA EC-DSA signature of all preceding fields (320 bits for c and followed by d value)

Figure 10 Restricted Authentication Device Certificate Format
The Restricted Authentication device certificate is comprised of the following fields:
Certificate Type (4 bits). (See Section 4.2.3.1 for a description of the encoding)
Certificate Format (4 bits). (See Section 4.2.3.1 for a description of the encoding)
Reserved Field (4 bits). These bits are reserved for future definition and are currently defined to have
a value of zero.
AL flag (1 bit). [OPTIONAL
7
]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.
Key Selection Vector (X
KSV
, 12 bits) assigned by the DTLA. This vector determines which keys will be
used during the Restricted Authentication procedure with this device. This KSV is used regardless of the
EMI of the stream to be handled or whether the device is being used as a source or sink of content.
The encoding of this field is as follows:
11109 1 0 2 3 5 4 6 7 8
X
K12
Selected
Key Selection Vector
X
K1
Selected
...
X
K2
Selected

Figure 11 Key Selection Vector
The Device ID number (X
ID
, 40 bits) assigned by the DTLA.
A EC-DSA signature from the DTLA of the components listed above (320 bits)
The overall size of a Restricted Authentication device certificate format is 48 bytes.
5.2.4 Random Number Generator
A random number generator is required for Restricted Authentication. The output of this random number
generator is indicated by the function RNG
R
. Either RNG
R
or RNG
F
as described in DTCP Specification available
under license from DTLA.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 34 (Informational Version) 2007-10-01

Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 35
5.3 Protocol Flow
5.3.1 Protocol Flow Overview
Figure 12 gives an overview of the Restricted Authentication protocol flow.
Request Authentication, send random challenge
and either device certificate or key selection
vector
1
2
Source Device [A] Sink Device [B]
3
Send random challenge and key selection
vector
Return response
Compute
Verification key
Compute response
Compute Auth key Compute Auth key
Verify response
If source supports
Full Authentication
(Verify Bs cert)
(Examine SRM)

Figure 12 Restricted Authentication Protocol Flow Overview
During Restricted Authentication:
1. The sink device initiates the authentication protocol by sending an asynchronous challenge request to the
source device. This request contains the type of Exchange Key to be shared by the source and sink devices
as well as a random number generated by the sink device. If the sink device knows that the source device
does not have a capability for Full Authentication, the sink sends its KSV to the source; otherwise, the sink
sends its Restricted Authentication device certificate.
2. The source device generates a random challenge and sends it to the sink device. If the source device
supports Full Authentication, it extracts the Device ID of the sink device from the certificate sent by the
sink. It then checks 1) that the certificate sent by the sink is valid and 2) that the sinks Device ID is not
listed in the certification revocation list in the system renewability message stored in the source device.
Also, if the value of the other devices certificate type or format fields is reserved, the authentication should
be immediately aborted.
If these checks are completed successfully, the source continues the protocol by computing the verification key.
3. After receiving a random challenge back from the source device, the sink device computes a response using
a verification key that it has computed and sends it to the source.
After the sink device returns a response, the source device compares this response with similar information
generated at the source side using its verification key. If the comparison matches its own calculation, the sink
device has been verified and authenticated. If the comparison does not match it, the source device shall reject
the sink device. Finally, each device computes the authentication key.
A detailed description of the Restricted Authentication protocol and associated state machine can be found in
the DTCP Specification available under license from DTLA.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 36 (Informational Version) 2007-10-01
Chapter 6 Content Channel Management and Protection
6.1 Introduction
This chapter details the mechanisms used to 1) share an Exchange Key between a source device and a sink
device and 2) establish and manage the encrypted isochronous channel through which protected content flows.
Either Full or Restricted Authentication (depending on the capabilities of the device) shall be completed prior to
establishing a content channel.
6.2 Content Management Keys
6.2.1 Exchange Keys (K
X
)
A common set of Exchange Keys (K
X
) are established between a source device and all sink devices that have
completed the appropriate authentication procedure (either Full or Restricted) with the source device required
to handle content with a specific EMI value (Section 6.4.2).
A single exchange key shall be used for all EMI values for an optional content cipher.
The procedure for establishing an Exchange Key is described in Section 6.3.1.
6.2.2 Content Key (K
C
)
6.2.2.1 K
C
For M6
The Content Key (K
C
) is used as the key for the content encryption engine. K
C
is computed from the three
values shown below:
An Exchange Key K
x
is assigned to each EMI used to protect the content.
A random number N
C
generated by the source device (using RNG
F
for devices that support Full
Authentication and RNG
R
for devices that support only Restricted Authentication) which is sent in plain text
to all sink devices in asynchronous packet(s).
Constant value C
a
, C
b
, or C
c
, which corresponds to an encryption mode EMI in the packet header.
The Content Key is generated as follows:
K
C
= J[K
x
, [EMI], N
C
] where:

[EMI] = C
a
when EMI is mode A
[EMI] = C
b
when EMI is mode B
[EMI] = C
c
when EMI is mode C
C
a
, C
b
, and C
c
are universal secret constants assigned by the DTLA. The values for these constants are
specified in DTCP specification available under license from DTLA.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 37
6.2.2.1.1 M6 Related Key and Constant Sizes
The following table details the length of the keys and constants described in this chapter:
Key or Constant Size (bits)
Exchange Key (K
X
) 96
Scrambled Exchange Key (K
SX
) 96
Constants (C
a
, C
b
, C
c
) 96
Content Key for M6 baseline Cipher (K
C
) 56
Nonce for Content Channel (N
C
) 64
Table 4 Size of M6 Related Content Management Keys and Constants
6.2.2.2 K
C
for AES-128
The Content Key (K
C
) is used as the key for the content encryption engine. K
C
is computed from the three
values shown below:
Exchange Key K
X
where only a single exchange key is used for all EMIs to protect the content.
A random number N
C
generated by the source device using RNG
F
which is sent in plain text to all sink
devices in asynchronous packet(s).
Constant value C
a
, C
b
, or C
c
which corresponds to an EMI value in the packet header.
The Content Key is generated as follows:
K
C
= J-AES(K
X
, [EMI], N
C
) Where:
[EMI] {
[EMI]=C
a
when EMI = Mode A
[EMI]=C
b
when EMI = Mode B
[EMI]=C
c
when EMI = Mode C
}
C
a
, C
b
, and C
c
are universal secret constants assigned by the DTLA. The values for these constants are
specified in DTCP Specification available under license from DTLA.
6.2.2.2.1 AES-128 Related Key and Constant Sizes
The following table details the length of the keys and constants described in this chapter:
Key or Constant Size (bits)
Exchange Key (K
X
) 96
Scrambled Exchange Key (K
SX
) 96
Constants (C
a
, C
b
, C
c
) 96
Content Key for AES-128 Optional Cipher
7
(K
C
) 128
Nonce for Content Channel (N
C
) 64
Table 5 Length of Keys and Constants (Content Channel Management)

7
Features of this specification that are labeled as optional describe capabilities whose usage has not yet been established by the 5C.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 38 (Informational Version) 2007-10-01
6.3 Protocol Flow
6.3.1 Establishing Exchange Key
After the completion of Full or Restricted Authentication, the source device establishes the Exchange Key(s)
described in Section 6.2.1. The following procedure is used for each key:
1. The source device assigned a random value for the particular Exchange Key (K
x
) (using RNG
F
for devices
that support Full Authentication and RNG
R
for devices that support only Restreicted Authentication) being
established.
2. It then scrambles the key K
X
using K
AUTH
resulting in K
SX
according to the function described in the DTCP
Specification available under license from the DTLA.
3. The source device sends K
SX
to the sink device.
4. The sink device descrambles the K
SX
using K
AUTH
(calculated during Authentication) to determine the shared
Exchange Key K
x
according to the function described in the DTCP Specification available under license from
DTLA.
The source device repeats the above steps for all of the Exchange Keys required between it and the sink device.
Finally, the devices update the SRM if it is determined to be necessary during the Full Authentication process
(see Chapter 4). The update procedure is described in Section 7.2.1.
Devices remain authenticated as long as they maintain valid Exchange Keys. The Exchange Key may be
repeatedly used to set up and manage the security of copyrighted content streams without further
authentication. It is recommended that source devices expire their Exchange Keys when they stop all
isochronous output. Additionally, both source and sink devices must expire their Exchange Keys when they are
detached from the bus (i.e. enter isolated state as described in section 3.7.3.1.1 of IEEE std 1394-1995).
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 39
6.3.2 Establishing Content Keys
This section describes the mechanism for establishing the Content Keys (K
C
) used to encrypt/decrypt content
being exchanged between the source and sink devices. Figure 13 shows an overview of content channel
establishment and key management protocol flow.
Send current seed value (N
C
). Compute the
appropriate (Odd or Even) key depending on
the value of the LSB of N
C
.
Encrypted Content Stream using Odd (or
Even) Key
1
2
Source Device Sink Device
Clear Text Content
Clear Text Content
Indicate key change. Encrypted Content
Stream using Even (or Odd) Key
3
Clear Text Content
Clear Text Content

Figure 13 Content Channel Establishment and Management Protocol Flow Overview
Content Keys are established between the source device and the sink device as follows:
1. When the source device starts sending content, it generates a 64 bits random number as an initial value of
the seed (N
C
) of the Content Key. The initial seed is referred to as Odd or Even based on its least
significant bit. If subsequent content channels are established, the current value of N
C
from the active
content channel(s) shall be used as the seed.
2. The source device begins transmitting the content using the Odd or Even Content Key (K
C
) corresponding to
the above reference of the initial seed to encrypt the content. The Content Key is computed by the source
device using the function J, Exchange Key K
x
, the seed (N
C
) and the [EMI]. A bit in the IEEE 1394 packet
header is used to indicate which key (ODD or EVEN) is being used to encrypt a particular packet of content.
If the initial seed is ODD, the Odd/Even bit in the IEEE 1394 packet header is set to Odd; otherwise, it is set
to Even.
3. In response to a N
C
request from a sink, the source device returns the seed N
C
which is used to generate
K
C
. The sink device computes the current K
C
. Note that the least significant bit of N
C
may not match the
received Odd/Even bit at the sink device (e.g. when sink device requests the seed N
C
just before sink
observed the Odd/Even update).
The source device computes the next K
C
using the same process used for the initial calculation with exception
that the seed (N
C
) is incremented by 1 mod 2
64
.
Periodically, the source device shall change Content Keys to maintain robust content protection. To change
keys, the source device starts encrypting with the new key computed above and indicates this change by
switching the state of the Odd/Even bit in the IEEE 1394 packet header. The minimum period for change of the
Content Key is defined as 30 seconds. The maximum period is defined as 120 seconds. Duration time for K
C
is
from 30 sec to 2 minutes. A source device should not increment the Content Key duration time counter when it
is outputting only contents marked with an EMI value (Section 6.4.2) of Copy-free. When a device suspends all
isochronous outputs it should reset its counter.
The protocol flow to establish the Content Key using IEEE 1394 transactions is shown in Chapter 8.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 40 (Informational Version) 2007-10-01
6.3.3 Odd/Even Bit
The Odd/Even bit (the 3rd bit of the sync field of the IEEE 1394 isochronous packet header) is used to indicate
which Content Key (K
C
) is currently being used to protect the content channel. The Odd/Even bit only exists
when the value of the tag field is 01. Figure 14 shows this bit location in the packet header. A 0 indicates
that the Even key should be used while 1 indicates that the Odd key should be used. The Odd key and Even
key are used and updated alternately. The Odd/Even bit can only be changed on Isochronous packets that
contain either the beginning of a new encryption frame or are idle packet between encryption frames. If an
Isochronous packet contains portions of more than one encryption frame, then the change in key is applied to
the first encryption frame which begins in the packet.
(Transmitted First)
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
sy
Data Length Tag Channel Tcode
EMI
O
d
d
/
E
v
e
n

-
Header CRC

Data Field

Data CRC
Figure 14 Odd/Even Bit Location in the Packet Header
6.4 Copy Control Information (CCI)
Copy Control Information (CCI) specifies the attributes of the content with respect to this content protection
system. Two CCI mechanisms are supported: Embedded CCI and the Encryption Mode Indicator.
6.4.1 Embedded CCI
Embedded CCI is carried as part of the content stream. Many content formats including MPEG have fields
allocated for carrying the CCI associated with the stream. Furthermore, the definition and format of the CCI is
specific to each content formats. In the following sections, Embedded CCI is interpreted to one of four states
Copy Never (11), Copy One Generation (10), No More Copies (01) or Copy Freely (00). The integrity of
Embedded CCI is ensured since tampering with the content stream results in erroneous decryption of the
content.
6.4.1.1 DTCP_Descriptor for MPEG-TS
The DTCP_Descriptor delivers Embedded CCI over the DTCP system when an MPEG-Transport Stream (MPEG-
TS) is transmitted. Appendix B is a detailed description of this descriptor.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 41
6.4.2 Encryption Mode Indicator (EMI)
The Encryption Mode Indicator (EMI) provides an easy-to-access yet secure mechanism for indicating the CCI
associated with a stream of digital content. For IEEE 1394 serial buses, the EMI is placed in the most significant
two bits of the Sync field of packet header as shown in Figure 15. The EMI bits only exist when the value of the
tag field is 01. By locating the EMI in an easy-to-access location, devices can immediately determine the CCI of
the content stream without needing to decode the content transport format to extract the Embedded CCI. This
ability is critical for enabling bit-stream recording devices (e.g., digital VCR) that do not recognize and cannot
decode specific content formats.
The EMI bits can only be changed on isochronous packets that contain either the beginning of a new encryption
frame or are idle packets between encryption frames. If an Isochronous packet contains portions of more than
one encryption frame, then the change in EMI is applied to the first encryption frame which begins in the
packet.
(Transmitted First)
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
sy
Data Length Tag Channel Tcode
EMI
O
d
d
/
E
v
e
n

-
Header CRC

Data Field

Data CRC
Figure 15 EMI Location
The EMI indicates the mode of encryption applied to a stream:
Licensed source devices will choose the right encryption mode according to the characteristics of the
content stream and set its EMI accordingly. If the content stream consists of multiple substreams with
different Embedded CCI, the strictest Embedded CCI will be used to set the EMI.
Licensed sink devices will choose the right decryption mode as indicated by the EMI.
If the EMI bits are tampered with, the encryption and decryption modes will not match, resulting in an
erroneous decryption of the content.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 42 (Informational Version) 2007-10-01
Table 6 shows the encoding used for the EMI bits.
EMI Mode EMI Value Meaning Authentication Required
Mode A 11 Copy-never
8
Full
Mode B 10 Copy-one-generation Restricted or Full
Mode C 01 No-more-copies Restricted or Full
N.A.
9
00 Copy-free None, not encrypted
Table 6 EMI Encoding
An encoding of 00 is used to indicate that the content can be copied-freely. No authentication or encryption
is required to protect this content.
For content that is never to be copied (e.g., content from prerecorded media with a Copy Generation
Management System (CGMS) value of 11), an EMI encoding of 11 is used. This content can only be
exchanged between devices that have successfully completed the Full Authentication procedure.
An EMI encoding of 10 indicates that one generation of copies can be made (e.g. content from prerecorded
media with a CGMS value of 10). Devices exchanging this content can either use Full or Restricted
Authentication.
If content with EMI = 10 is copied, future exchanges across a digital interconnect are marked with an EMI
encoding of 01, which indicates that a single-generation copy has already been made.
6.4.3 Relationship between Embedded CCI and EMI
A protected stream of content may consist of one or more programs. Each of these programs may be assigned
a different level of Embedded CCI. Since EMI is associated with the overall stream of content it is possible that
the stream will be composed of multiple programs and that the EMI will not match the Embedded CCI value of
each of the protected programs. In the event that there is a conflict, the most restrictive Embedded CCI value
will be used for the EMI. Table 7 shows the allowable combinations of EMI and Embedded CCI:

Embedded CCI for each program
00 EMI
EPN
10
-not-asserted EPN
10
-asserted
01 10 11
Mode A Allowed Allowed Allowed
11
Allowed Allowed
Mode B Allowed Allowed Prohibited Allowed Prohibited
Mode C Allowed Allowed Allowed Allowed Prohibited
N.A. Allowed Prohibited Prohibited Prohibited Prohibited
Table 7 Relationship between EMI and Embedded CCI


8
In case of audio transmission (refer to 6.4.5), the meaning of Mode A depends on each AM824 application type as defined in Appendix A.
9
Not Applicable. No EMI mode is defined for an encoding of 00.
10
Definition and usage of EPN is specified in Appendix B.
11
Not typically used.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 43
6.4.4 Treatment of EMI/Embedded CCI for Audiovisual Device Functions
This section presents the behavior of audiovisual device functions according to their ability to send/receive EMI
and detect/modify Embedded CCI. Other functions not listed in this section may be permitted as long as they
are consistent with the provisions of this specification.
6.4.4.1 Format-cognizant source function
A Format-cognizant source function can recognize the Embedded CCI of a content stream being transmitted.
Table 8 shows the EMI that should be used for a transmitted content stream containing component programs
with the following Embedded CCI values:
Embedded CCI of programs
00 01 10 11
EPN
10
-not-
asserted
EPN
10
-
asserted


EMI
Dont care Dont care *
12
Dont care Present Mode A
Dont care Dont care
Cannot be
Present
Present
Cannot be
Present
Dont care Present
Cannot be
Present
Dont care
Cannot be
Present

Mode B
Dont care Dont care Present
Cannot be
Present
13

Cannot be
Present
Mode C
Present
Cannot be
Present
Cannot be
Present
Cannot be
Present
Cannot be
Present
N.A.
Other combinations
Transmission
Prohibited
Table 8 Format-Cognizant Source Function CCI handling
6.4.4.2 Format-non-cognizant source function
A Format-non-cognizant source function need not recognize the Embedded CCI of a content stream being
transmitted. Table 9 shows the EMI value that is used by a Format-non-cognizant source function when
transmitting content streams with the following EMI:
EMI or recorded CCI
14
of source content EMI used for transmission
Copy-never Mode A
Copy-one-generation Mode B
No-more-copies Mode C
Copy-free N.A.
Table 9 Format-Non-Cognizant Source Function CCI handling

12
Dont care, but not typically used.
13
This combination is allowed for format-non-cognizant source function, but is not permitted for format-cognizant source functions.
14
Recorded CCI is copy control information that is not embedded in the content program and does not require knowledge of the content
format to extract.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 44 (Informational Version) 2007-10-01
6.4.4.3 Format-cognizant recording function
A Format-cognizant recording function recognizes the Embedded CCI of a received content program prior to
writing it to recordable media. Table 10 shows the CCI value that is recorded with content programs marked
with specific Embedded CCI values.
Embedded CCI of program
EMI
00 01 10 11
Mode A Recordable Do not record *
15
Do not record
Mode B Recordable
Discard entire content
stream
16

*
15

Discard entire content
stream
16

Mode C Recordable Do not record
Do not
record
Discard entire content
stream
16

Table 10 Format-cognizant recording function CCI handling
6.4.4.4 Format-cognizant sink function
A Format-cognizant sink function can recognize the Embedded CCI of received content. Table 11 shows the
Embedded CCI of programs contained within the content stream that can be received.
Embedded CCI of program
EMI
00 01 10 11
Mode A
Available for
processing
Available for
processing
17

Available for
processing
Available for
processing
Mode B
Available for
processing
Discard entire
content stream
18

Available for
processing
Discard entire
content stream
18

Mode C
Available for
processing
Available for
processing
Available for
processing
19

Discard entire
content stream
18

Table 11 Format-cognizant sink function CCI handling

15
If the recording function supports recording a CCI value of No-more-copies then the CCI value of No-more-copies shall be recorded with
the program. Otherwise the CCI of Copy-never shall be recorded with the program.
16
If the function detects this CCI combination among the programs it is recording, the entire content stream is discarded.
17
Not typically used.
18
If the function detects this CCI combination among the programs, the entire content stream is discarded.
19
If the device has a rule for handling No-more-copies, this program shall be handled according to the rule. Otherwise the program shall be
handled as Copy Never.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 45
6.4.4.5 Format-non-cognizant recording function
A Format-non-cognizant recording function can record content with appropriate EMI onto recordable media.
Table 12 shows the EMI value for content that can be recorded and the CCI that should be recorded with the
content.
EMI of the received stream

Recorded CCI
20
to be written onto
user recordable media
Mode A (Copy-never) Stream cannot be recorded
Mode B (Copy-one-generation) No-more-copies
Mode C (No-more-copies) Stream cannot be recorded
Table 12 Format-non-cognizant recording function CCI handling
6.4.4.6 Format-non-cognizant sink function
For this function, the content must be treated in a manner consistent with its EMI.
6.4.5 Treatment of EMI/Embedded CCI Audio Device Functions
This section describes the behavior of audio device functions according to their ability to send/receive EMI and
detect/modify Embedded CCI. Refer to Appendix A for specific information about treatment of AM824 audio
including specific rules governing the audio application types supported.
For audio transmission, format non-cognizant recording functions are not permitted.
6.4.5.1 Embedded CCI for audio transmission
Three Embedded CCI states are defined for the transmission of audio content as shown in Table 13.
Value Meaning
11 Not Defined
10 Copy-permitted-per-type
01 No-more-copies
00 Copy-free
Table 13 Embedded CCI Values
The copy permission status associated with content marked Copy-permitted-per-type (Value 10) provides
flexibility by allowing each audio application to have its own Application Specific Embedded CCI (ASE-CCI). For
example, the ASE-CCI for IEC60958 conformant transmission is SCMS.
6.4.5.2 Relationship between Embedded CCI and EMI
In Table 7 the combination of EMI=Mode A and Embedded CCI=01 is allowed, but not typically used.

20
Recorded CCI is copy control information that is not embedded in the content program and does not require knowledge of the content
format to extract.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 46 (Informational Version) 2007-10-01
6.4.5.3 Audio-Format-cognizant source function
Audio-format-cognizant source functions recognize the Embedded CCI of a content stream being transmitted.
Table 14 shows the EMI that should be used for transmitted content streams containing component programs
with the following Embedded CCI values.
Embedded CCI of programs
00 01 10
EMI
Type specific
21
Mode A
Don't care
Cannot be
present
Present Mode B
Don't care Present Don't care Mode C
Present
Cannot be
present
Cannot be
present
N.A.
Table 14 Audio-Format-Congnizant Source Function CCI handling
6.4.5.4 Audio-Format-non-cognizant source function
For this function, the content must be treated in a manner consistent with its EMI.
6.4.5.5 Audio-Format-cognizant recording function
Audio-Format-cognizant recording functions recognizes the Embedded CCI of a received content program prior
to writing it to recordable media. Table 15 shows the CCI handling rules for each EMI Mode.
Embedded CCI of program
EMI
00 01 10
Mode A Recordable Do not record Recordable
22

Mode B Recordable Discard entire content stream
23
Recordable
22

Mode C Recordable Do not record Recordable
22

Table 15 Audio-Format-cognizant recording function CCI handling

21
Usage is format specific, see Appendix A for each AM824 usage.
22
The CCI value of No-more-copies shall be recorded with the program. Additional rules for recording are specified by each audio
application in the Appendix A.
23
If the function detects this CCI combination among the programs it is recording, the entire content stream is discarded.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 47
6.4.5.6 Audio-Format-cognizant sink function
Audio-format-cognizant sink functions can recognize the Embedded CCI of received content. Table 16 shows the
Embedded CCI of programs contained within the content stream that can be received.
Embedded CCI of program
EMI
00 01 10
Mode A Available for processing Available for processing Available for processing
Mode B Available for processing Discard entire content stream
24
Available for processing
Mode C Available for processing Available for processing Available for processing
Table 16 Audio-format-cognizant sink function CCI handling
6.4.5.7 Audio-Format-non-cognizant recording function
Audio-Format-non-cognizant recording function is not permitted.
6.4.5.8 Audio-Format-non-cognizant sink function
Audio-Format-non-cognizant sink functions shall behave as described in Section 6.4.4.6.
6.5 Common Device Categories
Devices may support zero or more of the functions described in Section 6.4.4.
Common types of fixed function devices include, but are not limited to:
1. Format-cognizant pre-recorded content source device has a format-cognizant source function.
(e.g., DVD player)
2. Format-cognizant real-time-delivery content source/decoding device has a format-cognizant
source function and format-cognizant sink function. (e.g., Set Top Box or Digital TV).
3. Format-cognizant recorder and player has a format-cognizant source function, format-cognizant
sink function, and format-cognizant recording function. (e.g., DV-VCR)
4. Format-non-cognizant recorder and player has a format-non-cognizant source function and format-
non-cognizant recording function. (e.g., D-VHS VCR)
5. Format-non-cognizant Bus Bridge has a format-non-cognizant source function and format-non-
cognizant sink function. (e.g., IEEE 1394 to IEEE 1394 bus bridge)

24
If the function detects this CCI combination among the programs it is recording, the entire content stream is discarded.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 48 (Informational Version) 2007-10-01
6.6 Content Channel Ciphers
All compliant devices support the baseline cipher and possibly additional, optional ciphers for protecting
content.
25

6.6.1 Baseline Cipher
All devices and applications must, at a minimum, support the baseline cipher to ensure interoperability. The M6
block cipher using the converted cipher-block-chaining (C-CBC) mode is the baseline cipher. This cipher is
described in DTCP Specification available under license from DTLA.
6.6.2 Optional Cipher
Support is defined in Chapter 4 (Device Capability Mask), Chapter 6 (Establishment of multiple K
X
values),
Chapter 8 (Encoding of cipher selection in the AV/C Digital Interface Command Set).
For optional content channel ciphers, Extended Full authentication is mandatory and therefore the other
Authentication procedures (Full, Restricted and Enhanced Restricted) are not used.
6.6.2.1 AES-128 Cipher
For AES-128 as an optional cipher, the Cipher Block Chaining (CBC) mode is used. AES-128 is described in
FIPS 197 dated November 26, 2001 and the CBC mode is described in NIST SP800-38A 2001 Edition.
Additional rules for AES-128 Cipher are described in the DTCP Specification available under license from DTLA.

25
Features of this specification that are labeled as optional describe capabilities whose usage has not yet been established by the 5C.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 49
6.6.3 Content Encryption Formats
6.6.3.1 For M6
Table 17 shows the content encryption formats that will be used with content channel ciphers.
Data Format Encryption Frame Size
MPEG Transport Stream IEC61883-4 Transport Stream Packet 188 Bytes
DV (SD Format) IEC61883-2 Isochronous Transfer Unit 480 Bytes
Rec. ITU-R BO.1516
26

System B Transport Stream
IEC61883-7 Transport Stream Packet 140 Bytes
Audio
Two AM824 data in IEC61883-6 and its
extension specification
27

8 Bytes
BT.601
Source Packet Data in BT.601 Transport
Over IEEE-1394
28

176-960
Bytes
29

Table 17 M6 Content Encryption Formats
6.6.3.2 For AES-128
Table 18 shows the content encryption formats that will be used with content channel ciphers.
Data Format Encryption Frame Size
MPEG Transport Stream IEC61883-4 Transport Stream Packet 188 Bytes
DV (SD Format) IEC61883-2 Isochronous Transfer Unit 480 Bytes
Rec. ITU-R BO.1516
26

System B Transport Stream
IEC61883-7 Transport Stream Packet 140 Bytes
Audio
Four AM824 data in IEC61883-6 and its
extension specification
27

16 Bytes
BT.601
Source Packet Data in BT.601 Transport
Over IEEE-1394
28

176-960
Bytes
29

Table 18 AES-128 Content Encryption Formats

26
This recommencation replaced Rec. ITU-R BO.1294.
27
1394 Trade Association Document 2001003, Audio and Music Data Transmission Protocol 2.0, August 21, 2001
28
1394 Trade Association Document 2006020, BT.601 Transport Over IEEE-1394 1.1a, October 2, 2006 is being discussed to be
IEC61883-8 starndard.
29
The size of Source Packet Data is 4 bytes smaller than the Source Packet size. It depends on Video Mode. Compression Mode, and Color
Space Mode as defined in BT.601 Transport Over IEEE-1394
28

Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 50 (Informational Version) 2007-10-01
6.7 Additional Functions
This section presents the behavior of additional functions according to EXHIBIT B of the DIGITAL
TRANSMISSION PROTECTION LICENSE AGREEMENT.
6.7.1 Move Function
Move function defined by DTLA has two modes, Move-mode and Non-Move-mode. If content is transmitted
using Move function, a Source function shall use Move-mode. Otherwise, Non-Move-mode shall be used.
In the case of audiovisual MPEG transmission, the modes are indicated in Appendix B.
In the case of DV format transmission, ISR in SOURCE CONTROL pack can be used to indicate the Move-mode
in combination with CGMS in the same pack as shown in following table.
Modes ISR CGMS
Move-mode 00
2
or 01
2
10
2

Non-Move-mode Other combinations
Table 19 DV Format Move Function Modes
For other transmission formats, Move function is an optional feature
30
that is not currently specified.
6.7.2 Retention Function
Retention function defined by DTLA has two modes, Retention-mode and Non-Retention-mode. If content is
transmitted for purposes of enabling Retention function, a Source function shall use Retention-mode. Otherwise,
Non-Retention-mode shall be used.
In the case of audiovisual MPEG transmissions, the modes are indicated in Appendix B.
In the case of DV format transmission, ISR in SOURCE CONTROL pack
31
can be used to indicate the Retention-
mode in combination with CGMS in the same pack as shown in the following table.
Modes ISR CGMS
Retention-mode 11
2
11
2

Non-Retention-mode Other combinations
Table 20 DV Format Retention Function Modes
For other transmission formats, Retention function is an optional feature
30
that is not currently specified.


30
Features of this specification that are labeled as optional describe capabilities whose usage has not yet been established by the 5C.
31
Refer to "IEC 61834 Helical-scan digital video cassette recording system using 6,35 mm magnetic tape for
consumer use (525-60, 625-50, 1125-60 and 1250-50 systems)
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 51
Chapter 7 System Renewability
7.1 Introduction
Compliant devices that support Full Authentication can receive and process system renewability messages
(SRMs) created by the DTLA and distributed with content. These messages are used to ensure the long-term
integrity of the system.
7.1.1 SRM Message Components and Layout
There are several components to a system renewability message (SRM):
A message Type field (4 bits). This field has the same encoding as is used for the certificate type field in
device certificates. See Section 4.2.3.1 for a description.
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. X
SRMC
<= SRMM).
Reserved field (8 bits). These bits are reserved for future definition and are currently defined to have a
value of zero.
A monotonically increasing system renewability message Version Number (SRMV) (16 bits). This value is
exchanged as X
SRMV
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.
The DTLA EC-DSA signature of these components using L
-1
(320 bits).
The structure of first-generation SRMs is shown in Figure 16. The fields in the first 4 bytes of the SRM comprise
the SRM Header.
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
Type Generation reserved (zero) Version Number
CRL Length CRL Entries (Variable size)

DTLA signature (320 bits)

Figure 16 Structure of the First Generation System Renewability Message
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 52 (Informational Version) 2007-10-01
7.1.1.1 Certificate Revocation List (CRL)
The Certificate Revocation List (CRL) identifies devices that are no longer compliant. It consists of the CRL
Length field that specifies the length of the CRL in bytes. This field is followed by a sequence of entry type
blocks (1 byte) which are in turn followed by the number of CRL entries specified by the entry type block. Two
types of entry block are supported. One byte provides for the revocation of individual devices while the second
allows for the revocation of blocks of up to 65535.
7.1.1.2 DTLA EC-DSA Signature
The DTLA EC-DSA signature field is a 320-bit signature calculated over all of the preceding fields of the SRM
using the DTLA EC-DSA private key L
-1
. This field is used to verify the integrity of the SRM using the DTLA EC-
DSA public key L
1
.
7.1.2 SRM Scalability
To ensure the scalability of this renewability solution, the SRM format is extensible. Next-generation extensions
(CRLs and possibly other mechanisms) to a current-generation SRM format must be appended to the current-
generation SRM (as shown in Figure 17) in order to ensure backward compatibility with devices that only
support previous-generation SRMs. Devices are only responsible for supporting the generation of SRM that was
required by the DTLA as of the time the device was manufactured. The conditions under which the DTLA will
authorize a new-generation SRMs are specified in the DTLA license agreement.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 53

DTLA Sig.
on Hdr. &
Part #1
SRM Part #1
(CRL)
DTLA Sig. on
all preceding
fields
SRM Part #2
SRM Part #N
DTLA Sig. on
all preceding
fields
SRM Header
Additional Generations
of SRM Formats
Max Size TBD
Lowest-priority
revocations in the
CRL in SRM Part #N
First-Generation
SRM Format
Max is defined
in DTCP spec.
Highest-priority
revocations go
in the CRL in
SRM Part #1
Second-Generation
SRM Format
Max is defined in
DTCP spec.
Lower-priority
revocations in the
CRL in SRM Part #2

Figure 17 SRM Extensibility
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 54 (Informational Version) 2007-10-01
7.2 Updating SRMs
System renewability messages can be updated from:
other compliant devices (connected via the digital transmission means) that have a newer list.
prerecorded content media.
content streams via real-time compliant devices that can communicate externally (e.g., via the
Internet, phone line, cable system, direct broadcast satellite, etc.)
The general procedure for updating SRMs is as follows:
1. Examine the version number of the new SRM.
2. Verify that the SRM version number is greater than the one stored in non-volatile storage.
3. Verify integrity with the DTLA public key (L
1
).
4. If the SRM is valid and either a more recent version or the same version and larger, then replace the
entire currently stored SRM with as much of the newer version of the SRM as will fit in the devices non-
volatile storage.
7.2.1 Device-to-Device Update and State Machines
7.2.1.1 Updating a Devices SRM from Another Compliant Device
If during the Full Authentication procedure a more recent (or more complete) system renewability message is
discovered on another device, the following procedure is used to update the device with the outdated and/or
less complete copy:
1. The device with the newer and/or more complete SRM sends it to the other device.
2. The device being updated verifies the candidate SRMs signature with the DTLAs public key.
3. If the signature is valid, the device being updated replaces the entire currently stored SRM in its non-
volatile storage with as much of the replacement message as will fit in its non-volatile storage.
This procedure should take place following the completion of the exchange of K
X
.
A detailed description of the System Renewability protocol and associated state machine can be found in the
DTCP Specification available under license from the DTLA.

Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 55
Chapter 8 AV/C Digital Interface Command Set Extensions
8.1 Introduction
Audio/video devices which exchange content via the IEEE 1394 serial bus are typically IEC61883 and AV/C
Digital Interface Command Set compliant. It is important to review Chapters 5, 6, and 7 of the Specification for
AV/C Digital Interface Command Set (General Specification) for general rules about the AV/C commands and
responses.
These specifications define the use of IEEE 1394 asynchronous packets for the control and management of
devices and IEEE 1394 isochronous packets for the exchange of content. This chapter describes extensions to
the AV/C command set which support the DTCP authentication and key exchange protocols. Extensions to the
IEEE 1394 Isochronous packet format are described in Chapter 6.
8.2 SECURITY command
A new Security command is defined for AV/C. This command is intended for content protection purposes
including the DTCP system. The general format of the SECURITY command is as follows:
msb lsb
Opcode SECURITY (0F
16
)
Operand[0] category (msb)
Operand[1]
: category dependent field
Operand[X] (lsb)
Figure 18 Security command
The value of the Security Command opcode is 0F
16
. (Common Unit and Subunit command)
The category field for the SECURITY command is defined as follows:
Value category
0 Support for DTCP AKE. This command is called the AKE command.
1 - D
16
Reserved for future extension
E
16
Vendor_dependent
F
16
Extension of category field
Figure 19 Security command category field
The value 0 of the category field specifies that this command is used to support the DTCP Authentication and
Key Exchange protocols.
The AKE command is defined for the ctype of CONTROL and STATUS. Devices that support the AKE command
shall support both ctypes.
The value E
16
of the category field specifies that this command is used by vendors to specify their own security
commands for licensed use.
8.3 AKE command
The destination of this command is the target device itself. Therefore the 5 bit subunit_type field of an AV/C
command/response frame is equal to 11111
2
and the 3 bit subunit_ID field of the frame is equal to 111
2
.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 56 (Informational Version) 2007-10-01
8.3.1 AKE control command
The AKE control command is used to exchange the messages required to implement the Authentication and Key
Exchange protocols. The format of this command is shown below:

msb lsb
Opcode 0F
16

Operand[0] category =0000
2
(AKE) AKE_ID
Operand[1] (msb)
Operand[2] AKE_ID dependent field
Operand[3]
Operand[4] (lsb)
Operand[5] AKE_label
Operand[6] number (option) status
Operand[7] blocks_remaining (msb)
Operand[8] data_length (lsb)
Operand[9]
: data
Operand[8+
data_length]
Figure 20 AKE Control Command
Both the AKE Command and Response frames have the same opcode and first 9 operands (operand[0-8]). The
value of each field in the response frame is identical to that of the command frame except for the status and
data fields. If any of the fields in the first 9 operands contain reserved values, a response of
NOT_IMPLEMENTED should be returned.
If a given command frame includes a data field, the corresponding response frame does not have a data field.
AKE control commands are used to send the information used for the authentication procedure being performed
between the source and sink device. This information is sent in the data field and is called AKE_info. Non-zero
values in Reserved_zero fields of AKE_info should be ignored.
The AKE_ID field specifies the format of the AKE_ID dependent field. Currently only the encoding AKE_ID = 0
is defined. The AKE_ID dependent field for this encoding will be described in Section 8.3.3. The other values,
from 1
16
to F
16
, are reserved for future definition.
The AKE_label field is a unique tag which is used to distinguish a sequence of AKE commands associated with a
given authentication process. The initiator of an authentication procedure can select an arbitrary value for the
AKE_label. The value selected should be different from other AKE_label values that are currently in use by the
device initiating the authentication. The same AKE_label value will be used for all control commands associated
with a specific authentication procedure between a source and sink device. The AKE_label and source node ID
of each control command should be verified to ensure that it is from the appropriate controller.
The optional number field
32
specifies the step number of a specific control command to identify its position in
the sequence of control commands making up an authentication procedure. The initiator of an authentication
procedure sets the value of this field to 1 for the initial AKE control command. The value is incremented for
each subsequent command that is part of the same authentication process. When an AKE command must be
fragmented for transmission (see the description of the blocks_remaining field below), each fragment will use
the same value for the number field. Devices that do not support this field shall set its value to 0000
2
.

32
Features of this specification that are labeled optional describe capabilities whose usage has not yet been established by the 5C.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 57
The status field is used to notify the device issuing the command of the reason when the command results in a
REJECTED response. The device issuing the command sets the value of this field to 1111
2
. If the responding
device rejects the command, it overwrites the status field with a code indicating the reason for rejection. The
encoding of the status field is as follows:
Value Status response code
0000
2
No error ACCEPTED
0001
2

Support for no more authentication
procedures is currently available
REJ ECTED
0010
2
No isochronous output REJ ECTED
0011
2
No point to point connection REJ ECTED
0100
2
DTCP unavailable REJ ECTED
0101
2
No AC on the specified plug
33
REJ ECTED
0111
2
Any other error REJ ECTED
1111
2
No information
Reserved for
INTERIM
34

Figure 21 AKE Control Command Status Field
The following status codes are for testing purposes only. Products shall not return these codes, but instead
return 0111
2
(any other error) if these conditions occur.
1000
2
Incorrect command order (only for test) REJ ECTED
1001
2
Authentication failed (only for test) REJ ECTED
1010
2
Data field syntax error (only for test) REJ ECTED
Figure 22 AKE Control Command Status Field Test Values
Commands are limited to a maximum length of 512 bytes by the underlying FCP transport. When a given
command is larger than the buffers in a controller or target device can accommodate, the blocks_remaining
field is used to fragment it. (A device issuing a command can determine the size of data field that the target
device can accept using the AKE status command). When this fragmentation is required, the data field is
broken into N blocks that are sent sequentially, each in one of N separate commands, where each command is
small enough to be accommodated by the controllers and targets command buffers. At a minimum, these
buffers must be able to hold a command with a 32-byte data field
35
. The size of the data field in the first N-1
fragments shall be the same size and a multiple of 16 bytes greater than or equal to 32 bytes.
Each of the N command frames is identical except for the values in the blocks_remaining, data_length, and data
fields. For the first command, the blocks_remaining field is set to the value of N-1. In each successive
command, the blocks_remaining field is decreased by one until it reaches zero, indicating the last command
fragment. If the value of the block_remaining field is not correct (e.g., not in the correct order), the target
should return a REJECTED response with status field of 0111
2
(Any other error).
When an AKE_info is transmitted using multiple Control Commands, a controller shall send each command only
after receiving an ACCEPTED response for the previous command.
The data_length field specifies the length of data field in bytes. Responses to a command will use the same
value for their respective data_length fields even when the response returns no data. If a response has some
data when the response code is ACCEPTED, the corresponding command will have no data but the value of the
data_length field shall be the same as that of response.

33
This status is used for AC. As for the usage of this status code, refer to section D.4
34
Response with INTERIM response code should not be used except for SET_DTCP_MODE subfunction described in section D.3.3.
35
If future generations of System Renewability Messages (SRMM>0) are defined which have a maximum size larger than 4096 bytes, new
devices will be required to support an increase in the minimum buffer size.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 58 (Informational Version) 2007-10-01
The data field contains the data to be transferred. The contents of the data field depend on the AKE_ID field
and the AKE_ID dependent field. For responses with a response code of REJECTED, there is no data field.
8.3.2 AKE status command
The format of the AKE status command is as follows:
msb lsb
Opcode 0F
16

Operand[0] category =0000
2
(AKE) AKE_ID
Operand[1] (msb)
Operand[2] AKE_ID dependent field
Operand[3]
Operand[4] (lsb)
Operand[5] FF
16

Operand[6] F
16
status
Operand[7] 7F
16
(msb)
Operand[8] data_length (lsb)
Figure 23 AKE Status Command
Both the Command and Response frames have the same structure. The values of each field of the command
and response frames are identical except for the AKE_ID dependent, status, and data_length fields.
The AKE_ID field specifies the format of the AKE_ID dependent field. The AKE_ID dependent field for this
encoding will be described in Section 8.3.3. Currently, only the encoding of AKE_ID=0

is defined. The other
values, from 1
16
to F
16,
are reserved for future definition.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 59
The status field is used by a device to query the state of another device. When the command is issued, the
value of this field is set to 1111
2
. In the response, the target device overwrites this field with a value indicating
its current situation.
Value Status Response code
0000
2
No error STABLE
0001
2

Support for no more authentication
procedures is currently available
STABLE
0010
2
No isochronous output STABLE
0011
2
No point to point connection STABLE
0100
2
DTCP unavailable STABLE
0111
2
Any other error STABLE
1111
2
No information
36
REJ ECTED
Figure 24 AKE Status Command Status Field
The following status codes are for testing purposes only. Products shall not return these codes, but instead
return 0111
2
(any other error) if these conditions occur.
1001
2
Authentication failed (only for test) STABLE
Figure 25 AKE Status Command Status Field Test Values
The data_length field specifies the target devices maximum data field capacity in bytes. When the status
command is issued, the value of this field is set to 1FF
16
. In the response, the target device overwrites this field
with a value indicating its current situation. The minimum value to be supported is 020
16
(32 bytes).

36
It is recommended that implementers not use the No information response.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 60 (Informational Version) 2007-10-01
8.3.3 AKE_ID dependent field (AKE_ID = 0)
When AKE_ID = 0, the format of the AKE_ID dependent field is as follows:
msb lsb
Operand[1] subfunction
Operand[2] AKE_procedure
Operand[3] exchange_key
Operand[4] subfunction_dependent
Figure 26 AKE_ID dependent field
The subfunction field specifies the operation of control commands. The most significant bit of the subfunction
field indicates whether the control command has data or not.
If the msb is 0, that command has some data and the data_length field indicates its length.
If the msb is 1, that command has no data and the data_length field indicates the length of the data field in
response frame whose response code is ACCEPTED.
The subfunctions are described in the DTCP Specification available under license from DTLA. The following table
lists currently defined subfunctions:
Value Subfunction Comments
01
16
CHALLENGE
Send random value. This subfunction when sent from a sink
device initiates the AKE procedure.
02
16
RESPONSE Return data computed with the received random value.
03
16
EXCHANGE_KEY
Send an encrypted Exchange Key (K
X
) to the authenticated
contents-sink device.
04
16
SRM Send SRM to a device that has an outdated or smaller SRM.
05
16
RESPONSE2
Return data computed with the received random value and a
unique value used to identify the sink device.
C0
16
AKE_CANCEL
Notify a device that the current authentication procedure cannot
be continued.
80
16
CONTENT_KEY_REQ Request the data required for making Content Key (K
C
).
81
16
SET_DTCP_MODE
Set DTCP mode: This subfunction is used for AC. Refer to
Appendix D.
82
16
CAPABILITY_REQ Use to determine the capability of the device.
Table 21 AKE Subfunctions
For status commands, the value of the subfunction field shall be set to FF
16
.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 61
Each bit of the AKE_procedure field corresponds to one type of authentication procedure, as described in the
table below.
Bit AKE_procedure
0 (lsb) Restricted Authentication procedure (rest_auth)
1 Enhanced Restricted Authentication procedure (en_rest_auth)
37

2 Full Authentication procedure (full_auth)
3 Extended Full Authentication procedure
38
(ex_full_auth, optional)
39

4 - 7 (msb) Reserved for future extension and shall be zero
Table 22 AKE_procedure values
For the control command, the initiator of an authentication procedure sets one bit in this field to specify which
type of authentication will be performed. The value of the field then remains constant through the rest of that
authentication procedure.
For the status command the initiator shall set the initial value of this field to FF
16
. The target will overwrite the
field, clearing the bits that indicate the authentication procedures that the target does not support as a source
device. For example, if a source device supports both Full Authentication and Enhanced Restricted
Authentication, the values of the AKE_procedure field would be set to 06
16
.
Sink devices should investigate which authentication procedures a source device supports using the status
command prior to starting the authentication protocol. The following table shows how to select the appropriate
authentication procedure:

Sink supported authentication procedures
Source supported
Authentication
Procedures
Rest_auth and
En_rest_auth
Rest_auth and
Full_auth
Rest_auth,
Full_auth and
Ex_full_auth
Rest_auth Restricted Authentication
Restricted
Authentication
Restricted Authentication
En_rest_auth and
Full_auth
Enhanced Restricted
Authentication
Full Authentication Full Authentication
En_rest_auth,
Full_auth and
Ex_full_auth
Enhanced Restricted
Authentication
Full Authentication
Extended Full
Authentication
Table 23 Authentication selection

37
Source devices that support the Full Authentication procedure shall verify the device certificate of the sink device and examine the SRM
even in Restricted Authentication. This authentication procedure is referred to as Enhanced Restricted Authenticationin this chapter.
38
Devices that support extended device certificates use the Extended Full Authentication procedure described in this chapter.
39
Features of this specification that are labeled as optional describe capabilities whose usage has not yet been established by the 5C.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 62 (Informational Version) 2007-10-01
Each bit of the exchange_key field corresponds to one (or more) key(s) as described in the table below:
Bit exchange_key
0 (lsb)
Exchange Key for M6 Copy-never content (requires Full or Extended
Full Authentication)
1
Exchange Key for M6 Copy-one-generation content (any
authentication acceptable)
2
Exchange Key for M6 No-more-copies content
(any authentication acceptable)
3 Exchange key for AES-128 (requires Extended Full Authentication)
4 7 (msb) Reserved for future extension and shall be zero
Table 24 Exchange_key values
For the control command, the sink device sets the value of this field at the start of an authentication procedure
to specify which Exchange Key(s) will be supplied by the source device after the successful completion of the
procedure. For Full Authentication any bit can be set for M6. For Restricted Authentication, only one bit for
Copy-one-generation or No-more-copies shall be set. This field remains constant for the remainder of the
authentication procedure except when the EXCHANGE_KEY subfunction is performed.
For the status command, the initiator shall set FF
16
in this field, and target shall clear every bit of the field that
corresponds to an Exchange Key that the target cannot supply.
For example, if target can supply three keys that correspond to bit0 through bit2 in the table above, the value
of the exchange_key field will be set to 07
16
.
A sink device should decide which key(s) it will require by getting this information in advance of the
authentication procedure.
The definition of the subfunction_dependent field varies. The DTCP Specification available under license from
the DTLA describes the definitions for control commands. For status commands the value of this field is set to
FF
16
for both the command and response frames.
8.4 Bus Reset Behavior
If the source device continues to transmit content on an isochronous channel following a bus reset, the same
Exchange Keys and Content Keys shall be used as were in use prior to the reset.
If a bus reset occurs during an authentication procedure, both the source and sink devices shall immediately
stop the authentication procedure. Following the reset, the Source Node ID (SID) field in the CIP header may
have changed requiring the sink device to restart the authentication procedure using the new SID.
8.5 Action when Unauthorized Device is Detected During Authentication
After returning an ACCEPTED response to an initiator of a command, the target examines the AKE_information.
If the target determines that the initiator is an unauthorized device then the target shall immediately stop the
AKE procedure without any notification.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 63
8.6 Authentication AV/C Command Flows
The following figures illustrate the AV/C command flows used for Full and Enhanced Restricted/Restricted
Authentication. Refer to Chapters 4, 5, and 6 for the specific ordering relationships between the various
messages.
8.6.1 Figure Notation
Solid lines indicate command/response pairs that are always performed.
Dashed lines indicate command/response pairs that are performed on a conditional basis.
8.6.2 Full Authentication Command Flow

Source Sink
AKE status command
AKE status response
CHALLENGE subfunction
response
AKE status command
AKE status response
CHALLENGE subfunction
response
RESPONSE subfunction
response
RESPONSE subfunction
response
EXCHANGE_KEY subfunction(s)
response(s)
SRM subfunction(s)
Response(s)
CONTENT_KEY_REQ subfunction
Response with data

Figure 27 Full Authentication Command Flow

Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 64 (Informational Version) 2007-10-01

8.6.3 Enhanced Restricted / Restricted Authentication Command Flow

Source Sink
AKE status command
AKE status response
CHALLENGE subfunction
response
AKE status command
AKE status response
CHALLENGE subfunction
RESPONSE subfunction
response
response
EXCHANGE_KEY subfunction
response
CONTENT_KEY_REQ subfunction
Response with data

Figure 28 Enhanced Restricted/Restricted Authentication Command Flow





Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 65
Appendix A Additional Rules for Audio Applications
Only AM824 is specified for audio transport, other formats are to be specified.
A.1 AM824 Audio
This section describes the behavior of AM824 audio device functions according to their ability to send/receive
EMI and detect/modify Embedded CCI. AM824 is an audio content format that is transmitted according to the
IEC61883-6 specification
40
and its extension specification
41
.
For AM824 audio transmission, devices supporting DTCP shall distinguish between application types by
detecting the LABEL value.
42

For AM824 audio transmission, the combination of EMI=mode A and Embedded CCI=01 is permitted and may
be used. Mode A is used for content that requires System Renewability as described in Chapter 7.
A.1.1 Type 1: IEC 60958 Conformant Audio
A.1.1.1 Definition
IEC 60958 conformant audio applications have a LABEL value of 00
16
-3F
16
. IEC61937 data can also be
transmitted using Type 1.
A.1.1.2 Relationship between ASE-CCI and Embedded CCI
This application type utilizes three values of Embedded CCI: Copy-free, Copy-permitted-per-type, and No-more-
copies. SCMS states are used as the ASE-CCI. The mappings between SCMS states as specified by IEC60958
are mapped to the Embedded CCI values as shown in the following table.
SCMS State Embedded CCI Value
Recordable (Copy free) 00 (Copy-free)
General 00 (Copy-free)
Recordable, set L bit to Home copy (Copy once) 10 (Copy-permitted-per-type)
Not recordable (Copy prohibited) 01 (No-more-copies)
Table 25 Relationships between SCMS State and Embedded CCI
A.1.1.3 Usage of Mode A (EMI=11)
The usage of Mode A for this application type is not currently specified.
A.1.2 Type 2: DVD-Audio
A.1.2.1 Definition
DVD-Audio applications have a LABEL value of 48
16
-4F
16
(for Audio data) and D0
16
(for ancillary data). ASE-
CCI is transmitted as ancillary data.

40
Consumer Audio/Video Equipment -Digital Interface - Part 6: Audio and music data transmission protocol.
41
1394 Trade Association Document 2001003, Audio and Music Data Transmission Protocol 2.0, August 21, 2001.
42
LABEL value is defined by the IEC61883-6 specification and its extension specification.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 66 (Informational Version) 2007-10-01
A.1.2.2 Relationship between ASE-CCI and Embedded CCI
This application type utilizes three values of Embedded CCI: Copy-free, Copy-permitted-per-type and No-more-
copies. audio_copy_permission
43
, audio_quality
43
, audio_copy_number
43
, and ISRC_status
43
,
UPC_EAN_ISRC_number
43
, and UPC_EAN_ISRC_data
43
are used as ASE-CCI. The following table shows
relationship between ASE-CCI and Embedded CCI.
ASE-CCI
audio_copy_permission
audio_quality

audio_copy_number,
ISRC_status,
UPC_EAN_ISRC_number,
and
UPC_EAN_ISRC_data
Embedded CCI

11
(No More Copies)
dont care dont care
01
(No-more-copies)
*
44


dont care
01
(No-more-copies)
10
(Copying is permitted
per
audio_copy_number )
*
45


refer to rule 2 of section
A.2.4
10
(Copy-permitted-
per-type)
00
(Copy Freely)
dont care dont care
00
(Copy-free)
Table 26 DVD Audio, Relationship between ASE-CCI and Embedded CCI
A.1.2.3 Usage of Mode A (EMI=11)
Mode A shall be used only for a stream which contains one or more of the following programs:
Audio quality of the transmitted program does not meet the requirements specified by the audio_quality,
and
The value of audio_copy_permission is 10
2
.
A.1.2.4 Additional rules for recording
1) AM824 Audio Format-cognizant-recording functions shall not request Exchange Keys
46
for Mode A and Mode
C.
2) An AM824 Audio Format-cognizant recording function shall comply with the rules for number of permitted
copies specified by section 7.2 of DVD Specifications for Read-Only Disc Part 4: AUDIO SPECIFICATIONS
Version 1.2.
A.1.3 Type 3: Super Audio CD
A.1.3.1 Definition
The Super Audio CD audio application has a LABEL value of 50
16
, 51
16
and/or 58
16
(for audio data) and D1
16
(for
ancillary data). Application specific embedded CCI is transmitted as ancillary data.

43
Refer to section 7.2 of DVD Specifications for Read-Only Disc Part 4: AUDIO SPECIFICATIONS Version 1.2.
44
Audio quality of the transmitted program does not meet the requirements specified by the audio_quality.
45
Audio quality of the transmitted program meets the requirements specified by the audio_quality.
46
See Section 6.2.1.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 67
A.1.3.2 Relationship between ASE-CCI and Embedded CCI
This application type utilizes one value of Embedded CCI: No-more-copies and both Track_Attribute
47
and Track
_Copy_Management
47
are used as ASE-CCI in this revision of this specification. The following table shows
relationship between ASE-CCI and Embedded CCI.
ASE-CCI
Track_Attribute Track_Copy_Management
Embedded CCI
0000
2
All 0 01 (No-more-copies)
Other combinations *
48

Table 27 Super Audio CD, Relationship between ASE-CCI and Embedded CCI
A.1.3.3 Usage of Mode A (EMI=11)
For a stream, that contains one or more of the following programs. Mode A shall be used:
The value of Track_Attribute 0000
2
and Track_Copy_Management is all 0.
Other combinations of Track_Attribute and Track_Copy_Management values in this revision of this
specification. They are reserved for future enhancement. This provision is subject to revision.
A.2 MPEG Audio
Audio Transmission via MPEG Transport Stream is an optional feature
49
that is not currently specified.



47
Refer to the Super Audio CD SystemDescription Version 1.2 Part 3.
48
These combinations are reserved for future enhancement and the associated Embedded CCI shall be regarded as No-more-copies for this
revision of this specification. This provision is subject to revision.
49
Features of this specification that are labeled as optional describe capabilities whose usage has not yet been established by the 5C.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 68 (Informational Version) 2007-10-01
Appendix B DTCP_Descriptor for MPEG Transport Streams
Appendix B is a supplement to Section 6.4 Copy Control Information (CCI) which describes a method for
carrying CCI in an MPEG-TS transmission.
B.1 DTCP_descriptor
As no standardized method for carrying Embedded CCI in the MPEG-TS is currently available, the DTLA has
established the DTCP_descriptor to provide a uniform data field to carry Embedded CCI in the MPEG-TS. When
MPEG-TS format content is protected by DTCP, the DTCP_descriptor shall be used to deliver Embedded CCI
information to sink devices.
B.2 DTCP_descriptor syntax
The DTCP_descriptor is defined in accordance with the ATSC_CA_descriptor specified by ATSC
50
document
A/70
51
and is described as follows:
Syntax Size(bits) Formats
52
Value
DTCP_descr i pt or ( ) {
descr i pt or _t ag 8 ui msbf 0x88
descr i pt or _l engt h 8 ui msbf
CA_Syst em_I D 16 ui msbf 0x0f f f
f or ( i =0; i <descr i pt or _l engt h- 2; i ++) {
pr i vat e_dat a_byt e 8 bsl bf
}
}
Table 28 DTCP_descriptor syntax
The definition of the private_data_byte field of the DTCP_descriptor is as follows:
Syntax Size(bits) Formats
52

Pr i vat e_dat a_t ype{
Reser ved 1 bsl bf
Ret ent i on_Move_mode 1 bsl bf
Ret ent i on_St at e 3 bsl bf
EPN 1 bsl bf
DTCP_CCI 2 bsl bf
Reser ved 5 bsl bf
I mage_Const r ai nt _Token 1 bsl bf
APS 2 bsl bf
}
Table 29 Syntax of private_data_type for DTCP_descriptor
The DTCP_descriptor allows for future expandability should it become necessary to add newly defined
Embedded CCI. In the event that additional Embedded CCI is defined by the DTLA to support additional

50
Advanced Television Systems Committee
51
Conditional Access System for Terrestrial Broadcast (A/70) ATSC standard
52
as described in the definition of ISO/IEC 13818-1
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 69
functionality, the length of the private_data_byte field and the descriptor_length value may be extended. If
this occurs, currently defined fields in the private_data_byte shall not be altered to ensure backward
compatibility. All devices shall be designed so that any change to the descriptor_length value that results from
an extension of the private_data_byte field shall not prevent access to contents of the private_data_byte
defined as of the time the device is manufactured.
B.2.1 private_data_byte Definitions:
Retention_Move_mode
This field is used to indicate the mode of the Move function or the Retention function in combination with the
DTCP_CCI as shown in following tables.

Modes Retention_Move_mode DTCP_CCI
Move-mode 0
2
10
2

Non-Move-mode Other combinations
Table 30 Move Function Modes

Modes Retention_Move_mode DTCP_CCI
Retention-mode 0
2
11
2

Non-Retention-mode Other combinations
Table 31 Retention Function Modes

Retention_State
53,54

This field indicates the value of the Retention_State.

Retention_State_Indicator Retention Time
000
2
Forever
001
2
1 week
010
2
2 days
011
2
1 day
100
2
12 hours
101
2
6 hours
110
2
3 hours
111
2
90 minutes
Table 32 Retention States

53
Definition and usage are specified in EXHIBIT B of the DIGITAL TRANSMISSION PROTECTION LICENSE AGREEMENT
54
If an inter-industry standard or consensus supports retention states that differ from those set forth in this Specification, then this
Specification may be amended or supplemented to reflect such consensus retention states.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 70 (Informational Version) 2007-10-01
Encryption Plus Non-assertion (EPN)
53

This field indicates the value of the EPN.

EPN
Meaning
0
2

EPN-asserted
1
2

EPN-unasserted
Table 33 EPN
DTCP_CCI
This field indicates the copy generation management information.
DTCP_CCI Meaning
00
2
Copy-free
01
2
No-more-copies
10
2
Copy-one-generation
11
2
Copy-Never
Table 34 DTCP_CCI

Image_Constraint_Token
55
This field indicates the value of the Image_Constraint_Token.
Image_Constraint_Token Meaning
0
2
High Definition Analog Output in the form of Constrained Image
1
2
High Definition Analog Output in High Definition Analog Form
Table 35 Image_Constraint_Token

APS
56

This field indicates the analog copy protection information.

APS Meaning
00
2
Copy-free
01
2
APS is on : Type 1 (AGC)
10
2
APS is on : Type 2 (AGC +2L Colorstripe
57
)
11
2
APS is on : Type 3 (AGC +4L Colorstripe
57
)
Table 36 APS
reserved : These bits are reserved for future definition and are currently defined to have a value of one.

55
Definition and usage of the Image Constraint Token is specified in EXHIBIT B of the DIGITAL TRANSMISSION PROTECTION
LICENSE AGREEMENT
56
as described in the Specification of the Macrovision Copy Protection Process for DVD Products, Revision 7.1.D1, September 30, 1999
57
2L/4L Colorstripe is applicable on for NTSC analog output.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 71
B.3 Rules for the Usage of the DTCP_descriptor
B.3.1 Transmission of a partial MPEG TS
58

When a partial MPEG-TS that includes one or more programs is transmitted using DTCP, Format-cognizant
source function shall insert the DTCP_descriptor into the PMT
59
of each program for which the CCI is not Copy-
free or EPN assertion is required. When the DTCP_descriptor is inserted, it shall only be applied to the PMT.
A Format-cognizant source function shall set the DTCP_CCI bits, APS bits, and any other Embedded CCI defined
by the DTLA within the DTCP_descriptor according to the CCI provided for each program within the MPEG-TS.
The DTCP descriptor shall be inserted into the program_info loop of the relevant PMT.
Additionally, if any of the Elementary Streams within a program are assigned specific CCI values, format-
cognizant source function shall set the DTCP_CCI bits, APS bits, and any other Embedded CCI defined by the
DTLA within the DTCP_descriptor according to that CCI. The DTCP_descriptor shall be inserted into the ES_info
loop of the relevant PMT for the Elementary Stream.
B.3.2 Transmission of a full MPEG TS
When a full MPEG-TS is transmitted with DTCP protection, the same rules as for partial MPEG-TS are applied for
all the programs within the TS.
B.3.3 Treatment of the DTCP_descriptor by the sink device
This section describes the treatment of the DTCP_descriptor when received by a sink device. When the function
of the sink device is format cognizant and receives recognizable Embedded CCI other than the DTCP_descriptor
within an MPEG-TS, the alternative Embedded CCI shall take precedence over the information contained within
the DTCP_descriptor. Furthermore, the DTCP_descriptor is only valid when it is inserted into the PMT. If a
DTCP_descriptor is found in another location, it shall be ignored.
When the only Embedded CCI detected is the DTCP_descriptor, the DTCP_descriptor shall be regarded as the
Embedded CCI described in Sections 6.4.4.3 and 6.4.4.4 and interpreted as follows:
If a DTCP_descriptor is found in an ES_info loop of the PMT, the Embedded CCI value contained in the
DTCP_descriptor should only be used as the CCI for the specific ES for which the DTCP_descriptor is associated.
If a DTCP_descriptor is not found in the ES_info loop for a specific ES, but is instead found in the program_info
loop, the Embedded CCI values contained within the DTCP_descriptor shall be used as the CCI for that ES.
A program in a stream shall be regarded as Copy-free if the stream contains multiple programs and neither
Embedded CCI nor DTCP_descriptor are detected in the program and a DTCP_descriptor is detected in another
program on the same stream.



58
as described in the definition of EN 300 468
59
as described in the definition of ISO/IEC 13818-1
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 72 (Informational Version) 2007-10-01
Appendix C Limitation of the Number of Sink Devices Receiving a
Content Stream
Without exception, the number of authenticated sink devices, including those connected via bus bridge devices
receiving content from a Full Authentication capable source device shall be limited to no more than 34 devices
at any time.
C.1 Limitation Mechanism in Source Device
A source device that has a Full Authentication capability shall count the number of sink device using a Sink
Counter. The source device shall increment the Sink Counter and register the Device ID after successful AKE
60

with an unregistered sink device where the sinks device certificate has an AP flag value of zero. The source
device shall also increment the Sink Counter after successful AKE regardless of its registration status, when the
sinks device certificate has an AP flag value of one. If the source device outputs content to different buses
separately, it shall count the number of the sink devices using one Sink Counter.
When the source device expires all Exchange Keys (see section 6.3.1), it shall reset the Sink Counter to zero
and clear the list of registered Device IDs. When the source device expires all Exchange Keys distributed to
certain sink device(s), it may decrement the Sink Counter by the number of the sink device(s) and clear
registered Device ID(s) of the sink device(s) from the list. When the source device expires all Exchange Keys
distributed to certain bridge device(s), it may decrement the Sink Counter by the number of successful AKE
with the bridge device(s). Except for this case, a source device shall not decrease nor reset its Sink Counter.
When the Sink Counter reaches the prescribed maximum limit of 34, the source device shall reject any further
authentication requests from both unregistered sink devices with a device certificate having an AP flag value of
zero and sink devices with a device certificate having an AP flag value of one with the status code of 0111
2
Any
other error. This status code should not be used for other commands to indicate that the Sink Counter is 34.

60
Successful AKE means after source device sends Exchange Keys.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 73
Start
(Full AKE Capable Source)
Sink Counter (SC) =0 and
Clear All Registrations
Kx Expired
(SC <34)
Full AKE or Enhanced
Restricted AKE
Sink is Registered
Register the Sink
SC =SC +1
Yes
Yes
Yes
Yes
Succeed
Fail
No
No
Reject AKE Request
No
No
Sink Registered
and AP=0
Full or Enhanced
Restricted AKE
No
Yes
AP =1

Figure 29 Sink Counter Algorithm (Informative)
When a source device that has CIH flag value of one receives RESPONSE2 subfunction with NB flag value of
one, it shall use ID
U
instead of Device ID and regard the value of the AP flag as zero for the above described
procedure.
C.2 Limitation Mechanism in DTCP Bus Bridge Device
The DTCP bus bridge device has transcrypting capability which uses a sink function and a source function where
the sink function decrypts the received content stream from upstream source(s) and the source function re-
encrypts the stream and sends it to downstream sink(s). A DTCP bus bridge device shall have Full
Authentication capability and have a device certificate with the AP flag value of one. The bridge performs
authentication with the upstream source as a proxy of downstream sink(s).
C.2.1 DTCP Bus Bridge Device Source Function
A DTCP bus bridge device shall count the number of authenticated downstream sink devices receiving the
content stream from an upstream source device using a Sink Counter. The bus bridge devices Exchange Keys
are those used by its source function.
The bridge device shall increment the Sink Counter and register Device ID after successful AKE with an
unregistered downstream sink device with a device certificate having an AP flag value of zero. The bridge device
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 74 (Informational Version) 2007-10-01
shall also increment the Sink Counter after successful AKE with a downstream sink device, regardless of its
registration status, where the downstream sink's device certificate has an AP flag value of one.
The bridge device shall reject the authentication request from both unregistered downstream sink devices
having an AP flag of zero and downstream sink devices having an AP flag of one with the status code of 0111
2

"Any other error", when the Sink Counter in the bridge device is equal to the prescribed maximum limit of 34.
This status code should not be used for other commands to indicate that the Sink Counter is 34. The bridge
device may reject further authentication request from unregistered downstream sink device having an AP flag of
zero or a downstream sink device having an AP flag of one with the status code of 0111
2
"Any other error",
when it judges a Sink Counter of an upstream source device is 34.
When a DTCP bus bridge device expires all Exchange Keys, it shall reset its Sink Counter to zero and clear the
list of registered Device IDs. When the source device expires all Exchange Keys distributed to certain sink
device(s), it may decrement the Sink Counter by the number of the sink device(s) and clear registered Device
ID(s) of the sink device(s) from the list. When the source device expires all Exchange Keys distributed to
certain bridge device(s), it may decrement the Sink Counter by the number of successful AKE with the bridge
device(s). Except for this case, a bridge device shall not decrease nor reset its Sink Counter. The bridge device
shall not expire its Exchange Key while it outputs any stream.
If a DTCP bus bridge device outputs the content to different buses separately, it shall count the number of the
sink device using one Sink Counter.
If a DTCP bus bridge device outputs different content streams to different buses separately, e.g. via two
transcrypting capability in a DTCP bus bridge device, the bridge device shall count the number of downstream
sink devices using one Sink Counter, as long as the same Exchange Key is used for all of the downstream
buses.
When a DTCP bus bridge device that has CIH flag value of one receives RESPONSE2 subfunction with NB flag
value of one, it shall use ID
U
instead of Device ID and regard the value of the AP flag as zero for the above
described procedure.
C.2.2 DTCP Bus Bridge Device Sink Function
A DTCP bus bridge device is strongly encouraged not to execute unnecessary authentication
61
, because the Sink
Counter in the source device always counts up after every successful AKE if the bridge device uses a device
certificate having an AP flag of one for authentication with an upstream source device.
It is recommended that a DTCP bridge device acquires all Exchange keys that the source device can supply in
one authentication procedure to avoid unnecessary incrementing of the upstream source devices Sink Counter.
When the bridge device's Sink Counter is non-zero and the bridge device has not obtained any Exchange Keys
yet from an upstream source device, the bridge device shall 1) complete successive successful AKEs with the
upstream source device the same times as the value of the Sink Counter before retransmitting any content
streams from the upstream source device or 2) expire its Exchange Keys, reset its Sink Counter and clear the
list of registered Device IDs.
A DTCP bus bridge device may or may not expire its Exchange Key when an upstream source device changes its
Exchange Key.
C.2.3 Extra Key handling
An Extra Key makes a DTCP bus bridge device possible to accept one authentication request from an
unregistered downstream sink device having an AP flag value of zero or a downstream sink device having an AP

61
For example, if a sink function, which is independent of transcrypting use (refer to C.2.6), in a DTCP bus bridge device repeats
authentication using device certificate having AP flag value of one regardless of expiration of Exchange Key(s), the Sink Counter in the
source device reaches to 34 even if the bridge device is the only one sink device in the system.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 75
flag value of one. To obtain one Extra Key, a DTCP bus bridge device shall complete successful AKEs
62
only with
all upstream source devices that have Full Authentication capability.
The Extra Key is consumed after the successful AKE with the downstream sink.
When a DTCP bus bridge device without an Extra Key receives an authentication request from an unregistered
downstream sink device having an AP flag value of zero or a downstream sink device having an AP flag value of
one, the bridge device rejects the authentication request with the status code of 0001
2
" Support for no more
authentication procedures is currently available", and starts to obtain an Extra Key. To avoid the rejection of the
authentication request, a DTCP bus bridge device without Extra Key may start to obtain one Extra Key. A DTCP
bus bridge device with an Extra Key is not allowed to start procedure for obtaining additional Extra Key.
C.2.4 Implementation of DTCP bus bridge
A DTCP bus bridge device may count the number of succeeded procedures for obtaining an Extra Key using a
Key Counter.
There are two types of DTCP bus bridge device which are differentiated by whether or not they have a Key
Counter.
C.2.4.1 Implementation of DTCP bus bridge device without Key Counter
Without Key Counter, a DTCP bus bridge device can have one Extra Key when the bridge device resets its Sink
Counter.
When a DTCP bus bridge device expires its Exchange Key
63
, the bridge device is recommended to keep its Extra
Key as long as the upstream source device uses the same Exchange Key to avoid redundant authentication with
the source device.
An informative example of state machine of a DTCP bus bridge device transferring content streams from one
source, which does not use Key Counter, is described in Figure 30.

62
If the upstream source device does not have Full authentication capability, a DTCP bus bridge device shall count the number of sink
devices instead of the source device. Therefore it does not need to request authentication with the source device to obtain an Extra Key.
63
Note that expiring Exchange Key in a DTCP bridge device without Key Counter may cause redundant sink counting in the upstream
source device that keeps using its Exchange Key.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 76 (Informational Version) 2007-10-01
S2: Waiting Authenti cation wi th an Extra Key
S1: Authenti cati on with source

StartAuthentication with source tself)
Reject Authentication request
(NO MORE AUTHENTICATION)
Authentication caused by internal
request (Option)
(Sink Counter <34)
Authentication failure
Authentication success
S3: Authentication with unregistered sink or bridge
Authentication requested from
unregistered sink or bridge
Authentication failure
S0: Unauthenti cated
S6: Authenti cation wi th source
S0:S1 S1:S2 S3:S4
S4:S6b
Authentication success

S6:S4
Authentication failure
Authentication requested from
unregistered sink or bridge
(Sink Counter <34)
S4:S6a
S4: Wai ting Authentication without Extra Key
S7: Authenticati on wi th registered si nk
Authentication success
S2:S7
Authentication failure
Authentication success
Source Kxchanged
B
Expire its own Kx
Sink Counter = 0
S5: Authentication with registered sink
Authentication requested fromregistered sink
Authentication success
S4:S5
S5:S4a
Authentication requested fromregistered sink,
and Sink Counter =34
Reject Authentication request
(ANY OTHER ERROR)
Authentication failure
B
Expire its own Kx
Sink Counter = 0
A
Source Kxchanged
S1:S0
Expire its own Kx, Sink Counter = 0
S2:S0
S5:S4b
S2:S3
S3:S2a
S2:S2
S6:S2
S7:S2a
S7:S2b
S4:S4a
Sink Counter = Sink Counter +1
Authentication requested from
registered sink
S4:S2
S4:S0
Authentication requested fromunregistered sink or bridge,
and J udging Sink Counter of original source is 34 (Option)
Reject Authentication request
(ANY OTHER ERROR)
S4:S4b
A
Expire its own Kx, Sink Counter = 0

Figure 30 DTCP bus bridge State Machine without Key Counter (Informative)
C.2.4.2 Implementation of DTCP bus bridge device with Key Counter
Using Key Counter, a DTCP bus bridge device can have the same number of Extra Keys as the Key Counter
when the bridge device resets its Sink Counter.
When a DTCP bus bridge device expires its Exchange Key, the bridge device is recommended to keep its Key
Counter as long as the source device uses the same Exchange Key to avoid redundant authentication with the
source device.
A DTCP bus bridge device shall reset its Key Counter to zero when there is only one upstream source device
and the upstream source device changes its Exchange Keys.
Before retransmission of the content stream from the upstream source device, the bridge device shall complete
successive successful Extra Key procedure(s) with the source device until its Key Counter is not less than its
Sink Counter, or expire its own Exchange Key
64
.
An informative example of state machine of a DTCP bus bridge device transferring content streams from one
source, which uses Key Counter, is described in Figure 31.

64
If the bridge device cannot increment its Key Counter up to its Sink Counter for some reason such that the authentication is not succeeded,
the bridge device is recommended to expire its Exchange Keys.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 77
S2: Waiting Authenti cation with Extra Key
(Key Counter > Sink Counter)
S1: Authenti cation with source

StartAuthentication with source tself)
Reject Authentication request
(NO MORE AUTHENTICATION)
Authentication caused by internal
request (Option)
(Sink Counter =Key Counter <34)
Authentication failure
Authentication success
S3: Authentication with unregi stered sink or bridge
Authentication requested from
unregistered sink or bridge
Authentication failure
S0: Unauthenticated
(Sink Counter = Key Counter = 0)
Key Counter = Key Counter+ 1
S6: Authentication wi th source
S0:S1 S1:S2 S3:S4
S4:S6b
Authentication success, and
Key Counter =Sink Counter +1,

S6:S4
Authentication failure
Authentication requested from
unregistered sink or bridge
(Sink Counter =Key Counter <34)
S4:S6a
S4: Waiting Authentication without Extra Key
(Key Counter = Sink Counter = 0)
S8: Key Counter < Sink Counter,
Key Counter =0
S7: Authentication with registered sink
S9: Authentication with source
Expire its own Kx (Option)
Sink Counter = 0
Key Counter = 0
Start Authentication with source (Option)

Authentication success
Key Counter = Key Counter + 1
S2:S7
Authentication failure
Authentication success
Expire its own Kx, Sink Counter = 0
Authentication failure, and Key Counter =0
Source Kxchanged and Sink Counter =0
B
Expire its own Kx
Sink Counter = 0
S5: Authenti cation with registered sink
Authentication requested fromregistered sink
Authentication success
S4:S5
S5:S4a
Authentication requested fromunregistered sink or bridge
(Sink Counter =Key Counter =34)
Reject Authentication request
(ANY OTHER ERROR)
Authentication failure
B
Expire its own Kx
Sink Counter = 0
A
Source Kxchanged
Key Counter = 0
B
Expire its own Kx(Option)
Sink Counter = 0
S10: Key Counter < Sink Counter, Key Counter = 0
Authentication success, and
Key Counter +1 <Sink Counter
Authentication success, and Key Counter +1 =Sink Counter
Key Counter = Key Counter+ 1 (= Sink Counter)
Start Authentication with source (Option)

Source Kx changed, and Sink Counter =0
Authentication failure, and Key Counter =0
S1:S0
Key Counter = 0
S2:S0
S8:S0
S2:S8
S8:S9
S9:S0
S9:S10a
S5:S4b
S2:S3
S3:S2
S2:S2
S6:S2
S7:S2a
S7:S2b
S10:S9
S9:S10b
S9:S4
A
S4:S4a
Sink Counter = Sink Counter +1
(= Key Counter)
Authentication requested from
registered sink
S4:S2
S4:S8
S10:S2
Authentication requested fromunregistered sink or bridge,
and J udging Sink Counter of original source is 34 (Option)
Reject Authentication request
(ANY OTHER ERROR)
S4:S4b
Authentication success, and
Key Counter >Sink Counter +1,
S3:S2
Sink Counter = Sink Counter +1
Key Counter = Key Counter+ 1

Figure 31 DTCP bus bridge State Machine with Key Counter (Informative)
C.2.5 Additional device certificate in a DTCP bus bridge device
A DTCP bus bridge device may have device certificate with the AP flag value of zero in addition to the device
certificate with the AP flag value of one. The device ID of these two device certificates are different each other.
A DTCP bus bridge device may request an authentication to an upstream source device using device certificate
with the AP flag =0 for avoiding unnecessary count up of the Sink Counter in the source device.
In this case, Exchange Key(s) obtained by the authentication shall be used for the sink function independent of
transcrypting use in the bridge device, or shall be treated as a successful AKE for obtaining one Extra Key
regardless of the times the bridge device obtains the same Exchange Key(s).
C.2.6 Treatment of additional function in a DTCP bus bridge device
A DTCP bus bridge device may also have recording function or source / sink function independent of
transcrypting use.
If the DTCP bus bridge device has recording function or sink function independent of transcrypting use, the
bridge device shall count the bridge device as an authenticated downstream sink device using the Sink Counter.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 78 (Informational Version) 2007-10-01
If the DTCP bus bridge device has source function independent of transcrypting use, the source function shall
count
65
the number of authenticated downstream sink devices receiving the content stream according to the
rules described in Appendix C.1.


65
Note that if the DTCP bus bridge device outputs content stream from both an upstream source device and the source function in the bridge
device to the same downstream bus, the number of authenticated downstream sink devices for the source function is also limited by the
upstream source devices sink number limitation, because Extra Key is needed.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 79
Appendix D DTCP Asynchronous Connection
D.1 Purpose and Scope
Appendix D specifies the mechanisms to use DTCP for Asynchronous Connection (AC). All aspects of the IEEE
1394 DTCP isochronous functionally described in Volume 1 body and the other Appendices are preserved and
this appendix only details AC specific rules or additions.
D.2 Transmission of Protected Frame
D.2.1 Overview
Frame is minimal transmission unit of AC. Before transmitting a Frame, AC between Producer (source device of
AC) and Consumer (Sink device of AC) is established using AV/C commands. One or more Frames are
transmitted from the Producer to the Consumer. After the Frame transmission, the AC is broken using AV/C
command. AC does not specify the size of the Frame. AC does not use special header when transmitting the
Frame. Only the Frame data is transmitted.
In case of DTCP-AC, DTCP specific information such as EMI, Odd/Even bit shall be transmitted. To transmit this
information together with Frame data, Protected Content Packet is introduced. In case of DTCP-AC, the
Producer converts a Frame to Protected Frame and transmitted it to the Consumer.
In this section, Protected Frame is defined and transmission methods for Protected Frame are specified.
D.2.2 Protected Content Packet
Protected Content Packet is used to carry the Frame in DTCP-AC. Figure 32 shows the structure of Protected
Content Packet.
msb lsb
Header [0] reserved (zero) (msb)
Header [1] dp_length (9 bits 2-504) (lsb)
Header [2] reserved (zero)
Header [3]

reserved (zero) EMI
Odd/
Even
reserv
ed
(zero)
Header [4]
:
Header [7]

reserved (zero)
PC[0]
-
-
-
PC[8N-1]


Protected Content
(8xN bytes: N=1-63)
66

Figure 32 Structure of Protected Content Packet

Protect Content Packet has eight bytes header (PCP header) and Protected Content. PCP header has following
field.

66
In case of AES-128 optional cipher, N=2-63.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 80 (Informational Version) 2007-10-01
dp_length: the value of this field shows the size of Data Packet in bytes (2-504).
EMI: Refer to section 6.4.2
Odd/Even: Refer to section 6.3.3
Protected Content (i.e. Encryption Frame) consists of a Data Packet and zero padding bytes which are
encrypted according to the value of EMI. The size of Protected Content is multiple of 8 bytes. Figure 33 shows
the structure of Data Packet.

msb lsb
Header [0] reserved (zero) CT
DB[0]
-
-
-
DB[M-1]


Data Block
(M bytes: M=1-503)
Figure 33 Structure of Data Packet
Data Packet has one byte header (DP header) and a Data Block. DP header has following field.
CT (Content Type): specifies the treatment of EMI/Embedded CCI for the Data Block in the Data Packet and
the value of which are described in following table:
CT Definition Meaning
0
2

Audiovisual
Content
Rules for audiovisual device functions described in Section 6.4.4 are applied
1
2
Audio Content Rules for audio device functions described in Section 6.4.5 are applied
Table 37 Content Type
Data Block contains a part of the data in the Frame to be transmitted through DTCP-AC.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
2007-10-01 (Informational Version) Page 81
D.2.3 Construction of Protected Frame
When a Frame is transmitted using DTCP, the Frame is divided into one or more Data Blocks from the top of the
Frame. The maximum size of the Data Block is 503 bytes. When the value of EMI and CT are not changed in
the middle of the Frame, the size of all Data Blocks is 503 byte except the last one which may contain less than
503 byte. When the value of EMI and/or CT is changed in the middle of the frame, the size of the Data Block
before the changing point may contain less than 503 byte, so that a Data Packet contains the data which has
the same EMI and the same CT.
Data Packet consists of one byte DP header and a Data Block. Data Packet size is within the inclusive range of
2 to 504bytes. If the size of the Data Packet is not multiple of 8 bytes, Encryption Padding bytes are added so
that encryption size becomes multiple of 8 bytes. The size of the Encryption Padding bytes is from 0 to 7
67
.
The value of each padding byte is 00
16
.
A Data block and Encryption Padding bytes are encrypted according to the value of EMI, and becomes a
Protected Content. The Size of the Protected Content is 8 x N bytes (N= 1, 2,.. 63). Protected Content Packet
consists of 8 bytes PCP header and a Protected Content. When the size of a Protected Content Packet is not
equal to 512 bytes, Alignment Padding bytes are added so that PCP header is located at every 512 bytes in the
Protected Frame. The size of the Alignment Padding bytes is 8 x M bytes (M= 0, 1,.. 62). Alignment Padding
bytes shall be used only when next Protected Content Packet has different EMI or CT during a Protected Frame
transmission.
Following figure shows the generic construction of Protected Content Packet in the Protected Frame.

Figure 34 Generic Construction of Protected Content Packet in the Protected Frame
D.2.4 N
C
Update Process
For DTCP-AC, the N
C
shall be updated after a Protected Frame is transmitted. If the size of a Protected Frame
is larger than 32,768PCPs (16Mbytes), the N
C
shall be updated every 32,768PCPs transmission. N
C
is updated
by incrementing it by 1 mod 2
64
.

67
In case of AES-128 optional cipher, when the size of Data Packet is 2 through 15 bytes, the size of Encryption Padding bytes becomes 1 to
14 bytes. When the size of Data Packet is 16 through 504 bytes, Encryption Padding becomes 0 to 7 bytes.

Alignment Padding
(8xM bytes : M=0-62)

PCP Header (8 bytes)
Encryption Padding
(0-7 bytes)
67

Data Block
(1-503 bytes)
(Data from Frame)
DP Header (1 byte)
512
PCP
DP
All data in Data Block is extracted from
Frame and has the same EMI & CT
Encryption padding may be necessary for the
last PCP of the Frame or next PCP has
different EMI/CT
Alignment padding may be necessary when
next PCP has different EMI/CT
Encrypted part.
The size of Encrypted part is
8xN byte (N=1-63)
Non-encrypted part.
Digital Transmission Content Protection Specification Revision 1.51 (Informational Version)
Page 82 (Informational Version) 2007-10-01
If a device has DTCP functionality for both isochronous transmission as a source device and AC as a Producer,
the device may use different N
C
for an isochronous transmission and AC. If a Producer has plural asynchronous
output plugs, the Producer may use different N
C
for each plug.
D.2.5 Duration of Exchange Keys
The K
X
for isochronous transmission shall also be used for K
X
for AC. K
X
for AC shall not be expired as long as
AC is established. When all ACs of the Producer are broken, K
X
of AC is recommended to be expired as long as
the Producer is stopping all isochronous output as a source device.
D.2.6 Frame Transfer type
AC specifies two types of frame transfers. They are file-type transfers and stream-type transfers.
D.2.6.1 File-type Transfer
In file-type transfers, all of the selected frame data in the Producer is transmitted to the Consumer. DTCP-AC
described in this Appendix is applied to file-type transfers.
D.2.6.2 Stream-type Transfer
DTCP-AC for stream-type transfers is an optional feature
68
that is not currently specified.
D.3 Embedded CCI
Embedded CCI is carried as part of the content stream. Many content formats including MPEG have fields
allocated for carrying the CCI associated with the stream. The definition and format of the CCI is specific to
each content format. Information used to recognize the content format should be embedded within the content.
D.4 AKE Command Extensions
The DTCP Specification available under license from the DTLA describes the AKE command extensions for DTCP-
AC.


68
Features of this specification that are labeled as optional describe capabilities whose usage has not yet been established by the 5C.