(57)【要約】      （修正有）【課題】移動機（例えば、携帯電話）向けのマルチメディアコンテンツファイル提供サービスにおいて、正当なコンテンツ制作ツールを用いて作られたコンテンツファイルに対してのみ、移動機側にて所定のサービスを提供するようにする。【解決手段】移動機側は、内部に予め保持されているルート証明書を用いて取得したコンテンツファイル内の公開鍵証明書の認証を行う手段（Ｓ１２）と、ヘッダ部分に埋め込まれている公開鍵を用いて秘密鍵で暗号化された認証データを復号し第１のハッシュ値を求める手段（Ｓ１３）と、予め通知されていた前記と同じ複数箇所の部分データを抜き出して第２のハッシュ値を求める手段（Ｓ１４，１５）と、前記第１のハッシュ値と前記第２のハッシュ値とを比較する手段（Ｓ１６）と、これらが一致した場合に所定のサービスを提供し、不一致の場合には該サービスを提供しないようにする手段（Ｓ１７，１８）とを具備する。【選択図】図５
2010068527.tif 000002
【特許請求の範囲】
【請求項１】
送信機側は、コンテンツファイルから抜き出された複数箇所の部分データのハッシュ値に秘密鍵を用いてデジタル署名を施して認証データを求める手段と、前記コンテンツファイルのヘッダ部分に、前記認証データと、前記秘密鍵と対になっている公開鍵と、該公開鍵の正当性を認証するための公開鍵証明書とを埋め込む手段とを具備し、
移動機側は、移動機内部に予め保持されているルート証明書を用いて取得したコンテンツファイル内の公開鍵証明書の認証を行う手段と、該コンテンツファイル内のヘッダ部分に埋め込まれている公開鍵を用いて秘密鍵で暗号化された認証データを復号し第１のハッシュ値を求める手段と、該コンテンツファイル内の予め通知されていた前記と同じ複数箇所の部分データを抜き出し該部分データの第２のハッシュ値を求める手段と、前記第１のハッシュ値と前記第２のハッシュ値とを比較する手段と、該第１及び第２のハッシュ値が一致したコンテンツファイルに対して所定のサービスを提供し不一致のコンテンツファイルに対しては該サービスを提供しないようにする手段とを具備したコンテンツファイル制作者認証方式。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、携帯電話向けのマルチメディアコンテンツファイルの提供サービスにおいて、正当なコンテンツ制作ツールを用いて作られたコンテンツファイルに対してのみ、携帯電話側にて所定のサービスを提供するようにしたコンテンツファイル制作者の認証方式に関する。
【背景技術】
【０００２】
この種の従来技術として、伝送されるコンテンツ、例えば契約書などの改竄の有無を判定するためのデジタル署名技術、また他の従来技術として、送受信者間で相手を認証する、すなわち送信者側が正しい秘密鍵を持っているかどうかを検証するためのチャレンジレスポンス手順がある。
【０００３】
このチャレンジレスポンス手順の概略を図８に示す。図８に示されているように、受信側は乱数値を生成し、該乱数値を送信側に送信（チャレンジコード送信）する。受信側と送信側は、該乱数値に基づいて秘密鍵を用いてある種の計算（ハッシュ計算）を行い、送信側は、該ハッシュ計算の結果を受信側に送信（レスポンスコード送信）する。受信側では、受信した値と自身のハッシュ計算により得た値とを突き合わせ、一致していれば、送信側が正しい秘密鍵を持っている者と判断する。
【０００４】
なお、上記の従来技術に関連する文献として、例えば特開２００２−３３４１７３号公報「コンテンツ配信方法及びこれに用いるサーバ及び端末並びにコンピュータプログラム」がある。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００２−３３４１７３号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
しかしながら、前記の従来技術は、相手の認証のために送受信者間で通信をすることが必要になるが、コンテンツ配信サービスにおいては、コンテンツ制作者と受信者との間で直接の通信をすることは非現実的であるという問題がある。
【０００７】
本発明の目的は、移動機（例えば、携帯電話）向けのマルチメディアコンテンツファイル提供サービスにおいて、正当なコンテンツ制作ツールを用いて作られたコンテンツファイルに対してのみ、移動機側にて所定のサービスを提供するようにしたコンテンツファイル制作者認証方式を提供することにある。
【０００８】
また、本発明の他の目的は、不正なコンテンツ制作ツールを用いて作られたコンテンツファイル、例えば海賊版ツールで制作されたコンテンツファイルを検出して、該コンテンツファイルに対しては移動機内の所定のサービスを提供しないコンテンツファイル制作者認証方式を提供することにある。
【０００９】
さらに本発明の他の目的は、正当なコンテンツ制作ツールを用いて作られたコンテンツファイルであることの認証のために送受信者間で通信をすることを必要としないコンテンツファイル制作者認証方式を提供することにある。
【課題を解決するための手段】
【００１０】
前記した目的を達成するために、本発明は、送信機側は、コンテンツファイルから抜き出された複数箇所の部分データのハッシュ値に秘密鍵を用いてデジタル署名を施して認証データを求める手段と、前記コンテンツファイルのヘッダ部分に、前記認証データと、前記秘密鍵と対になっている公開鍵と、該公開鍵の正当性を認証するための公開鍵証明書とを埋め込む手段とを具備し、移動機側は、移動機内部に予め保持されているルート証明書を用いて取得したコンテンツファイル内の公開鍵証明書の認証を行う手段と、該コンテンツファイル内のヘッダ部分に埋め込まれている公開鍵を用いて秘密鍵で暗号化された認証データを復号し第１のハッシュ値を求める手段と、該コンテンツファイル内の予め通知されていた前記と同じ複数箇所の部分データを抜き出し該部分データの第２のハッシュ値を求める手段と、前記第１のハッシュ値と前記第２のハッシュ値とを比較する手段と、該第１及び第２のハッシュ値が一致したコンテンツファイルに対して所定のサービスを提供し不一致のコンテンツファイルに対しては該サービスを提供しないようにする手段とを具備した点に特徴がある。
【発明の効果】
【００１１】
本発明によれば、正当なコンテンツ制作ツールを用いて作られたコンテンツファイルに対してのみ、所定のサービスを提供できるようになる。逆に、不正なコンテンツ制作ツールを用いて作られたコンテンツファイル、例えば海賊版ツールで制作されたコンテンツファイルに対して、所定のサービスを提供することを、防止できるようになる。
【００１２】
また、コンテンツファイルの部分データに対してデジタル署名を行っているので、少ない演算量でデジタル署名をすることができる。または、デジタル署名を用いることなく、コンテンツファイル制作者しか知り得ない情報によって作成された認証データを用いて、コンテンツファイルの正当性を判断することができるようになる。
【００１３】
また、移動機側では、コンテンツファイル制作側に通信を行うことなく、該コンテンツファイルが正当なコンテンツファイル制作ツールで作成されたものかどうかを検証することができるようになる。
【図面の簡単な説明】
【００１４】
【図１】本発明の概略のシステム構成を示すブロック図である。
【図２】本発明の第１の実施形態におけるデジタル署名の一例の説明図である。
【図３】コンテンツファイルの構成例を示す説明図である。
【図４】コンテンツファイル制作プログラムを示すフローチャートである。
【図５】移動機のコンテンツファイル制作者認証プログラムを示すフローチャートである。
【図６】本発明の第２の実施形態における認証データ付与の一例の説明図である。
【図７】移動機側のコンテンツファイル制作者認証プログラムを示すフローチャートである。
【図８】従来のチャレンジレスポンス手順を示す図である。
【発明を実施するための形態】
【００１５】
以下に、図面を参照して、本発明を詳細に説明する。図１は、本発明が利用される携帯電話向けのマルチメディアコンテンツファイル提供サービスの概略のシステム図である。
【００１６】
コンテンツファイルの送信側（制作側）では、コンテンツデータ例えば音楽ソース１に対して、あるハードウェアキー２（制作側しか持たない秘密情報）を適用して暗号化処理３を行いコンテンツファイル４を得る。すなわち、該送信側（制作側）は、自身のコンテンツファイル制作ツールでコンテンツデータを暗号化し、該コンテンツファイル４を作成する。
【００１７】
一方、受信側（移動機側）では、該コンテンツファイル４をダウンロードし、一旦ファイル蓄積部１１に保持する。検証部１２は、該ダウンロードしたコンテンツファイルが正当な制作ツールで制作されたものかどうかの検証を行い、該正当な制作ツールで制作されたことが検証された場合には、該コンテンツファイル４を登録部１３に登録して、ユーザに提供する。例えば、ユーザに前記音楽ソース１の再生機能を提供する。一方、該検証部１２で該ダウンロードしたコンテンツファイルが正当な制作ツールで制作されたことが検証されなかった場合には、該コンテンツファイル４をユーザに提供しない措置をする。
【００１８】
次に、本発明の第１の実施形態について説明する。通常のデジタル署名では、コンテンツデータの全体に対してハッシュ値を計算し、秘密鍵で暗号化することにより署名値を得る。これは、コンテンツデータのどこにも改竄が行われていないことを保証するためである。
【００１９】
これに対して、本発明の第１の実施形態では、コンテンツファイルの制作者が正当な秘密鍵を持っていることを保証すること、あるいはコンテンツファイルの制作ツールが正規の秘密鍵を有していることを認証することが目的であり、コンテンツデータそのものの完全性、すなわちコンテンツデータそのものが改竄されているかどうか、換言すればコンテンツデータ全体の真贋は関心事ではない。
【００２０】
まず、前記暗号化処理３で実行される暗号化処理の方法について説明する。提供されるコンテンツデータとしては、前記音楽ソース１以外に、ビデオデータ、オーディオデータ、またはビデオ・オーディオデータ等が含まれる。
【００２１】
図２に示されているように、コンテンツデータＡから、部分データＡ１，Ａ２，Ａ３，・・・が抜き出され、これらにハッシュ関数を適用してハッシュ値が計算される。次に、該ハッシュ値に秘密鍵を用いてデジタル署名を施した認証データが求められる。
【００２２】
次に、該認証データは、図３に示すヘッダ部分の適当な格納箇所、すなわち適当なフィールド（アトム）に埋め込まれる。ここに、図３は、前記コンテンツファイル４のフォーマット例を示し、該コンテンツファイル４はヘッダ部分とデータ部分からなる。また、前記秘密鍵と対になっている公開鍵も前記アトムに埋め込まれる。さらに、該公開鍵の正当性を認証するための公開鍵証明書もアトムに埋め込まれる。この公開鍵証明書は、携帯電話内部に保持されているルート証明書により認証される証明書である。
【００２３】
ここで、データ部分から抜き出されるデータＡ１，Ａ２，Ａ３，・・・の位置は、制作側と携帯電話で予め定めておくものとする。例えば、データの先頭から１ｋバイトであるとか、１０バイトおきに１バイトずつ合計で５ｋバイトになるまで抜き出すとか、予め定めておく。
【００２４】
図４は、前記制作側（送信側）のプログラムまたは動作を説明するフローチャートである。ステップＳ１では、署名のないコンテンツファイル、例えば前記音楽ソース１を作成する。ステップＳ２では、データ部分から部分的にデータ（例えば、前記データＡ１，Ａ２，Ａ３）を抜き出す。ステップＳ３では、該抜き出されたデータにハッシュ関数を適用してハッシュ値を求め、ステップＳ４では、該ハッシュ値を秘密鍵で暗号化してデジタル署名を付与した認証データを作成し、これを前記アトムに埋め込む。ステップＳ５では、該秘密鍵と対になっている公開鍵もアトムに埋め込み、該公開鍵の正当性を認証するための公開鍵証明書もアトムに埋め込む。ステップＳ６では、サーバにアップロードする。
【００２５】
次に、携帯電話側（移動機側）のプログラムまたは処理を、図５を参照して説明する。携帯電話側では、デジタル署名の検証を行う。ステップＳ１１では、サーバからダウンロードしたコンテンツファイルに署名があるか否かの判断をする。すなわち、ヘッダに、前記認証データが含まれているか否かの検証を行う。署名がある場合には、ステップＳ１２に進み、携帯電話内にあるルート証明書を用いて、コンテンツファイル（図３参照）内の公開鍵証明書の認証を行う。なお、前記コンテンツファイルに署名がない場合には、ステップＳ１８に進み、所定のサービスを提供しない。
【００２６】
ステップＳ１２の認証が正しかった場合にはステップＳ１３に進み、この公開鍵を用いて、前記秘密鍵で暗号化された認証データを復号し、ハッシュ値を求める。すなわち、制作側（送信側）で計算したハッシュ値を取り出す。ステップＳ１２の認証が正しくなかった場合には、処理を中止する。ステップＳ１４では、コンテンツファイルのデータ部から、予め定められていた制作側と同一位置の部分データ、すなわち制作側と共有している部分データ（例えば、前記データＡ１，Ａ２，Ａ３）を抜き出す。そして、ステップＳ１５で、該抜き出した部分データにハッシュ関数を適用してハッシュ値を計算する。
【００２７】
ステップＳ１６では、ステップＳ１３とＳ１５で求めたハッシュ値が一致するか否かの判断をする。一致した場合には、デジタル署名が検証されたことになる。ステップＳ１６の判断が肯定の場合には、ステップＳ１７に進んで所定のサービス、例えばオーディオの再生を行う。一方、一致しなかった場合には、デジタル署名は検証されなかったことになり、ステップＳ１８に進んで、所定のサービスを行わないようにする。
【００２８】
上記した第１の実施形態によれば、コンテンツファイルの部分データに対してデジタル署名を行っているので、少ない演算量でデジタル署名をすることができる。
【００２９】
また、移動機側では、コンテンツファイル制作側に通信を行うことなく、該コンテンツファイルが正当なコンテンツファイル制作ツールで作成されたものかどうかを検証することができるようになる。また、正当なコンテンツ制作ツールを用いて作られたコンテンツファイルに対してのみ、所定のサービスを提供できるようになる。逆に、不正なコンテンツ制作ツールを用いて作られたコンテンツファイル、例えば海賊版ツールで制作されたコンテンツファイルに対して、所定のサービスを提供することを、防止できるようになる。
【００３０】
次に、本発明の第２の実施形態を、図６および図７を参照して説明する。この実施形態は、移動機側にて、受信したコンテンツファイルが正当なコンテンツ制作ツールを用いて作られたものであるかどうかを検証し、正当なコンテンツ制作ツールを用いて作られたコンテンツファイルに対してのみ、所定のサービスを提供するようにしたものである。なお、この実施形態では、デジタル署名を用いずに行われる。
【００３１】
図６を参照して、コンテンツファイルの送信側（制作側）の処理を説明する。まず、送信側では、コンテンツファイル制作者しか知り得ない情報である秘密情報２１と演算式２２とを予め有しており、該秘密情報２１と演算式２２は受信側（移動機側）の蓄積手段（図示されていない）に予め格納されているものとする。例えば、移動機の出荷に先立って、前記秘密情報２１と演算式２２は、移動機の製造者等によって、携帯電話などの移動機のメモリに予め記憶されているものとする。
【００３２】
図６に示されているように、送信側は、音楽ソースなどのコンテンツデータＢに対して、前記秘密情報２１を用いて前記演算式２２で所定の演算（例えば、スクランブル演算）を行い、認証データを得る。次いで、該認証データをコンテンツファイル２３のヘッダ部に格納し、該コンテンツファイル２３を携帯電話などの移動機に配信する。
【００３３】
次に、携帯電話などの移動機側の動作を、図７のフローチャートを参照して説明する。
【００３４】
移動機側は、前記コンテンツファイルを受信またはダウンロードし、ファイル蓄積部１１（図１参照）に蓄積する。次いで、ステップＳ２１で、該コンテンツファイルのヘッダに認証データが存在するか否かの判断がなされる。この判断が否定の時には、ステップＳ２６に進んで所定のサービスを提供しない処理をする。
【００３５】
一方、前記ステップＳ２１の判断が肯定の時には、ステップＳ２２に進んでコンテンツファイルのヘッダから認証データを抽出する。次いで、ステップＳ２３に進み、コンテンツファイル内のデータに対して、予め記憶していた秘密情報と演算式を用いて所定の演算を行い認証データを生成する。ステップＳ２４では、ステップＳ２２で抽出した認証データとステップＳ２３で生成した認証データが一致するか否かの判断を行い、この判断が肯定すなわち一致する場合にはステップＳ２５に進んで所定のサービスを提供する。一方、該判断が否定の時にはステップＳ２６に進む。
【００３６】
この第２の実施形態によれば、デジタル署名を用いることなく、正当なコンテンツ制作ツールを用いて作られたコンテンツファイルであるかどうかを検証でき、移動機側は、正当なコンテンツファイルに対してのみ、所定のサービスを提供することができるようになる。また、移動機側は、受信したコンテンツファイルが正当なコンテンツファイル制作ツールで作成されたものか否かを、該コンテンツファイルの制作側に通信しなくても検証することができるようになる。
【００３７】
上記の各実施形態では、本発明に係るプログラム又は動作を図４、図５及び図７のフローチャートを参照して説明したが、これらの処理は、コンテンツファイル制作側および移動機側が有しているコンピュータあるいはマイクロコンピュータ（ＣＰＵ）により実行されることができる。また、これらの処理手順は、本発明の趣旨を逸脱しない範囲で、種々の変更ができることは明らかである。
【符号の説明】
【００３８】
１・・・音楽ソース、２・・・ハードウェアキー、３・・・暗号化処理、４・・・コンテンツファイル、１１・・・ファイル蓄積部、１２・・・検証部、１３・・・登録部。
【図１】
2010068527.tif 000003
【図２】
2010068527.tif 000004
【図３】
2010068527.tif 000005
【図４】
2010068527.tif 000006
【図５】
2010068527.tif 000007
【図６】
2010068527.tif 000008
【図７】
2010068527.tif 000009
【図８】
2010068527.tif 000010