Encrypting High Definition Video for Network transmission

using HDCP

Prof. Hans-Joachim Gelke

Institute of Embedded Systems
Zurich University of Applied Sciences
Technikumstrasse 20/22
CH-8401,Winterthur, Switzerland
hans.gelke@zhaw.ch

ABSTRACT If Ethernet or wireless networks retransmit HDCP protected

Retransmitting High Bandwidth Digital Contend Protected video, downstream HDCP protection is mandatory.
(HDCP) audio and video through networks requires to ad- A research project at Institute of Embedded Systems shows
here to the HDCP standard and a license issued by Digital the feasibility to add HDCP content protection to an already
Content Protection, LLC. The intention is to prevent unau- existing platform which is capable of transmitting HD video
thorized interception and copying of motion pictures and over Ethernet (see figure 1).
television programs. While en- decrypting HDCP signals in
Bluray players, set top boxes and TVs is accomplished with
off the shelf components, there is no easy HDCP 2.1 solution
to en-decrypt contend protected material to be sent over
Ethernet, wireless or fiber optic channels. This paper de-
scribes possibilities to accomplish HDCP 2.1 en-decryption
and key exchange in an FPGA by sharing hardware and
processing power with the already existing soft core proces-
sor and such avoiding additional hardware. The following
subjects are discussed: Introduction to HDCP, authentica-
tion and key exchange, pairing, locality check, session key
exchange and FPGA implementation of HDCP functions in
Programmable Systems on Chip (PSoC). Considerations on
which components are better suited to be implemented in Figure 1: Original InES system for transmitting
logic cells or in firmware and additional discussions about video over Ethernet
the licensing and key purchase process are made.
1.1 Research Platform
Keywords Figure 2 shows a block diagram of the original platform
HDCP, HDMI, RSA, AES, Digital-CP LLC, HMAC-SHA256 whose main components are: Video I/O-modules, JPEG2000
compression devices, Ethernet physical interface and FPGA
1. INTRODUCTION with soft core processor.
The Institute of Embedded Systems (InES) is specialized in
the research of Real Time Ethernet solutions which com- The system is controlled by Linux and a user interface real-
prises transmission of high definition video and audio over ized with an embedded Web server.
Ethernet.
The PC and consumer electronics world are merging and
most new PCs are now equipped with HDMI, Display Port,
DVI and other multimedia interfaces capable of playing back
high definition video content. Therefore those outputs are
protected with HDCP if they are capable of outputting copy-
righted contents.

Figure 2: Original HD Video transmission system

with FPGA

1.2 The HDCP Cryptographic System

In 2003 Intel developed the HDCP encryption system to
copy protect audio and video data during transmission be-
tween transmitter and receiver. If the transmitting device
(e.g. Bluray player) requires a HDCP connection, the re- 2.1 Authentication and Key Exchange
ceiver needs to support HDCP as well. Video and audio data Before the transmitter begins sending encrypted video, an
are transmitted in encrypted form. Receiver and transmitter Authentication Protocol must be successful.
need to exchange a common key. Parts of the Authentication Protocol are:

1. Authorization and Key Exchange - The Receiver must

posses an unrevoked public key certificate

2. Locality Check - A round trip time measurement to

restrict distribution to a locality

3. Session Key Exchange - A common key used for pay-

load encryption

4. Authentication with Repeaters - To control content

Figure 3: Encrypted HDCP 1.x transmission be- distribution to simultaneous sinks
tween a Bluray player and monitor

The currently actual HDCP 1.4 specification [5] describes The Authentication and Key Exchange (AKE) process af-
the protection mechanism between a HD-source device (e.g. firms the HDCP Transmitter that the HDCP Receiver is
Bluray Player) and a HD-sink (e.g. TV-monitor or sur- authorized to receive HDCP content and results in a com-
round amplifier). The physical interface is not restricted mon secret Master Key (km), which is used to exchange a
to a HDMI cable but could be also Display Port, DVI or Session Key (ks). The Session Key is used for the AES
other cable links allowing transmission of HDCP content. encryption of audiovisual content.

