暗号化データ配信サービスシステム
【課題】複雑な暗号鍵管理を必要とせず、許可された利用者および端末においてのみデータの閲覧・利用可能とすることができるようにする。
【解決手段】配信サーバ３０では、配信するデータを暗号化して送信し、クライアント端末１０では、受信したデータを当該利用者およびクライアント端末１０に固有の共通鍵で復号化し、閲覧または利用する。そして代理中継サーバ２０では、配信サーバ３０から暗号化されたデータを受信して復号化し、その復号化したデータを当該利用者およびクライアント端末１０に固有の共通鍵で暗号化してクライアント端末１０へ送信する。
【解決手段】配信サーバ３０では、配信するデータを暗号化して送信し、クライアント端末１０では、受信したデータを当該利用者およびクライアント端末１０に固有の共通鍵で復号化し、閲覧または利用する。そして代理中継サーバ２０では、配信サーバ３０から暗号化されたデータを受信して復号化し、その復号化したデータを当該利用者およびクライアント端末１０に固有の共通鍵で暗号化してクライアント端末１０へ送信する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ（コンテンツ）を暗号化配信することで許可された利用者および端末においてのみそのデータを閲覧・利用を可能とする暗号化データ配信サービスシステムに関し、特にメモリ、ユーザインタフェースなどの仕様がＰＣに比べ制限されている携帯型端末に対して暗号化データ配信サービスを効率的に行うのに適した暗号化データ配信サービスシステムに関するものである。
【背景技術】
【０００２】
近年、データを公開鍵暗号方式で暗号化配信し、特定の利用者のみにそのデータの閲覧・利用を可能とすることで、データの著作権保護、不正コピーの禁止の機能を持つネットワークを介した暗号化データ配信サービスが利用されるようになった。
しかしながら、暗号化通信を行う際に必要となる公開鍵や秘密鍵の取り扱いは、ユーザインタフェースが制限された携帯型端末では操作が難しく、また公開鍵暗号方式は、共通鍵暗号方式に比べ処理量が多いため、メモリ量などが制限された携帯型端末では、十分な処理速度を得るのが難しい。
【０００３】
一方、鍵を効率よく取り扱うための暗号化通信システムも提案されている（例えば、特許文献１など参照）。図７に示すように、この暗号化通信システムは、複数のユーザ側計算機１と、複数のマーチャント側計算機２と、中継装置３と、第三者機関４とから構成されている。このような構成を有する従来の暗号化システムは次のように動作する。
任意のユーザ側計算機１と中継装置３の両方において、第三者機関４の認証の下でユーザ共通鍵を保持し、同様にマーチャント側計算機２と中継装置３の両方において、第三者機関４の認証の下でマーチャント共通鍵を保持する。そして、マーチャント側計算機２は送信するメッセージを、マーチャント共通鍵で暗号化して中継装置３に送り、中継装置３において、マーチャント共通鍵で復号化し、さらにユーザ共通鍵で暗号化してユーザ側計算機１に送信し、ユーザ側計算機１において、受信したメッセージをユーザ共通鍵で復号する。
【０００４】
このとき、共通鍵暗号方式の代わりに、公開鍵暗号方式を使って、ユーザ側計算機１にユーザ秘密鍵を保持するとともに中継装置３にユーザ公開鍵を保持し、またマーチャント側計算機２にマーチャント秘密鍵を保持するとともに中継装置３にマーチャント公開鍵を保持して、上記と同様の暗号化通信を行うことが可能である。
そのため、ユーザ側計算機１およびマーチャント側計算機２において、暗号化通信する際、予め指定された中継装置３との通信のための暗号鍵のみを扱えばよいので、暗号鍵の取り扱いの煩雑さが減少し、また多数の計算機間での暗号化通信に必要な各暗号鍵を管理しなくてよいので、鍵管理を効率よく行うことを実現している。
【０００５】
【特許文献１】特開平１０−３４１２２３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、このような従来の暗号化通信システムでは、以下のような問題点があった。まず第１に、配信サービス側が、中継装置までの通信において特定の利用者に応じた暗号化を行っていないため、このような中継方式の暗号化通信では、ある特定の利用者および端末に対してのみ閲覧・利用を許可するようなデータを配信することができないという問題点があった。第２に、第三者機関によって発行された暗号鍵を使っているため、配信された暗号化データは、暗号鍵を漏らせば、他の利用者や端末でも閲覧・利用が可能となってしまうという問題点があった。
本発明はこのような課題を解決するためのものであり、複雑な暗号鍵管理を必要とせず、データを許可された利用者および端末においてのみ閲覧・利用可能とすることができる暗号化データ配信サービスシステムを提供することを目的としている。
【課題を解決するための手段】
【０００７】
このような目的を達成するために、本発明にかかるデータ配信サービスシステムは、データを暗号化して配信することにより、特定の利用者および端末のみにおいて利用可能とするデータ配信サービスシステムにおいて、配信するデータを暗号化して送信する配信サーバと、受信したデータを当該利用者およびその端末に固有の共通鍵で復号化し、閲覧または利用する利用者端末と、前記配信サーバから暗号化されたデータを受信して復号化し、その復号化したデータを当該利用者および前記端末に固有の共通鍵で暗号化した形式に変換して前記端末へ送信する代理中継サーバとを備えている。
【発明の効果】
【０００８】
本発明によれば、代理中継サーバにより、配信サーバから暗号化されたデータが受信されて復号化され、その復号化したデータが当該利用者および端末に固有の共通鍵で暗号化した形式に変換されて端末へ送信される。
したがって、端末側では共通鍵暗号方式を使うだけでよく、配信サーバと代理中継サーバとの間で公開鍵・秘密鍵を用いたとしてもその煩雑な鍵管理を代理中継サーバに委託でき、複雑な暗号鍵管理を必要とせず、データを許可された利用者および端末においてのみ閲覧・利用可能とすることができる。また、共通鍵暗号方式は公開鍵暗号方式に比べ処理が容易なため、比較的処理能力が劣る携帯型端末であっても、暗号化データ配信サービスシステムを実現できる。さらに、当該利用者およびその端末に固有の共通鍵を動的に生成して、代理中継サーバへ更新登録するようにしてもよく、これにより共通鍵が端末に永続的に保持されなくなるため、共通鍵の盗用が極めて困難となり高い安全性が得られる。
【発明を実施するための最良の形態】
【０００９】
次に、本発明の実施の形態について図面を参照して説明する。
図１は本発明の一実施の形態にかかる暗号化データ配信サービスシステムを示すブロック図である。
この暗号化データ配信サービスシステムは、データ（コンテンツ）を暗号化して配信する配信サーバ３０と、配信サーバ３０からの暗号化されたデータを一旦復号化して再び暗号化して中継する代理中継サーバ２０と、代理中継サーバ２０からのデータを復号化して閲覧・利用するクライアント端末１０とから構成される。
【００１０】
代理中継サーバ２０には、配信サーバ３０およびクライアント端末１０との通信を管理する通信インタフェース部２１、配信サーバ３０から受信した暗号化データを復号する復号化処理部２５、クライアント端末に送信するデータを暗号化する暗号化処理部２４、利用者の種々の情報、特に復号化処理に用いる利用者の秘密鍵および暗号化処理に用いる共通鍵を管理する利用者情報テーブル２２、配信データのアクセス制御情報が蓄積されている配信データ情報テーブル２３、およびこれら各部を制御して代理中継処理を行う中継制御部２６が設けられている。
【００１１】
クライアント端末１０には、代理中継サーバ２０との通信を管理する通信インタフェース部１１、利用者の操作を処理するユーザインタフェース部１４、利用者およびクライアント端末１０に固有の共通鍵を生成する暗号鍵生成部１３、代理中継サーバ２０から受信したデータを復号化処理する復号化処理部１２、閲覧・利用したデータの利用履歴を管理するデータ利用履歴情報テーブル１５、およびこれら各部を制御して暗号化されたデータを閲覧・利用する端末制御部１６が設けられている。
【００１２】
次に、図１および図２を参照して、本実施の形態の代理中継サーバ２０の動作について詳細に説明する。図２は代理中継サーバの処理動作を示すフローチャートである。
代理中継サーバ２０の中継制御部２６では、まず、通信インターフェース部２１を介してクライアント端末１０の接続要求を待ち、接続要求があれば（ステップ１００：ＹＥＳ）、利用者のログイン処理で利用者の認証を行う（ステップ１１０）。例えば、クライアント端末１０で利用者のアカウント名とパスワードを入力し、代理中継サーバ側に保持されているアカウント名とパスワードに一致するかどうかチェックすることで、利用者の認証を行い、ログイン処理をする。このような認証情報は、利用者情報テーブル２２で保持するが、認証の方式としては、さまざまな手法を適用することが可能である。
【００１３】
ここで、図３を参照して、ステップ１１０での認証処理について説明する。図３は代理中継サーバにおける認証処理を示すフローチャートである。
まず、中継制御部２６では、利用者情報テーブル２２に保持されている利用者のアカウント名を検索し、一致する利用者のアカウント名から、予め登録された利用者の個人情報が保持されている領域を確認する（ステップ３００）。次に、クライアント端末１０の表示画面の大きさ、表示色数、シリアル番号、ＯＳのバージョン番号といった端末情報を取得する（ステップ３１０）。この場合、予め利用者情報テーブル２２に登録しておいた端末情報を取得してもよいし、クライアント端末１０と通信することで端末情報を受信してもよい。
【００１４】
さらに、予め登録してあるクライアント端末１０および利用者に固有の共通鍵を利用者情報テーブル２２から取得する（ステップ３２０）。共通鍵は、利用者個人情報テーブルに含まれている情報を使って、クライアント端末１０の暗号鍵生成部１３と同一の処理、同一のアルゴリズムで、動的に生成してもよい。
これらステップ３００〜３２０の処理でエラーが発生した場合は、ログイン不成功と判断し、一連の認証処理を終了してステップ１００へ戻る（ステップ３３０：ＮＯ）。エラーがなければログイン成功と判断し（ステップ３３０：ＹＥＳ）、一連の認証処理を終了してステップ１２０へ移行する。
このように、データ配信に先立って、代理中継サーバ２０において、利用者の認証を行うようにしたので、鍵管理の不正利用を抑制でき、代理中継サーバ２０での厳重な鍵管理を実現できる。
【００１５】
図２のステップ１１０においてログインが成功した場合（ステップ１１０：ＹＥＳ）、中継制御部２６では、クライアント端末１０から、データの配信要求があるかどうかチェックする（ステップ１２０）。
ここで、データの配信要求以外の処理要求、例えばパスワード変更といった利用者情報の更新などの場合は（ステップ１２０：ＮＯ）、その要求された処理を行った後（ステップ１３０）、クライアント端末からの処理要求があるかどうか調べるため、ステップ１２０へ戻る。
【００１６】
クライアント端末１０からデータの配信要求があった場合は（ステップ１２０：ＹＥＳ）、当該データを保持している配信サーバ３０へのアクセスが許可されているかどうか、またそのデータへのアクセスが許可されているかどうかを、配信データ情報テーブル２３を使って調べる（ステップ１４０）。
配信データ情報テーブル２３には、種々の配信データのアクセス制御情報が蓄積されている。このような情報を使うことで、例えば、利用者がその配信サーバ３０のデータへアクセス可能な年齢１８歳に満たない場合や、そのデータに既にアクセスしたことがあるが、そのデータへのアクセスがただ一度だけに制限されている場合などのアクセスの許可・不許可を調べる。
【００１７】
このように、代理中継サーバ２０の配信データ情報テーブル２３で個々のデータのアクセス制御情報を管理し、クライアント端末１０からの要求に応じて、その要求データに対するアクセス可否を判断するようにしたので、利用者ごとに各データの厳密なアクセス管理を実現できる。
【００１８】
ステップ１４０において、データへのアクセスが許可され要求可と判断されたた場合は（ステップ１４０：ＹＥＳ）、実際にデータを保持している配信サーバ３０へデータの送信要求を行い、その要求に対して返信されてきたデータを受信する（ステップ１５０）。必要であれば、利用者情報テーブル２２に保持されている利用者情報も併せて送信する。
そして、受信したデータが正しく受信されたかどうか調べ（ステップ１６０）、データの取得成功が確認された場合は（ステップ１６０：ＹＥＳ）、受信したデータが暗号化されており、別のサーバなどから暗号鍵を取得する必要がある場合があり、実際に受信したデータがクライアント端末１０で利用可能であるかどうかを調べる（ステップ１７０）。
【００１９】
受信したデータがクライアント端末１０で利用可能であり、代理中継サーバ２０からクライアント端末１０へデータ配信可能であると判断された場合は（ステップ１７０：ＹＥＳ）、通信インターフェース部２１を介してクライアント端末１０へデータを送信し（ステップ１８０）、ステップ１２０へ戻る。
上記のステップ１４０、１６０、１７０の処理において、エラーが生じた場合には、クライアント端末１０にエラー通知を行い（ステップ１９０）、ステップ１２０へ戻る。
【００２０】
ここで、図４を参照して、ステップ１８０でのデータ配信処理について説明する。
中継制御部２６では、まず、配信サーバ３０から取得したデータが暗号化されていれば、これを復号化処理部２５で復号化する（ステップ５００）。このとき、取得したデータが利用者の公開鍵で暗号化されている場合には、利用者情報テーブル２２に保持されている秘密鍵を用いて復号化する。また利用者およびクライアント端末１０に固有の共通鍵で暗号化されている場合には、同じく利用者情報テーブル２２に保持されているその共通鍵を取得して復号化する。
なお、配信サーバ３０でデータを暗号化する際に用いる公開鍵や共通鍵については、代理中継サーバ２０から直接通知するようにしてもよい。また、公開鍵については代理中継サーバ２０から通知された利用者の個人情報に基づき第三者機関から取得してもよい。
【００２１】
続いて、利用者情報テーブル２２の端末情報を参照し、必要ならばデータの変換やファイルフォーマットの変換を行う（ステップ５１０）。例えば、２５６色のカラー画像データに対して端末が白黒表示しかできない場合は白黒データ変換処理を行ったり、表示画面の大きさにあわせて画像データの拡大縮小処理を行ったりする。
さらに、そのデータの利用情報を付加する（ステップ５２０）。利用情報は、配信サーバ３０や別のサーバ（例えば図示しない課金サーバ）から取得される、データの利用回数や利用期限といった情報である。そして、ステップ３２０で取得したデータを利用者およびクライアント端末１０に固有の共通鍵を使って、暗号化処理部２４で暗号化し（ステップ５３０）、クライアント端末１０に送信して（ステップ５４０）、一連のデータ配信処理を終了する。
【００２２】
次に、図１および図５を参照して、本実施の形態のクライアント端末１０の動作について詳細に説明する。図５はクライアント端末の処理動作を示すフローチャートである。
クライアント端末１０の端末制御部１６では、まず、代理中継サーバ２０との通信接続を行う（ステップ７００）。接続後、ログイン処理を行う（ステップ７１０）。このステップ７１０の処理に対して、代理中継サーバ２０においては図２のステップ１１０の処理が対応する。ここでは、利用者により、代理中継サーバ２０から転送された入力プロンプトに対し、必要に応じてアカウント名、パスワード、端末情報をユーザインタフェース部１４から入力する。プログラムでそれらの情報を自動的に取得可能であれば、自動的にログイン処理を進めてもよい。
【００２３】
続いて、利用者が代理中継サーバ２０に保持されている利用者情報テーブル２２を更新もしくは生成するかどうかチェックする（ステップ７２０）。ここで、このような利用者登録を行わず、データの配信要求を行うのであれば（ステップ７２０：ＹＥＳ）、所望のデータに関するＩＤやネットワーク上のファイルの位置情報を代理中継サーバ２０へ送信して、データ配信要求を行う（ステップ８００）。
その後、代理中継サーバ２０からデータを正しく受信できたかどうか調べ（ステップ８１０）、所望のデータを受信できなかった場合は（ステップ８１０：ＹＥＳ）、エラー処理を行う（ステップ９００）。
【００２４】
一方、エラーなくデータを受信できた場合は（ステップ８１０：ＹＥＳ）、そのデータをクライアント端末１０で保存しあるいは利用する（ステップ８２０）。データを保存する場合は、暗号化されたまま保存する。
データの利用において、代理中継サーバ２０と接続しておくかどうかは、そのデータの利用情報やデータの種別により、保存されたデータを後日オフラインで利用することも可能である。
【００２５】
このように、本実施の形態によれば、代理中継サーバ２０において、配信サーバから暗号化配信されたデータを代理中継サーバ２０で受信して復号化し、その復号化したデータを利用者とクライアント端末とに固有の共通鍵で暗号化した形式に変換してクライアント端末へ送信するようにしたので、クライアント端末側では共通鍵暗号方式を適用するだけでよく、配信サーバと代理中継サーバとの間で公開鍵・秘密鍵を用いたとしてもその煩雑な鍵管理を代理中継サーバに委託でき、複雑な暗号鍵管理を必要とせず、データを許可された利用者および端末においてのみ閲覧・利用可能とすることができる。
また、共通鍵暗号方式は公開鍵暗号方式に比べ処理が容易なため、比較的処理能力が劣る携帯型端末であっても、暗号化データ配信サービスシステムを実現できる。
【００２６】
データ利用時には、暗号鍵生成部１３で生成した共通鍵を使って、復号化処理部１２においてデータを一部もしくはすべてを復号し、含まれているデータの利用情報を参照する。データの利用情報が含まれていない場合は、残りの部分の復号を行い、データの表示やプログラムの実行を行う。
配信サーバ３０と代理中継サーバ２０との間のデータ通信について、公開鍵・秘密鍵を用いた公開鍵暗号方式を適用することにより、極めて高度なデータ保護を行うことができる。また、公開鍵暗号方式ではなく、利用者とクライアント端末とに固有の共通鍵を用いた共通鍵暗号方式を適用した場合は、高度なデータ保護を行えるとともに、代理中継サーバ２０での鍵管理が簡略化される。
【００２７】
データの利用情報として、データの有効利用期限が付加されている場合には、現在の日時を取得して比較することで、データの利用の可否を決定する。
また、データの利用情報として、データの有効利用回数が付加されている場合には、現在までに利用した回数をデータ利用履歴情報テーブル１５から取得して比較することでデータの利用可否を決定し、現在までに利用した回数の更新を行う。さらにデータの利用情報として、データの有効利用時間が付加されている場合には、現在までに利用した延べ時間をデータ利用履歴情報テーブル１５から取得して比較することでデータの利用の可否を決定する。そして、現在までに利用した延べ時間の更新を行う。利用した回数、延べ時間などの利用履歴情報は、共通鍵を使って暗号化した後にクライアント端末１０のデータ利用履歴情報テーブル１５へ保存され管理される。
【００２８】
このように、データに付加されている利用情報に基づき、クライアント端末１０でそのデータの利用可否を判断するようにしたので、利用者ごとに個別の条件で利用可否を判断できる。また、クライアント端末１０で利用者ごとの個別の条件、例えば利用履歴情報を管理するようにしたので、より詳細な利用可否管理を実現できるとともに、代理中継サーバ２０で各利用者の個別の条件を管理する必要がなくなり、代理中継サーバ２０の処理負担を軽減できる。
【００２９】
ステップ７２０において、利用者が利用者登録を行うよう指示した場合は（ステップ７２０：ＹＥＳ）、ステップ７３０へ移行して利用者情報の登録処理を行う。このクライアント端末１０における利用者情報登録処理に対して、代理中継サーバ２０においては、図６のステップ６００〜６４０の処理が対応する。
まず、クライアント端末１０の端末制御部１６では、利用者のアカウント、パスワードなどの個人情報を送信し（ステップ７３０）、代理中継サーバ２０の中継制御部２６はそれを受信する（ステップ６００）。
【００３０】
続いて、クライアント端末１０は、端末情報を送信し（ステップ７４０）、代理中継サーバ２０はそれを受信する（ステップ６１０）。さらにクライアント端末１０は、暗号鍵生成部１３で共通鍵を生成し（ステップ７５０）、それを送信する（ステップ７６０）。代理中継サーバ２０は、その共通鍵を受信し（ステップ６２０）、また利用者に対して発行された公開鍵暗号のための公開鍵・秘密鍵の組を第三者機関（図示せず）から取得して（ステップ６３０）、これら情報を利用者情報テーブル２２へ保存する（ステップ６４０）。また、更新する場合には、必要な項目のみが通信され、代理中継サーバ２０の利用者情報テーブル２２が更新される。
【００３１】
このように、当該利用者およびそのクライアント端末１０に固有の共通鍵を、クライアント端末１０の暗号鍵生成部１３で適時動的に生成して、代理中継サーバへ更新登録するようにしてもよく、これにより共通鍵がクライアント端末１０に永続的に保持されなくなるため、共通鍵の盗用が極めて困難となり高い安全性が得られる。
【図面の簡単な説明】
【００３２】
【図１】本発明の一実施の形態による暗号化データ配信サービスシステムを示すブロック図である。
【図２】代理中継サーバの動作を示すフローチャートである。
【図３】認証処理を示すフローチャートである。
【図４】暗号化データ配信処理を示すフローチャートである。
【図５】クライアント端末の動作を示すフローチャートである。
【図６】利用者登録処理を示すフローチャートである。
【図７】従来の暗号化通信システムを示すブロック図である。
【符号の説明】
【００３３】
１０…クライアント端末、２０…代理中継サーバ、３０…配信サーバ、４０…認証サーバ、１１，２１…通信インタフェース部、１２，２２…復号化処理部、１３…暗号鍵生成部、１４…ユーザインタフェース部、１５…データ利用履歴情報テーブル、１６…端末制御部、２３…配信データ情報テーブル、２４…暗号化処理部、２５…利用者情報テーブル、２６…中継制御部。
【技術分野】
【０００１】
本発明は、データ（コンテンツ）を暗号化配信することで許可された利用者および端末においてのみそのデータを閲覧・利用を可能とする暗号化データ配信サービスシステムに関し、特にメモリ、ユーザインタフェースなどの仕様がＰＣに比べ制限されている携帯型端末に対して暗号化データ配信サービスを効率的に行うのに適した暗号化データ配信サービスシステムに関するものである。
【背景技術】
【０００２】
近年、データを公開鍵暗号方式で暗号化配信し、特定の利用者のみにそのデータの閲覧・利用を可能とすることで、データの著作権保護、不正コピーの禁止の機能を持つネットワークを介した暗号化データ配信サービスが利用されるようになった。
しかしながら、暗号化通信を行う際に必要となる公開鍵や秘密鍵の取り扱いは、ユーザインタフェースが制限された携帯型端末では操作が難しく、また公開鍵暗号方式は、共通鍵暗号方式に比べ処理量が多いため、メモリ量などが制限された携帯型端末では、十分な処理速度を得るのが難しい。
【０００３】
一方、鍵を効率よく取り扱うための暗号化通信システムも提案されている（例えば、特許文献１など参照）。図７に示すように、この暗号化通信システムは、複数のユーザ側計算機１と、複数のマーチャント側計算機２と、中継装置３と、第三者機関４とから構成されている。このような構成を有する従来の暗号化システムは次のように動作する。
任意のユーザ側計算機１と中継装置３の両方において、第三者機関４の認証の下でユーザ共通鍵を保持し、同様にマーチャント側計算機２と中継装置３の両方において、第三者機関４の認証の下でマーチャント共通鍵を保持する。そして、マーチャント側計算機２は送信するメッセージを、マーチャント共通鍵で暗号化して中継装置３に送り、中継装置３において、マーチャント共通鍵で復号化し、さらにユーザ共通鍵で暗号化してユーザ側計算機１に送信し、ユーザ側計算機１において、受信したメッセージをユーザ共通鍵で復号する。
【０００４】
このとき、共通鍵暗号方式の代わりに、公開鍵暗号方式を使って、ユーザ側計算機１にユーザ秘密鍵を保持するとともに中継装置３にユーザ公開鍵を保持し、またマーチャント側計算機２にマーチャント秘密鍵を保持するとともに中継装置３にマーチャント公開鍵を保持して、上記と同様の暗号化通信を行うことが可能である。
そのため、ユーザ側計算機１およびマーチャント側計算機２において、暗号化通信する際、予め指定された中継装置３との通信のための暗号鍵のみを扱えばよいので、暗号鍵の取り扱いの煩雑さが減少し、また多数の計算機間での暗号化通信に必要な各暗号鍵を管理しなくてよいので、鍵管理を効率よく行うことを実現している。
【０００５】
【特許文献１】特開平１０−３４１２２３号公報
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、このような従来の暗号化通信システムでは、以下のような問題点があった。まず第１に、配信サービス側が、中継装置までの通信において特定の利用者に応じた暗号化を行っていないため、このような中継方式の暗号化通信では、ある特定の利用者および端末に対してのみ閲覧・利用を許可するようなデータを配信することができないという問題点があった。第２に、第三者機関によって発行された暗号鍵を使っているため、配信された暗号化データは、暗号鍵を漏らせば、他の利用者や端末でも閲覧・利用が可能となってしまうという問題点があった。
本発明はこのような課題を解決するためのものであり、複雑な暗号鍵管理を必要とせず、データを許可された利用者および端末においてのみ閲覧・利用可能とすることができる暗号化データ配信サービスシステムを提供することを目的としている。
【課題を解決するための手段】
【０００７】
このような目的を達成するために、本発明にかかるデータ配信サービスシステムは、データを暗号化して配信することにより、特定の利用者および端末のみにおいて利用可能とするデータ配信サービスシステムにおいて、配信するデータを暗号化して送信する配信サーバと、受信したデータを当該利用者およびその端末に固有の共通鍵で復号化し、閲覧または利用する利用者端末と、前記配信サーバから暗号化されたデータを受信して復号化し、その復号化したデータを当該利用者および前記端末に固有の共通鍵で暗号化した形式に変換して前記端末へ送信する代理中継サーバとを備えている。
【発明の効果】
【０００８】
本発明によれば、代理中継サーバにより、配信サーバから暗号化されたデータが受信されて復号化され、その復号化したデータが当該利用者および端末に固有の共通鍵で暗号化した形式に変換されて端末へ送信される。
したがって、端末側では共通鍵暗号方式を使うだけでよく、配信サーバと代理中継サーバとの間で公開鍵・秘密鍵を用いたとしてもその煩雑な鍵管理を代理中継サーバに委託でき、複雑な暗号鍵管理を必要とせず、データを許可された利用者および端末においてのみ閲覧・利用可能とすることができる。また、共通鍵暗号方式は公開鍵暗号方式に比べ処理が容易なため、比較的処理能力が劣る携帯型端末であっても、暗号化データ配信サービスシステムを実現できる。さらに、当該利用者およびその端末に固有の共通鍵を動的に生成して、代理中継サーバへ更新登録するようにしてもよく、これにより共通鍵が端末に永続的に保持されなくなるため、共通鍵の盗用が極めて困難となり高い安全性が得られる。
【発明を実施するための最良の形態】
【０００９】
次に、本発明の実施の形態について図面を参照して説明する。
図１は本発明の一実施の形態にかかる暗号化データ配信サービスシステムを示すブロック図である。
この暗号化データ配信サービスシステムは、データ（コンテンツ）を暗号化して配信する配信サーバ３０と、配信サーバ３０からの暗号化されたデータを一旦復号化して再び暗号化して中継する代理中継サーバ２０と、代理中継サーバ２０からのデータを復号化して閲覧・利用するクライアント端末１０とから構成される。
【００１０】
代理中継サーバ２０には、配信サーバ３０およびクライアント端末１０との通信を管理する通信インタフェース部２１、配信サーバ３０から受信した暗号化データを復号する復号化処理部２５、クライアント端末に送信するデータを暗号化する暗号化処理部２４、利用者の種々の情報、特に復号化処理に用いる利用者の秘密鍵および暗号化処理に用いる共通鍵を管理する利用者情報テーブル２２、配信データのアクセス制御情報が蓄積されている配信データ情報テーブル２３、およびこれら各部を制御して代理中継処理を行う中継制御部２６が設けられている。
【００１１】
クライアント端末１０には、代理中継サーバ２０との通信を管理する通信インタフェース部１１、利用者の操作を処理するユーザインタフェース部１４、利用者およびクライアント端末１０に固有の共通鍵を生成する暗号鍵生成部１３、代理中継サーバ２０から受信したデータを復号化処理する復号化処理部１２、閲覧・利用したデータの利用履歴を管理するデータ利用履歴情報テーブル１５、およびこれら各部を制御して暗号化されたデータを閲覧・利用する端末制御部１６が設けられている。
【００１２】
次に、図１および図２を参照して、本実施の形態の代理中継サーバ２０の動作について詳細に説明する。図２は代理中継サーバの処理動作を示すフローチャートである。
代理中継サーバ２０の中継制御部２６では、まず、通信インターフェース部２１を介してクライアント端末１０の接続要求を待ち、接続要求があれば（ステップ１００：ＹＥＳ）、利用者のログイン処理で利用者の認証を行う（ステップ１１０）。例えば、クライアント端末１０で利用者のアカウント名とパスワードを入力し、代理中継サーバ側に保持されているアカウント名とパスワードに一致するかどうかチェックすることで、利用者の認証を行い、ログイン処理をする。このような認証情報は、利用者情報テーブル２２で保持するが、認証の方式としては、さまざまな手法を適用することが可能である。
【００１３】
ここで、図３を参照して、ステップ１１０での認証処理について説明する。図３は代理中継サーバにおける認証処理を示すフローチャートである。
まず、中継制御部２６では、利用者情報テーブル２２に保持されている利用者のアカウント名を検索し、一致する利用者のアカウント名から、予め登録された利用者の個人情報が保持されている領域を確認する（ステップ３００）。次に、クライアント端末１０の表示画面の大きさ、表示色数、シリアル番号、ＯＳのバージョン番号といった端末情報を取得する（ステップ３１０）。この場合、予め利用者情報テーブル２２に登録しておいた端末情報を取得してもよいし、クライアント端末１０と通信することで端末情報を受信してもよい。
【００１４】
さらに、予め登録してあるクライアント端末１０および利用者に固有の共通鍵を利用者情報テーブル２２から取得する（ステップ３２０）。共通鍵は、利用者個人情報テーブルに含まれている情報を使って、クライアント端末１０の暗号鍵生成部１３と同一の処理、同一のアルゴリズムで、動的に生成してもよい。
これらステップ３００〜３２０の処理でエラーが発生した場合は、ログイン不成功と判断し、一連の認証処理を終了してステップ１００へ戻る（ステップ３３０：ＮＯ）。エラーがなければログイン成功と判断し（ステップ３３０：ＹＥＳ）、一連の認証処理を終了してステップ１２０へ移行する。
このように、データ配信に先立って、代理中継サーバ２０において、利用者の認証を行うようにしたので、鍵管理の不正利用を抑制でき、代理中継サーバ２０での厳重な鍵管理を実現できる。
【００１５】
図２のステップ１１０においてログインが成功した場合（ステップ１１０：ＹＥＳ）、中継制御部２６では、クライアント端末１０から、データの配信要求があるかどうかチェックする（ステップ１２０）。
ここで、データの配信要求以外の処理要求、例えばパスワード変更といった利用者情報の更新などの場合は（ステップ１２０：ＮＯ）、その要求された処理を行った後（ステップ１３０）、クライアント端末からの処理要求があるかどうか調べるため、ステップ１２０へ戻る。
【００１６】
クライアント端末１０からデータの配信要求があった場合は（ステップ１２０：ＹＥＳ）、当該データを保持している配信サーバ３０へのアクセスが許可されているかどうか、またそのデータへのアクセスが許可されているかどうかを、配信データ情報テーブル２３を使って調べる（ステップ１４０）。
配信データ情報テーブル２３には、種々の配信データのアクセス制御情報が蓄積されている。このような情報を使うことで、例えば、利用者がその配信サーバ３０のデータへアクセス可能な年齢１８歳に満たない場合や、そのデータに既にアクセスしたことがあるが、そのデータへのアクセスがただ一度だけに制限されている場合などのアクセスの許可・不許可を調べる。
【００１７】
このように、代理中継サーバ２０の配信データ情報テーブル２３で個々のデータのアクセス制御情報を管理し、クライアント端末１０からの要求に応じて、その要求データに対するアクセス可否を判断するようにしたので、利用者ごとに各データの厳密なアクセス管理を実現できる。
【００１８】
ステップ１４０において、データへのアクセスが許可され要求可と判断されたた場合は（ステップ１４０：ＹＥＳ）、実際にデータを保持している配信サーバ３０へデータの送信要求を行い、その要求に対して返信されてきたデータを受信する（ステップ１５０）。必要であれば、利用者情報テーブル２２に保持されている利用者情報も併せて送信する。
そして、受信したデータが正しく受信されたかどうか調べ（ステップ１６０）、データの取得成功が確認された場合は（ステップ１６０：ＹＥＳ）、受信したデータが暗号化されており、別のサーバなどから暗号鍵を取得する必要がある場合があり、実際に受信したデータがクライアント端末１０で利用可能であるかどうかを調べる（ステップ１７０）。
【００１９】
受信したデータがクライアント端末１０で利用可能であり、代理中継サーバ２０からクライアント端末１０へデータ配信可能であると判断された場合は（ステップ１７０：ＹＥＳ）、通信インターフェース部２１を介してクライアント端末１０へデータを送信し（ステップ１８０）、ステップ１２０へ戻る。
上記のステップ１４０、１６０、１７０の処理において、エラーが生じた場合には、クライアント端末１０にエラー通知を行い（ステップ１９０）、ステップ１２０へ戻る。
【００２０】
ここで、図４を参照して、ステップ１８０でのデータ配信処理について説明する。
中継制御部２６では、まず、配信サーバ３０から取得したデータが暗号化されていれば、これを復号化処理部２５で復号化する（ステップ５００）。このとき、取得したデータが利用者の公開鍵で暗号化されている場合には、利用者情報テーブル２２に保持されている秘密鍵を用いて復号化する。また利用者およびクライアント端末１０に固有の共通鍵で暗号化されている場合には、同じく利用者情報テーブル２２に保持されているその共通鍵を取得して復号化する。
なお、配信サーバ３０でデータを暗号化する際に用いる公開鍵や共通鍵については、代理中継サーバ２０から直接通知するようにしてもよい。また、公開鍵については代理中継サーバ２０から通知された利用者の個人情報に基づき第三者機関から取得してもよい。
【００２１】
続いて、利用者情報テーブル２２の端末情報を参照し、必要ならばデータの変換やファイルフォーマットの変換を行う（ステップ５１０）。例えば、２５６色のカラー画像データに対して端末が白黒表示しかできない場合は白黒データ変換処理を行ったり、表示画面の大きさにあわせて画像データの拡大縮小処理を行ったりする。
さらに、そのデータの利用情報を付加する（ステップ５２０）。利用情報は、配信サーバ３０や別のサーバ（例えば図示しない課金サーバ）から取得される、データの利用回数や利用期限といった情報である。そして、ステップ３２０で取得したデータを利用者およびクライアント端末１０に固有の共通鍵を使って、暗号化処理部２４で暗号化し（ステップ５３０）、クライアント端末１０に送信して（ステップ５４０）、一連のデータ配信処理を終了する。
【００２２】
次に、図１および図５を参照して、本実施の形態のクライアント端末１０の動作について詳細に説明する。図５はクライアント端末の処理動作を示すフローチャートである。
クライアント端末１０の端末制御部１６では、まず、代理中継サーバ２０との通信接続を行う（ステップ７００）。接続後、ログイン処理を行う（ステップ７１０）。このステップ７１０の処理に対して、代理中継サーバ２０においては図２のステップ１１０の処理が対応する。ここでは、利用者により、代理中継サーバ２０から転送された入力プロンプトに対し、必要に応じてアカウント名、パスワード、端末情報をユーザインタフェース部１４から入力する。プログラムでそれらの情報を自動的に取得可能であれば、自動的にログイン処理を進めてもよい。
【００２３】
続いて、利用者が代理中継サーバ２０に保持されている利用者情報テーブル２２を更新もしくは生成するかどうかチェックする（ステップ７２０）。ここで、このような利用者登録を行わず、データの配信要求を行うのであれば（ステップ７２０：ＹＥＳ）、所望のデータに関するＩＤやネットワーク上のファイルの位置情報を代理中継サーバ２０へ送信して、データ配信要求を行う（ステップ８００）。
その後、代理中継サーバ２０からデータを正しく受信できたかどうか調べ（ステップ８１０）、所望のデータを受信できなかった場合は（ステップ８１０：ＹＥＳ）、エラー処理を行う（ステップ９００）。
【００２４】
一方、エラーなくデータを受信できた場合は（ステップ８１０：ＹＥＳ）、そのデータをクライアント端末１０で保存しあるいは利用する（ステップ８２０）。データを保存する場合は、暗号化されたまま保存する。
データの利用において、代理中継サーバ２０と接続しておくかどうかは、そのデータの利用情報やデータの種別により、保存されたデータを後日オフラインで利用することも可能である。
【００２５】
このように、本実施の形態によれば、代理中継サーバ２０において、配信サーバから暗号化配信されたデータを代理中継サーバ２０で受信して復号化し、その復号化したデータを利用者とクライアント端末とに固有の共通鍵で暗号化した形式に変換してクライアント端末へ送信するようにしたので、クライアント端末側では共通鍵暗号方式を適用するだけでよく、配信サーバと代理中継サーバとの間で公開鍵・秘密鍵を用いたとしてもその煩雑な鍵管理を代理中継サーバに委託でき、複雑な暗号鍵管理を必要とせず、データを許可された利用者および端末においてのみ閲覧・利用可能とすることができる。
また、共通鍵暗号方式は公開鍵暗号方式に比べ処理が容易なため、比較的処理能力が劣る携帯型端末であっても、暗号化データ配信サービスシステムを実現できる。
【００２６】
データ利用時には、暗号鍵生成部１３で生成した共通鍵を使って、復号化処理部１２においてデータを一部もしくはすべてを復号し、含まれているデータの利用情報を参照する。データの利用情報が含まれていない場合は、残りの部分の復号を行い、データの表示やプログラムの実行を行う。
配信サーバ３０と代理中継サーバ２０との間のデータ通信について、公開鍵・秘密鍵を用いた公開鍵暗号方式を適用することにより、極めて高度なデータ保護を行うことができる。また、公開鍵暗号方式ではなく、利用者とクライアント端末とに固有の共通鍵を用いた共通鍵暗号方式を適用した場合は、高度なデータ保護を行えるとともに、代理中継サーバ２０での鍵管理が簡略化される。
【００２７】
データの利用情報として、データの有効利用期限が付加されている場合には、現在の日時を取得して比較することで、データの利用の可否を決定する。
また、データの利用情報として、データの有効利用回数が付加されている場合には、現在までに利用した回数をデータ利用履歴情報テーブル１５から取得して比較することでデータの利用可否を決定し、現在までに利用した回数の更新を行う。さらにデータの利用情報として、データの有効利用時間が付加されている場合には、現在までに利用した延べ時間をデータ利用履歴情報テーブル１５から取得して比較することでデータの利用の可否を決定する。そして、現在までに利用した延べ時間の更新を行う。利用した回数、延べ時間などの利用履歴情報は、共通鍵を使って暗号化した後にクライアント端末１０のデータ利用履歴情報テーブル１５へ保存され管理される。
【００２８】
このように、データに付加されている利用情報に基づき、クライアント端末１０でそのデータの利用可否を判断するようにしたので、利用者ごとに個別の条件で利用可否を判断できる。また、クライアント端末１０で利用者ごとの個別の条件、例えば利用履歴情報を管理するようにしたので、より詳細な利用可否管理を実現できるとともに、代理中継サーバ２０で各利用者の個別の条件を管理する必要がなくなり、代理中継サーバ２０の処理負担を軽減できる。
【００２９】
ステップ７２０において、利用者が利用者登録を行うよう指示した場合は（ステップ７２０：ＹＥＳ）、ステップ７３０へ移行して利用者情報の登録処理を行う。このクライアント端末１０における利用者情報登録処理に対して、代理中継サーバ２０においては、図６のステップ６００〜６４０の処理が対応する。
まず、クライアント端末１０の端末制御部１６では、利用者のアカウント、パスワードなどの個人情報を送信し（ステップ７３０）、代理中継サーバ２０の中継制御部２６はそれを受信する（ステップ６００）。
【００３０】
続いて、クライアント端末１０は、端末情報を送信し（ステップ７４０）、代理中継サーバ２０はそれを受信する（ステップ６１０）。さらにクライアント端末１０は、暗号鍵生成部１３で共通鍵を生成し（ステップ７５０）、それを送信する（ステップ７６０）。代理中継サーバ２０は、その共通鍵を受信し（ステップ６２０）、また利用者に対して発行された公開鍵暗号のための公開鍵・秘密鍵の組を第三者機関（図示せず）から取得して（ステップ６３０）、これら情報を利用者情報テーブル２２へ保存する（ステップ６４０）。また、更新する場合には、必要な項目のみが通信され、代理中継サーバ２０の利用者情報テーブル２２が更新される。
【００３１】
このように、当該利用者およびそのクライアント端末１０に固有の共通鍵を、クライアント端末１０の暗号鍵生成部１３で適時動的に生成して、代理中継サーバへ更新登録するようにしてもよく、これにより共通鍵がクライアント端末１０に永続的に保持されなくなるため、共通鍵の盗用が極めて困難となり高い安全性が得られる。
【図面の簡単な説明】
【００３２】
【図１】本発明の一実施の形態による暗号化データ配信サービスシステムを示すブロック図である。
【図２】代理中継サーバの動作を示すフローチャートである。
【図３】認証処理を示すフローチャートである。
【図４】暗号化データ配信処理を示すフローチャートである。
【図５】クライアント端末の動作を示すフローチャートである。
【図６】利用者登録処理を示すフローチャートである。
【図７】従来の暗号化通信システムを示すブロック図である。
【符号の説明】
【００３３】
１０…クライアント端末、２０…代理中継サーバ、３０…配信サーバ、４０…認証サーバ、１１，２１…通信インタフェース部、１２，２２…復号化処理部、１３…暗号鍵生成部、１４…ユーザインタフェース部、１５…データ利用履歴情報テーブル、１６…端末制御部、２３…配信データ情報テーブル、２４…暗号化処理部、２５…利用者情報テーブル、２６…中継制御部。
【特許請求の範囲】
【請求項１】
データを暗号化して配信することにより、特定の利用者および端末のみにおいて利用可能とするデータ配信サービスシステムにおいて、
配信するデータを暗号化して送信する配信サーバと、
受信したデータを当該利用者およびその端末に固有の共通鍵で復号化し、閲覧または利用する利用者端末と、
前記配信サーバから暗号化されたデータを受信して復号化し、その復号化したデータを当該利用者および前記端末に固有の共通鍵で暗号化した形式に変換して前記端末へ送信する代理中継サーバとを備えることを特徴とする暗号化データ配信サービスシステム。
【請求項１】
データを暗号化して配信することにより、特定の利用者および端末のみにおいて利用可能とするデータ配信サービスシステムにおいて、
配信するデータを暗号化して送信する配信サーバと、
受信したデータを当該利用者およびその端末に固有の共通鍵で復号化し、閲覧または利用する利用者端末と、
前記配信サーバから暗号化されたデータを受信して復号化し、その復号化したデータを当該利用者および前記端末に固有の共通鍵で暗号化した形式に変換して前記端末へ送信する代理中継サーバとを備えることを特徴とする暗号化データ配信サービスシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２００６−１９７６４０（Ｐ２００６−１９７６４０Ａ）
【公開日】平成１８年７月２７日（２００６．７．２７）
【国際特許分類】
【出願番号】特願２００６−５９８２６（Ｐ２００６−５９８２６）
【出願日】平成１８年３月６日（２００６．３．６）
【分割の表示】特願２０００−３２２０１４（Ｐ２０００−３２２０１４）の分割
【原出願日】平成１２年１０月２０日（２０００．１０．２０）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成１８年７月２７日（２００６．７．２７）
【国際特許分類】
【出願日】平成１８年３月６日（２００６．３．６）
【分割の表示】特願２０００−３２２０１４（Ｐ２０００−３２２０１４）の分割
【原出願日】平成１２年１０月２０日（２０００．１０．２０）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]