JP2008527892A - セキュアホストインタフェース - Google Patents

Abstract

本発明は、アプリケーションユニット（１，２１，４１）とドライブユニット（３，２３，４３）とを有するコピープロテクトされたコンテンツへのアクセス権限を制御するデジタル著作権管理システム（４０）と、アプリケーションユニットと、ドライブユニットと、対応するデジタル著作権管理方法とに関する。特に“フィルタ・ドライバ”ハッキングが不可能とされ、又は少なくとも実質的に複雑化されるデジタル著作権管理のセキュリティの向上と、デジタル著作権に関して与えられるコマンドとその実行に関する確実なコンファメーションを可能にするため、アプリケーションユニットは、バスキー（ＫＢ）を格納するキーストレージユニット（４５）と、アクセス権限に関するメッセージとチャレンジ（ＲＸ）とを有するドライブユニットにより実行されるリクエスト（７，２７）を生成するリクエスト生成ユニット（４７）と、リクエストを送信し、該リクエストに対するレスポンス（１３，３３）をドライブユニットから受信する通信ユニット（５１）と、バスキーを用いてレスポンスを復号化し、レスポンスにおけるチャレンジの指標の有無をチェックすることによって、リクエストとレスポンスとの間のリンクを検証するレスポンス検証ユニット（４９）とを有し、ドライブユニットは、バスキーを格納するキーストレージユニット（５５）と、アクセス権限に関するメッセージとチャレンジを含むリクエストをアプリケーションユニットから受信し、該リクエストに対するレスポンスを送信する通信ユニット（５１）と、リクエストを検証し、メッセージを処理するリクエスト処理ユニット（５７）と、チャレンジの指標とメッセージに対するリプライとを含むレスポンスを生成するレスポンス生成ユニット（５９）とを有し、チャンレンジの指標とリプライは、バスキーにより暗号的にリンクされ、レスポンスにおけるチャレンジの指標は、リクエストが実行されたことを示す。

Description

本発明は、アプリケーションユニットとドライブユニットとを有するコピープロテクトされるコンテンツに対するアクセス権限を制御するデジタル著作権管理システムに関する。本発明はさらに、アプリケーションユニット、ドライブユニット及び対応するデジタル著作権管理方法に関する。

ブルーレイディスクやそれの競合フォーマットであるＨＤ−ＤＶＤのコピープロテクションシステムの強力な候補としてＡＡＣＳが提唱されたことは、光媒体に対するデジタル著作権管理（ＤＲＭ）への関心を復活させた。ＡＡＣＳの要求の１つは、システムがまだ規定されていない各種ビジネスモデル及び使用ケースをサポートする拡張された及び拡張可能な使用をサポートしなければならないということである。それは、記録及び電子ダウンロードに適用可能である必要がある。

同様の要求が、ＷＯ２００２／０１５１８４−Ａ１（ＰＨＮＬ０００４４８）などに記載されるように、解読キーや使用権限などのＤＲＭデータが“キーロッカー（ｋｅｙ ｌｏｃｋｅｒ）”と呼ばれるディスク上のエリアに格納される既知のＤＲＭシステムにおいて中心的な役割を担っている。キーロッカーは、特にいわゆる隠されたチャネルキーを利用して暗号化される。隠されたチャネルとは、ドライブのみにアクセス可能であり、好ましくは、メインデータチャネルから独立して格納されるディスク上のエリアである。再生攻撃を回避するため、ドライブは、キーロッカーに格納されるデータが変更されるときは常に、隠されたチャネルを変更する。再生攻撃では、ハッカーはまず、ハードディスクなどの安全な場所にディスク上のＤＲＭ権限のビットイメージを格納し、その後、おそらくディスクに暗号的にバインドされている自らの権限を利用し、もとのビットイメージを復元し、これにより、もとの権限を復元する。この攻撃は、それらが使用されるときは常に当該権限を再暗号化することによって回避される。

ブルーレイディスクフォーマットに対するＤＶＤ＋ＲＷのためのＶＣＰＳのポートであるＢＤ−ＶＣＰＳでは（ＶＣＰＳの仕様については、ｈｔｔｐ：／／ｗｗｗ．ｌｉｃｅｎｓｉｎｇ．ｐｈｉｌｉｐｓ．ｃｏｍ／ｖｃｐｓを参照されたい。この仕様の記載が参照することによりここに含まれる。）、ディスクに関する任意のＤＲＭ権限をサポートするため、既知の隠されたチャネルなどの特徴が与えられている。この記載について、隠されたチャネルは、“ＲＥマーク”として知られている。既知のＤＲＭシステムと異なって、ＲＥマークとの直接的なインタフェースが提供され、キーロッカーなどの構成は設けられない。後者は、所望される場合には、ホストアプリケーションにより実現されるかもしれない。このため、ホストがＲＥマークキーにアクセスするのに利用可能な３つのコマンド、すなわち、リード、チェンジ及びワイプが必要とされる。

リードコマンドは、以前に確立されたバスキーを使用して暗号化されたＲＥマークキーを返す。チェンジコマンドは、ドライブにＲＥマークに格納されているキーをランダムに変更させる。ワイプコマンドは、ドライブにディスクからＲＥマークをイレースさせる。さらなるエンハンスメントとして、ディスク上への８個などの複数のＲＥマークの格納が可能である。従って、これらのコマンドのそれぞれは、動作すべきものに対する固有のＲＥＭマークを示すパラメータを含む。

