JP4760385B2 - 暗号化システム - Google Patents

Description

本発明は、ストリーム配信に関し、特にＩＰマルチキャストストリーム配信時における鍵管理、及び暗号化システムに関する。

近年、ネットワークインフラの整備に伴って、映像コンテンツをマルチキャストで配信する方式が普及しつつある。この方式では、ユーザの視聴権の有無に関らずビデオサーバから映像コンテンツの配信が継続されるため、視聴権の無くなった人による継続視聴を排除する必要がある。そこで、暗号化サーバが、暗号化鍵（Ｋｃｎ）で映像コンテンツを暗号化して暗号化コンテンツを生成し、各ユーザへ配信し、更に、この暗号化鍵（Ｋｃｎ）を所定の時間間隔で変更させている。この暗号化鍵（Ｋｃｎ）は、他の暗号化鍵（Ｋｐｈ）で暗号化され、暗号化鍵データとして、上記暗号化コンテンツと共に各ユーザへ配信されていた。各ユーザは、システム内に独立して配置されている鍵管理サーバから各々個別に上記暗号化鍵（Ｋｐｈ）を受入れて暗号化鍵データから暗号化鍵（Ｋｃｎ）を取得し、この暗号化鍵（Ｋｃｎ）を用いて上記暗号化コンテンツを復号化していた。

各ユーザ毎の視聴権の有無は、各ユーザに対する鍵管理サーバからの上記暗号化鍵（Ｋｐｈ）の送信によって制限されている。又、セキュリティ確保のために、鍵管理サーバは、上記暗号化鍵（Ｋｐｈ）の送信を要求する各ユーザを所定の方式に基づいて認証することとしていた。この認証を行うために、更に、適切なタイミングで暗号化鍵の更新を行うために、鍵管理サーバは、ユーザの視聴中／ビデオサーバの配信中、定期的に各ユーザ（Ｐｌａｙｅｒ）と通信を行っていた。
特開２００３−１７４４４１号公報 Ｉｎｔｅｒｎｅｔ Ｄｒａｆｔ ＩＥＴＦ ＭＳＥＣ ＷＧ Ｍａｒｋ Ｂａｕｇｈｅｒ、 Ｒａｎ Ｃａｎｅｔｔｉ、 Ｌａｋｓｈｍｉｎａｔｈ Ｄｏｎｄｅｔｉ、 Ｆｒｅｄｒｉｋ Ｌｉｎｄｈｏｌｍ、 Ｆｅｂｒｕａｒｙ ２８、 ２００２

しかしながら、上記従来の技術では、鍵管理サーバが、本来の任務であるＲｅ−ｋｅｙプロトコルを実行する他に、レジストレーションプロトコルまで実行していたため鍵管理サーバの汎用性が失われていた（解決すべき課題１）。更に、上記従来の技術では、鍵管理サーバが、コンテンツ暗号化鍵を生成していたため、何らかの障害、例えば鍵管理サーバとビデオサーバ間での通信障害などの発生によってビデオサーバがコンテンツ暗号化鍵の取得が不可能になり、ビデオサーバの配信が停止してしまうことになった（解決すべき課題２）。ここで、Ｒｅ−ｋｅｙプロトコルとは、ユーザの視聴中／ビデオサーバの配信中に、鍵管理サーバと各ユーザ（Ｐｌａｙｅｒ）とが暗号化鍵の更新を行うために通信を行うことであり、レジストレーションプロトコルとは、ユーザの視聴要求／ビデオサーバの配信開始をシステム側が認証することである。

本発明は、マルチキャストストリーム配信を要求するストリーム受信装置を認証する認証サーバと、コンテンツを暗号化するコンテンツ暗号化鍵を生成・管理・運用し、コンテンツを暗号化してマルチキャストストリーム配信するビデオサーバの要求に基づいて、該当するコンテンツ暗号化鍵を返信すると共に、認証サーバが認証したストリーム受信装置の要求に基づいて、該当するコンテンツ暗号化鍵を返信する鍵管理サーバとを備え、認証サーバは、ストリーム受信装置を操作するユーザのユーザ情報を鍵管理サーバに送信し、鍵管理サーバは、ユーザ情報を受けると、当該ユーザからの配信要求を可能にすべく、ユーザ固有通信暗号化鍵と、ユーザを確認するための第１チケットと、ユーザ固有のＭＡＣ鍵とを設定し、これらを鍵管理サーバ確認情報として認証サーバに送信し、認証サーバは、鍵管理サーバ確認情報を受けると、該情報をストリーム受信装置に送信し、ストリーム受信装置は、鍵管理サーバ確認情報を受けると、自己のユーザＩＤと、視聴コンテンツの識別子と、第１チケットとを含む暗号化鍵要求情報を鍵管理サーバに送信し、鍵管理サーバは、暗号化鍵要求情報を受けると、該情報が改竄されているか否かを判定し、改竄されていない場合には、該暗号化鍵要求情報に含まれる第１チケットと、自己が有するメモリに格納されている設定した第１チケットとを照合して該当するユーザ情報を確認すると、ストリーム受信装置に対し当該ユーザが要求している視聴コンテンツに対応するコンテンツ暗号化鍵と、新たに新規設定した第２チケットとを送信し、ストリーム受信装置は、コンテンツ暗号化鍵と、第２チケットとが改竄されていないことを確認すると、該コンテンツ暗号化鍵を用いて視聴コンテンツを復号することを主要な特徴とする。

