HDCP1.4+Material for Certification

10 August 2012

Sony Corporation

2012/8/10Sony Confidential1

Introduction - What’s HDCP1.4+?• HDCP1.4:

• Specification:

• http://www.digital-cp.com/files/static_page_files/DAD40C4C-1A4B-B294-D0E92C72CFE974A0/HDCP%20Specification%20Rev1_4_Secure.pdf

• Licensing(Compliance Rule and Robustness Rule):

• HDCP License Agreement:

• http://www.digital-cp.com/files/static_page_files/26D315BF-1A4B-B294-D04BB484EE81591E/HDCP%20License%20Agreement0831_2011_clean%20_2_.pdf

• Addendum to HDCP License Agreement

• http://www.digital-cp.com/files/static_page_files/62BFCBA3-1A4B-B294-D09C885021187455/HDCP%202%200%20Addendum_Clean_FINAL2_04_30_11_ver2.pdf

• HDCP1.4 Purported Hack:

• It was reported that HDCP1.4 Master Key was published.

• HDCP1.4 technology provider, i.e. Intel confirmed the ability of the published Master Key to generate interoperable device key sets.

• HDCP1.4+:

• Some technical schemes will be added to enhance HDCP1.4. Note that all the HDCP1.4 schemes are applied as they are.

• In other words, HDCP1.4+ = HDCP1.4 & additional schemes.

• Compliance and Robustness Rule of HDCP1.4+ are same as latest HDCP (i.e. HDCP License Agreement and Addendum to HDCP License Agreement)

2012/8/10Sony Confidential2