光ディスクドライブのホストインタフェースは、Ｍｕｌｔｉ−Ｍｅｄｉａ Ｃｏｍｍａｎｄ（ＭＭＣ）セットにより規定される。（ＳＣＳＩ Ｍｕｌｔｉ−Ｍｅｄｉａ Ｃｏｍｍａｎｄｓ−４（Ｔ１０／１５４５Ｄ）仕様を参照されたい。この仕様の記載は、参照することによりここに含まれる。）当該セットのコマンドは、ドライブが実行すべきアクションを示す記述子ブロック及びパラメータブロック（ホストがドライブにデータを送信する場合）又はデータブロック（ホストがドライブから受信する）から構成される。１つのコマンドは、パラメータブロック及びデータブロックを指定しないかもしれない。まず、上述した必要なコマンドの何れもがパラメータブロックとデータブロックの両方を必要とするため、必要なコマンドはこのアーキテクチャに適合される。しかしながら、特別な手段がなければ、セキュリティホールが存在するであろう。その理由は、ハッカーがホストのＯＳソフトウェアスタックに“フィルタドライバ”を挿入するかもしれず、それは上記コマンドをブロック及び／又はリダイレクトするためである。この結果、ホスト上で実行されるアプリケーションは、ディスク上のＲＥマークが更新された（又はこの問題については、適切な場所から抽出された）ことを確信することができない。バスキーを確立するためドライブとホストとの間の認証プロトコルを実行し、その後に当該バスキーを使用してコマンドデータを暗号化することは、それだけでは十分でない。

従って、本発明の課題は、デジタル著作権管理におけるセキュリティの向上を可能にし、特に“フィルタドライバ”ハックが不可能とされ、又は少なくとも実質的に複雑化されるデジタル著作権管理システム、アプリケーションユニット、ドライブユニット及び対応するデジタル著作権管理方法を提供することである。さらに、上述したようなリード、ライト又はワイプコマンドなどのデジタル著作権に関して与えられるコマンドに関する確実な確認とそれの実行が存在すべきである。

本発明によると、上記課題は、コピープロテクトされたコンテンツへのアクセス権限を制御するドライブユニットを有するデジタル著作権管理システムに使用されるアプリケーションユニットであって、当該アプリケーションユニットは、
・バスキーを格納するキーストレージユニットと、
・前記アクセス権限に関するメッセージとチャレンジとを含む前記ドライブユニットにより実行されるリクエストを生成するリクエスト生成ユニットと、
・前記リクエストを送信し、前記ドライブユニットから前記リクエストに対するレスポンスを受信する通信ユニットと、
・前記バスキーを用いて前記レスポンスを復号化し、前記リクエストが実行されたことを示す前記レスポンスにおける前記チャレンジの指標の有無をチェックすることによって、前記リクエストと前記レスポンスとの間のリンクを検証するレスポンス検証ユニットと、
を有するアプリケーションユニットにより実現される。

本発明によると、上記課題は、コピープロテクトされたコンテンツへのアクセス権限を制御するアプリケーションユニットを有するデジタル著作権管理システムに使用されるドライブユニットであって、当該ドライブユニットは、
・バスキーを格納するキーストレージユニットと、
・前記アプリケーションユニットからチャレンジと前記アクセス権限に関するメッセージとを有する当該ドライブユニットによって実行されるリクエストを受信し、前記リクエストにレスポンスを送信する通信ユニットと、
・前記メッセージを処理するリクエスト処理ユニットと、
・前記チャレンジの指標と前記メッセージに対するリプライとを含む前記レスポンスを生成するレスポンス生成ユニットとを有し、前記リプライと前記チャレンジの指標とは、前記バスキーによって暗号的にリンクされ、前記レスポンスにおける前記チャレンジの指標は、前記リクエストが実行されたことを示すドライブユニットにより実現される。

さらに本発明によると、上記課題は、上述したアプリケーションユニットとドライブユニットとを有し、バスキーがアプリケーションユニットとドライブユニットに共有されるコピープロテクトされたコンテンツへのアクセス権限を制御するデジタル著作権管理システム及び対応する方法によって実現される。

本発明はさらに、アプリケーションユニット上で実行されると、請求項１２のデジタル著作権管理方法のステップａ）、ｂ）、ｅ）及びｆ）をアプリケーションユニットに実行させ、ドライブユニット上で実行されると、請求項１２のデジタル著作権管理方法のステップｂ）〜ｅ）をドライブユニットに実行させるコンピュータプログラムコード手段を有するコンピュータプログラムに関する。

本発明は、すべての隠されたチャネル又はＲＥマーク関連コマンドにおけるチャレンジ・レスポンス機構を使用するアイデアに基づく。基本的には、ＲＥマークアクセスは、２つの独立したコマンドに分けられている。第１コマンドを用いて、ホストはＲＥマークアクセスのためドライブを準備する。このコマンドは、ホストにより生成される乱数などのチャレンジを有し、アクセスモードなどの追加的なパラメータと（ＲＥマークのリード、チェンジ、ワイプ）、ディスクが複数のＲＥマークを有する場合、何れのＲＥマークが動作するかについての指標とを有するかもしれない。第２コマンドを用いて、ホストはドライブからＲＥマークデータと共に、第１コマンドと共に送信された乱数とを抽出する。返されたＲＥマークデータは、返されたデータにおける攻撃のカット・アンド・ペーストを防ぐため、乱数に暗号的にバインドされる必要がある。従って、アプリケーションユニットにより送信され、ドライブユニットにより受信されるリクエストは、メッセージとチャレンジとを有し、当該メッセージはアクセス権限をアクセス及び／又は処理するコマンドを含む。

本発明によるアプリケーションユニットの実施例では、リクエスト生成ユニットは、バスキーによりメッセージとチャレンジとを暗号的にリンクさせるよう構成される。メッセージとチャレンジとがバスキーにより暗号的にリンクされているとき、例えば、バスキーを利用して、及び／又はメッセージとバスキーとの組み合わせから求められるハッシュ値を含めて一緒に暗号化されるとき、受信者は、メッセージが実際にアプリケーションユニットから得られたものであることを検証することができる。従って、メッセージとチャレンジとの間の暗号リンクを予想するドライブユニットは、リンクしていないメッセージとチャレンジが（多数の）レスポンスを解析することによりバスキーをハッキングするのに利用可能であるため、これらを単に無視するかもしれない。さらに、アプリケーションユニットの検証がない場合、他の何れかの（認証されていない）アプリケーションが、ワイプコマンドを使用することによって隠されたチャネル又はＲＥマークを破壊するかもしれない。これらの危険を回避するための他の準備がある場合、メッセージとチャレンジとの間のリンクは、コマンドもチャレンジも秘密に維持されていないため、省かれるかもしれない。