ユーザの登録、認証、コンテンツ情報の管理、というサービス毎に異なる部分を鍵管理サーバから切り離して、認証サーバに分担処理させることとしたので、鍵管理サーバがＲｅ―ｋｅｙプロトコルに専念できるようになる。その結果鍵管理サーバの汎用性が高まるという効果を得る。

ユーザの登録、認証、コンテンツ情報の管理等、サービス毎に異なる部分を鍵管理サーバから切り離して分担処理させるための認証サーバを配置し、鍵管理サーバに対してＲｅ―ｋｅｙプロトコルに専念させる。更に、ビデオサーバと鍵管理サーバとの間に何らかの通信障害が発生しても、ビデオサーバの配信が停止するのを排除するため、コンテンツ暗号化鍵の生成をビデオサーバが実行し、生成したコンテンツ暗号化鍵を鍵管理サーバへ送信することとする。

本実施例による暗号化システムは、上記、解決すべき課題１に対応すべく、ユーザの登録、認証、コンテンツ情報の管理、というサービス毎に異なる部分を鍵管理サーバから切り離して、認証サーバに分担処理させ、鍵管理サーバに対してＲｅ―ｋｅｙプロトコルに専念させる。かかる目的を達成するために本実施例は、以下のように構成される。
図１は、実施例１の暗号化システムのシステム構成図である。
図に示すように、実施例１の暗号化システム１００は、鍵管理サーバ１と、認証サーバ２と、Ｐｌａｙｅｒ３と、ビデオサーバ４とを含む。

鍵管理サーバ１は、コンテンツ暗号化鍵生成部１−１を有し、各種コンテンツのコンテンツ暗号化鍵を生成し、自己が有するメモリに格納し、ビデオサーバ４からコンテンツ識別子を含めた、暗号化鍵の取得要求を受入れると、含まれているコンテンツに対応するコンテンツ暗号化鍵をビデオサーバ４へ送信するサーバである。又、認証サーバ２からＰｌａｙｅｒ３のユーザＩＤ（Ｐｌａｙｅｒ３を一意に特定する一定長の文字列）、コンテンツ識別子（そのユーザが視聴出来るコンテンツを一意に特定する一定長の文字列）、同コンテンツの視聴期限を含むユーザ情報を受入れると、そのユーザ情報を自己が有するメモリに格納し、Ｐｌａｙｅｒ３が直接、鍵管理サーバ１へコンテンツ暗号化鍵の取得要求を実施することを可能にするユーザ固有通信暗号化鍵、ユーザを確認するためのチケット、ユーザ固有ＭＡＣ鍵等を含む鍵管理サーバ確認情報を、それぞれ設定して認証サーバ２へ送信するサーバでもある。

更に、Ｐｌａｙｅｒ３から鍵管理サーバ確認情報に基づいて構成された暗号化鍵要求を受入れると、該当するユーザ情報を確認し、確認出来ると、該当するコンテンツ暗号化鍵をＰｌａｙｅｒ３へ送出するサーバである。ここでチケットとは、ユーザを確認するための一定長の擬似乱数ビット列である。又、ユーザ固有ＭＡＣ鍵とは、送信されたメッセージが改竄されていないことや、本人が送信したものであることを確認するために使うメッセージ・ダイジェストである。

認証サーバ２は、鍵管理サーバクライアントライブラリ２−１を有し、ユーザ情報（ユーザＩＤ、パスワード、視聴出来るコンテンツ、及びその視聴期間）を登録ユーザ情報として予め登録しておき、Ｐｌａｙｅｒ３を認証するサーバである。即ち、Ｐｌａｙｅｒ３からユーザのパスワード、ユーザが視聴出来るコンテンツ、等を含む視聴要求を受入れると、鍵管理サーバクライアントライブラリ２−１に予め登録されている登録ユーザ情報に基づいて認証処理を実行するサーバである。ここで、その視聴要求が正しいものと認証できたときには、視聴要求してきたＰｌａｙｅｒ３のユーザＩＤと、コンテンツ識別子と、同コンテンツの視聴期限を含めて、鍵管理サーバ１へＰｌａｙｅｒ３のユーザ情報（視聴要求）として送信するサーバである。又、鍵管理サーバ１からユーザ固有通信暗号化鍵と、チケットと、ユーザ固有ＭＡＣ鍵とを、鍵管理サーバへのアクセス情報として受信すると、この鍵管理サーバへのアクセス情報とコンテンツ識別子とを、視聴要求してきたＰｌａｙｅｒ３へ転送するサーバでもある。ここでコンテンツ識別子とは、コンテンツを一意に特定する一定長の文字列である。