1.3 HDCP 2.1 Interface Independent Adapta- 2.1.1 Principles of the RSA Crypto System
tion Authentication and Key Exchange is based on derivates of
the RSA Crypto System which is used for encrypting the
In parallel to the original 1.x HDCP Specifications, which
Master Key(km) and verifying a so called HDCP Receiver
describe the protection mechanism of point to point cable
Certificate.
connected devices, there is also a HDCP 2.1 specification
[7], which describes Interface Independent HDCP adapta-
tions such as Ethernet, WLAN, Wireless Home Digital In-
RSA is a cryptographic procedure which is used for decrypt-
terface (WHID) and others. The HDCP 2.1 specification
ing and encrypting data. It is using a pair of keys consisting
provides more sophisticated cryptography and additional
of a Private Key and a Public Key.
features such as measuring the link round trip time to con-
tain transmission inside a local area (locality check). HDCP
2.1 does not replace but coexists with the 1.4 specification.
The Public Key is used to encrypt and check signatures. The
Private Key is used to decrypt or sign data. The Public Key
HDCP 2.1 is found in HD-players which distribute contents
is not secret and can be transmitted in plain text.
to one or several HD-Monitors via wireless interfaces or in
The Private Key is kept secret and can be derived from the
bridges which convert HDMI to Ethernet and vice versa.
Public Key only with extremely high effort.
In HDCP 2.1 each receiver has its own Private Key and
Public Key pair.

Figure 4: HDCP 2.x for interface independent links

The use case shown in figure 4 requires the coexistence of

HDCP 1.x and HDCP 2.x specifications. While 1.x is eas-
ily realized with off-the-shelf HDMI chips, HDCP 2.x often
has to be implemented according to the users architecture
requirements.

2. INTRODUCTION TO HDCP 2.1

HDCP 2.1 does not reinvent Cryptography, but applies a
combination of state of the art cryptographic standards.
While RSA is used for authentication and key exchange, the
AES standard is used to encrypt the audiovisual payload. Figure 5: RSA cyphering using a Public and Private
Key Pair
The advantage of RSA cryptography with a public key and a CRT coefficient: qinv = q 1 mod p
private key pair is, that there is no identical secret key which
has to be exchanged between receiver and transmitter.
The disadvantage of RSA encryption is that the calculation Decyphering can then be split up into the two functions:
of cypher text and plain text is elaborate.
m1 = cdp (mod p) respectively m2 = cdq (mod q)
The public key consists of a pair of numbers (e,n) and the
private key of a pair of numbers (d,n). N is the RSA Module resulting in:
n = pq based on the prime numbers p and q. The RSA
module n is the same for public and private key. m = (qinv (m1 m2)mod p)q + m2 = cd ( mod pq)

Figure 6 shows how clear text ((m)) is encrypted into cyphered This is more efficient than computing m = cd ( mod pq) even
text ((c)). though two modular exponentiations have to be computed.
The reason is that these two modular exponentiations use a
smaller exponent and a smaller modulus.

2.1.4 Receiver Certificate

For every HDCP 2.1 receiver, the HDCP license needs to
purchase a receiver certificate, which provides each receiver
with a unique identification and the receiver Public RSA
Key. The contents of the certificate is shown in table 1. It
Figure 6: RSA Encryption of Clear Text contains the receiver identification, the receiver public key
and a cryptographic signature over all fields of the certifi-
Figure 7 shows how cyphered text (c) is decrypted into Clear cate.
Text (m) is decrypted.
Content Size/bits
Unique Receiver ID 40
Unique RSA Public Key 1048
Reserved 16
Cryptographic signature 3072
of preceding fields

Table 1: Contents of individual receiver certificate