HDCP1.4• HDCP1.4 (Slide#3):

• Data for HDCP1.4 Authentication (D1.4auth):

• Includes pseudo-random value(An), Key Selection Vector(KSV) etc. which are exchanged between Source and Sink as defined in HDCP1.4 specification.

• 1st step:

• D1.4auth are exchanged between Source and Sink as plain-text by HDCP1.4 Authentication scheme to share session key(Km/Km’).

• 2nd step:

• Stream data is encrypted by Source and decrypted by Sink using key derived from D1.4auth.

• HDCP1.4 Purported Hack:

• It was guessed that any session key(Km/Km’) can be calculated if the following conditions are met:

• Some sets (40?) of HDCP1.4 Device Key Sets are available,

• Reverse engineering or purchase from licensor?

• D1.4auth between Source and Sink is available.

• Monitoring is easy because D1.4auth is transferred as plain-text.

• If Session Key(Km/Km’) and D1.4auth are available, HDCP1.4 protected stream can be decrypted. This means that man-in -the-middle-attack would be successful.

2012/8/10Sony Confidential3

HDCP1.4 (Illustrated)

2012/8/10Sony Confidential4

Source Device(A) Sink Device(B)

HDCP1.4 Authentication1. Shar e Sessi on Key ( Km/ Km’ )

2. St r eam Encr ypt i onHDCP1.4 Encryption

Pl ai n baseband st r eam

Pl ai n baseband st r eam

HDCP Enc

HDCP Dec

D1. 4aut h

D1. 4auth

D1. 4aut h: Dat a f or HDCP1. 4 Aut hent i cat i on

HDCP1.4+• Problem for HDCP1.4:

• If an attacker has sufficient sets of HDCP1.4 Device Key Set, HDCP1.4 protected stream can be decrypted by the man-in-the-middle attack.

• Countermeasure:

• Use Kauth' instead of An

• Kauth is shared securely between Source and Sink by Additional Authentication as described later.

• The least significant 64-bit of x-coordinate of Kauth is used as Kauth’.

• Effect:

• 64-bit pseudo-random value An (i.e. Kauth’ in case of HDCP1.4+) can be protected from attacker.

• An is defined in HDCP1.4 specification, 2.2.1 First Part of Authentication Protocol.

• This means that an attacker cannot perform the HDCP Cipher successfully to decrypt HDCP1.4 protected contents.

• HDCP Cipher is defined in HDCP1.4 specification, 4 HDCP Cipher.

• Only way to attack would be a brute force attack for 64-bit key.

• Other data (e.g. KSV) than An could be monitored between Source and Sink during the normal HDCP1.4 Authentication, because most HDCP1.4+ capable Source/Sink are assumed to support both 1.4 and 1.4+.

• On the other hand, Kauth’ cannot be monitored because this value is shared by more robust Additional Authentication.

2012/8/10Sony Confidential5

HDCP1.4+ (Illustrated)

2012/8/10Sony Confidential6

Source Device(A) Sink Device(B)

Additional Authentication

HDCP1.4 Authentication

0. Shar e Addi t i onal Sessi on Key ( Kaut h)

1. Shar e Sessi on Key ( Km/ Km’ )

2. St r eam Encr ypt i onHDCP1.4 Encryption

Replace An with Kauth’

HDCP Enc

HDCP Dec

Pl ai n baseband st r eam

Pl ai n baseband st r eam

Kaut h Kaut h

D1. 4aut h ( i ncl .

An)

D1. 4aut h ( i ncl . An)

D1. 4aut h’

D1. 4aut h: Dat a f or HDCP1. 4 Aut hent i cat i onKaut h’ : The l east si gni f i cant 64- bi t of x- coor di nat e of Kaut hD1. 4aut h’ : D1. 4aut h whose An i s r epl aced by Kaut h’

Replace An with Kauth’

D1. 4aut h’

Additional Authentication• Purpose:

• To share Additional Session Key(Kauth) which is used instead of An

• Overview:

• Diffie-Hellman key distribution method using ECDSA algorithm

• Widely available method in various services

• Bit length of ECDSA private key is 160 bits.

• Both Source and Sink have the following issued by CA(Licensor):

• ECDSA private key (Secrecy required)

• ECDSA public key certificate signed by CA(Licensor)

• Revocation List is also issued by CA(Licensor).

• Source will stop transferring data if Sink is revoked.

• After the authentication, shared data will be Kauth.

2012/8/10Sony Confidential7

Additional Authentication (Illustrated)

2012/8/10Sony Confidential8

Source(A) Sink(B)

Revocation List

Brand||Bcert

Arand||Acert

Av||Asig

Bv||Bsig

Apr i v: Pr i vat e key f or A

Acer t : Cer t i f i cat e f or A

Gener at e r andom number Br and

Ver i f y Bcer t and check i f t hi s i s i ncl uded i n

Revocat i on Li stGener at e r andom

number Ar andVer i f y Acer t

Gener at e r andom number Ak

Av=Ak GAsi g=Si gn( Apr i v, Br and| |

Av)

Gener at e r andom number BkBv=Bk GBsi g=Si gn( Bpr i v, Ar and| |Bv)

Ver i f y( Apub, Asi g, Br and| | Av)

Ver i f y( Bpub, Bsi g, Ar and| | Bv)

Kaut h= Ak Bv

Thi s i s based on Di f f i e- Hel l man key di st r i but i on usi ng ECDSA.

G: Base Poi nt of El l i pt i c Cur ve

Kaut h= Ak Bv

Bpr i v: Pr i vat e key f or B

Bcer t : Cer t i f i cat e f or B

Private key and Certificate are securely stored in device in

advance.

Updated if it is newer and the signature is

verified

Replace An with Kauth’• Purpose:

• To protect An from an attacker

• Overview:

• Kauth is shared between Source and Sink by robust Additional Authentication.

• Kauth is a 320-bit value of (160-bit x-coordinate, 160-bit y-coordinate).

• To support current HDCP1.4 scheme as it is, An is exchanged between Source and Sink by HDCP1.4 Authentication. However, An is not used for HDCP1.4 Encryption/Decryption.

• Kauth’ (the least significant 64-bit of x-coordinate of Kauth) is used instead of An during HDCP1.4 process.

2012/8/10Sony Confidential9

Replace An with Kauth’ (Illustrated)

2012/8/10Sony Confidential10

Source(A) Sink(B)

Fi r st Par t of HDCP1. 4 Aut hent i cat i on Pr ot ocol

( r ef er t o HDCP1. 4 speci f i cat i on, Fi gur e 2- 1)

Initiate Authentication:An, Aksv

Bksv

Gener at e r andom number An

( Ks, M0, R0) = hdcpBl kCi pher ( Km,

REPEATER | | Kaut h’ )

Additional Authentication

Shar e Kaut h

Shar e Kaut h

( Ks’ , M0’ , R0’ ) = hdcpBl kCi pher ( Km’, REPEATER | | Kaut h’ )

Pl ai n- t ext

Revocation List for Additional Authentication

• Purpose:

• To revoke Sink by Source

• Overview:

• Revocation List is securely stored (i.e. cannot be replaced by an attacker) in Source device when shipping. Also, stored Revocation List is updated when Source device encounters a newer Revocation List.

• Before storing, Source device verifies the signature of the Revocation List signed by CA(Licensor).

• How is new Revocation List delivered?:

• Download latest revocation list with content

• Note:

• HDCP revocation of Source by Sink does not work.

• HDCP is optional for data transmission from Source device, because private contents are transferred as plain-text. Evil Source device would send pirated contents as plain-text, in other words, HDCP would not be initiated. That is why revocation does not work.

2012/8/10Sony Confidential11

Revocation List for Additional Authentication (Illustrated)

2012/8/10Sony Confidential12

Source(A) Sink(B)Server

Content, Revocation List

Revocation List

Version compariso

n

DownloadedRevocation List

StoredRevocation List

Replace stored RL by downloaded RL, if downloaded RL is

newer

Signature verification If

verified

Additional AuthenticationCheck if Sink is included in

RL

Revocation List