Ｐｌａｙｅｒ３は、ビデオサーバから暗号化されたコンテンツを受信する装置である。但し、図では説明の都合上１台のみ記載してあるが、実際には多数台配置されている。更に、認証サーバ２に対してユーザのパスワード、ユーザが視聴を希望するコンテンツ、等を含む視聴要求を実行し、認証サーバ２から受信したユーザ固有通信暗号化鍵を用いて鍵管理サーバ１に対してコンテンツ暗号化鍵を直接要求し、鍵管理サーバ１からコンテンツ暗号化鍵を取得し、そのコンテンツ暗号化鍵を用いて、ビデオサーバから受信した暗号化されたコンテンツを復号化する装置である。

ビデオサーバ４は、鍵管理サーバ１に対して、（自己が配信しようとしているコンテンツの）コンテンツ識別子を含めた、コンテンツ暗号化鍵の取得要求を送信し、鍵管理サーバ１から、（要求した）コンテンツ暗号化鍵を取得し、該当するコンテンツを暗号化して各Ｐｌａｙｅｒ３に対してマルチキャスト配信するサーバである。

図２は、実施例１の暗号化システムの動作説明図である。
この図は、上記図１を用いて説明した、Ｐｌａｙｅｒ３、認証サーバ２、ビデオサーバ４、鍵管理サーバ１を含むシステム全体の動作を、ステップＳ１−１からステップＳ１−１１までのシーケンスに分割して説明するための説明図である。以下に、その動作シーケンスについてステップ順に説明する。

ステップＳ１−１
ビデオサーバ４は、コンテンツ配信前に鍵管理サーバ１に対して（自己が配信しようとしているコンテンツの）コンテンツ識別子を含めた、コンテンツ暗号化鍵の取得要求を送信する。

ステップＳ１−２
鍵管理サーバ１は、ビデオサーバ４からコンテンツ暗号化鍵の取得要求を受信すると、自己が有するメモリに格納されているコンテンツ情報を検索し、ビデオサーバ４が要求しているコンテンツを検索できたときには上記取得要求に対応するコンテンツ暗号化鍵をビデオサーバ４へ送信する。このときコンテンツ暗号化鍵に鍵の更新タイミングを含めて送信する。この鍵の更新タイミングは、鍵管理サーバ１の起動時に設定されている。尚、鍵管理サーバ１は、ビデオサーバ４が要求しているコンテンツを検索できなかったときにはビデオサーバ４へエラー通知を送信して再度取得要求させる。

ステップＳ１−３
ビデオサーバ４は、鍵管理サーバ１から取得したコンテンツ暗号化鍵を用いて暗号化マルチキャストストリームの配信を開始する。このときストリームの配信を行うＲＴＰパケット毎に暗号化に用いたコンテンツ暗号化鍵の識別番号を付加する。これは、Ｐｌａｙｅｒ３が、受信するＲＴＰパケット毎にどのコンテンツ暗号化鍵を用いて復号化すべきかを把握させるためである。又、ここでは、ビデオサーバ４が用いる方式（暗号化の単位は配信パケットの単位で暗号化するのか、ＭＰＥＧの仕様に準拠して暗号化するのか等）、関数（共通鍵暗号を使うとして、ＡＥＳを使うのか、ＤＥＳを使うのか等）等については固定しない。即ち、システムに応じて異なる。

ステップＳ１−４
ユーザは、Ｐｌａｙｅｒ３を介して、視聴要求を認証サーバ２に対して行う。このとき認証サーバ２へ送信する情報の内容には、サービスの形態／ポリシーに依存して変化するが、一例として、ユーザＩＤ、パスワード、視聴を希望するコンテンツ、コンテンツの視聴期限などが含まれる。

ステップＳ１−５
認証サーバ２は、Ｐｌａｙｅｒ３から受入れた視聴要求と鍵管理サーバクライアントライブラリ２−１の内容とを照合し、その視聴要求が正しいものと認証できたときには、視聴要求してきたＰｌａｙｅｒ３のユーザＩＤと、コンテンツ識別子と、同コンテンツの視聴期限を含めて、鍵管理サーバ１へユーザ視聴要求しているＰｌａｙｅｒ３のユーザ情報として送信する（ユーザ情報キャッシュイン）。

