DLNAのDTCP-IPを解除する方法 第5話「エッチの前には認知してくれるか確認しなさい」
DLNAのDTCP-IPを解除する方法 第4話『『萌え』で覚える中間者攻撃』 - セカンドベストは何か？の続き。
DTCP-IPのECDHは、中間者攻撃でぶっこ抜き？
DTLA社は安全なDTCP-IP通信のために、DH鍵交換の前には必ず認証するように規定している。
『エッチ（＝DH鍵交換）の前には、認知してくれるか確認（＝電子認証）」と覚えよう。
テストに出るゾ！
stargazer lily-2 / Luigi Crespo Photography
DH鍵共有は中間者攻撃に弱い
前回の記事でDH鍵共有を萌え要素で考えてみた。
ルパン三世を例に、中間者攻撃の脆弱性があることが分かった。
では中間者攻撃を防ぐ、
つまり、あとで公開しない安全なDTCPを行うにはどうすればいいのか？。
DH鍵交換の前に、DTLA社のお墨付きの信頼できるパートナーか、確認をすれば良いのだ。
通信相手のなりすましや、データが改ざんがないことを確かめるプロセスを「認証」と呼ぶ。*1
DTCP-IPの完全認証の手順
DTLA社が各機器ごとに発行したデバイスキー（device key, 機器証明書）を用いて、チャレンジ/レスポンス認証を行う。
ECDSA*2という楕円曲線のアルゴリズムを利用した公開鍵暗号方式で認証を行なっている。
完全認証方式では、チャレンジ/レスポンス認証をボブ(サーバ)とクリス（クライアント）の双方でダブルチェックする。
認証が正常に行われると、ECDHによる鍵交換のステップに移る。
このように機器認証と鍵交換のプロセスをAKE*3と呼ぶ。
SE◯じゃないゾ！
参考
ユビキタス時代の著作権管理技術―DRMとコンテンツ流通
posted with amazlet at 13.01.06
図2が完全認証方式のプロセスだ。処理の概要を流れ図にするにあたり、現実のデータのやり取りの順番と若干異なってしまったことはお許し願いたい。完全認証方式では、ソース機器とシンク機器の双方で「チャレンジ乱数」と機器証明書のやり取りを行った後、公開鍵方式の一つであるDSA（Digital Signature Algorithm）方式で相互の機器証明書の正当性をチェックする。その後、SRMで相手の証明書がCRLに含まれていないことを確認する。
デジオンの三阪 英一氏による解説
ここまでで問題がなければ、続けて「Diffie-Hellman（DH）鍵交換方式」で鍵交換を始める。相手の公開鍵を使って計算したメッセージを相互にやり取りし、最終的に共通の認証キーを得る。DSAとDHのいずれも、暗号方式として楕円曲線暗号（Elliptic Curve、EC）を採用している。楕円曲線暗号は、同じ公開鍵暗号方式のRSA暗号よりも、より高い暗号強度を持つとされている。
ＲＡ−ＡＫＥ手続きのチャレンジ・レスポンス部分（Ｃｈａｌｌｅｎｇｅ−Ｒｅｓｐｏｎｓｅ ｐｏｒｔｉｏｎ ｏｆ ＡＫＥ）では、まず、ＲＡ−Ｓｉｎｋから、Ｒｘ乱数とＲｘ証明書を含んだＲｘチャレンジが送信される。これに対しＲＡ−Ｓｏｕｒｃｅからは、Ｔｘ乱数及びＴｘ証明書を含んだＴｘチャレンジが返信される。以降、ＲＡ−Ｓｏｕｒｃｅから、Ｒｘ乱数、Ｔｘメッセージ、Ｔｘ署名を含んだＲｘレスポンスが送信されるとともに、ＲＡ−ＳｉｎｋからはＴｘ乱数、Ｒｘメッセージ、Ｒｘ署名を含んだＴｘレスポンスが送信される。
ソニーの特許
【００９９】
各チャレンジ・コマンドには、機器固有の識別情報であるＤｅｖｉｃｅ ＩＤが含まれている。
図２に完全認証のプロトコルを示す。完全認証では次の処理を行う。
１−３−１−１０ ＡＶネットワークのコンテンツ保護規格ＤＴＣＰ
（１）相手機器が持つ証明書を相手機器の公開鍵で検証する。
（２）ＤＨ（Diffie Hellman）法により認証鍵（ＫAuth）を共有する。
（３）ＫAuthを共有するための情報やＳＲＭに関する情報も、デジタル署名を付加して相互に検証する。
DTCP-IPの機器認証の脆弱性
DTCP-IPでは、映像をAESで暗号化しているが、
AESには鍵共有の問題があった。
そこで安全に鍵を共有できるようDH鍵交換を行なっているが、
DH鍵交換には中間者攻撃の問題があった。
そこで中間者攻撃を防ぐために電子認証を行なっている。
では、電子認証の問題はなにか？
DTCP-IPの認証には、デバイスキーと呼ばれる証明書を用いている。
デバイスキーには、DTLA社によるデジタル署名と機器ごとに異なる公開鍵が含まれている。
このデバイスキーが第３者に入手されてしまうと、DTCP-IPは解読されてしまう危険性がある。
もしもデバイスキー流出したら？
鍵が流出してしまうと、DRMの安全性は崩壊してしまう。
DTCP-IPでは様々な暗号化方式を組み合わせているが、
大本のデバイスキーを漏らしてしまうと、取り返しのつかない時代に陥る。
もはやコーラで消毒しても無意味。
ちなみにDTCP-IPの慰謝料は800万ドルだ。
学校中でカンパを集めても到底足りないだろう。
DTCP-IPでは、万が一デバイスキーが流出してしまった場合の対策も考慮してあるが、
完全にリカバリーできるわけではない。
デバイスキー流出対策
電子認証のプロセスには、デバイスキーがDTLA社が発行した本物であるかを判断するだけでなく、有効か無効かを判断する手続きがある。
DTCP-IPの完全認証では、システム更新メッセージ*4によって、無効な機器の情報を含むデータベースであるCRL*5の更新処理を必ず実行する。*6
テレビ放送波やインターネット、新しいDLNA機器との通信によって、CRLは絶えず更新されるので、流出したデバイスキーを使い続けることは難しくなる。
だからといって、CRLの更新は大きな負担になる。
「だ、大丈夫、ぜったいに漏らさないから！」
そんなテキトーな言葉を鵜呑みにせず、きちんと認知してくれる人とだけDH鍵共有スルこと。
３重の暗号化、その大本はデバイスキー
- 映像はAESで暗号化
- AESの鍵はDH鍵共有
- DH鍵共有の前にデバイスキーで認証
DTCP-IPでは２重３重の安全対策を行なっている。
デバイスキーはその大本になる非常に重要な鍵である。
認証さえしていれば、デバイスキーが流出してしまうリスクはゼロだと言い切れるか？
続く。