本発明によるアプリケーションユニットの他の実施例では、リクエスト生成ユニットは、リクエストのインテグリティテストに使用するため、リクエストにシグネチャを含めるよう構成される。シグネチャの有効性をチェックすることによって、リクエストを受信したドライブユニットは、送信中などにリクエストが変更した（変更された）か、又は不完全に受信されたか判断するようにしてもよい。このシグネチャは、アプリケーションユニットとドライブユニットの両者によって知られている固定された又は所定のビットパターンであってもよく、リクエストのインテグリティは、例えば、リクエストを復号化することによって、リクエストから適切なシグネチャを求めることにより決定されてもよい。シグネチャはまた、メッセージとチャレンジの組み合わせなどのチェックサムであってもよく、ドライブユニットにより計算されるチェックサムが、リクエストに含まれるシグネチャと比較される。

本発明によるアプリケーションユニットのさらなる実施例では、リクエスト生成ユニットはバスキーを用いてリクエストを暗号化するよう構成される。バスキーはドライブユニットとアプリケーションユニットのみしか知らないため、認証されていないユニット、すなわち、バスキーを所有しないユニットは、本発明によるデジタル著作権管理プロトコルに参加することができる。

本発明のアプリケーションユニットのさらなる他の実施例では、リクエスト生成ユニットは、ハッシュ関数によって、特にバスキーを用いた鍵付きハッシュ関数によって、チャレンジ及び／又はメッセージから求められる値とバスキーとをリクエストに含めるよう構成される。前の実施例と同様に、本実施例によるアプリケーションユニットから送信されるリクエストは、対応して構成されたドライブユニットによりバスキーを用いて検証されてもよい。

本発明によるアプリケーションユニットの好適な実施例では、メッセージは、隠されたチャネルエントリを管理するコマンド、特に隠されたチャネルエントリをリード、チェンジ及び／又はワイプするためのコマンドを含む。他のメッセージが当該メッセージに含まれてもよいが、改ざんに対して隠されたチャネルエントリ又はＲＥマークを管理するのにこれらのコマンドをプロテクトし、又はこれらのコマンドが実際に適切で認証されたドライブユニットにより実行されたという確実なコンファメーションを可能にすることが好ましい。

従って、本発明によるドライブユニットの好適な実施例では、リプライは、隠されたチャネルエントリ、特にドライブユニットによりリード又はチェンジされた隠されたチャネルエントリを含む。

本発明によるアプリケーションユニットの他の好適な実施例では、リクエスト生成ユニットは、乱数、リクエストを特定する識別子、特に実質的に一意的な識別子、及び／又は所定のデータをチャレンジとしてリクエストに含めるよう構成される。チャレンジとして乱数を使用することは、それが予測不可能であるという効果を有し、アプリケーションユニットからそれを取得する以外に当該乱数を取得する他の方法は実質的に存在しない。チャレンジを提供する他の容易な方法は、識別子をリクエストに含めることである。さらに、例えば、固定された（しかし好ましくは一意的な）チャレンジを各アプリケーションユニットに提供することによって、又はいくつかのリクエストについて共通のチャレンジとして（好ましくはランダムな）数を生成するアプリケーションを有することによって、アプリケーションユニットに所定のチャレンジを提供することが可能である。これらの可能性の組み合わせは、それらのトレードオフの一部を回避することによってそれらの効果の一部を実現するかもしれない。

本発明のさらなる他の実施例では、アプリケーションユニットは、ホスト、特にソフトウェアアプリケーションである。本発明は、特にアプリケーションユニットとドライブユニットの間に入る可能性がある他の悪意のあるソフトウェアアプリケーションに関して重大な脆弱性があるソフトウェアアプリケーションに関連する。しかしながら、本発明はまた、ドライブユニットと通信するハードウェア装置などの他の方法により実現されるアプリケーションユニットに適用可能であるということに留意する必要がある。

図１は、本発明によるデジタル著作権管理方法の実施例としてＲＥマークアクセスプロトコルの一例を示す。以下の記載は、ＲＥマークを参照するが、本発明が特別なタイプの隠されたチャネルデータとしてのＲＥマークに限定されず、デジタル著作権管理のための特別なタイプのデータとしての隠されたチャネルデータを管理することに限定されるものでないということに留意する必要がある。アプリケーションユニット又はホスト１と、ドライブ又はドライブユニット３が、適切な通信手段（図示せず）を介し接続されている。以下において、“ホスト”という用語は“アプリケーションユニット”と同意語として使用され、同じことが“ドライブ”と“ドライブユニット”に適用されることに留意する必要がある。この２ステッププロトコルの前に、ドライブ３及びホスト１は共有バスキーＫＢをもたらす認証プロトコルを実行していることが仮定される。このような認証プロトコルの一例は、ＶＣＰＳ仕様に求めることができる。

ＲＥマーク値をリード、チェンジ又はワイプするため、ドライブ３及びホスト１は、以下のステップを登場順に実行する必要がある。

ホスト１は、アクセスすべきＲＥマークスロットｎと、アクセスモード［ｍｏｄｅ＝０（リード）、１（チェンジ）、２（ワイプ）］を選択する。さらに、ホスト１は、乱数ＲＸを生成する（ステップ５）。その後、ホストは以下のメッセージ７をドライブ１に送信する。

ここで、記号（Ｍ）Ｋは、メッセージＭがキーＫにより暗号化されていることを意味する（好ましくは、ＣＢＣ（Ｃｉｐｈｅｒ Ｂｌｏｃｋ Ｃｈａｉｎｉｎｇ）モードを利用して）。さらに、ｓｉｇは、メッセージのインテグリティをチェックするため含まれている既知のビットパターンである。メッセージを暗号化する１つの理由は、認証されていないアプリケーションがＲＥマークを破壊することを回避することであることに留意されたい。

ドライブ３は、ホスト１から受信したメッセージ７を解読し、当該メッセージ７のフォーマットをチェックする。フォーマットが適切でない場合、ドライブ３はプロトコルを中断する。不適切なフォーマットは、通信エラーを示すか、又は不適切なバスキーを使用することによりＲＥマークを操作しようとしていることを示すかもしれない。他方、メッセージフォーマット及びメッセージの真正性が検証された場合（ステップ９）、ドライブは、パラメータｎ及びモードにより符号化されたリクエストを実行する（ステップ１１）。

