送信システムにおけるデバイスタイプ認証
【課題】本発明の一般的な目的は、通信システムにおいてデバイスタイプ認証を実現することである。本発明の他の目的は、信号を発する広範囲に及ぶ試みを回避するような方法およびデバイスを実現することである。
【解決手段】通信システム（１）では、情報を含む、好ましくはデバイスタイプ関連コミットメントと関係するヘッダに、さらにその情報用の署名を付ける。署名により、ヘッダ情報の信憑性が保証される。好ましくは第１のデバイス（２０）の少なくとも不正使用防止デバイスタイプに固有の情報に基づいて、第１のデバイス（２０）で不正使用防止になるように署名を作成する。ヘッダ情報および署名はコンテンツプロバイダ（１０）へ伝送され、そこで、署名の検証が行われてから、デバイスタイプ関連コミットメントが有効であると認められる。このような署名をシステムで使用する場合には、ＨＴＴＰまたはＳＭＴＰを使用するのが好ましい。
【解決手段】通信システム（１）では、情報を含む、好ましくはデバイスタイプ関連コミットメントと関係するヘッダに、さらにその情報用の署名を付ける。署名により、ヘッダ情報の信憑性が保証される。好ましくは第１のデバイス（２０）の少なくとも不正使用防止デバイスタイプに固有の情報に基づいて、第１のデバイス（２０）で不正使用防止になるように署名を作成する。ヘッダ情報および署名はコンテンツプロバイダ（１０）へ伝送され、そこで、署名の検証が行われてから、デバイスタイプ関連コミットメントが有効であると認められる。このような署名をシステムで使用する場合には、ＨＴＴＰまたはＳＭＴＰを使用するのが好ましい。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に通信システムによるデータ転送に関し、詳細には、コンピュータコードまたはメディアオブジェクトの処理に関する。
【背景技術】
【０００２】
さまざまな種類のコンピュータコードまたはメディア製品を、通信ネットワークを経由したデータ転送により提供する市場が成長しつつある。代表的な例としては、音楽の録音、コンピュータプログラム、画像、ビデオシーケンス、または文字による創作物などのダウンロードがある。このような一連のデータのほとんどは、ある種の著作権に関係している。しかし、コンピュータネットワーク技術の進歩が速いため、不正配布や不正コピーが後を絶たない。
【０００３】
この技術分野では、コンテンツプロバイダおよび事業者が、ダウンロードされたメディアオブジェクトの利用法を管理する必要がある。ダウンロードとは、メディアオブジェクトをそれが利用されるであろうデバイスに配信する手段のことである。このような保護を講じるために、さまざまなデジタル著作権管理（ＤＲＭ）概念が発展してきた。それゆえ、ＤＲＭはダウンロードされた後のメディアオブジェクトの利用法を管理するための手段である。
【０００４】
この分野のさまざまな関係企業が参加してＯｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ （ＯＭＡ）という組織内で協力しあい、さまざまなＤＲＭソリューションを提供してきた。しかし、コンテンツの保護に関しては、現在利用可能なＤＲＭ仕様は完全かつ確実なものと言うことはできない。今日、ＤＲＭの利用は、ターミナル、例えば電話の中のプログラムを変更することができないという意味で閉じたデバイスをターゲットとしている。
【０００５】
このような閉じた電話の例としてはＳｏｎｙ Ｅｒｉｃｓｓｏｎ Ｔ６８ｉがある。このようなデバイスは、ＤＲＭの取り扱いに適したものであろう（現在リリースされているものがそうでないとしても）。
【０００６】
コンテンツの保護は、そのような場合には、その特定の種類のデバイスのハードウェアまたはソフトウェアによって保証される。受信デバイスにそれが特定のデバイスであり、デバイスソフトウェアを備えるか、または別のＤＲＭ関連アプリケーションをサポートしていると明記されていれば、受信当事者は特定の規則に従うことを約束することになる。したがって、このようなステートメントは、ある種のデバイスタイプ関連コミットメントに関係する。
【０００７】
コンテンツプロバイダは、ＤＲＭ付きのメディアオブジェクトコンテンツを受信当事者に送信する前に、受信端末の能力に関する情報を受信する。これは、通常、例えば、Ａｃｃｅｐｔ、Ｕｓｅｒ Ａｇｅｎｔ、またはＵＡＰｒｏｆなどのＨＴＴＰ（「ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ」）ヘッダを使用して実行する。コンテンツプロバイダは、この情報を使用して、ＤＲＭガイドラインに従うことを保証しない端末にコンテンツを送信することを防ぐ。
【０００８】
公開された米国特許出願番号２００３／００１４４９６Ａ１では、デジタルメディア用の閉ループ配信システムが開示されている。デバイス識別情報は、コンテンツサーバに送られる。コンテンツサーバは、デバイス、ユーザ、および使用権に関する情報を収めたデータベースに照らし合わせてデバイス識別情報の管理または認証を行う。特定のデバイスおよびそのユーザが使用権と適切な能力を有している場合、メディアコンテンツが返される。識別情報に関する認証は、コンテンツプロバイダ側にのみ格納され利用可能なデータに基づいて行われる。したがって、これは上述の最新技術の代表的な例である。
【特許文献１】米国特許出願番号２００３／００１４４９６Ａ１
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかし、従来技術のデバイスの問題点は、どのような端末でも、たとえサポートしていなくてもＤＲＭをサポートしているという合図を送ることが容易にできることである。ＤＲＭ仕様に従ってその能力に関する情報を送信するか、または偽りのデバイス識別情報を送りさえすればよいのである。従来技術のシステムでは、コンテンツプロバイダは、デバイスによって主張されたことが本当に真実なのかを確実に知ることはできない。つまり、コンテンツプロバイダが貴重なコンテンツを、それとは知らずにＤＲＭ規則を課さない端末に送信するような状況も起こりえる。これらの端末は、したがって、ＤＲＭ保護をたやすく破ることができ、コンテンツを制御されずに取り扱うことも可能である。
【００１０】
そこで、本発明の一般的な目的は、通信システムにおいてデバイスタイプ認証を実現することである。本発明の他の目的は、信号を発する広範囲に及ぶ試みを回避するような方法およびデバイスを実現することである。
【課題を解決するための手段】
【００１１】
上記の目的は、添付の特許請求項による方法およびデバイスによって達成される。要するに、情報を含む、好ましくはデバイスタイプ関連コミットメントと関係するヘッダに、さらにその情報用の署名を付与する。署名により、ヘッダ情報の信憑性が保証される。好ましくはそのデバイスの少なくとも不正使用防止デバイスタイプに固有の情報に基づいて、受信デバイスで不正使用防止になるように署名を作成する。ヘッダ情報および署名はコンテンツプロバイダへ伝送され、そこで、署名の検証が行われてから、デバイスタイプ関連コミットメントが有効であると認められる。このような署名をシステムで使用する場合には、ＨＴＴＰまたはＳＭＴＰ（「Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ」）を使用するのが好ましい。
【００１２】
本発明の一実施形態では、署名の実際の検証は、通信システム内の別のデバイス、例えば、受信端末のメーカーに関係するデバイスで実行される。
【００１３】
本発明の１つの利点は、信頼できるデバイスタイプ認証に冗長なデバイスタイプログイン手順を必要としないことである。ここで提案しているような署名は、現在のヘッダ構造に容易に組み込むことができる。
【発明を実施するための最良の形態】
【００１４】
本発明は、本発明の他の目的および利点とともに、以下の説明および添付の図面を参照することより最もよく理解できる。
【００１５】
従来技術による解決方法の問題点を詳述するために、現在利用可能なさまざまなＤＲＭ手法について簡単に検討することからこの説明を始める。これ以降、本発明による解決方法について、多数の実施例を用いて説明する。
【００１６】
図１は、一般的な通信システム１を示している。第１のデバイス、つまりこの説明ではコンテンツプロバイダとして動作するサーバ１０は、第２のデバイス、つまり端末２０に永続的にまたは一時的に確立された接続３０により接続される。この例では、端末２０のユーザは、メディアオブジェクト４０をサーバ１０からダウンロードすることを望んでいる。このために、ＨＴＴＰ ＧＥＴメッセージが端末２０からサーバ１０に送信され、サーバ１０が受信した情報と関連する状態を受け入れれば、メディアオブジェクト４０を返すことができる。
【００１７】
ＤＲＭ仕様に関するＯＭＡの提案では、３つの異なるＤＲＭレベルがあり、図２〜４に概略が示されている。ＤＲＭを使用することにより、コンテンツプロバイダはメディアオブジェクトを使用する際の規則または権利を定義することができる。さまざまな権利を単一のメディアオブジェクトに関連付けることが可能である。権利が異なれば、料金も異なるであろう。コンテンツプロバイダは、メディアオブジェクトを無料でプレビューする権利をユーザに付与し、完全な使用権についてのみユーザに課金するようにできる。価値はメディアオブジェクト自体を使用する権利にあるので、ＤＲＭによれば、メディアオブジェクト自体を販売するのではなく、メディアオブジェクトを使用する権利を販売することができる。
【００１８】
特別な場合について、最初に、図２の「順方向ロック」に示されている。特定のコンテンツ４４を含むメディアオブジェクト４２からなるＤＲＭメッセージ４６は、コンテンツプロバイダから消費者デバイス２０にＷＡＰダウンロードされる。ここでは、別の権利オブジェクトは存在していない。その代わりに、権利はメディアオブジェクト４２自体と組み合わされ、一組のデフォルトの権利がメディアオブジェクト４２に与えられる。消費者が異なれば、配信されるメディアオブジェクトの権利に対する要求も異なることが多いため、このようなケースは採用しにくい場合が多い。
【００１９】
図３には、組合せ配信が示されている。ここでは、メディアオブジェクト４２のコンテンツ４４および関連する権利４８は、端末２０によりダウンロードされた全く同一のＤＲＭメッセージ４６を使用して配信される。この解決方法は、権利４８と実際のコンテンツ４４との間で接続を維持しやすいためかなり容易である。
【００２０】
図４には、別の配信方法が示されている。メディアオブジェクト４３は不正使用ができないようにロックされ、コンテンツ４４は関連する権利４７が利用できる場合にのみユーザに利用を許可できる。したがって、関連する権利４７は、ロックされたメディアオブジェクト４３の鍵として動作する。セキュリティレベルを高めるために、ロックされたメディアオブジェクト４３および権利４７は、別々に端末に送信される。メディアオブジェクト４３は、端末２０によってダウンロードされる。権利は、未確認プッシュにより、端末２０に供給することができる。端末２０では、メディアオブジェクト４３および権利４７は、互いに関連付けられ、メディアオブジェクト４３のコンテンツ４４は、権利４７の規則に応じてユーザに利用を許可することができる。
【００２１】
ＷＡＰダウンロードＤＲＭ適用範囲では、２つの主要な問題が解決される。第１に、メディアオブジェクトの転送が禁止されることである。第２に、メディアオブジェクトの使用に対して特定の規則を定義することができる、つまり、あらゆる種類のプレビュー、アクセス回数制限、有効期間制限などを全く同じ概念で解決することができるということである。
【００２２】
しかし、上で説明したように、端末が実際にＤＲＭコミットメントに従っているという仮定にＤＲＭ概念全体が基づいているという点に大きな問題がある。ＤＲＭ付きのコンテンツが端末に送信される前に、メディアオブジェクトを保持しているサーバが端末の能力に関する情報を受信する。これは、例えば、Ａｃｃｅｐｔ、Ｕｓｅｒ Ａｇｅｎｔ、またはＵＡＰｒｏｆなどのＨＴＴＰヘッダを使用して実行する。端末では、ＤＲＭ使用に従って能力に関する情報を送信するだけで、ＤＲＭをサポートしていることを主張する信号をサーバに送信することができる。しかし、サーバ側では、主張内容が本当に真実であるかどうかを見分けられない。つまり、コンテンツプロバイダが貴重なコンテンツを、それと知らずにＤＲＭ規則を課さない端末に送信する場合もありえるということである。そのため、これらの端末は、ＤＲＭ保護をたやすく破り、自分の判断でコンテンツを使用することができる。
【００２３】
上述のように、本発明による問題の解決方法は、ヘッダ情報自体の署名を導入することである。署名は、さまざまなデータオブジェクト、例えば、テキスト、実行可能ファイル、またはメディアファイルが本物かどうかの検証のため、さまざまなアプリケーションで使用されている。この場合、署名で保護されるのは実際のデータ内容ではなく、ヘッダ情報である。したがって、この署名を使用することにより、ヘッダ情報が正しいかどうかを検証することができる。この概念は、さまざまなアプリケーションで使用することも可能であるが、特に、デバイスタイプ関連コミットメントに関係するヘッダ情報の認証に特に適している。このようなコミットメントの代表的な例として、特定のＤＲＭスキームに従うコミットメントがある。
【００２４】
端末が「ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｏｍａ．ｄｒｍ．ｍｅｓｓａｇｅ」という部分を含むＨＴＴＰヘッダを送信すると、暗黙のうちに、受信サーバに、端末がＯＭＡ ＤＲＭ規制に従うことを認めたと通知することになる。同様に、ＨＴＴＰヘッダ情報に「Ｕｓｅｒ-Ａｇｅｎｔ：ＳＥＭ４．６」が含まれていると、端末がＳｏｎｙ-Ｅｒｉｃｓｓｏｎ-Ｍｏｂｉｌｅ ４．６ソフトウェアをベースとしていることを主張することになる。受信サーバはそのようなソフトウェアがＤＲＭをサポートしていることを容易に知ることができ、したがってＵｓｅｒＡｇｅｎｔヘッダは暗黙のうちにＤＲＭに従うというコミットメントになる。さらに、ＨＴＴＰヘッダ「ＵＡＰｒｏｆ：ｗｗｗ．ｓｅｍ．ｃｏｍ／ｐｈｏｎｅｓ／ｔ６８」は暗黙のコミットメントである、というのも、Ｔ６８携帯電話の主張するサポート内容を結論できるからである。
【００２５】
本発明によれば、デバイスのサポートする能力を通知するヘッダには端末による署名が入る。その後、サーバは、署名の妥当性を確認し、送信者側が信頼できるデバイスであることを確認することができる。署名を作成する実際のプロセスは、従来技術の原理に従って実行することができる。しかし、ヘッダ情報の署名はまだ使用されたことがない。
【００２６】
上記のヘッダの例では、ＨＴＴＰはモデル通信プロトコルとして使用されていた。しかし、デバイス関連情報を含むヘッダを使用する、ＳＭＴＰなどの他のプロトコルも使用することができる。
【００２７】
本発明では、第１のヘッダ情報を使って、例えば、デバイスタイプ関連コミットメントを定義する。第２のヘッダ情報にその署名を入れる。第１のヘッダ情報と第２のヘッダ情報は、別々のヘッダに入れることもできるし、また全く同一のヘッダにまとめて入れることもできる。例えば、ヘッダ「Ｕｓｅｒ-Ａｇｅｎｔ-Ｓｉｇｎａｔｕｒｅ」の代わりに、ヘッダ「Ｕｓｅｒ-Ａｇｅｎｔ」を修正して署名も入れられるようにできる。
【００２８】
ほとんどの場合、第１のヘッダ情報と第２のヘッダ情報を両方とも全く同じ実際のメッセージに含めるのが便利である。しかし、第１のヘッダ情報を一方のメッセージに入れ、第２のヘッダ情報を他のメッセージ、好ましくは後のメッセージに入れて送ることも可能である。これら２つのメッセージは１つのまとめられたメッセージとしてみなし、２回に分けて伝送することが可能である。このようにヘッダ情報の伝送を分けることで、セキュリティのレベルが高まるが、その一方で、これらの部分メッセージを関連付ける付加的手段が受信側に必要になる。本開示では、「メッセージ」という用語は、単一のメッセージを含むだけでなく、この段落の前のほうで述べたようなまとめられたメッセージを含むものとして解釈する。
【００２９】
以下では、本発明の実装例をいくつか説明する。図５には、通信システム１が示されている。端末２０は、ダウンロードエージェントＳＥＭ４．６を使用するダウンロード手段２２および共有秘密情報２４用の不正使用防止記憶装置２３を備える。共有秘密情報２４は、この実施形態では、ＳＥＭ４．６ダウンロードエージェントを備える端末に固有の秘密データ文字列である。ダウンロード手段２２により適切に指定されたルーチンでないと、この不正使用防止記憶装置２３の内容を読み出すことはできない。次に、ダウンロード手段２２は、通信システム１で他の当事者と通信する役割を果たす通信手段２１、および通信手段２１により送信されるメッセージのヘッダを作成するヘッダプロバイダ２５を備える。本発明の一実施形態によれば、ダウンロード手段２２は、さらに、署名作成器２６も備える。
【００３０】
端末２０のユーザは、メディアオブジェクトをサーバ１０を備えるコンテンツプロバイダからダウンロードすることを望んでいる。端末２０は、対象となるメディアオブジェクト用にＨＴＴＰ ＧＥＴメッセージを用意し、ヘッダプロバイダ２５は、ヘッダ「Ｕｓｅｒ-Ａｇｅｎｔ：ＳＥＭ４．６」を作成する。ダウンロード手段２２は、記憶装置２３の共有秘密情報２４の内容を読み出し、ＨＴＴＰ Ｕｓｅｒ−Ａｇｅｎｔヘッダからデータを追加し、署名作成器２６を通じて実行する。署名作成器は、この実施形態では、鍵付きメッセージダイジェスト、例えば、ＭＤ５である。ＨＴＴＰヘッダから追加されたデータは、この特定の例では、「ＳＥＭ４．６」というテキスト文字列である。ＭＤ５は、あるデータの１２８ビット固有表現を生成する一方向関数となっている。署名作成器２６の計算からの出力結果はヘッダの署名を構成し、ヘッダプロバイダ２５により、例えば、新しいヘッダ「Ｕｓｅｒ-Ａｇｅｎｔ-Ｓｉｇｎａｔｕｒｅ：８９７ｙ６５ｇｈｄｒａ４８」内に追加される。この実施形態では、ヘッダプロバイダ２５は、元のヘッダ情報と、その署名からなるヘッダ情報の両方を作成する役割を果たす。
【００３１】
今署名付きヘッダを有するＨＴＴＰ ＧＥＴメッセージは、サーバ１０に送信される。サーバ１０は、この実施形態では、共有秘密情報１４−端末２０と同じ共有秘密情報２４−を含む。また、この共有秘密情報１４は、不正使用が防止され記憶装置１３に格納される。通信手段１１がメッセージを受信する。サーバ１０は、Ｕｓｅｒ−Ａｇｅｎｔヘッダに気づき、それをヘッダ情報の認証が必要なケースに関連付ける。ヘッダ情報は、Ｕｓｅｒ−Ａｇｅｎｔ部分と署名部分を備えており、認証手段１５に転送される。記憶装置１３は、認証手段１５に含まれるか、または接続されている。認証手段１５内の署名作成器１６は、記憶装置１３からこのＵｓｅｒ Ａｇｅｎｔと関連付けられた共有秘密情報１４を読み出す。この共有秘密情報に対して、ＨＴＴＰヘッダから得られるデータが追加され、端末２０の署名作成器２６と同じデータが追加される。署名作成器１６は、このデータをＭＤ５ルーチンに通し、独立した結果を得る。ＭＤ５からの計算された出力の値がＨＴＴＰヘッダの署名と同じであれば、元のＨＴＴＰ Ｕｓｅｒ−Ａｇｅｎｔヘッダは信頼できるものである。
【００３２】
そこで、サーバは、検証済みのＵｓｅｒ−Ａｇｅｎｔをマッピングし、端末がサポートしているＤＲＭクラスを確認し、適当なＤＲＭクラスに応じて要求されたメディアオブジェクトとともに返信する。
【００３３】
当業者であれば、端末およびサーバ内のさまざまな手段は物理的デバイスというよりは機能手段であることを認識するであろう。端末およびサーバのさまざまな部分手段をソフトウェア、ハードウェア、またはそれらを混合したものとして実現できる。さらに、一体として実装するだけでなく、分散手段としても実装することができる。さらに、当業者であれば、さまざまな手段を互いに分離した状態に置くことも、一体化できることも理解するであろう。したがって、本開示の図に示されたブロック構造は、物理的なブロック構造であるというよりは、手段の機能を理解しやすくすることのみを目的としている。
【００３４】
本発明の上記の実施形態では、共有秘密情報とＨＴＴＰヘッダ情報との混合をＭＤ５手順の入力として使用されている。しかし、他の入力も可能である。ＨＴＴＰヘッダ情報は完全に無視されることもありえるため、署名は共有秘密情報にのみ基づく。ただし。そのように生成された署名は、侵入者を引き寄せ、その侵入者の目的のために使用される可能性もある。
【００３５】
以上で、端末とサーバとの間の通信について説明した。このような通信はもちろん、通信システム内の任意のデバイス間で実行することも可能である。しかし、通常の場合、サーバはメディアオブジェクトを提供する側であり、コンピュータ、携帯電話、オーディオプレーヤなどの端末は受信側である。
【００３６】
署名作成は、端末とサーバの両方に知られている他の情報に基づくことも可能である。例えば、時刻と共有秘密情報とを混ぜて署名を生成することができる。これは、ある時刻にヘッダとともに送信した署名が、別の時刻に無効になるということを意味する。同様に、日付を使用して、明らかにランダムにすることもできる。また、特にはＵｓｅｒ−Ａｇｅｎｔに接続されていない他のヘッダ情報をこのような目的に使用することも可能である。これらのすべての場合において、署名は、サーバがヘッダを受信したときに端末とサーバの両方に共通の情報に基づく。
【００３７】
本発明の他の実施形態は図６に示されている。ここでは、記憶装置２３および署名作成器２６は一体化されている。この実施形態では、共有秘密情報２４はアルゴリズムの定義を含み、これに基づき、署名が作成される。代表例の１つでは、ヘッダ情報（ＳＥＭ４．６）および時刻が署名作成器２６に入力される。
【００３８】
署名作成器２６は、記憶装置２３から秘密アルゴリズム定義を読み込んで、それに従い、署名生成を実行する。
【００３９】
サーバ側では、署名の検証を同様にして実行する。入力データ、つまりヘッダ情報と時刻が署名作成器１６に入力されるが、これは、記憶装置１３から取り出したアルゴリズム情報に依存する。結果とヘッダ署名との比較により、真偽が検証される。
【００４０】
もちろん、図５および図６の実施形態を組み合わせることも可能であり、その場合、記憶装置１３、２３は共有データ秘密情報と共有アルゴリズム定義秘密情報の両方を格納している。
【００４１】
当業者であれば、署名の信頼性は共有秘密情報の機密性に依存することを理解するであろう。共有秘密情報および署名アルゴリズムが知られている場合、侵入者は正しい署名もまたシミュレートすることができる。端末の場合、共有秘密情報は端末の製造時にメーカーによって用意され、この情報の不正取得を禁止する手段が存在する。実際にこの秘密情報を秘密に保つことがメーカーの利益につながっているため、メーカー側で強力な保護対策を講じるものと思われる。
【００４２】
しかし、この手順を図５および図６の実施形態に従って運用する場合、共有秘密情報もまた、サーバ内に置かなければならない。この概念を利用するであろう関係企業、コンテンツプロバイダなどが多数存在するため、共有秘密情報を各サーバに分散させなければならない。つまり、重要情報を膨大な数のデバイスと膨大な数の関係企業に分散させなければならないということである。関与するサーバの共有秘密情報保護対策が不十分であったり、関与する関係企業のそのような秘密情報の日常的取り扱いが不完全であれば、署名保護の保全性は損なわれる可能性がある。
【００４３】
図７では、共有秘密情報を多数の当事者に分散する危険性を減じる、本発明の他の実施形態を示している。端末側は、図５に示されているのと同様である。しかし、サーバ１０の認証手段１５は、共有秘密情報自体を含まない。その代わりに、本発明では、認証手段１５は第三者に認証要求を転送する手段、つまりセーフサーバ５０を備える。認証手段１５は、Ｕｓｅｒ−Ａｇｅｎｔヘッダ情報を読み込んで、このユーザエージェントに認証サービスを提供するセーフサーバ５０を調べる。
【００４４】
セーフサーバ５０は、注意深く管理された共有秘密情報を取り扱うためのハードウェアおよびルーチンを含む。例えば、端末２０のメーカーは、このようなセーフサーバ５０をきちんと用意し、共有秘密情報を不正使用防止策を講じたうえで提供していることを保証することができる。認証手段１５からの認証要求には、サーバ１０に届いたヘッダ情報、特に、署名の作成および署名自体で使用される部分が含まれる。セーフサーバ５０は、この情報を受信すると、不正使用防止策が講じられている署名検証手順を実行する。署名検証では、共有秘密情報に関する知識を利用する。署名が検証されれば、そのヘッダ情報が本物であることを知らせる返信が認証手段１５に送り返される。検証されなければ、偽の署名であることを通知する返信が送り返される。セーフサーバ５０が検証を行って本物であることが確認されれば、そのヘッダ情報はサーバ１０によって本物であると認められ、例えば、適当なＤＲＭルーチンに従って、メディアオブジェクトを安全に配布することができる。
【００４５】
サーバ１０は、異なるセーフサーバ５１〜５３にさらに接続可能であることが好ましく、各サーバは１つまたはいくつかのユーザエージェント、アプリケーション定義、またはデバイスタイプの共有秘密情報を保証する。元のヘッダ情報から、真偽検証の要求を行うためセーフサーバ５０〜５３のうちの１つとコンタクトをとらなければならないと結論される。同様に、他のコンテンツプロバイダの所有する他のサーバ６０、６１も同じセーフサーバ５０〜５３に接続可能である。
【００４６】
この構成では、共有秘密情報が１つまたは少数の非常に信頼できるサーバで利用可能であれば十分である。したがって完全に異なるレベルまでの機密性を保証できる。この概念は、セーフサーバとコンテンツプロバイダとの間の信頼できる関係に基づいている。コンテンツプロバイダは、メディアオブジェクトを配布するリスクを負う側の当事者である。しかし、セーフサーバの事業者、例えば、端末メーカーは、不正使用を目的にその秘密情報にアクセスし得ないことを保証する。
【００４７】
図８は、本発明による方法の実施形態の主要なステップの流れ図である。手順は、ステップ２００から始まる。ステップ２０２では、通信メッセージの第１のヘッダ情報が第１のデバイスにおいて供給される。第１のヘッダ情報は、デバイスタイプ関連コミットメントと関連付けられている情報を含むのが好ましい。ステップ２０４で、第１の署名は不正使用防止策を講じたうえで第１のデバイスにおいて作成される。署名作成は、少なくとも、第１のヘッダ情報の少なくとも一部と関連付けられている不正使用防止情報に基づく。ステップ２０６で、通信メッセージの第２のヘッダ情報として署名が供給される。ステップ２０８で、メッセージは、第１のデバイスの接続先の通信システムの他のデバイスに伝送される。最後に、ステップ２１０で、メッセージが第２のデバイスに届いた後に前記第１の署名を検証することにより、第１のヘッダ情報が認証される。ステップ２１２で手順は終了する。
【００４８】
本発明による方法の他の好ましい実施形態は、前の説明から容易に推論できる。
【００４９】
当業者であれば、付属の請求項で定義された、本発明の範囲を逸脱することなく、さまざまな修正および変更を本発明に加えられることを理解するであろう。
【図面の簡単な説明】
【００５０】
【図１】サーバによって端末にメディアオブジェクトが供給される一般的な通信システムの図である。
【図２】第１のＤＲＭ概念を表す図である。
【図３】第２のＤＲＭ概念を表す図である。
【図４】第３のＤＲＭ概念を表す図である。
【図５】本発明による通信システムの実施形態のブロック図である。
【図６】本発明による通信システムの他の実施形態のブロック図である。
【図７】本発明による通信システムのさらに他の実施形態のブロック図である。
【図８】本発明による方法の実施形態の主要なステップを説明する流れ図である。
【符号の説明】
【００５１】
１ 一般的な通信システム
１０ サーバ
１１ 通信手段
１３ 記憶装置
１４ 共有秘密情報
１５ 認証手段
１６ 署名作成器
２０ 端末
２０ 消費者デバイス
２１ 通信手段
２２ ダウンロード手段
２３ 不正使用防止記憶装置
２４ 共有秘密情報
２５ ヘッダプロバイダ
２６ 署名作成器
４０ メディアオブジェクト
４２ メディアオブジェクト
４３ メディアオブジェクト
４４ コンテンツ
４６ ＤＲＭメッセージ
４７ 権利
４８ 権利
５０ セーフサーバ
５１〜５３ セーフサーバ
６０、６１ サーバ
【技術分野】
【０００１】
本発明は、一般に通信システムによるデータ転送に関し、詳細には、コンピュータコードまたはメディアオブジェクトの処理に関する。
【背景技術】
【０００２】
さまざまな種類のコンピュータコードまたはメディア製品を、通信ネットワークを経由したデータ転送により提供する市場が成長しつつある。代表的な例としては、音楽の録音、コンピュータプログラム、画像、ビデオシーケンス、または文字による創作物などのダウンロードがある。このような一連のデータのほとんどは、ある種の著作権に関係している。しかし、コンピュータネットワーク技術の進歩が速いため、不正配布や不正コピーが後を絶たない。
【０００３】
この技術分野では、コンテンツプロバイダおよび事業者が、ダウンロードされたメディアオブジェクトの利用法を管理する必要がある。ダウンロードとは、メディアオブジェクトをそれが利用されるであろうデバイスに配信する手段のことである。このような保護を講じるために、さまざまなデジタル著作権管理（ＤＲＭ）概念が発展してきた。それゆえ、ＤＲＭはダウンロードされた後のメディアオブジェクトの利用法を管理するための手段である。
【０００４】
この分野のさまざまな関係企業が参加してＯｐｅｎ Ｍｏｂｉｌｅ Ａｌｌｉａｎｃｅ （ＯＭＡ）という組織内で協力しあい、さまざまなＤＲＭソリューションを提供してきた。しかし、コンテンツの保護に関しては、現在利用可能なＤＲＭ仕様は完全かつ確実なものと言うことはできない。今日、ＤＲＭの利用は、ターミナル、例えば電話の中のプログラムを変更することができないという意味で閉じたデバイスをターゲットとしている。
【０００５】
このような閉じた電話の例としてはＳｏｎｙ Ｅｒｉｃｓｓｏｎ Ｔ６８ｉがある。このようなデバイスは、ＤＲＭの取り扱いに適したものであろう（現在リリースされているものがそうでないとしても）。
【０００６】
コンテンツの保護は、そのような場合には、その特定の種類のデバイスのハードウェアまたはソフトウェアによって保証される。受信デバイスにそれが特定のデバイスであり、デバイスソフトウェアを備えるか、または別のＤＲＭ関連アプリケーションをサポートしていると明記されていれば、受信当事者は特定の規則に従うことを約束することになる。したがって、このようなステートメントは、ある種のデバイスタイプ関連コミットメントに関係する。
【０００７】
コンテンツプロバイダは、ＤＲＭ付きのメディアオブジェクトコンテンツを受信当事者に送信する前に、受信端末の能力に関する情報を受信する。これは、通常、例えば、Ａｃｃｅｐｔ、Ｕｓｅｒ Ａｇｅｎｔ、またはＵＡＰｒｏｆなどのＨＴＴＰ（「ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ」）ヘッダを使用して実行する。コンテンツプロバイダは、この情報を使用して、ＤＲＭガイドラインに従うことを保証しない端末にコンテンツを送信することを防ぐ。
【０００８】
公開された米国特許出願番号２００３／００１４４９６Ａ１では、デジタルメディア用の閉ループ配信システムが開示されている。デバイス識別情報は、コンテンツサーバに送られる。コンテンツサーバは、デバイス、ユーザ、および使用権に関する情報を収めたデータベースに照らし合わせてデバイス識別情報の管理または認証を行う。特定のデバイスおよびそのユーザが使用権と適切な能力を有している場合、メディアコンテンツが返される。識別情報に関する認証は、コンテンツプロバイダ側にのみ格納され利用可能なデータに基づいて行われる。したがって、これは上述の最新技術の代表的な例である。
【特許文献１】米国特許出願番号２００３／００１４４９６Ａ１
【発明の開示】
【発明が解決しようとする課題】
【０００９】
しかし、従来技術のデバイスの問題点は、どのような端末でも、たとえサポートしていなくてもＤＲＭをサポートしているという合図を送ることが容易にできることである。ＤＲＭ仕様に従ってその能力に関する情報を送信するか、または偽りのデバイス識別情報を送りさえすればよいのである。従来技術のシステムでは、コンテンツプロバイダは、デバイスによって主張されたことが本当に真実なのかを確実に知ることはできない。つまり、コンテンツプロバイダが貴重なコンテンツを、それとは知らずにＤＲＭ規則を課さない端末に送信するような状況も起こりえる。これらの端末は、したがって、ＤＲＭ保護をたやすく破ることができ、コンテンツを制御されずに取り扱うことも可能である。
【００１０】
そこで、本発明の一般的な目的は、通信システムにおいてデバイスタイプ認証を実現することである。本発明の他の目的は、信号を発する広範囲に及ぶ試みを回避するような方法およびデバイスを実現することである。
【課題を解決するための手段】
【００１１】
上記の目的は、添付の特許請求項による方法およびデバイスによって達成される。要するに、情報を含む、好ましくはデバイスタイプ関連コミットメントと関係するヘッダに、さらにその情報用の署名を付与する。署名により、ヘッダ情報の信憑性が保証される。好ましくはそのデバイスの少なくとも不正使用防止デバイスタイプに固有の情報に基づいて、受信デバイスで不正使用防止になるように署名を作成する。ヘッダ情報および署名はコンテンツプロバイダへ伝送され、そこで、署名の検証が行われてから、デバイスタイプ関連コミットメントが有効であると認められる。このような署名をシステムで使用する場合には、ＨＴＴＰまたはＳＭＴＰ（「Ｓｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ」）を使用するのが好ましい。
【００１２】
本発明の一実施形態では、署名の実際の検証は、通信システム内の別のデバイス、例えば、受信端末のメーカーに関係するデバイスで実行される。
【００１３】
本発明の１つの利点は、信頼できるデバイスタイプ認証に冗長なデバイスタイプログイン手順を必要としないことである。ここで提案しているような署名は、現在のヘッダ構造に容易に組み込むことができる。
【発明を実施するための最良の形態】
【００１４】
本発明は、本発明の他の目的および利点とともに、以下の説明および添付の図面を参照することより最もよく理解できる。
【００１５】
従来技術による解決方法の問題点を詳述するために、現在利用可能なさまざまなＤＲＭ手法について簡単に検討することからこの説明を始める。これ以降、本発明による解決方法について、多数の実施例を用いて説明する。
【００１６】
図１は、一般的な通信システム１を示している。第１のデバイス、つまりこの説明ではコンテンツプロバイダとして動作するサーバ１０は、第２のデバイス、つまり端末２０に永続的にまたは一時的に確立された接続３０により接続される。この例では、端末２０のユーザは、メディアオブジェクト４０をサーバ１０からダウンロードすることを望んでいる。このために、ＨＴＴＰ ＧＥＴメッセージが端末２０からサーバ１０に送信され、サーバ１０が受信した情報と関連する状態を受け入れれば、メディアオブジェクト４０を返すことができる。
【００１７】
ＤＲＭ仕様に関するＯＭＡの提案では、３つの異なるＤＲＭレベルがあり、図２〜４に概略が示されている。ＤＲＭを使用することにより、コンテンツプロバイダはメディアオブジェクトを使用する際の規則または権利を定義することができる。さまざまな権利を単一のメディアオブジェクトに関連付けることが可能である。権利が異なれば、料金も異なるであろう。コンテンツプロバイダは、メディアオブジェクトを無料でプレビューする権利をユーザに付与し、完全な使用権についてのみユーザに課金するようにできる。価値はメディアオブジェクト自体を使用する権利にあるので、ＤＲＭによれば、メディアオブジェクト自体を販売するのではなく、メディアオブジェクトを使用する権利を販売することができる。
【００１８】
特別な場合について、最初に、図２の「順方向ロック」に示されている。特定のコンテンツ４４を含むメディアオブジェクト４２からなるＤＲＭメッセージ４６は、コンテンツプロバイダから消費者デバイス２０にＷＡＰダウンロードされる。ここでは、別の権利オブジェクトは存在していない。その代わりに、権利はメディアオブジェクト４２自体と組み合わされ、一組のデフォルトの権利がメディアオブジェクト４２に与えられる。消費者が異なれば、配信されるメディアオブジェクトの権利に対する要求も異なることが多いため、このようなケースは採用しにくい場合が多い。
【００１９】
図３には、組合せ配信が示されている。ここでは、メディアオブジェクト４２のコンテンツ４４および関連する権利４８は、端末２０によりダウンロードされた全く同一のＤＲＭメッセージ４６を使用して配信される。この解決方法は、権利４８と実際のコンテンツ４４との間で接続を維持しやすいためかなり容易である。
【００２０】
図４には、別の配信方法が示されている。メディアオブジェクト４３は不正使用ができないようにロックされ、コンテンツ４４は関連する権利４７が利用できる場合にのみユーザに利用を許可できる。したがって、関連する権利４７は、ロックされたメディアオブジェクト４３の鍵として動作する。セキュリティレベルを高めるために、ロックされたメディアオブジェクト４３および権利４７は、別々に端末に送信される。メディアオブジェクト４３は、端末２０によってダウンロードされる。権利は、未確認プッシュにより、端末２０に供給することができる。端末２０では、メディアオブジェクト４３および権利４７は、互いに関連付けられ、メディアオブジェクト４３のコンテンツ４４は、権利４７の規則に応じてユーザに利用を許可することができる。
【００２１】
ＷＡＰダウンロードＤＲＭ適用範囲では、２つの主要な問題が解決される。第１に、メディアオブジェクトの転送が禁止されることである。第２に、メディアオブジェクトの使用に対して特定の規則を定義することができる、つまり、あらゆる種類のプレビュー、アクセス回数制限、有効期間制限などを全く同じ概念で解決することができるということである。
【００２２】
しかし、上で説明したように、端末が実際にＤＲＭコミットメントに従っているという仮定にＤＲＭ概念全体が基づいているという点に大きな問題がある。ＤＲＭ付きのコンテンツが端末に送信される前に、メディアオブジェクトを保持しているサーバが端末の能力に関する情報を受信する。これは、例えば、Ａｃｃｅｐｔ、Ｕｓｅｒ Ａｇｅｎｔ、またはＵＡＰｒｏｆなどのＨＴＴＰヘッダを使用して実行する。端末では、ＤＲＭ使用に従って能力に関する情報を送信するだけで、ＤＲＭをサポートしていることを主張する信号をサーバに送信することができる。しかし、サーバ側では、主張内容が本当に真実であるかどうかを見分けられない。つまり、コンテンツプロバイダが貴重なコンテンツを、それと知らずにＤＲＭ規則を課さない端末に送信する場合もありえるということである。そのため、これらの端末は、ＤＲＭ保護をたやすく破り、自分の判断でコンテンツを使用することができる。
【００２３】
上述のように、本発明による問題の解決方法は、ヘッダ情報自体の署名を導入することである。署名は、さまざまなデータオブジェクト、例えば、テキスト、実行可能ファイル、またはメディアファイルが本物かどうかの検証のため、さまざまなアプリケーションで使用されている。この場合、署名で保護されるのは実際のデータ内容ではなく、ヘッダ情報である。したがって、この署名を使用することにより、ヘッダ情報が正しいかどうかを検証することができる。この概念は、さまざまなアプリケーションで使用することも可能であるが、特に、デバイスタイプ関連コミットメントに関係するヘッダ情報の認証に特に適している。このようなコミットメントの代表的な例として、特定のＤＲＭスキームに従うコミットメントがある。
【００２４】
端末が「ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｏｍａ．ｄｒｍ．ｍｅｓｓａｇｅ」という部分を含むＨＴＴＰヘッダを送信すると、暗黙のうちに、受信サーバに、端末がＯＭＡ ＤＲＭ規制に従うことを認めたと通知することになる。同様に、ＨＴＴＰヘッダ情報に「Ｕｓｅｒ-Ａｇｅｎｔ：ＳＥＭ４．６」が含まれていると、端末がＳｏｎｙ-Ｅｒｉｃｓｓｏｎ-Ｍｏｂｉｌｅ ４．６ソフトウェアをベースとしていることを主張することになる。受信サーバはそのようなソフトウェアがＤＲＭをサポートしていることを容易に知ることができ、したがってＵｓｅｒＡｇｅｎｔヘッダは暗黙のうちにＤＲＭに従うというコミットメントになる。さらに、ＨＴＴＰヘッダ「ＵＡＰｒｏｆ：ｗｗｗ．ｓｅｍ．ｃｏｍ／ｐｈｏｎｅｓ／ｔ６８」は暗黙のコミットメントである、というのも、Ｔ６８携帯電話の主張するサポート内容を結論できるからである。
【００２５】
本発明によれば、デバイスのサポートする能力を通知するヘッダには端末による署名が入る。その後、サーバは、署名の妥当性を確認し、送信者側が信頼できるデバイスであることを確認することができる。署名を作成する実際のプロセスは、従来技術の原理に従って実行することができる。しかし、ヘッダ情報の署名はまだ使用されたことがない。
【００２６】
上記のヘッダの例では、ＨＴＴＰはモデル通信プロトコルとして使用されていた。しかし、デバイス関連情報を含むヘッダを使用する、ＳＭＴＰなどの他のプロトコルも使用することができる。
【００２７】
本発明では、第１のヘッダ情報を使って、例えば、デバイスタイプ関連コミットメントを定義する。第２のヘッダ情報にその署名を入れる。第１のヘッダ情報と第２のヘッダ情報は、別々のヘッダに入れることもできるし、また全く同一のヘッダにまとめて入れることもできる。例えば、ヘッダ「Ｕｓｅｒ-Ａｇｅｎｔ-Ｓｉｇｎａｔｕｒｅ」の代わりに、ヘッダ「Ｕｓｅｒ-Ａｇｅｎｔ」を修正して署名も入れられるようにできる。
【００２８】
ほとんどの場合、第１のヘッダ情報と第２のヘッダ情報を両方とも全く同じ実際のメッセージに含めるのが便利である。しかし、第１のヘッダ情報を一方のメッセージに入れ、第２のヘッダ情報を他のメッセージ、好ましくは後のメッセージに入れて送ることも可能である。これら２つのメッセージは１つのまとめられたメッセージとしてみなし、２回に分けて伝送することが可能である。このようにヘッダ情報の伝送を分けることで、セキュリティのレベルが高まるが、その一方で、これらの部分メッセージを関連付ける付加的手段が受信側に必要になる。本開示では、「メッセージ」という用語は、単一のメッセージを含むだけでなく、この段落の前のほうで述べたようなまとめられたメッセージを含むものとして解釈する。
【００２９】
以下では、本発明の実装例をいくつか説明する。図５には、通信システム１が示されている。端末２０は、ダウンロードエージェントＳＥＭ４．６を使用するダウンロード手段２２および共有秘密情報２４用の不正使用防止記憶装置２３を備える。共有秘密情報２４は、この実施形態では、ＳＥＭ４．６ダウンロードエージェントを備える端末に固有の秘密データ文字列である。ダウンロード手段２２により適切に指定されたルーチンでないと、この不正使用防止記憶装置２３の内容を読み出すことはできない。次に、ダウンロード手段２２は、通信システム１で他の当事者と通信する役割を果たす通信手段２１、および通信手段２１により送信されるメッセージのヘッダを作成するヘッダプロバイダ２５を備える。本発明の一実施形態によれば、ダウンロード手段２２は、さらに、署名作成器２６も備える。
【００３０】
端末２０のユーザは、メディアオブジェクトをサーバ１０を備えるコンテンツプロバイダからダウンロードすることを望んでいる。端末２０は、対象となるメディアオブジェクト用にＨＴＴＰ ＧＥＴメッセージを用意し、ヘッダプロバイダ２５は、ヘッダ「Ｕｓｅｒ-Ａｇｅｎｔ：ＳＥＭ４．６」を作成する。ダウンロード手段２２は、記憶装置２３の共有秘密情報２４の内容を読み出し、ＨＴＴＰ Ｕｓｅｒ−Ａｇｅｎｔヘッダからデータを追加し、署名作成器２６を通じて実行する。署名作成器は、この実施形態では、鍵付きメッセージダイジェスト、例えば、ＭＤ５である。ＨＴＴＰヘッダから追加されたデータは、この特定の例では、「ＳＥＭ４．６」というテキスト文字列である。ＭＤ５は、あるデータの１２８ビット固有表現を生成する一方向関数となっている。署名作成器２６の計算からの出力結果はヘッダの署名を構成し、ヘッダプロバイダ２５により、例えば、新しいヘッダ「Ｕｓｅｒ-Ａｇｅｎｔ-Ｓｉｇｎａｔｕｒｅ：８９７ｙ６５ｇｈｄｒａ４８」内に追加される。この実施形態では、ヘッダプロバイダ２５は、元のヘッダ情報と、その署名からなるヘッダ情報の両方を作成する役割を果たす。
【００３１】
今署名付きヘッダを有するＨＴＴＰ ＧＥＴメッセージは、サーバ１０に送信される。サーバ１０は、この実施形態では、共有秘密情報１４−端末２０と同じ共有秘密情報２４−を含む。また、この共有秘密情報１４は、不正使用が防止され記憶装置１３に格納される。通信手段１１がメッセージを受信する。サーバ１０は、Ｕｓｅｒ−Ａｇｅｎｔヘッダに気づき、それをヘッダ情報の認証が必要なケースに関連付ける。ヘッダ情報は、Ｕｓｅｒ−Ａｇｅｎｔ部分と署名部分を備えており、認証手段１５に転送される。記憶装置１３は、認証手段１５に含まれるか、または接続されている。認証手段１５内の署名作成器１６は、記憶装置１３からこのＵｓｅｒ Ａｇｅｎｔと関連付けられた共有秘密情報１４を読み出す。この共有秘密情報に対して、ＨＴＴＰヘッダから得られるデータが追加され、端末２０の署名作成器２６と同じデータが追加される。署名作成器１６は、このデータをＭＤ５ルーチンに通し、独立した結果を得る。ＭＤ５からの計算された出力の値がＨＴＴＰヘッダの署名と同じであれば、元のＨＴＴＰ Ｕｓｅｒ−Ａｇｅｎｔヘッダは信頼できるものである。
【００３２】
そこで、サーバは、検証済みのＵｓｅｒ−Ａｇｅｎｔをマッピングし、端末がサポートしているＤＲＭクラスを確認し、適当なＤＲＭクラスに応じて要求されたメディアオブジェクトとともに返信する。
【００３３】
当業者であれば、端末およびサーバ内のさまざまな手段は物理的デバイスというよりは機能手段であることを認識するであろう。端末およびサーバのさまざまな部分手段をソフトウェア、ハードウェア、またはそれらを混合したものとして実現できる。さらに、一体として実装するだけでなく、分散手段としても実装することができる。さらに、当業者であれば、さまざまな手段を互いに分離した状態に置くことも、一体化できることも理解するであろう。したがって、本開示の図に示されたブロック構造は、物理的なブロック構造であるというよりは、手段の機能を理解しやすくすることのみを目的としている。
【００３４】
本発明の上記の実施形態では、共有秘密情報とＨＴＴＰヘッダ情報との混合をＭＤ５手順の入力として使用されている。しかし、他の入力も可能である。ＨＴＴＰヘッダ情報は完全に無視されることもありえるため、署名は共有秘密情報にのみ基づく。ただし。そのように生成された署名は、侵入者を引き寄せ、その侵入者の目的のために使用される可能性もある。
【００３５】
以上で、端末とサーバとの間の通信について説明した。このような通信はもちろん、通信システム内の任意のデバイス間で実行することも可能である。しかし、通常の場合、サーバはメディアオブジェクトを提供する側であり、コンピュータ、携帯電話、オーディオプレーヤなどの端末は受信側である。
【００３６】
署名作成は、端末とサーバの両方に知られている他の情報に基づくことも可能である。例えば、時刻と共有秘密情報とを混ぜて署名を生成することができる。これは、ある時刻にヘッダとともに送信した署名が、別の時刻に無効になるということを意味する。同様に、日付を使用して、明らかにランダムにすることもできる。また、特にはＵｓｅｒ−Ａｇｅｎｔに接続されていない他のヘッダ情報をこのような目的に使用することも可能である。これらのすべての場合において、署名は、サーバがヘッダを受信したときに端末とサーバの両方に共通の情報に基づく。
【００３７】
本発明の他の実施形態は図６に示されている。ここでは、記憶装置２３および署名作成器２６は一体化されている。この実施形態では、共有秘密情報２４はアルゴリズムの定義を含み、これに基づき、署名が作成される。代表例の１つでは、ヘッダ情報（ＳＥＭ４．６）および時刻が署名作成器２６に入力される。
【００３８】
署名作成器２６は、記憶装置２３から秘密アルゴリズム定義を読み込んで、それに従い、署名生成を実行する。
【００３９】
サーバ側では、署名の検証を同様にして実行する。入力データ、つまりヘッダ情報と時刻が署名作成器１６に入力されるが、これは、記憶装置１３から取り出したアルゴリズム情報に依存する。結果とヘッダ署名との比較により、真偽が検証される。
【００４０】
もちろん、図５および図６の実施形態を組み合わせることも可能であり、その場合、記憶装置１３、２３は共有データ秘密情報と共有アルゴリズム定義秘密情報の両方を格納している。
【００４１】
当業者であれば、署名の信頼性は共有秘密情報の機密性に依存することを理解するであろう。共有秘密情報および署名アルゴリズムが知られている場合、侵入者は正しい署名もまたシミュレートすることができる。端末の場合、共有秘密情報は端末の製造時にメーカーによって用意され、この情報の不正取得を禁止する手段が存在する。実際にこの秘密情報を秘密に保つことがメーカーの利益につながっているため、メーカー側で強力な保護対策を講じるものと思われる。
【００４２】
しかし、この手順を図５および図６の実施形態に従って運用する場合、共有秘密情報もまた、サーバ内に置かなければならない。この概念を利用するであろう関係企業、コンテンツプロバイダなどが多数存在するため、共有秘密情報を各サーバに分散させなければならない。つまり、重要情報を膨大な数のデバイスと膨大な数の関係企業に分散させなければならないということである。関与するサーバの共有秘密情報保護対策が不十分であったり、関与する関係企業のそのような秘密情報の日常的取り扱いが不完全であれば、署名保護の保全性は損なわれる可能性がある。
【００４３】
図７では、共有秘密情報を多数の当事者に分散する危険性を減じる、本発明の他の実施形態を示している。端末側は、図５に示されているのと同様である。しかし、サーバ１０の認証手段１５は、共有秘密情報自体を含まない。その代わりに、本発明では、認証手段１５は第三者に認証要求を転送する手段、つまりセーフサーバ５０を備える。認証手段１５は、Ｕｓｅｒ−Ａｇｅｎｔヘッダ情報を読み込んで、このユーザエージェントに認証サービスを提供するセーフサーバ５０を調べる。
【００４４】
セーフサーバ５０は、注意深く管理された共有秘密情報を取り扱うためのハードウェアおよびルーチンを含む。例えば、端末２０のメーカーは、このようなセーフサーバ５０をきちんと用意し、共有秘密情報を不正使用防止策を講じたうえで提供していることを保証することができる。認証手段１５からの認証要求には、サーバ１０に届いたヘッダ情報、特に、署名の作成および署名自体で使用される部分が含まれる。セーフサーバ５０は、この情報を受信すると、不正使用防止策が講じられている署名検証手順を実行する。署名検証では、共有秘密情報に関する知識を利用する。署名が検証されれば、そのヘッダ情報が本物であることを知らせる返信が認証手段１５に送り返される。検証されなければ、偽の署名であることを通知する返信が送り返される。セーフサーバ５０が検証を行って本物であることが確認されれば、そのヘッダ情報はサーバ１０によって本物であると認められ、例えば、適当なＤＲＭルーチンに従って、メディアオブジェクトを安全に配布することができる。
【００４５】
サーバ１０は、異なるセーフサーバ５１〜５３にさらに接続可能であることが好ましく、各サーバは１つまたはいくつかのユーザエージェント、アプリケーション定義、またはデバイスタイプの共有秘密情報を保証する。元のヘッダ情報から、真偽検証の要求を行うためセーフサーバ５０〜５３のうちの１つとコンタクトをとらなければならないと結論される。同様に、他のコンテンツプロバイダの所有する他のサーバ６０、６１も同じセーフサーバ５０〜５３に接続可能である。
【００４６】
この構成では、共有秘密情報が１つまたは少数の非常に信頼できるサーバで利用可能であれば十分である。したがって完全に異なるレベルまでの機密性を保証できる。この概念は、セーフサーバとコンテンツプロバイダとの間の信頼できる関係に基づいている。コンテンツプロバイダは、メディアオブジェクトを配布するリスクを負う側の当事者である。しかし、セーフサーバの事業者、例えば、端末メーカーは、不正使用を目的にその秘密情報にアクセスし得ないことを保証する。
【００４７】
図８は、本発明による方法の実施形態の主要なステップの流れ図である。手順は、ステップ２００から始まる。ステップ２０２では、通信メッセージの第１のヘッダ情報が第１のデバイスにおいて供給される。第１のヘッダ情報は、デバイスタイプ関連コミットメントと関連付けられている情報を含むのが好ましい。ステップ２０４で、第１の署名は不正使用防止策を講じたうえで第１のデバイスにおいて作成される。署名作成は、少なくとも、第１のヘッダ情報の少なくとも一部と関連付けられている不正使用防止情報に基づく。ステップ２０６で、通信メッセージの第２のヘッダ情報として署名が供給される。ステップ２０８で、メッセージは、第１のデバイスの接続先の通信システムの他のデバイスに伝送される。最後に、ステップ２１０で、メッセージが第２のデバイスに届いた後に前記第１の署名を検証することにより、第１のヘッダ情報が認証される。ステップ２１２で手順は終了する。
【００４８】
本発明による方法の他の好ましい実施形態は、前の説明から容易に推論できる。
【００４９】
当業者であれば、付属の請求項で定義された、本発明の範囲を逸脱することなく、さまざまな修正および変更を本発明に加えられることを理解するであろう。
【図面の簡単な説明】
【００５０】
【図１】サーバによって端末にメディアオブジェクトが供給される一般的な通信システムの図である。
【図２】第１のＤＲＭ概念を表す図である。
【図３】第２のＤＲＭ概念を表す図である。
【図４】第３のＤＲＭ概念を表す図である。
【図５】本発明による通信システムの実施形態のブロック図である。
【図６】本発明による通信システムの他の実施形態のブロック図である。
【図７】本発明による通信システムのさらに他の実施形態のブロック図である。
【図８】本発明による方法の実施形態の主要なステップを説明する流れ図である。
【符号の説明】
【００５１】
１ 一般的な通信システム
１０ サーバ
１１ 通信手段
１３ 記憶装置
１４ 共有秘密情報
１５ 認証手段
１６ 署名作成器
２０ 端末
２０ 消費者デバイス
２１ 通信手段
２２ ダウンロード手段
２３ 不正使用防止記憶装置
２４ 共有秘密情報
２５ ヘッダプロバイダ
２６ 署名作成器
４０ メディアオブジェクト
４２ メディアオブジェクト
４３ メディアオブジェクト
４４ コンテンツ
４６ ＤＲＭメッセージ
４７ 権利
４８ 権利
５０ セーフサーバ
５１〜５３ セーフサーバ
６０、６１ サーバ
【特許請求の範囲】
【請求項１】
通信システム（１）に接続された第１のデバイス（２０）において、通信メッセージの、デバイスタイプ関連コミットメントと関連付けられた第１のヘッダ情報を提供するステップと、
前記通信メッセージを前記通信システム（１）に接続された第２のデバイス（１０）に伝送するステップとを含む、通信システム（１）におけるデバイスタイプの認証方法であって、
さらに、
前記第１のデバイスの少なくとも不正使用防止デバイスタイプに固有の情報に基づいて、前記第１のデバイス（２０）で不正使用防止可能なように第１の署名を作成するステップと、
前記第１のデバイス（２０）において、前記署名を含む前記通信メッセージの第２のヘッダ情報を提供するステップと、
前記通信ステップの後に前記第１の署名を検証することにより前記第１のヘッダ情報を認証するステップとを有することを特徴とする方法。
【請求項２】
前記通信システム（１）が、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）およびＳｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）から構成されるグループから選択された転送プロトコルに基づくことを特徴とする請求項１に記載の方法。
【請求項３】
前記デバイスタイプ関連コミットメントが、デジタル著作権管理（ＤＲＭ）に準拠する旨のコミットメントであることを特徴とする請求項２に記載の方法。
【請求項４】
前記第１のデバイスがユーザ端末（２０）であることを特徴とする請求項１から３のいずれか１項に記載の方法。
【請求項５】
前記第２のデバイスがサーバ（１０）であることを特徴とする請求項１から４のいずれか１項に記載の方法。
【請求項６】
前記デバイスタイプに固有の情報が、前記署名を作成する際に従うアルゴリズムの定義を含むことを特徴とする請求項１または５に記載の方法。
【請求項７】
前記デバイスタイプに固有の情報が、それぞれの特定のデバイスタイプに対し一意であるデータ列を含むことを特徴とする請求項１から６のいずれか１項に記載の方法。
【請求項８】
署名を作成する前記ステップが、時刻、日付、およびヘッダ情報から構成されるグループの内の少なくとも１つの項目にさらに基づくことを特徴とする請求項１から７のいずれか一項に記載の方法。
【請求項９】
認証する前記ステップがさらに、
前記第２のデバイス（１０）で、前記第１のヘッダ情報に基づく前記第１のデバイスのデバイスタイプを決定するステップと、
少なくとも前記決定されたデバイスタイプと関連する不正使用防止情報に基づいて前記第２のデバイス（１０）で第２の署名を作成するステップと、前記第１および第２の署名が一致した場合に前記決定されたデバイスタイプを本物であると認めるステップとを含むことを特徴とする請求項１から８のいずれか一項に記載の方法。
【請求項１０】
認証する前記ステップがさらに、
前記第１のヘッダ情報および前記第１の署名に関する情報を前記第２のデバイス（１０）から前記通信システム（１）に接続された第３のデバイス（５０〜５３）に転送するステップと、
前記第３のデバイス（５０〜５３）により前記第１のヘッダ情報の真偽の検証を要求するステップと、
前記第３のデバイス（５０〜５３）の検証で本物と確認されたら前記第１のヘッダ情報を本物として認めるステップとを含むことを特徴とする請求項１から８のいずれか１項に記載の方法。
【請求項１１】
前記第３のデバイス（５０〜５３）は、前記第１のデバイス（２０）のメーカーと関連していることを特徴とする請求項１０に記載の方法。
【請求項１２】
通信メッセージの、デバイスタイプ関連コミットメントと関連付けられた第１のヘッダ情報を供給する手段（２５）と、
前記通信メッセージを前記通信システム（１）に接続された他のデバイス（１０）に伝送する通信手段（２１）とを備えた、通信システム（１）に接続可能な通信デバイス（２０）であって、
前記通信デバイスのデバイスタイプに固有の情報（２４）の不正使用防止対策済み記憶装置（２３）と、
少なくとも前記デバイスタイプに固有の情報（２４）に基づいて第１の署名を作成するように構成された不正使用防止署名作成器（２６）と、前記署名を含む前記通信メッセージの第２のヘッダ情報を供給するための手段（２５）とを特徴とする通信デバイス。
【請求項１３】
前記通信手段（２１）が、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）およびＳｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）から構成されるグループから選択された転送プロトコルをサポートするように構成されていることを特徴とする請求項１２に記載の通信デバイス。
【請求項１４】
さらに、デジタル著作権管理（ＤＲＭ）手段を備え、それにより、前記デバイスタイプ関連コミットメントはデジタル著作権管理（ＤＲＭ）に準拠する旨のコミットメントであることを特徴とする請求項１３に記載の通信デバイス。
【請求項１５】
前記通信デバイスがユーザ端末であることを特徴とする請求項１２から１４のいずれか１項に記載の通信デバイス。
【請求項１６】
前記通信システム（１）に接続された送信デバイスから通信メッセージを受信する通信手段（１１）を備え、
前記通信メッセージは、デバイスタイプ関連コミットメントと関連付けられた第１のヘッダ情報を含む、通信システム（１）に接続可能な通信デバイス（１０）であって、
前記通信メッセージがさらに第１の署名を含む第２のヘッダ情報を含み、
前記第１の署名を検証するように構成された認証手段（１５）を備えることを特徴とする通信デバイス（１０）。
【請求項１７】
前記認証手段（１５）がさらに、
前記第１のヘッダ情報に基づいて前記送信デバイスのデバイスタイプを決定する手段と、
通信デバイスのデバイスタイプに固有な情報の記憶装置（１３）と、
前記決定されたデバイスタイプに対応するデバイスタイプに固有の情報を取り出すように構成され、前記取り出されたデバイスタイプに固有の情報に基づき第２の署名を作成するようにさらに構成された署名作成器（１６）と、
前記第１および第２の署名が一致した場合に前記決定されたデバイスタイプは本物であると認める手段とを備えることを特徴とする請求項１６に記載の通信デバイス。
【請求項１８】
前記認証手段（１５）がさらに、
前記第１のヘッダ情報および前記第１の署名に関する情報を前記通信システム（１）に接続された他のデバイスに転送する手段と、
前記他のデバイスにより前記第１のヘッダ情報の真偽の検証を要求する手段と、
前記他のデバイスの検証で本物と確認されたら前記第１のヘッダ情報を本物として認める手段とを備えることを特徴とする請求項１６に記載の通信デバイス。
【請求項１９】
前記通信手段（１１）が、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）およびＳｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）から構成されるグループから選択された転送プロトコルをサポートするように構成されていることを特徴とする請求項１６から１８のいずれか一項に記載の通信デバイス。
【請求項２０】
さらに、デジタル著作権管理（ＤＲＭ）手段を備え、それにより、前記デバイスタイプ関連コミットメントはデジタル著作権管理（ＤＲＭ）に準拠する旨のコミットメントであることを特徴とする請求項１９に記載の通信デバイス。
【請求項２１】
前記通信デバイスがサーバ（１０）であることを特徴とする請求項１６から２０のいずれか１項に記載の通信デバイス。
【請求項１】
通信システム（１）に接続された第１のデバイス（２０）において、通信メッセージの、デバイスタイプ関連コミットメントと関連付けられた第１のヘッダ情報を提供するステップと、
前記通信メッセージを前記通信システム（１）に接続された第２のデバイス（１０）に伝送するステップとを含む、通信システム（１）におけるデバイスタイプの認証方法であって、
さらに、
前記第１のデバイスの少なくとも不正使用防止デバイスタイプに固有の情報に基づいて、前記第１のデバイス（２０）で不正使用防止可能なように第１の署名を作成するステップと、
前記第１のデバイス（２０）において、前記署名を含む前記通信メッセージの第２のヘッダ情報を提供するステップと、
前記通信ステップの後に前記第１の署名を検証することにより前記第１のヘッダ情報を認証するステップとを有することを特徴とする方法。
【請求項２】
前記通信システム（１）が、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）およびＳｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）から構成されるグループから選択された転送プロトコルに基づくことを特徴とする請求項１に記載の方法。
【請求項３】
前記デバイスタイプ関連コミットメントが、デジタル著作権管理（ＤＲＭ）に準拠する旨のコミットメントであることを特徴とする請求項２に記載の方法。
【請求項４】
前記第１のデバイスがユーザ端末（２０）であることを特徴とする請求項１から３のいずれか１項に記載の方法。
【請求項５】
前記第２のデバイスがサーバ（１０）であることを特徴とする請求項１から４のいずれか１項に記載の方法。
【請求項６】
前記デバイスタイプに固有の情報が、前記署名を作成する際に従うアルゴリズムの定義を含むことを特徴とする請求項１または５に記載の方法。
【請求項７】
前記デバイスタイプに固有の情報が、それぞれの特定のデバイスタイプに対し一意であるデータ列を含むことを特徴とする請求項１から６のいずれか１項に記載の方法。
【請求項８】
署名を作成する前記ステップが、時刻、日付、およびヘッダ情報から構成されるグループの内の少なくとも１つの項目にさらに基づくことを特徴とする請求項１から７のいずれか一項に記載の方法。
【請求項９】
認証する前記ステップがさらに、
前記第２のデバイス（１０）で、前記第１のヘッダ情報に基づく前記第１のデバイスのデバイスタイプを決定するステップと、
少なくとも前記決定されたデバイスタイプと関連する不正使用防止情報に基づいて前記第２のデバイス（１０）で第２の署名を作成するステップと、前記第１および第２の署名が一致した場合に前記決定されたデバイスタイプを本物であると認めるステップとを含むことを特徴とする請求項１から８のいずれか一項に記載の方法。
【請求項１０】
認証する前記ステップがさらに、
前記第１のヘッダ情報および前記第１の署名に関する情報を前記第２のデバイス（１０）から前記通信システム（１）に接続された第３のデバイス（５０〜５３）に転送するステップと、
前記第３のデバイス（５０〜５３）により前記第１のヘッダ情報の真偽の検証を要求するステップと、
前記第３のデバイス（５０〜５３）の検証で本物と確認されたら前記第１のヘッダ情報を本物として認めるステップとを含むことを特徴とする請求項１から８のいずれか１項に記載の方法。
【請求項１１】
前記第３のデバイス（５０〜５３）は、前記第１のデバイス（２０）のメーカーと関連していることを特徴とする請求項１０に記載の方法。
【請求項１２】
通信メッセージの、デバイスタイプ関連コミットメントと関連付けられた第１のヘッダ情報を供給する手段（２５）と、
前記通信メッセージを前記通信システム（１）に接続された他のデバイス（１０）に伝送する通信手段（２１）とを備えた、通信システム（１）に接続可能な通信デバイス（２０）であって、
前記通信デバイスのデバイスタイプに固有の情報（２４）の不正使用防止対策済み記憶装置（２３）と、
少なくとも前記デバイスタイプに固有の情報（２４）に基づいて第１の署名を作成するように構成された不正使用防止署名作成器（２６）と、前記署名を含む前記通信メッセージの第２のヘッダ情報を供給するための手段（２５）とを特徴とする通信デバイス。
【請求項１３】
前記通信手段（２１）が、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）およびＳｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）から構成されるグループから選択された転送プロトコルをサポートするように構成されていることを特徴とする請求項１２に記載の通信デバイス。
【請求項１４】
さらに、デジタル著作権管理（ＤＲＭ）手段を備え、それにより、前記デバイスタイプ関連コミットメントはデジタル著作権管理（ＤＲＭ）に準拠する旨のコミットメントであることを特徴とする請求項１３に記載の通信デバイス。
【請求項１５】
前記通信デバイスがユーザ端末であることを特徴とする請求項１２から１４のいずれか１項に記載の通信デバイス。
【請求項１６】
前記通信システム（１）に接続された送信デバイスから通信メッセージを受信する通信手段（１１）を備え、
前記通信メッセージは、デバイスタイプ関連コミットメントと関連付けられた第１のヘッダ情報を含む、通信システム（１）に接続可能な通信デバイス（１０）であって、
前記通信メッセージがさらに第１の署名を含む第２のヘッダ情報を含み、
前記第１の署名を検証するように構成された認証手段（１５）を備えることを特徴とする通信デバイス（１０）。
【請求項１７】
前記認証手段（１５）がさらに、
前記第１のヘッダ情報に基づいて前記送信デバイスのデバイスタイプを決定する手段と、
通信デバイスのデバイスタイプに固有な情報の記憶装置（１３）と、
前記決定されたデバイスタイプに対応するデバイスタイプに固有の情報を取り出すように構成され、前記取り出されたデバイスタイプに固有の情報に基づき第２の署名を作成するようにさらに構成された署名作成器（１６）と、
前記第１および第２の署名が一致した場合に前記決定されたデバイスタイプは本物であると認める手段とを備えることを特徴とする請求項１６に記載の通信デバイス。
【請求項１８】
前記認証手段（１５）がさらに、
前記第１のヘッダ情報および前記第１の署名に関する情報を前記通信システム（１）に接続された他のデバイスに転送する手段と、
前記他のデバイスにより前記第１のヘッダ情報の真偽の検証を要求する手段と、
前記他のデバイスの検証で本物と確認されたら前記第１のヘッダ情報を本物として認める手段とを備えることを特徴とする請求項１６に記載の通信デバイス。
【請求項１９】
前記通信手段（１１）が、ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＨＴＴＰ）およびＳｉｍｐｌｅ Ｍａｉｌ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ（ＳＭＴＰ）から構成されるグループから選択された転送プロトコルをサポートするように構成されていることを特徴とする請求項１６から１８のいずれか一項に記載の通信デバイス。
【請求項２０】
さらに、デジタル著作権管理（ＤＲＭ）手段を備え、それにより、前記デバイスタイプ関連コミットメントはデジタル著作権管理（ＤＲＭ）に準拠する旨のコミットメントであることを特徴とする請求項１９に記載の通信デバイス。
【請求項２１】
前記通信デバイスがサーバ（１０）であることを特徴とする請求項１６から２０のいずれか１項に記載の通信デバイス。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【公開番号】特開２０１１−１５９３１３（Ｐ２０１１−１５９３１３Ａ）
【公開日】平成２３年８月１８日（２０１１．８．１８）
【国際特許分類】
【出願番号】特願２０１１−７１７１１（Ｐ２０１１−７１７１１）
【出願日】平成２３年３月２９日（２０１１．３．２９）
【分割の表示】特願２００４−５２３５１（Ｐ２００４−５２３５１）の分割
【原出願日】平成１６年２月２６日（２００４．２．２６）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
【公開日】平成２３年８月１８日（２０１１．８．１８）
【国際特許分類】
【出願日】平成２３年３月２９日（２０１１．３．２９）
【分割の表示】特願２００４−５２３５１（Ｐ２００４−５２３５１）の分割
【原出願日】平成１６年２月２６日（２００４．２．２６）
【出願人】（５９８０３６３００）テレフオンアクチーボラゲット エル エム エリクソン（パブル） (2,266)
【Ｆターム（参考）】
[ Back to top ]