Figure 7: RSA Decryption of Clear Text
In order to verify that the receiver certificate is authentic,
2.1.2 Measures to increase RSA security the HDCP transmitter decrypts the signature field and com-
Since plain RSA is deterministic, it is possible to guess a pares it to the hash value of the received certificate (see fig-
clear text, encrypt it with the public key and compare the ure 8). If the values are identical, the HDCP transmitter is
resulting cypher text. With sufficient computing power, assured that the HDCP receiver owns an original certificate
large tables can be built and eventually the private key and the message was not tampered.
can be concluded. To avoid attacks, a derivate of the plain
RSA method can be used. HDCP uses Optimal Asymmetric
Encryption Padding (RSAES-OAEP) utilizing padding and
hash functions.

2.1.3 The Chinese Remainder Theorem

Dencrypting with the private key requires a high effort of
computing power, therefore the Chinese Remainder Theo-
rem helps decyphering and signing data faster and more
efficient. Since the module n and exponent d are very large
and therefore high computing power is required, the Chinese
Remainder Theorem allows to split the private key in two
smaller exponents dp and dq and modules p and q. HDCP Figure 8: Verifying the certificate
delivers the Receiver Private Key based on the Chinese Re-
mainder theorem as a quintuple of:
2.1.5 Message Authenticity Check with HMAC-SHA256
For proving the authenticity of messages in HDCP, an en-
First prime number: p crypted hash number of the message is calculated. The re-
sulting signature is called Hash-based Message Authenticity
Second prime number: q Code (HMAC). The HMAC-SHA256 is a message authenti-
Decypher Exponent: dp = d mod (p 1) cation method based on a SHA256 hash function. The input
to the HMAC-SHA256 is a key, possibly combined with a
Decypher Exponent: dq = d mod (q 1) random number, and a message. The output is hash based
message access code (HMAC), which can be considered a The transmitter verifies the signature of the certificate using
signature . the DCP Public Key (keypubdcp) (see section 2.1.5). The
HDCP 2.1 public key is known to everyone and published
in the HDCP specification. Failure of signature verification
causes the HDCP to abort the authentication protocol.

If the transmitter does not have the 128-bit Master Key

(km) stored from previous sessions (see pairing below), the
transmitter generates the pseudo random 128-bit Master
Key (km), RSA encrypts it with the Receiver Public Key
and sends it to the receiver (see section 2.1.1).

Figure 9: Applying the HMAC-SHA256 for message After a transmitter sent the encrypted Master Key, it checks
authentication whether the Receiver ID of the connected device is found on
the Revocation List. A Receiver ID found on the Revoca-
Figure 9 shows how the HMAC-SHA256 is applied for mes-
tion List means that the HDCP revoked the license for the
sage authentication. The transmitter asks the receiver to
receiver and the AKE is aborted.
calculate the HMAC value of the message. The message is
sent in plain text to the receiver. The receiver calculates a
HMAC based on a key and a message and sends it back to
In the meantime the receiver received the encrypted km and
the transmitter. The transmitter compares if the received
RSA decrypts it with the corresponding Receiver Private
HMAC is identical to its own HMAC. Only someone who is
Key. This process is the most calculation intensive, due to
in possession of the pre-shared key and pre-shared random
the large RSA private key. HDCP requires that this process
number can compute the correct HMAC. Additionally, it is
and the subsequent hash value calculation must be com-
impossible to conclude the key from the HMAC, because the
pleted within one second.
HMAC-SHA256 algorithm is a one way function.
After the receiver successfully has decrypted km, it sends
back (H), a HMAC-SHA256 (see section 2.1.5) hash value
In HDCP the HMAC-SHA256 method is used for:
of the Master Key derivate. Sending back the hash value
assures the transmitter, that the receiver could successfully
1. Proving the transmitter that the receiver correctly de- decrypt the Master Key (km).
crypted the Master Key(km) After the transmitter successfully received the hash Value(H)
from the receiver and compared it to the own calculated
2. Authentication required when measuring the distance hash value (H), the Authentication and Key Exchange is
between receiver and transmitter (locality check) completed; otherwise the AKE is aborted.

2.1.6 Authentication and Key Exchange Flow

2.1.7 Pairing
A process called pairing may speed up the authentication
protocol by storing and reusing the Master Key (km) of a
previous authentication session and exchanging a new km
may be skipped.