その後、ドライブは、以下のレスポンスメッセージ１３をホストに送信する。

このレスポンスメッセージ１３では、ＲＭ_ｎは、可能な更新後のｎ番目のＲＥマーク値の現在値である。モード＝２（ワイプ）である場合、ドライブ３はＲＭ_ｎをすべてゼロに設定するかもしれない。

ホスト１は、ドライブ３から受信したレスポンスメッセージ１３を解読し、メッセージ１３のフォーマットをチェックする。乱数ＲＸ、パラメータｎ及びモードがメッセージ７においてホスト１がドライブ３に送信した値と同一でない場合、ホスト１はプロトコルを中断し、ＲＥマークの新たな値を無視する。そうでない場合、新たな値ＲＭ_ｎは受け付けされ、ＤＲＭデータをプロテクトするためホスト１により使用される。ドライブ３及び／又はホスト１がプロトコルを中断した場合、プロトコルのリトライはステップ５からスタートしなければならないことに留意されたい。

図２及び３は、上述したプロトコルを実現するコマンド記述子ブロックのＭＭＣパラメータデータのそれぞれの返されたデータの具体例を提供する。（また、認証プロトコルに使用されるコマンドに関するさらなる情報についてはＶＣＰＳ仕様を参照されたい。）
図２に示されるＳＥＮＤ ＫＥＹ ＲＥ Ｍａｒｋコマンドは、特定のＲＥマーク値をリード、チェンジ又はワイプするため、ホスト１のリクエストを送信する。ＳＥＮＤ ＫＥＹ ＲＥ Ｍａｒｋコマンドは、上記プロトコルにおけるメッセージ７の機能を提供する。ＳＥＮＤ ＫＥＹ ＲＥ Ｍａｒｋコマンドのセマティックは、以下のとおりである。

ドライブホスト認証プロトコルが良好に終了しなかった場合、ドライブ３はＣＨＥＣＫ ＣＯＮＤＩＴＩＯＮステータスによりコマンドを終了する。さらに、ドライブ３は、センスバイトＳＫ／ＡＳＣ／ＡＳＣＱをＩＬＬＥＧＡＬ ＲＥＱＵＥＳＴ／ＣＯＭＭＡＮＤ ＳＥＱＵＥＮＣＥ ＥＲＲＯＲ（０ｘ０５／０ｘ２Ｃ／０ｘ００）にセットする。認証成功後、プロトコルのリトライがステップ５からスタートしなければならない。ドライブ３は、リクエストされたＲＥマークがすでにディスク上に取得されていることをチェックする。そうでない場合、それはランダムに生成された値によりＲＥマークを生成する。ＲＥマークの書き込み中に復元不可能なエラーが発生した場合、ドライブ３は、ＣＨＥＣＫ ＣＯＮＤＩＴＩＯＮステータスによりコマンドを終了する。さらに、ドライブ３は、センサバイトＳＫ／ＡＳＣ／ＡＳＣＱをＩＬＬＵＧＡＬ ＲＥＱＵＥＳＴ／ＳＹＳＴＥＭ ＲＥＳＯＵＲＣＥ ＦＡＩＬＵＲＥ（０ｘ０５／０ｘ５５／０ｘ００）にセットする。そうでない場合、ドライブはＧＯＯＤステータスにより終了する。リザーブされたすべてのバイトが０ｘ００（Ｒｅｓｅｒｖｅｄ）にセットされ、データ長は３８にセットされる。

“暗号化メッセージ１”は、パラメータｎ（８ビット）及びモード（８ビット）、ホストからの乱数ＲＸ（１１２ビット）並びに固定されたビットパターンｓｉｇ（１２８ビット）を有し、そのすべてがＣＢＣモードによりＡＥＳ（Ａｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄ，Ｆｅｄｅｒａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｐｒｏｃｅｓｓｉｎｇ Ｐｕｂｌｉｃａｔｉｏｎ（ＦＩＰＳ ＰＵＢ）１９７を参照されたい）を利用したバスキーＫＢ（認証プロトコルを利用して以前に取得された）を利用して暗号化される。

図３に示されるＲＥＰＯＲＴ ＫＥＹ ＲＥ Ｍａｒｋコマンドは、要求されたＲＥマークの現在値（及び潜在的な更新値）を返す。ＲＥＰＯＲＴ ＫＥＹ ＲＥ Ｍａｒｋコマンドは上記プロトコルによるメッセージ１３の機能を提供する。ＲＥＰＯＲＴ ＫＥＹ ＲＥ Ｍａｒｋコマンドのセマティックは、以下のとおりである。

ドライブ・ホスト認証プロトコルが不成功に終了した場合、ドライブ３はＣＨＥＣＫ ＣＯＮＤＩＴＩＯＮステータスによりコマンドを終了する。さらに、ドライブ３は、センスバイトＳＫ／ＡＳＣ／ＡＳＣＱをＩＬＬＥＧＡＬ ＲＥＱＵＥＳＴ／ＣＯＭＭＡＮＤ ＳＥＱＵＥＮＣＥ ＥＲＲＯＲ（０ｘ０５／０ｘ２Ｃ／０ｘ００）にセットする。認証成功後、プロトコルのリトライがステップ５からスタートしなければならい。ＲＥマークアクセスシーケンスに違反した場合、又はドライブ３がステップ９においてＲＥマークアクセスプロトコルを中断した場合、ドライブ３はＣＨＥＣＫ ＣＯＮＤＩＴＩＯＮステータスによりコマンドを終了する。さらに、ドライブ３が、センスバイトＳＫ／ＡＳＣ／ＡＳＣＱをＩＬＬＥＧＡＬ ＲＥＱＵＥＳＴ／ＣＯＭＭＡＮＤ ＳＥＱＵＥＮＣＥ ＥＲＲＯＲ（０ｘ０５／０ｘ２Ｃ／０ｘ００）にセットする。認証成功後、プロトコルのリトライはステップ５からスタートしなければならない。そうでない場合、ドライブ３はレスポンスメッセージ１３内で要求されたＲＥマーク値を返し、ＧＯＯＤステータスステータスにより終了する。リザーブされたすべてのバイトが０ｘ００（Ｒｅｓｅｒｖｅｄ）にセットされ、データ長は３８にセットされる。