ステップＳ１−６
鍵管理サーバ１は、認証サーバ２からユーザ情報を受入れると、そのユーザ情報を自己が有するメモリに格納する。更に、Ｐｌａｙｅｒ３が直接鍵管理サーバ１に対するコンテンツ暗号化鍵の取得要求を可能にするユーザ固有通信暗号化鍵、ユーザを確認するためのチケット、ユーザ固有ＭＡＣ鍵等を設定し、自己が有するメモリに格納するとともに、鍵管理サーバ確認情報として認証サーバ２へ送信する。これらの鍵管理サーバ確認情報は各ユーザ毎に異なる。但し、既に、同一のユーザ情報が既に格納されている場合には、そのユーザ情報に上書きする。尚、ユーザ固有ＭＡＣ鍵は、サービスのポリシーに応じて決定される。

ステップＳ１−７
認証サーバ２は、鍵管理サーバ１から鍵管理サーバ確認情報を受入れると、視聴要求したＰｌａｙｅｒ３へ転送する。

ステップＳ１−８
Ｐｌａｙｅｒ３は、鍵管理サーバ１から鍵管理サーバ確認情報を受入れると、自己のユーザＩＤと、視聴コンテンツの識別子と、受信した上記チケットとを含む、ユーザ固有ＭＡＣ鍵に基づくメッセージを生成し、ユーザ固有通信暗号化鍵で暗号化した暗号化鍵要求として鍵管理サーバ１へ送信する。

ステップＳ１−９
鍵管理サーバ１は、Ｐｌａｙｅｒ３から暗号化鍵要求を受入れると、ユーザ固有通信暗号化鍵を用いて復号化してユーザ固有ＭＡＣ鍵を用いて生成されたメッセージを取得し、自己の有するユーザ固有ＭＡＣ鍵を用いてデータが改竄されていないことを確認する。又、データの改竄が認められない場合には、そのメッセージからチケットを取得し、取得したチケットと自己が有するメモリに格納されているチケットと照合し、該当するユーザ情報（視聴コンテンツの識別子を含む）を確認する。更に、コンテンツの視聴期限が有効か否かを判定する。ここで、チケット同士の照合不可、又はデータ改竄可能性がある場合、チケットと照合不可の場合、コンテンツの視聴期限が無効の場合には、エラー通知をＰｌａｙｅｒ３に送信し、暗号化鍵要求を拒否する。

ステップＳ１−１０
鍵管理サーバ１は、該当するユーザ情報を確認できた場合には、自己が有するメモリに格納されている、そのときの鍵更新タイミングに合致した（ユーザが要求している視聴コンテンツの識別子に対応する）コンテンツ暗号化鍵を読み出す。又、更新チケットを新規設定し、自己のメモリに格納されているチケットを新規設定した更新チケットで上書きする。次回の暗号化鍵要求の安全性を維持するためである。更に、更新チケットと、コンテンツ暗号化鍵を含むユーザ固有ＭＡＣ鍵を用いて生成したメッセージをユーザ固有通信暗号化鍵で暗号化した暗号化鍵をＰｌａｙｅｒ３へ送出する。

ステップＳ１−１１
Ｐｌａｙｅｒ３は、鍵管理サーバ１から受信した暗号化された暗号化鍵を復号化し、ユーザ固有ＭＡＣ鍵を用いて生成したメッセージを取得する。Ｐｌａｙｅｒ３は、自己の有するユーザ固有ＭＡＣ鍵を用いて、鍵管理サーバ１から受信したメッセージが改竄されていないことを確認し、確認できたときはメッセージからコンテンツ暗号化鍵を取得し、このコンテンツ暗号化鍵に付加されている鍵更新タイミングの識別番号と、ビデオサーバからストリーム配信されてくるＲＴＰパケットに付加されてくる鍵更新タイミングの識別番号との一致を確認し、取得したコンテンツ暗号化鍵を用いてビデオサーバから受信した暗号化されたコンテンツの復号化を開始する。又、コンテンツ暗号化鍵の鍵更新タイミングの識別番号と、ＲＴＰパケットに付加されてくる鍵更新タイミングの識別番号とが不一致になったときには、Ｐｌａｙｅｒ３は、ステップＳ１−８以降を繰り返し、更新されたコンテンツ暗号化鍵を取得してコンテンツの復号化を継続する。このときに上記新規設定されたチケットが用いられることになる。以後同様にＰｌａｙｅｒ３は、ステップＳ１−８以降を繰り返しながらコンテンツの復号化を継続することになる。

以上説明したようにユーザの登録、認証、コンテンツ情報の管理、というサービス毎に異なる部分を鍵管理サーバから切り離して認証サーバに分担処理させることとしたので、鍵管理サーバがＲｅ―ｋｅｙプロトコルに専念できるようになる。その結果鍵管理サーバの汎用性が高まるという効果を得る。