To abbreviate the authentication process if the HDCP de-

vice configuration stays the same, the receiver sends the
AES encrypted (with receiver private key) Master Key to
the transmitter (see figure 11). The transmitter stores the
AES encrypted Master Key and the Master Key itself. If
the same devices meet again, the saved km will be reused.
By the next time a receiver connects to a transmitter, the re-
ceiver needs to perform only an AES decryption to get the
Master Key. The time savings during the authentication
process can be up to one second.
Figure 10: Simplified authentication flow
2.1.8 Locality Check
The Authentication and Key Exchange is initiated by the The locality check has to make sure that receiver and trans-
HDCP transmitter, sending an authentication initiation mes- mitter are in the same building (or at least close). Sharing
sage, containing a 64-bit pseudo random number (rtx) and HDCP content over long distances must be inhibited. For
the transmitter information (shown in Fig. 10). this purpose the HMAC-SHA256 message authentity check
as described in 2.1.5 is used.
The receiver responds by sending its Receiver Certificate and The transmitter sends a Random Number (rn) to the re-
receiver information to the transmitter. ceiver and expects a HMAC-SHA256 value L, calculated on
 Figure 13: Locality check with pre-computed hash
value

Figure 11: AES encrypted Master Key is stored by

transmitter and retrieved by receiver

Figure 14: Session Key Exchange

Session Key is used for the AES encryption of the audio

and video data.

2.2 HDCP Encryption according to the Ad-

vanced Encryption Standard AES
Figure 12: Rround trip time determines distance to At least 200 ms after the successful Session Key Exchange
receiver (SKE), the transmission of encrypted audiovisual content
may start. For the encryption and decryption, a 128 bit AES
core is used. The key for the AES core is the Session Key
rn and derived key (kd), of this random number back within
(ks) xored with a Secret Constant (lc128). This constant is
7ms. If the HMAC is not ready in time, the connection will
provided by DCP LLC and is identical for all devices. The
be aborted.
AES encryption and decryption is running in counter mode
(see figure 15). This means not the audio visual content is
Calculating the HMAC in software requires 70 ms, much
encrypted, but a 128-bit Counter value (inputCTR). This
longer than the required 7 ms. This means, locality mea-
counter value is the plain text input of the AES core. The
surement would require HMAC calculation with FPGA logic
audiovisual content is divided into 128-bit packets. For every
cells. However, the newer HDCP 2.1 specification adds a
packet, the counter value is incremented and encrypted to
pre-compute option. The HMAC may be computed by the
generate 128-bit of cypher text. This cypher text is XORED
transmitter and receiver prior to location measurement. Dur-
with the audiovisual content.
ing round trip measurement, the transmitter merely sends
a challenge consisting of the least significant 128-bits of its
computed hash value L (see figure 13). If the bits match,
The Framer transmits the counter value (in plain text) to-
the receiver sends back the most significant bits of its own
gether with the corresponding encrypted data to the re-
computed hash value L, which are compared by the trans-
ceiver. To get the original data, the receiver has to encrypt
mitter.
the received counter value and XOR the result with the en-
crypted data. XORing the audiovisual data twice with the
2.1.9 Session Key Exchange same cypher text will result in the original data.
If the preceding tests were successful, the transmitter gener-
ates a true random 128-bit Session Key. The Session Key is The InES implementation deviates slightly from the HDCP
encrypted based on the Master Key (known to receiver and specification. The HDCP specification describes an addi-
transmitter) and sent to the receiver (see figure 14). The tional Stream Counter, which allows multiplexing multiple
 3.1.1 RSA Decryption in C
