HDCPプロトコルについて

鍵共有方式

DHと比較するとこの程度で大丈夫?、とか思うんだが、Blomの方式とかいうらしい。

秘密な対称行列を用意し、そこから3列適当に選んで足す。何列でもいいんだけど。

4 9 2 8 3 1     0     9+8+3   20
9 8 1 1 2 9     1     8+1+2   11
2 1 6 2 9 2  x  0  =  1+2+9 = 12
8 1 2 1 0 1     1     1+1+0    2
3 2 9 0 5 8     1     2+0+5    7
1 9 2 1 8 7     0     9+1+8   18

ここで(0,1,0,1,1,0)がA公開鍵、(20,11,12,2,7,18)がA秘密鍵になるわけだ。

Bも同様にして公開鍵と秘密鍵を作成しておく。

4 9 2 8 3 1     1     4+9+3   16
9 8 1 1 2 9     1     9+8+2   19
2 1 6 2 9 2  x  0  =  2+1+9 = 12
8 1 2 1 0 1     0     8+1+0    9
3 2 9 0 5 8     1     3+2+5   10
1 9 2 1 8 7     0     1+9+8   18

ここでAがBにA公開鍵を渡す。Bは自分のB秘密鍵とA公開鍵を内積して1つの数字を作る。これは結局対称行列の赤字部分の加算になっている。

16   0                   4 9 2 8 3 1
19   1                   9 8 1 1 2 9
12 * 0 = 19+9+10 = 38    2 1 6 2 9 2
 9   1                   8 1 2 1 0 1
10   1                   3 2 9 0 5 8
18   0                   1 9 2 1 8 7

A側でも同じ処理をすることにより同じ結果38が得られる。(対称行列だからね)

実際のHDCPではここでAやBが送信側や受信側になっていて、行列の大きさは40x40、各数字は56ビットになっている、という程度の簡単なもの。ざっと見の感想としては。

公開鍵と秘密鍵のペアがいくつか、実質には直交している公開鍵40個分あったらあっさり対称行列が解かれてしまう。ランダムに集めても50個程度で解かれてしまうのでは。
で、その集め方だけど、HDCP受信側(モニタ)が受動装置であり、プロトコル上「暗号化装置」として何回でも動作させられてしまう。（送信側の認証を受信側で行っていない）送信側から送った乱数トークンを生成共有鍵で暗号化、なので暗号化自体に特異点があると秘密鍵は判明する。

まあ実際にはHDCPトランスミッタはIC化されてごく一部のメーカしか作らないんで当面は安心なんだろうなあ。結局はコンテンツホルダーに対する「ポーズ」なんだろうし。

マスターキーが公開されちゃったみたいですね。関係者から漏れたのか、闇メーカが50回キー請求したのか、格納されたキーを50個タンパしたのか、特異点をついたのか不明ですが、想定された事態なだけで、すでにHDCP2.0が策定済みです。こっちはRSAを採用してるので関係者から漏れる以外は安全ですが、今のHDMIのI2Cライン上での認証だと時間がかかり、 DisplayPortかHDMIもバージョンがあがってからでないと採用できないので当分先でしょうね。ポーズポーズ、っと。 (10-9-21)