“暗号化メッセージ２”は、パラメータｎ（８ビット）及びモード（８ビット）、指定されたＲＥマーク値ＲＭ_ｎ（１２８ビット）並びにホスト１により以前に送信された乱数ＲＸ（１１２ビット）を有し、そのすべてが、ＣＢＣモードによりＡＥＳを利用してバスキーＫＢ（認証プロトコルを使用して以前に取得された）を用いて暗号化される。

図４は、図１に示される実施例に類似したＲＥマークアクセスプロトコルの他の例を示す。再び、この２ステッププロトコルの前に、ドライブ２３とホスト２１が、共有されたバスキーＫＢをもたらす認証プロトコルを実行していることが仮定される。図１の実施例のプロトコルとの主な相違は、ＲＥマーク値が秘密データであるとみなされないということである。

ＲＥマーク値をリード、チェンジ又はワイプするため、ドライブ２３及びホスト２１は登場順により以下のステップを実行しなければならない。

ホスト２１は、アクセスすべきＲＥマークスロットｎとアクセスモード［モード＝０（リード）、１（チェンジ）、２（ワイプ）］を選択する。さらに、ホストは乱数ＲＸを生成する（ステップ２５）。その後、ホスト２１は、以下のメッセージをドライブに送信する。

ここで、Ｍ_１は、

の省略形であり、ハッシュ関数は共有バスキーを使用した鍵付きハッシュ関数である。当該ハッシュ関数はまた他のタイプのものであってもよく、ハッシュを含めることは任意的なものであるということに留意すべきである。その主たる目的は、認証されていないアプリケーションがＲＥマークを破壊することを防ぐことである。ドライブ２３は、受信したメッセージ２７のフォーマットをチェックする（ステップ２９）。当該フォーマットが不適切である場合、通信エラー又はハッキングを示すため、ドライブはプロトコルを中断する。他方、メッセージ２７が検証される場合、ドライブ２３はパラメータｎ及びモードに符号化されるリクエストを実行する（ステップ３１）。その後、ドライブ２３は、以下のレスポンスメッセージ３３をホスト２１に送信する。

ここで、Ｍ_２は、

を表し、ＲＭ_ｎは可能な更新後のｎ番目のＲＥマーク値の現在値である。モード＝２（ワイプ）である場合、ドライブはＲＭ_ｎをすべてゼロにセットする。ホスト２１は、受信したレスポンスメッセージ３３のフォーマットをチェックする。乱数ＲＸがホストがメッセージ２７によりドライブに送信した値と同一でない場合、ホスト２１はプロトコルを中断し、ＲＥマークの新たな値を無視する。メッセージに含まれたハッシュがメッセージ２７の残りと一致しない場合、ホストはプロトコルを中断し、ＲＥマークの新たな値を無視する。そうでない場合、新たな値ＲＭ_ｎが受け付けされ、ＤＲＭデータをプロテクトするため、ホストにより使用される。図１の上記実施例と同様に、ドライブ及び／又はホストがプロトコルを中断した場合、プロトコルのリトライはステップ２５からスタートする必要があるということに留意されたい。

ＭＭＣについて返されたデータブロックとパラメータブロックは、図１に示される実施例のもの、すなわち、図２及び３に示されたものと同様である。

以下において、本発明のより抽象的な説明が与えられる。図５に示されるような２つの周知な攻撃に対するＡｌｉｃｅ（Ａ）とＢｏｂ（Ｂ）との間の通信をセキュアにするための方法は、従来技術から知られている。Ａｌｉｃｅは、メッセージ、特にデジタル著作権管理に関するコマンドをＢｏｂに相当する受信者に送信するホスト又はアプリケーションユニットに対応する。Ａｌｉｃｅ（Ａ）がＢｏｂ（Ｂ）にメッセージを送信すると、Ｅｖｅ（Ｅ）は盗聴し、メッセージの情報を盗もうとするかもしれない。Ｅｖｅ（Ｅ）は、盗聴によってＡｌｉｃｅがＢｏｂに送信する情報を盗もうとしている。すなわち、当該上方の秘匿性が攻撃されている。Ｍａｌｌｏｒｙ（Ｍ）は盗聴だけでなく、Ｂｏｂへのメッセージを変更する。

Ｍａｌｌｏｒｙ（Ｍ）がＡｌｉｃｅがＢｏｂに送信するメッセージを変更する場合、情報のインテグリティが攻撃される。

これらの攻撃を防ぐための標準的な方法は、ＡｌｉｃｅとＢｏｂが以下のようなプロトコルを実行することである。
１．彼らは通信を開始する前に秘密を共有する。この共有された秘密は、再利用可能である。
２．彼らは、図５の攻撃の下で情報を共有する前に、図６に示されるプロトコルステップを実行する。概略すると、Ａｌｉｃｅは共有されている秘密をＢｏｂが知っていることを検証することによって、Ｂｏｂと話をしていることを検証する。Ｂｏｂは、彼らの共有されている秘密と適切な方法により合成されたＡｌｉｃｅにより送信されるチャレンジを返すことが可能であるべきである。任意的には、Ｂｏｂは、同様にしてＡｌｉｃｅと接続されることを検証することが可能である（相互認証）。項ｆ（ｘ，ｙ，．．．）は、レスポンス又はメッセージがｘ，ｙ，．．．を用いて構成されていることを示す。例えば、ｘがデータであり、ｙがキーであるとき、ｆ（ｘ，ｙ）は、ｙによるｘの暗号化の結果を示すかもしれない。
３．彼らは、おそらく前の２つのステップからのチェレンジ／レスポンスに基づき、ＵＳ４，２００，７７０に記載されるようなＤｉｆｆｉｅ−Ｈｅｌｌｍａｎキー交換などを利用して、一時的な秘密であるバスキーを共有することにより継続する。