Trials using the Big Digits Library for modular exponen-
tiation [2] showed that the decryption process done in C
took about 1.8 seconds, while the HDCP standard allows
only one second including hash calculation (see figure 10).
The calculations were done with a 100 DMIPS FPGA soft
core processor and hardware multipliers enabled. Therefore,
calculations could not be completed without increasing the
timeout from one to two seconds. Increasing the timeout
makes HDCP 2.1 incompatible to third party systems.
To accomplish modular exponentiation well within one sec-
ond, implementation of the modular exponentiation algo-
Figure 15: AES Encryption of Audio/Video Content rithms in FPGA hardware might be a feasible solution. Al-
ternative software implementations with higher clock fre-
quency hard cores or external processors need to be investi-
gated.
MPEG Elementary Streams. Since we transmit audio and
video in one stream, the stream counter value is always zero.
The counter mode has the following advantages [3]: 3.1.2 HMAC calculation for verifying km decryption
HMAC calculation (H)is performed in the receiver follow-
ing the Master Key encryption and decryption process (see
An identical AES encryption core can be used for the section 2.1.5). An evaluation of HMAC calculation in soft-
transmitter and the receiver. Only an AES encryption ware found out, that calculation lasts about 70 ms; which is
type core is required, no AES decryption type core only a fraction of the required one second for km decryption
is required, which makes the data encryption and de- and HMAC calculation(see figure 10). Hardware support for
cryption operation identical (XOR the payload with HMAC calculation therefore gains no advantage.
an encrypted counter value)
3.1.3 Locality Check
Replay attacks are impossible because every encrypted Locality check uses the same HMAC algorithm as used for
counter value looks different and therefore every trans- proving that the receiver has correctly decrypted km (see
mitted package looks different (even if the original con- section 2.1.5). The older HDCP 2.0 specification dictates
tent does not change). Because the counter value is HMAC calculation including round trip measurement time
increased with every 128-bit of generated cypher text, within 7 ms, however the soft core processor requires 70
a counter value is used only once. ms for HMAC calculation alone, which exceeds round trip
measurement by a factor of 10.
If a packet gets lost, synchronization is not at risk, During the course of the project, HDCP specification 2.1 was
because the counter value is transmitted with the en- released, in which the HMAC value for the locality check
crypted data (L) may be precomputed and round trip measurement is
accomplished by merely exchanging challenges. This allows
HMAC calculation for locality check in software only.
3. IMPLEMENTATION IN FPGA
HDCP specifies only the round trip time of 7ms for the lo-
3.1 Computing Performance Considerations cation measurement but gives no distance figure. If the AV
Since the system is commanded by a processor running a content is transmitted over a low latency Ethernet network,
Linux operating system, it makes sense to outsource as many in 7ms the signal may possibly travel up to 250km and back.
tasks as possible to the Linux user space; taking good care
of nobody tampering the operating system from the outside.
However, implementing cryptographic algorithms in C is cal- 3.1.4 Calculating Pairing Information
culation intensive, since many algorithms contain exponen- Calculating the pairing information before sending it to the
tial and modulus operations with number sizes over several transmitter requires an AES encryption of the Master Key
1000 bits. An additional problem arises since the standard by the receiver (see section 2.1.7). Authentication with pair-
integer range and the C math library does not support sizes ing information requires that the receiver AES decrypts the
that large. Master Key. According to the AKE Flow (see figure 10)
both may not last longer than 200 ms. It shows that AES
A free library of multiple-precision arithmetic routines writ- encryption for pairing can easily be accomplished in software
ten in ANSI C to carry out large natural number calcula- and needs no hardware support.
tions (Big Digits) was used for the cryptographic algorithms.
The Big Digits library is available from DI Management, an 3.2 AES Encryption Block
Australian based computer consultancy firm, which offers Even so AES encryption is done on JPEG2000 compressed
the library free for download [11]. The Big Digits library video, there may be data rates of up to 1Gbit/s, which can
includes multiple-precision arithmetic algorithms like add, not yet be reached by FPGA soft or hard core processors.
subtract, multiply and divide. The library includes modular Since the Audio and Video information is already processed
multiplication, exponentiation and inversion and is therefore by the FPGA, it makes sense, to implement the AES en-
especially helpful for the RSA algorithms. cryption core in FPGA as well. Figure 16 shows where the
new AES core is placed inside the FPGA. file resulted in a 1.7% smaller file [3]. This proofs the
realtively high entropy of the generated file.
The second test executed, even so not required by the
HDCP, was the NIST Statistical Test Suite; only half
of the tests passed [3].
The HDCP recommended method of a Pseudo Ran-
dom Number Generator, seeded by a true TRNG could
be an alternative to get better results but was not
tested.