本実施例による暗号化システムは、上記、解決すべき課題２に対応すべく、コンテンツ暗号化鍵の生成をビデオサーバが実行し、生成したコンテンツ暗号化鍵を鍵管理サーバへ送信することとし、何らかの障害があっても、ビデオサーバの配信が停止するのを排除することを目的として本実施例は以下のように構成される。
図３は、実施例２の暗号化システムのシステム構成図である。
図に示すように、実施例２の暗号化システム２００は、鍵管理サーバ２１と、認証サーバ２と、Ｐｌａｙｅｒ３と、ビデオサーバ２４とを含む。以下に実施例１との相違部分のみについて説明する。実施例１と同様の部分については実施例１と同一の符号を付して説明を省略する。

鍵管理サーバ２１は、各種コンテンツのコンテンツ暗号化鍵をビデオサーバ２４から受信し、自己が有するメモリに格納し、認証サーバ２からＰｌａｙｅｒ３のユーザＩＤ（Ｐｌａｙｅｒ３を一意に特定する一定長の文字列）、コンテンツ識別子（そのユーザが視聴出来るコンテンツを一意に特定する一定長の文字列）、同コンテンツの視聴期限を含むユーザ情報を受入れると、そのユーザ情報を自己が有するメモリに格納し、Ｐｌａｙｅｒ３が直接、鍵管理サーバ１へコンテンツ暗号化鍵の取得要求を実施することを可能にするユーザ固有通信暗号化鍵、ユーザを確認するためのチケット、ユーザ固有ＭＡＣ鍵等を設定し、鍵管理サーバ確認情報として認証サーバ２へ送信するサーバでもある。

更に、Ｐｌａｙｅｒ３から鍵管理サーバ確認情報に基づいて構成された暗号化鍵要求を受入れると、該当するユーザ情報を確認し、確認出来ると該当するコンテンツ暗号化鍵をＰｌａｙｅｒ３へ送出するサーバである。ここでチケットとは、ユーザを確認するための一定長の擬似乱数ビット列である。又、ユーザ固有ＭＡＣ鍵とは、送信されたメッセージが改竄されていないことや、本人が送信したものであることを確認するために使うメッセージ・ダイジェストである。実施例１との構成上の相違点は、実施例１の鍵管理サーバ１（図１）は、コンテンツ暗号化鍵生成部１−１（図１）を有していたが、本実施例では有していない点のみである。

ビデオサーバ２４は、コンテンツ暗号化鍵生成部２４−１を有し、各種コンテンツのコンテンツ暗号化鍵を生成し、自己が有するメモリに格納し、鍵管理サーバ２１に対して、生成したコンテンツ暗号化鍵を送信するサーバである。又、自己が生成したコンテンツ暗号化鍵を用いて、該当するコンテンツを暗号化して各Ｐｌａｙｅｒ３に対してマルチキャスト配信するサーバである。実施例１との構成上の相違点は、実施例１のビデオサーバ４（図１）は、コンテンツ暗号化鍵生成部２４−１（図３）を有していないが、本実施例では有している点のみである。

図４は、実施例２の暗号化システムの動作説明図である。
この図は、上記図３を用いて説明した、Ｐｌａｙｅｒ３、認証サーバ２、ビデオサーバ２４、鍵管理サーバ２１を含むシステム全体の動作を、ステップＳ２−１からステップＳ２−１１までのシーケンスに分割して説明するための説明図である。以下に、その動作シーケンスについてステップ順に説明する。

ステップＳ２−１
ビデオサーバ２４（図３）は、コンテンツ暗号化鍵を生成する。この鍵の更新タイミングは、ビデオサーバ２４の起動時に設定される。

ステップＳ２−２
ビデオサーバ２４（図３）は、コンテンツ識別子と、対応するコンテンツ暗号化鍵とを鍵管理サーバ２１（図３）へ送信する。このときコンテンツ暗号化鍵に鍵の更新タイミングを含めて送信する。鍵管理サーバ２１（図３）はコンテンツ暗号化鍵をコンテンツ識別子と対応付けて、自己が有するメモリに格納する。

ステップＳ２−３
ビデオサーバ２４は、自己が生成したコンテンツ暗号化鍵を用いて暗号化マルチキャストストリームの配信を開始する。このときストリームの配信を行うＲＴＰパケット毎に暗号化に用いたコンテンツ暗号化鍵の識別番号を付加する。これは、Ｐｌａｙｅｒ３が、受信するＲＴＰパケット毎にどのコンテンツ暗号化鍵を用いて復号化すべきかを把握させるためである。又、ここでは、ビデオサーバ２４が用いる方式（暗号化の単位は配信パケットの単位で暗号化するのか、ＭＰＥＧの仕様に準拠して暗号化するのか等）、関数（共通鍵暗号を使うとして、ＡＥＳを使うのか、ＤＥＳを使うのか等）等については固定しない。即ち、システムに応じて異なる。

ステップＳ２−４
ユーザは、Ｐｌａｙｅｒ３を介して、視聴要求を認証サーバ２に対して行う。このとき認証サーバ２へ送信する情報の内容は、サービスの形態／ポリシーに依存して変化するが、一例として、ユーザＩＤ、パスワード、視聴を希望するコンテンツ、コンテンツの視聴期限などが含まれる。