この初期段階の後、バスキーと送信された情報とを合成することによって、ＡｌｉｃｅとＢｏｂの間で情報がセキュアに共有することが可能である。バスキーによる暗号化によって秘匿性が保証され、バスキーに基づくＭＡＣ（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）を添付することからインテグリティが得られる。この結果はまた、ＳＡＣ（Ｓｅｃｕｒｅ Ａｕｔｈｅｎｔｉｃａｔｅｄ Ｃｈａｎｎｅｌ）として知られている。

図６に示されるように、ＡｌｉｃｅとＢｏｂの両者により共有されている秘密がある。この共有されている秘密は、（相互）認証を実行するため利用され、Ａｌｉｃｅは、チャンレンジを有する第１リクエストをＢｏｂに送信する。Ｂｏｂは、このチャレンジと共有されている秘密とを用いて第１レスポンスを生成し、当該レスポンスをＡｌｉｃｅに送信する。これにより、当該レスポンスの適切な生成をチェックすることによって、ＡｌｉｃｅはＢｏｂと実際に通信することを検証することができる。同じことが、Ｂｏｂからの第２リクエストとＡｌｉｃｅからの第２レスポンスに適用される。通信の適切な参加者の検証後、バスキーがＡｌｉｃｅとＢｏｂとの間で交換される。さらなる通信について、当該場スキーが共有されている秘密として利用される。

図５に示される攻撃とは別に、図７のパート（ａ）に示されるように、Ｂｏｂに送信された情報がＯｔｔｏ（Ｏ）によりブロック又は妨害されているより一般的でない攻撃のクラスが存在する。Ｏｔｔｏは、例えば、彼のアカウントからデジタル権限のデクリメント又は取り消しをブロックするなど、これを実行する動機付けがあるかもしれない。この攻撃を回避することは基本的には不可能であるが、図７のパート（ｂ）に示されるように、ＢｏｂがＡｌｉｃｅからの送信の受け付けを認証することを要求などすることによって、Ａｌｉｃｅは自分が妨害されていることがわかるように、プロトコルを構成することが可能である。このとき、Ａｌｉｃｅは、Ｏｔｔｏのアカウントをキャンセルするなど、Ｏｔｔｏを罰するための他の措置をとることが可能である。

この直接的な手段による問題点は、ＢｏｂだけでなくＯｔｔｏもまた、それがバスキーにより暗号的にプロテクトされていても、このアクノリッジメントを生成することが可能であるということである。すなわち、第１ラウンドでは、Ｏｔｔｏは、Ａｌｉｃｅの送信が通過することを許可し、単にＢｏｂからのレスポンスを記録する。Ａｌｉｃｅからの以降の送信は妨害されるが、図８に示されるように、Ｏｔｔｏは、Ａｌｉｃｅにすべてがダンディ（ｄａｎｄｙ）であるという幻想を与えるため、Ｂｏｂからの“コンファメーション”を再生する。パート（ａ）において、ＯｔｔｏはＡｌｉｃｅの送信がＢｏｂに通過することを許可し、これにより、Ｂｏｂのコンファメーション“を記録することが可能となる。パート（ｂ）において、Ｏｔｔｏは、Ａｌｉｃｅからの以降のすべての送信を妨害するが、Ａｌｉｃｅには彼女のメッセージがパート（ａ）からのＢｏｂのレスポンスを再生することによって通過しているという幻想を与える。

本発明の課題の１つは、後者の攻撃に対する解決手段を提供することである。この解決手段は、以下のとおりである。すなわち、ＡｌｉｃｅはＢｏｂからのレスポンスが以下の一般的な形式を有することを要求すべきである。

ここで、“バスキー”は、ＳＡＣがセットアップされている間の共有されている秘密であり、“セキュリティシグネチャ”は、以下の要件を充足するバイナリ文字列である。
・当該文字列は、十分長く、典型的には６４ビットより大きなものであるべきである。
・当該文字列は、Ａｌｉｃｅが送信するすべての情報／コマンドに対しこと練っているべきである。
・Ａｌｉｃｅは、セキュリティシグネチャを知っているか、又は計算することが可能であるべきである。“他のデータ”は、本開示に関係しないレスポンスの任意的なペイロードである。

このレスポンスを受信すると、Ａｌｉｃｅは、当該レスポンスが“セキュリティシグネチャ”及び“バスキー”についての自らの知識に従っていることをチェックすべきである。バスキーの目的は、Ｏｔｔｏが図８の攻撃を実行することが可能となるのに、適切なレスポンスがどうあるべきか予測することを防ぐことである。文字列の目的は、ＯｔｔｏがＢｏｂから古いレスポンスを再生することを防ぐことであり、このため、シグネチャは常時変更されるべきである。シグネチャは、Ｏｔｔｏが乱数を単に抽出することによって良好な確立によりレスポンスを予測することが不可能となるように、十分長いものであるべきである。

このようなレスポンスの構造の具体例として以下があげられる。
・“セキュリティシグネチャ”は、Ａｌｉｃｅが送信するすべての情報／コマンドについて単調に増加する整数である。すなわち、“セキュリティシグネチャ”は、コマンドのシリアル番号である。
・“セキュリティシグネチャ”は、

の形式をとる。ここで、ｐａｙｌｏａｄ［ｎ］は、プロトコルの第ｎラウンドのペイロードであり、ｓｅｃｓｉｇ１及びｓｅｃｓｉｇ２は、固定された文字列である。Ａｌｉｃｅは、受信したすべてのｐａｙｌｏａｄ［ｎ］を記録し、（ａ）同一のペイロードが２回受信されていないか、また（ｂ）ｓｅｃｓｉｇ１及びｓｅｃｓｉｇ２が予想されたものであるかチェックする。この形式の“セキュリティシグネチャ”は、Ｂｏｂのみが実質的に同一でないペイロードを返す場合に限って良好に機能する。上記ＲＥマークの例では、このケースとなる。
・“セキュリティシグネチャ”は、プロトコルの各ラウンドについて新規なＡｌｉｃｅによりランダムに選択された乱数（チャレンジ）であり、情報／コマンド段階においてＢｏｂに転送される。レスポンスを受信すると、Ａｌｉｃｅは、Ｂｏｂからの応答に適切なチャレンジが存在するかチェックする。図９は、このプロトコルの一例を示す。当該チャレンジが、ＡｌｉｃｅがＢｏｂに送信する情報のすべてのブロックについて異なるとき、対応するレスポンスもまた異なる。従って、Ａｌｉｃｅは、ＯｔｔｏがＢｏｂからの古いレスポンスを再生しているか、又はＢｏｂ自身が新しいレスポンスを送信しているか検出することが可能である。