3.4 Making the FPGA system tamper proof

Figure 16: Prototype System with AES Block in The Linux operating system and the Web server require spe-
FPGA cial precaution to prevent intruders from getting access to
secret keys.
In addition, FPGA Systems are especially susceptible for at-
Since there are many commercial and non commercial AES
tacks since the entire design (FPGA configuration and pro-
FPGA IP blocks available, this block does not need to be
cessor software) is not safely contained inside a hard coded
designed from scratch. It should be considered, that some
IC, but loaded from an external configuration Flash PROM
AES implementations are specific to a certain FPGA archi-
every time the system is powered up. Attackers could eaves-
tecture only.
drop the configuration Flash and extract the keys while they
are loaded into the FPGA. Therefore it is highly recom-
For the prototype we chose an AES core from Open Cores
mended to use an FPGA which has the capability to encrypt
[10], because it provides sufficient performance and utilizes
the configuration Flash.
the least amount of resources. Furthermore, this core is suit-
able for all FPGA types.
This core is not pipelined and therefore requires 12 clock
cycles to encrypt each 128-bit word at a maximum clock
frequency of 107 MHz, which translates into a data rate of
1.067 Gbit/s. This data rate is enough to transfer a com-
pressed 1080p/50 Hz Full-HD video and takes full advan-
tage of Gigabit Ethernet. Synthesized into a 120k logic cell
FPGA, it requires about 4% of FPGA space [3].

3.3 Random Number Generator

In cryptographic systems, true random numbers are very
important, to avoid for example replay attacks. Random
numbers are required by HDCP for Key Generation and
must not be predictable, continue to resurface or be static.

The HDCP standard differentiates between True Random

Numbers and Pseudo Random Numbers. True random num-
bers are required only for the Master Key (km) and the
Session Key (ks), all other random numbers may be pseudo
random numbers.

Figure 17: Partitioning of the FPGA Configuration

3.3.1 Pseudo Random Number Generator Flash
Pseudo Random Number Generators (PRNG) are readily
available as FPGA IPs. The following precautions were taken in the prototype:
Entropy sources for non secret numbers can be timers, net-
work statistics, error connection signals or the video signal.
1. Placing secret keys in separate encrypted mem-
ory section
3.3.2 True Random Number Generator The Receiver Private Key, the stored Master Key for
FPGA manufacturers offer true random noise generators pairing and the Secret Global Constant (lc128) are
(TRNG), which utilize race conditions on the FPGA and stored in a separate section of the configuration Flash,
are equivalent to analog noise generators. For the prototype which is encrypted by a cypher algorithm e.g. AES,
such a FPGA True Random Number Generator [1] was in- blowfish. The cypher key is stored in the encrypted
vestigated by two tests: FPGA configuration section (see next).
2. Placing software encryption keys in (encrypted)
Zipping files takes advantage of data repetition. A file FPGA configuration section
with high entropy should be difficult to zip. Trying The FPGA configuration information is scattered through-
to Zip compress a 9.6 MB randomly generated noise out this section and only FPGA manufacturers know
 the details on where which information is stored. Re- 5. CONCLUSION