ステップＳ２−５
認証サーバ２は、Ｐｌａｙｅｒ３から受入れた視聴要求と鍵管理サーバクライアントライブラリ２−１の内容とを照合し、その視聴要求が正しいものと認証できたときには、視聴要求してきたＰｌａｙｅｒ３のユーザＩＤと、コンテンツ識別子と、同コンテンツの視聴期限を含めて、鍵管理サーバ１へユーザ視聴要求しているＰｌａｙｅｒ３のユーザ情報として送信する（ユーザ情報キャッシュイン）。

ステップＳ２−６
鍵管理サーバ２１は、認証サーバ２からユーザ情報を受入れると、そのユーザ情報を自己が有するメモリに格納する。更に、Ｐｌａｙｅｒ３が直接鍵管理サーバ２１に対するコンテンツ暗号化鍵の取得要求を可能にするユーザ固有通信暗号化鍵、ユーザを確認するためのチケット、ユーザ固有ＭＡＣ鍵、等を設定し、自己が有するメモリに格納するとともに、鍵管理サーバ確認情報として認証サーバ２へ送信する。これらの鍵管理サーバ確認情報は各ユーザ毎に異なる。但し、既に、同一のユーザ情報が既に格納されている場合には、そのユーザ情報に上書きする。尚、ユーザ固有ＭＡＣ鍵は、サービスのポリシーに応じて決定される。

ステップＳ２−７
認証サーバ２は、鍵管理サーバ２１から鍵管理サーバ確認情報を受入れると、視聴要求したＰｌａｙｅｒ３へ転送する。

ステップＳ２−８
Ｐｌａｙｅｒ３は、鍵管理サーバ１から鍵管理サーバ確認情報を受入れると、自己のユーザＩＤと、視聴コンテンツの識別子と、受信した上記チケットとを含む、ユーザ固有ＭＡＣ鍵に基づくメッセージを生成し、ユーザ固有通信暗号化鍵で暗号化した暗号化鍵要求として鍵管理サーバ２１へ送信する。

ステップＳ２−９
鍵管理サーバ２１は、Ｐｌａｙｅｒ３から暗号化鍵要求を受入れると、ユーザ固有通信暗号化鍵を用いて復号化してユーザ固有ＭＡＣ鍵を用いて生成されたメッセージを取得し、自己の有するユーザ固有ＭＡＣ鍵を用いてデータが改竄されていないことを確認する。又、データの改竄が認められない場合には、そのメッセージからチケットを取得し、取得したチケットと自己が有するメモリに格納されているチケットと照合し、該当するユーザ情報（視聴コンテンツの識別子を含む）を確認する。更に、コンテンツの視聴期限が有効か否かを判定する。ここで、チケット同士の照合不可、又はデータ改竄可能性がある場合、チケットと照合不可の場合、コンテンツの視聴期限が無効の場合には、エラー通知をＰｌａｙｅｒ３に送信し、暗号化鍵要求を拒否する。

ステップＳ２−１０
鍵管理サーバ２１は、該当するユーザ情報を確認できた場合には、自己が有するメモリに格納されている、そのときの鍵更新タイミングに合致した（ユーザが要求している視聴コンテンツの識別子に対応する）コンテンツ暗号化鍵を読み出す。又、更新チケットを新規設定し、自己のメモリに格納されているチケットを新規設定した更新チケットで上書きする。次回の暗号化鍵要求の安全性を維持するためである。更に、更新チケットと、コンテンツ暗号化鍵を含む、ユーザ固有ＭＡＣ鍵を用いて生成したメッセージをユーザ固有通信暗号化鍵で暗号化した暗号化鍵をＰｌａｙｅｒ３へ送出する。

ステップＳ２−１１
Ｐｌａｙｅｒ３は、鍵管理サーバ１から受信した暗号化鍵を復号化し、ユーザ固有ＭＡＣ鍵を用いて生成したメッセージを取得する。Ｐｌａｙｅｒ３は、自己の有するユーザ固有ＭＡＣ鍵を用いて、鍵管理サーバ１から受信したメッセージが改竄されていないことを確認し、確認できたときはメッセージからコンテンツ暗号化鍵を取得し、このコンテンツ暗号化鍵に付加されている鍵更新タイミングの識別番号と、ビデオサーバからストリーム配信されてくるＲＴＰパケットに付加されてくる鍵更新タイミングの識別番号との一致を確認し、取得したコンテンツ暗号化鍵を用いてビデオサーバから受信した暗号化されたコンテンツの復号化を開始する。又、コンテンツ暗号化鍵の鍵更新タイミングの識別番号と、ＲＴＰパケットに付加されてくる鍵更新タイミングの識別番号とが不一致になったときには、Ｐｌａｙｅｒ３は、ステップＳ２−８以降を繰り返し、更新されたコンテンツ暗号化鍵を取得してコンテンツの復号化を継続する。このときに上記新規設定されたチケットが用いられることになる。以後同様にＰｌａｙｅｒ３は、ステップＳ２−８以降を繰り返しながらコンテンツの復号化を継続することになる。