図９は、図８の攻撃に対する可能なセキュリティ手段を示す。そこでは、Ａｌｉｃｅのすべての送信が（ランダムな）チャレンジを有し、Ｂｏｂはバスキーと適切に合成されたＢｏｂのコンファメーションにおいてエコーする必要がある。

図９に示されるキー交換及び（相互）認証の各ステップは、図６に示されるものと同一である。しかしながら、さらなる通信は、メッセージのペア、すなわち、リクエストとレスポンスのペアを有し、当該リクエストと共にチャレンジが与えられ、当該チャレンジは再びレスポンスと通信される。チャレンジが、ＡｌｉｃｅとＢｏｂのみによって知られている共有される秘密を使用して暗号処理されているため、リクエストの送信者は、受信者が実際に対応するリクエストを受信したことを検証することができる。好ましくは、当該チャレンジは、リクエストとレスポンスの各ペアの後に変更され、すなわち、同一のチャレンジは、リクエスト共に再び使用されることは実質的にない。これは、いくつかのメッセージを解析することにより共有された秘密の秘匿性を破る可能性を減少させ、再生攻撃の危険を回避する。

図１０は、アプリケーションユニット４１とドライブユニット４３とを有する本発明によるデジタル著作権管理システム４０を示す。このアプリケーションユニット４１は、バスキーを格納する第１キーストレージユニット４５と、リクエスト生成ユニット４７と、レスポンス検証ユニット４９とを有する。ドライブユニット４３は、バスキーを格納するキーストレージユニット５５と、リクエスト処理ユニット５７と、レスポンス生成ユニット５９とを有する。ドライブユニット４３とアプリケーションユニット４１は、通信ユニット５１を共有する。ドライブユニットは、デジタル著作権管理の対象となるコンテンツを有するディスク５３にアクセスするよう構成され、特に、当該ディスク５３の隠されたチャネルに読み書きするよう構成される。

動作中、リクエスト生成ユニット４７は、メッセージとチャレンジとを有するリクエストを生成し、メッセージは、ディスク５３上のＲＥマークを変更するコマンドなど、デジタル著作権関連コマンドを有する。当該リクエストは、通信ユニット５１を介しドライブユニット４３に送信される。当該リクエストがリクエスト処理ユニット５７により有効であると検出される場合、リクエスト処理ユニット５７は、例えば、ディスク５３上のＲＥマークを変更させる。この変更は、レスポンス生成ユニット５９によるレスポンスにチャレンジの指標と共に含まれるＲＥマークに対する新たな値を与える。少なくとも当該レスポンスの生成のため、バスキーが使用され、当該バスキーを用いてリクエストを生成することが好ましい。当該レスポンスは、通信ユニットを介しアプリケーションユニット４１に送信される。レスポンスの有効性は、バスキーを用いたレスポンスの復号化後、チャレンジの指標の有無をチェックすることによってレスポンス検証ユニットによりチェックされる。当該レスポンスが有効であると検出された場合、リクエストが実際にドライブユニット４３により処理され、レスポンスがドライブユニット４３により生成されたことは、アプリケーションユニット４１に明らかである。

ＢＤ−ＶＣＰＳとしてのデジタル著作権管理システムによって、３回の再生と２回の複製の許可など、ステートフル（ｓｔａｔｅｆｕｌ）な権利のセキュアな格納がディスク上に設けられる。既知のＤＲＭシステムに使用される隠されたチャネルに類似するＲＥマークなどの光サイドチャネルが、この目的のために使用される。既知のＤＲＭシステムと異なって、ＢＤ−ＶＣＰＳはキーロッカーを規定セス、その代わりにアプリケーションに隠されたチャネルに対する直接的なインタフェースを提供する。本発明者は、アプリケーションとドライブとの間の認証が隠されたチャネルアクセスに関する各種攻撃に対するプロテクションを提供するのに十分でないということを認識している。本発明によると、この問題に対する解決手段は、好ましくは隠されたチャネルに対するアクセス毎に使用される必要がある追加的なチャレンジ・レスポンス機構を追加することから構成される。

本発明が上述された実施例を参照して説明されたが、他の実施例もまた同一の課題を達成するのに利用可能であるということは明らかである。本発明の範囲は、上述した実施例に限定されるものでなく、他の通信システムに適用可能である。

さらに、請求項を含む本明細書における“有する”という動詞とその派生語の使用は、記載された特徴、整数、ステップ又はコンポーネントの存在を特定するものであると理解され、他の１以上の特徴、整数、ステップ若しくはコンポーネント又はそのグループの存在又は追加を排除するものでないということに留意すべきである。また、請求項の要素に前置される不定冠詞“ある”は、そのような要素が複数存在することを排除するものでないということに留意すべきである。さらに、参照符号は請求項の範囲を限定するものでなく、本発明は、ハードウェアとソフトウェアの両方により実現可能であり、いくつかの“手段”は、同一のハードウェアアイテムにより表されるかもしれない。さらに、本発明は、新規なそれぞれ及びすべての特徴又は特徴の組み合わせにある。