trieving FPGA configuration data from the configura- HDCP 2.1 is the content protection for next generation trans-
tion Flash is as difficult as concluding the source code mission of HD contents over wireless or wired networks. It
from a compiled .exe file; but as mentioned before, an uses 1024 bit RSA encryption for key exchange and 128 bit
encrypted FPGA configuration Flash would be best. AES encryption for AV content. Locality check limits the
geographic distribution of HD contents.
To store the Receiver Private Key in this section is not AES encryption and decryption of a 1 Gbit/s Audio Video
ideal, because HDL code synthesis would be required Stream with FPGA logic cells is possible.
for each receiver device. Most cryptographic algorithms could be accomplished by
the 100 DMIPS FPGA soft core processor, except the RSA
decryption could not quite be completed within the required
3. Not placing secret numbers or private keys in one second. Implementing the RSA modular exponentiation
the Linux or software executable image in FPGA logic cells or a more powerful soft or hard core pro-
Only the receiver certificate is public and may be placed cessor would be a more appropriate solution.
in this section. Many of the cryptographic hardware blocks and software
libraries are available as open cores and proofed to be func-
3.4.1 Linux Access Protection tional and helpful. Since we already use a soft core processor
Access to the Linux operating system must be controlled, in the system for other purposes, the additionally required
all console ports which allow access to the Linux must be cryptographic blocks add only 4% to the FPGA logic cells.
closed or put under password protected user management. The performance requirements of the cryptographic software
A secure bootloader, this is a bootloader which checks that algorithms do not add overhead to the over all processor
the Linux image was not tampered, must be implemented. load, since they are active only during the connection is
built up.
Even so decryption is only switched on for HDCP protected
3.4.2 HDCP Testing sources, the user notices no difference in system performance
A HDCP 2.0 IIA Compliance Test Specification is available between handling copyrighted and non copyrighted mate-
on the HDCP web site [6]. The HDCP license agreement rial.
includes also a Robustness Check List[6] as an aid for eval-
uating the design architecture. The robustness check list is
not complete and does not replace the specification. 6. REFERENCES
[1] Altera Corporation. Altera Cookbook. Altera
Corporation, 2011.
4. HDCP LICENSING [2] Rodriguez-Henriques et al. Francisco. Cryptographic
Products which are able to decrypt HDCP signals are sub- Algorithms on Reconfigurable Hardware. Springer,
ject to HDCP licensing. Interfaces which may transmit Berlin, 2007.
HDCP coded contents are not limited to HDMI, Display
[3] Lukas Itin. Hd video over ip with hdcp. Masters
Port, DVI, GVIF, UDI, USB. To be able to purchase e.g.
thesis, ZHAW, 2011.
a HDMI receiver IC with integrated HDCP decryption re-
quires a license by Digital Content Protection, LLC [8]. [4] Digital-CP LLC. HDCP Component License
Once a HDCP protected signal is decoded, the licensee must Agreement. Digital-CP LLC, 2002.
inhibit that the content is distributed to prohibited sinks or [5] Digital-CP LLC. High Bandwith Digital Content
recorded. If the licensee fails this commitment, the licensee Protection System V1.4. Digital-CP LLC, 2009.
is liable up to 8 Mio. U.S. dollars. [6] Digital-CP LLC. HDCP 2.0 IIA Compliance Test
Specification. Digital-CP LLC, 2011.
Using the HDCP 2.1 license requires no additional licenses [7] Digital-CP LLC. HDCP Interface Independent
for adopters but to purchase individual certificates for each Adaptation V2.1. Digital-CP LLC, 2011.
HDCP 2.1 receiver. The certificates for the receivers can be [8] Digital-CP LLC. HDCP License Agreement.
purchased in minimum quantities of 10000 pieces and are Digital-CP LLC, 2011.
shipped on an encrypted DVD. [9] Digital-CP LLC. HDCP Specification 2.x Signing
Purchase and order of receiver certificates is conducted via Facility Users Guide. Digital-CP LLC, 2011.
a so called Signing Facility [9]. [10] Usselmann Rudolf. Rijndael AES IP core. OpenCores,
Before Digital Content Protection, LLC can prepare the 2009.
DVD, the licensee needs to generate a public key. The pub- [11] DI Management Services. BigDigits multiple-precision
lic key is sent per email to Digital Content Protection, LLC. arithmetic source code. DI Management Services, 2.3
Additional to the public key, a fingerprint of the key needs edition, 2011.
to be sent to DCP by another method than email.

It is important to note that contract manufacturers need

to close a HDCP Component License Agreement [4] to be
allowed to assemble HDCP licensed components and install
encryption firmware.