図５は、実施例２の暗号化システムの鍵管理サーバ停止時の動作説明図である。
この図は、上記図３を用いて説明した、Ｐｌａｙｅｒ３、認証サーバ２、ビデオサーバ２４、鍵管理サーバ２１を含むシステム全体の動作シーケンスであって、特に鍵管理サーバ２１が何らかの理由によって停止した場合の動作をステップＳ２−１１からステップＳ２−２０までに分割して説明するための説明図である。以下に、その動作シーケンスについてステップ順に説明する。

ステップＳ２−１１
ビデオサーバ２４（図３）は、コンテンツ暗号化鍵を生成する。この鍵の更新タイミングは、ビデオサーバ２４の起動時に設定されている。

ステップＳ２−１２
ビデオサーバ２４（図３）は、コンテンツ識別子と、対応するコンテンツ暗号化鍵とを鍵管理サーバ２１（図３）へ送信する。鍵管理サーバ２１（図３）はコンテンツ暗号化鍵をコンテンツ識別子と対応付けて、自己が有するメモリに格納する。

ステップＳ２−１３
ビデオサーバ２４は、自己が生成したコンテンツ暗号化鍵を用いて暗号化マルチキャストストリームの配信を開始する。このときストリームの配信を行うＲＴＰパケット毎に暗号化に用いたコンテンツ暗号化鍵の識別番号を付加する。これは、Ｐｌａｙｅｒ３が、受信するＲＴＰパケット毎にどのコンテンツ暗号化鍵を用いて復号化すべきかを把握させるためである。又、ここでは、ビデオサーバ２４が用いる方式（暗号化の単位は配信パケットの単位で暗号化するのか、ＭＰＥＧの仕様に準拠して暗号化するのか等）、関数（共通鍵暗号を使うとして、ＡＥＳを使うのか、ＤＥＳを使うのか等）等については固定しない。即ち、システムに応じて異なる。

ステップＳ２−１４
鍵管理サーバ２１が何らかの理由によって動作を停止する。
ステップＳ２−１５
ビデオサーバ２４は、コンテンツ暗号化鍵の生成を続ける。

ステップＳ２−１６
ビデオサーバ２４は、生成したコンテンツ暗号化鍵を鍵管理サーバ２１へ送信するが、鍵管理サーバ２１が動作を停止しているので送信に失敗する。

ステップＳ２−１７
ビデオサーバ２４は、暗号化マルチキャストストリーム配信を継続する。
ステップＳ２−１８
鍵管理サーバ２１の動作が復旧する。

ステップＳ２−１９
ビデオサーバ２４は、生成したコンテンツ暗号化鍵を鍵管理サーバ２１へ送信すると、鍵管理サーバ２１の動作が復旧しているので送信に成功する。以下、通常の動作（図４）を継続する。

以上説明したように、本実施例では、ビデオサーバ２４が、自らコンテンツ暗号化鍵の生成を行うので、ビデオサーバ２４と鍵管理サーバ２１との間に何らかの障害、例え場通信切断が発生しても、ビデオサーバ２４は、暗号化マルチキャストストリーム配信を継続することが出来るという効果を得る。

以上の説明では、Ｐｌａｙｅｒはビデオサーバとは共通鍵方式を用いることとして説明したが、本発明はこの例に限定されるものでは無い。即ち、共通鍵方式に限らず他の方式を用いることも可能である。

実施例１の暗号化システムのシステム構成図である。 実施例１の暗号化システムの動作説明図である。 実施例２の暗号化システムのシステム構成図である。 実施例２の暗号化システムの動作説明図である。 実施例２の暗号化システムの鍵管理サーバ停止時の動作説明図である。

符号の説明

１ 鍵管理サーバ
１−１ コンテンツ暗号化鍵生成部
２ 認証サーバ
２−１ 鍵管理サーバクライアントライブラリ
３ Ｐｌａｙｅｒ
４ ビデオサーバ
１００ 暗号化システム

Claims (5)

