HDCP2.3認証について

はじめに

HDCPはHDMIなどで使用されるコンテンツ保護技術であり、2020年10月8日現在のHDMI向けの現行バージョンはHDCP1.4とHDCP2.3です。HDCP2.xは、その登場からおよそ10年経過していますが、特に大きな問題もなく更新が続いており、有線・無線問わず様々なインターフェイスやコンテンツで採用されています。HDCP2.2以上を要求している4Kコンテンツが多いため、最近のハイエンドのTVやBDプレイヤー、STB、AVレシーバーなどのほとんどはHDCP2.2/2.3に対応しています。今回、HDCP2.3の認証プロトコルについて、再度確認してみました。HDCPはDigital Content Protection, LLC (DCP)が管理しているオープンな規格のため、誰でも仕様書をダウンロードすることが可能です。

HDCP2.3について

HDCP2.3は、暗号方式として世界標準となっているAES-128やRSAを使用したハイブリッド暗号システムを採用しており、独自のCipherを使用していたHDCP1.4に比べてセキュリティが大きく強化されています。その他、4個までのRepeaterや32個までのデバイス数を接続可能のほか、HDCP1.xとHDCP2.xの変換などもサポートされています。

HDCP2.3の認証はHDCP1.4と同様にDDCのHDCP Portを介してTransmitterがマスターとなって行われます。HDCP2.3でのメッセージの送受信はWrite_Message、Read_Messageレジスタに対してバースト転送することにより行われます。Receiverからのメッセージの有無(メッセージのサイズ)は、RxStatusレジスタ内のMessage_Sizeに格納されます。再認証要求などのその他のReceiverの状態もRxStatusレジスタに格納されますので、TransmitterはRxStatusレジスタを定期的にポーリングする必要があります。

HDCP2.3の認証のやり取りをモニタしてみる

実際のBDプレイヤーとTV間のHDCP2.3の認証のやり取りをSCDC/EDIDコントローラAJSC-1でモニタしてみました。AJSC-1にはDDCをモニタする機能があり、HDCP2.2/2.3のメッセージにも対応しています。

取得したDDCログは、HTMLでレポートとして出力することが可能です。今回のHTMLレポートはこちらのようになります。

HDCP2.3認証プロトコルの各ステップ

それでは、HTMLファイルのレポートを見ながら各ステップについて順に見ていきましょう。

Read HDCP2Version

Transmitterは相手のReceiverがHDCP2.2以上に対応しているかどうかを確認します。ReceiverはHDCP2VersionレジスタのBit 2が1になっていることを返信しています。

Write AKE_Init

TransmitterがAKE_Initというメッセージを送り、AKE(Authentication and Key Exchange)認証が開始されます。AKE_Initメッセージでは、64bitの疑似乱数r_txやTxCapsといったパラメータがReceiverに渡されます。

Reply AKE_Send_Cert

cert_rxの中にはReceiverIDという各個体でユニークな値があり、20bitのゼロと20bitの1を含む40bitの値となっています。HDCP1.4でのKSVに相当します。

Write AKE_No_Stored_km

Transmitterが相手のReceiverIDに紐付いた128bitのマスター鍵k_mを保持していない場合、AKE_No_Stored_kmメッセージを送信します。cert_rxに含まれる公開鍵kpub_rxを使用して1024bit RSAで疑似乱数k_mを暗号化し送信します。

Reply AKE_Send_H_prime

256bitのk_dを使用してHMAC-SHA256によるハッシュ値H’を計算し返信します。k_dは、k_mとr_tx, r_rxを使用しカウンタモードAESで出力したdkey₀, dkey₁ (ctr=0,1)を結合した値です。Transmitterは受け取ったH’とTransmitter自身がもっているHが一致しているかを確認します。

Reply AKE_Send_Pairing_Info

AKEを早く終わらせるために、ペアリング機能が実装必須となります。H’の計算後、ReceiverはAESを使用してk_mを暗号化しE_kh(k_m)を生成します。E_kh(k_m)をメッセージで返信します。

AKE_Send_Paring_Infoの返信によりAKEは完了になります。

Write LC_Init, Reply LC_Send_L_prime

AKEとペアリングが完了するとローカリティチェックを行います。Receiverは、Write LC_Initに記載されたnonce(乱数)r_nを用いてL’を計算しLC_Send_L_primeメッセージを返信します。

20ms以内にLC_Send_L_primeメッセージを受信できない場合、ローカリティの確認に失敗となり認証が中断となります。LC_Send_L_primeメッセージを受信したらLとL’がマッチしていることを確認します。

Write SKE_Send_Eks

ローカリティチェックが完了するとSession Key Exchange (SKE)に進みセッション鍵の交換を行います。疑似乱数のセッション鍵k_sと疑似乱数r_ivを生成します。カウンタモードAES Ctr=2で出力したdkey₂を用いてk_sは暗号化してE_dkey(k_s)を生成します。E_dkey(k_s)およびr_ivをメッセージで送信します。TransmitterはSKE_Send_Eks送信後200ms後にコンテンツを暗号化してもよいことになります。Receiver側ではE_dkey(K_s)からセッション鍵k_sを復号し、それを使用してコンテンツを復号します。

REAUTH_REQ

SKEの後、もしもReceiverがRepeaterだった場合は下流デバイスの情報をTransmitter側へ伝えるステップが入りますが、今回はRepeaterではないためこれで認証が完了となります。この後Receiverが再認証してほしい場合はRxStatusのREAUTH_REQビットを立てますのでTransmitterは少なくとも毎秒1回はRxStatusをポーリングする必要があります。59行目でREAUTH_REQビットが立ち、再認証を要求していますのでAKE_Initから再び開始されます。既にk_mは持っているため、AKE_Stored_kmメッセージが送られ、ペアリングのステップがスキップされます。

先のAKE_Send_Pairing_InfoにあるE_kh(k_m)とWrite AKE_Stored_kmでのE_kh(k_m)が一致していることがわかります。

まとめ

今回は、HDCP2.3のメッセージをモニタしてみました。各認証ステップの間には制限時間がきつく設けられており、それを守れない場合に認証エラーが起きます。HDCP2.2/2.3における接続性不具合での主な原因として、このタイミングに関わることも多いようです。アリオンでは、HDCP1.4、HDCP2.2/2.3のコンプライアンステストやデバッギング、相談も承っておりますので、何かございましたらお気軽にお問い合わせください。

本記事に関するお問い合わせ