図１は、本発明によるデジタル著作権管理方法の第１実施例の概略的なフローチャートを示す。 図２は、ＳＥＮＤ ＫＥＹ ＲＥ Ｍａｒｋコマンドのパラメータデータの構成を示す。 図３は、ＲＥＰＯＲＴ ＫＥＹ ＲＥ Ｍａｒｋコマンドの返されたデータの構成を示す。 図４は、本発明によるデジタル著作権管理方法の第２実施例の概略的なフローチャートを示す。 図５は、セキュア化されていない通信に対する２つの可能な攻撃を示す。 図６は、チャレンジ・レスポンス及びキー交換プロトコルの概略的なフローチャートを示す。 図７は、セキュア化されていない通信に対する他の可能な攻撃を示す。 図８は、従来の第２の通信に対する可能な攻撃を示す。 図９は、エンハンスされた通信プロトコルの概略的なフローチャートを示す。 図１０は、本発明によるデジタル著作権管理システムを示す。

Claims (15)

1. コピープロテクトされたコンテンツへのアクセス権限を制御するドライブユニットを有するデジタル著作権管理システムに使用されるアプリケーションユニットであって、
   当該アプリケーションユニットは、
   バスキーを格納するキーストレージユニットと、
   前記アクセス権限に関するメッセージとチャレンジとを含む前記ドライブユニットにより実行されるリクエストを生成するリクエスト生成ユニットと、
   前記リクエストを送信し、前記ドライブユニットから前記リクエストに対するレスポンスを受信する通信ユニットと、
   前記バスキーを用いて前記レスポンスを復号化し、前記リクエストが実行されたことを示す前記レスポンスにおける前記チャレンジの指標の有無をチェックすることによって、前記リクエストと前記レスポンスとの間のリンクを検証するレスポンス検証ユニットと、
   を有するアプリケーションユニット。
2. 前記リクエスト生成ユニットは、前記バスキーによって前記メッセージと前記チャレンジとを暗号的にリンクさせるよう構成される、請求項１記載のアプリケーションユニット。
3. 前記リクエスト生成ユニットは、前記リクエストのインテグリティテストに使用するため、シグネチャを前記リクエストに含めるよう構成される、請求項１記載のアプリケーションユニット。
4. 前記リクエスト生成ユニットは、前記バスキーを用いて前記リクエストを暗号化するよう構成される、請求項１記載のアプリケーションユニット。
5. 前記リクエスト生成ユニットは、ハッシュ関数によって、特に前記バスキーを用いた鍵付きハッシュ関数によって、前記チャレンジ及び／又は前記メッセージ並びに前記バスキーから求められる値を前記リクエストに含めるよう構成される、請求項１記載のアプリケーションユニット。
6. 前記メッセージは、隠されたチャネルエントリを管理するコマンド、特に隠されたチャネルエントリをリードするため、隠されたチャネルエントリをチェンジするため、及び／又は隠されたチャネルエントリをワイプするためのコマンドを含む、請求項１記載のアプリケーションユニット。
7. 前記リクエスト生成ユニットは、乱数、前記リクエストを特定する識別子、特に実質的に一意的な識別子、及び／又は所定のデータを前記チャレンジとして前記リクエストに含めるよう構成される、請求項１記載のアプリケーションユニット。
8. 当該アプリケーションユニットは、ホスト、特にソフトウェアアプリケーションである、請求項１記載のアプリケーションユニット。
9. コピープロテクトされたコンテンツへのアクセス権限を制御するアプリケーションユニットを有するデジタル著作権管理システムに使用されるドライブユニットであって、
   当該ドライブユニットは、
   バスキーを格納するキーストレージユニットと、
   前記アプリケーションユニットからチャレンジと前記アクセス権限に関するメッセージとを有する当該ドライブユニットによって実行されるリクエストを受信し、前記リクエストにレスポンスを送信する通信ユニットと、
   前記メッセージを処理するリクエスト処理ユニットと、
   前記チャレンジの指標と前記メッセージに対するリプライとを含む前記レスポンスを生成するレスポンス生成ユニットと、
   を有し、
   前記リプライと前記チャレンジの指標とは、前記バスキーによって暗号的にリンクされ、
   前記レスポンスにおける前記チャレンジの指標は、前記リクエストが実行されたことを示すドライブユニット。
10. 前記リプライは、隠されたチャネルエントリ、特に当該ドライブユニットによりリード又はチェンジされた隠されたチャネルエントリを有する、請求項９記載のドライブユニット。
11. 請求項１記載のアプリケーションユニットと、請求項９記載のドライブユニットとを有するコピープロテクトされたコンテンツへのアクセス権限を制御するデジタル著作権管理システムであって、
    前記バスキーは、前記アプリケーションユニットと前記ドライブユニットとにより共有されるデジタル著作権管理システム。
12. バスキーを共有するアプリケーションユニットとドライブユニットとを有するデジタル著作権管理システムにおけるコピープロテクトされたコンテンツへのアクセス権限を制御するデジタル著作権管理方法であって、
    ａ）チャレンジと前記アクセス権限に関するメッセージとを有する前記ドライブユニットにより実行されるリクエストを生成するステップと、
    ｂ）前記アプリケーションユニットから前記ドライブユニットに前記リクエストを通信するステップと、
    ｃ）前記メッセージを処理するステップと、
    ｄ）前記チャレンジの指標と前記メッセージに対するリプライとが前記バスキーにより暗号的にリンクする前記指標と前記リプライとを含むレスポンスを生成するステップと、
    ｅ）前記ドライブユニットから前記アプリケーションユニットに前記レスポンスを通信するステップと、
    ｆ）前記バスキーを用いて前記レスポンスを復号化し、前記リクエストが実行されたことを示す前記レスポンスにおける前記チャレンジの指標の存在の有無をチェックすることによって、前記リクエストと前記レスポンスとの間のリンクを検証するステップと、
    を有する方法。
13. 前記ステップｂ）の後であって、前記ステップｃ）の前に前記リクエストを検証するステップをさらに有するデジタル著作権管理方法。
14. 当該コンピュータプログラムがアプリケーションユニット上で実行されると、請求項１２記載の方法のステップａ）、ｂ）、ｅ）及びｆ）を前記アプリケーションユニットに実行させるコンピュータプログラムコード手段を有するコンピュータプログラム。
15. 当該コンピュータプログラムがドライブユニット上で実行されると、請求項１２記載の方法のステップｂ）〜ｅ）を前記ドライブユニットに実行させるコンピュータプログラムコード手段を有するコンピュータプログラム。
    

Images