1. マルチキャストストリーム配信を要求するストリーム受信装置を認証する認証サーバと、
   コンテンツを暗号化するコンテンツ暗号化鍵を生成・管理・運用し、前記コンテンツを暗号化してマルチキャストストリーム配信するビデオサーバの要求に基づいて、該当するコンテンツ暗号化鍵を返信すると共に、前記認証サーバが認証した前記ストリーム受信装置の要求に基づいて、該当するコンテンツ暗号化鍵を返信する鍵管理サーバとを備え、
   前記認証サーバは、前記ストリーム受信装置を操作するユーザのユーザ情報を前記鍵管理サーバに送信し、
   前記鍵管理サーバは、前記ユーザ情報を受けると、当該ユーザからの配信要求を可能にすべく、ユーザ固有通信暗号化鍵と、ユーザを確認するための第１チケットと、ユーザ固有のＭＡＣ鍵とを設定し、これらを鍵管理サーバ確認情報として前記認証サーバに送信し、
   認証サーバは、前記鍵管理サーバ確認情報を受けると、該情報を前記ストリーム受信装置に送信し、
   前記ストリーム受信装置は、前記鍵管理サーバ確認情報を受けると、自己のユーザＩＤと、視聴コンテンツの識別子と、前記第１チケットとを含む暗号化鍵要求情報を前記鍵管理サーバに送信し、
   前記鍵管理サーバは、前記暗号化鍵要求情報を受けると、該情報が改竄されているか否かを判定し、改竄されていない場合には、該暗号化鍵要求情報に含まれる前記第１チケットと、自己が有するメモリに格納されている前記設定した第１チケットとを照合して該当するユーザ情報を確認すると、前記ストリーム受信装置に対し当該ユーザが要求している視聴コンテンツに対応するコンテンツ暗号化鍵と、新たに新規設定した第２チケットとを送信し、
   前記ストリーム受信装置は、前記コンテンツ暗号化鍵と、前記第２チケットとが改竄されていないことを確認すると、該コンテンツ暗号化鍵を用いて前記視聴コンテンツを復号することを特徴とするマルチキャストストリーム配信における暗号化システム。
2. マルチキャストストリーム配信を要求するストリーム受信装置を認証する認証サーバと、
   コンテンツを暗号化するコンテンツ暗号化鍵を管理・運用し、前記認証サーバが認証した前記ストリーム受信装置の要求に基づいて、該当するコンテンツ暗号化鍵を返信する鍵管理サーバと、
   前記コンテンツ暗号化鍵を生成し、前記鍵管理サーバへ送信すると共に、生成した前記コンテンツ暗号化鍵を用いて暗号化した暗号化マルチキャストストリームを前記ストリーム受信装置へ配信するビデオサーバとを備え、
   前記認証サーバは、前記ストリーム受信装置を操作するユーザのユーザ情報を前記鍵管理サーバに送信し、
   前記鍵管理サーバは、前記ユーザ情報を受けると、当該ユーザからの配信要求を可能にすべく、ユーザ固有通信暗号化鍵と、ユーザを確認するための第１チケットと、ユーザ固有のＭＡＣ鍵とを設定し、これらを鍵管理サーバ確認情報として前記認証サーバに送信し、
   認証サーバは、前記鍵管理サーバ確認情報を受けると、該情報を前記ストリーム受信装置に送信し、
   前記ストリーム受信装置は、前記鍵管理サーバ確認情報を受けると、自己のユーザＩＤと、視聴コンテンツの識別子と、前記第１チケットとを含む暗号化鍵要求情報を前記鍵管理サーバに送信し、
   前記鍵管理サーバは、前記暗号化鍵要求情報を受けると、該情報が改竄されているか否かを判定し、改竄されていない場合には、該暗号化鍵要求情報に含まれる前記第１チケットと、自己が有するメモリに格納されている前記設定した第１チケットとを照合して該当するユーザ情報を確認すると、前記ストリーム受信装置に対し当該ユーザが要求している視聴コンテンツに対応するコンテンツ暗号化鍵と、新たに新規設定した第２チケットとを送信し、
   前記ストリーム受信装置は、前記コンテンツ暗号化鍵と、前記第２チケットとが改竄されていないことを確認すると、該コンテンツ暗号化鍵を用いて前記視聴コンテンツを復号することを特徴とするマルチキャストストリーム配信における暗号化システム。
3. 前記認証サーバは、予め格納する登録ユーザ情報と、前記マルチキャストストリーム配信を要求するストリーム受信装置より受信する受信ユーザ情報とを照合し、照合できたときに該ストリーム受信装置を認証することを特徴とする請求項１又は請求項２に記載の暗号化システム。
4. 前記鍵管理サーバは、
   前記認証サーバを介して該認証サーバに認証されたストリーム受信装置の認証ユーザ情報を受信して格納し、前記ストリーム受信装置へのコンテンツ暗号化鍵の直接送信を可能とするユーザ固有通信暗号化鍵を前記認証サーバを介して前記ストリーム受信装置へ送信することを特徴とする請求項１又は請求項２に記載の暗号化システム。
5. 前記鍵管理サーバは、
   更に、前記ストリーム受信装置の前記認証の確認に用いるチケット及び前記ストリーム受信装置との間におけるデータ通信の改竄防止に用いるユーザ固有のＭＡＣ鍵とを設定し、前記認証サーバを介して前記ストリーム受信装置へ送信することを特徴とする請求項４に記載の暗号化システム。

Images