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

暗号化システム Download PDF

Info

Publication number
JP4760385B2
JP4760385B2 JP2006003823A JP2006003823A JP4760385B2 JP 4760385 B2 JP4760385 B2 JP 4760385B2 JP 2006003823 A JP2006003823 A JP 2006003823A JP 2006003823 A JP2006003823 A JP 2006003823A JP 4760385 B2 JP4760385 B2 JP 4760385B2
Authority
JP
Japan
Prior art keywords
key
user
management server
content
key management
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2006003823A
Other languages
English (en)
Other versions
JP2007189325A (ja
Inventor
雅史 佐藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Oki Electric Industry Co Ltd
Original Assignee
Oki Electric Industry Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Oki Electric Industry Co Ltd filed Critical Oki Electric Industry Co Ltd
Priority to JP2006003823A priority Critical patent/JP4760385B2/ja
Publication of JP2007189325A publication Critical patent/JP2007189325A/ja
Application granted granted Critical
Publication of JP4760385B2 publication Critical patent/JP4760385B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Description

本発明は、ストリーム配信に関し、特にIPマルチキャストストリーム配信時における鍵管理、及び暗号化システムに関する。
近年、ネットワークインフラの整備に伴って、映像コンテンツをマルチキャストで配信する方式が普及しつつある。この方式では、ユーザの視聴権の有無に関らずビデオサーバから映像コンテンツの配信が継続されるため、視聴権の無くなった人による継続視聴を排除する必要がある。そこで、暗号化サーバが、暗号化鍵(Kcn)で映像コンテンツを暗号化して暗号化コンテンツを生成し、各ユーザへ配信し、更に、この暗号化鍵(Kcn)を所定の時間間隔で変更させている。この暗号化鍵(Kcn)は、他の暗号化鍵(Kph)で暗号化され、暗号化鍵データとして、上記暗号化コンテンツと共に各ユーザへ配信されていた。各ユーザは、システム内に独立して配置されている鍵管理サーバから各々個別に上記暗号化鍵(Kph)を受入れて暗号化鍵データから暗号化鍵(Kcn)を取得し、この暗号化鍵(Kcn)を用いて上記暗号化コンテンツを復号化していた。
各ユーザ毎の視聴権の有無は、各ユーザに対する鍵管理サーバからの上記暗号化鍵(Kph)の送信によって制限されている。又、セキュリティ確保のために、鍵管理サーバは、上記暗号化鍵(Kph)の送信を要求する各ユーザを所定の方式に基づいて認証することとしていた。この認証を行うために、更に、適切なタイミングで暗号化鍵の更新を行うために、鍵管理サーバは、ユーザの視聴中/ビデオサーバの配信中、定期的に各ユーザ(Player)と通信を行っていた。
特開2003−174441号公報 Internet Draft IETF MSEC WG Mark Baugher、 Ran Canetti、 Lakshminath Dondeti、 Fredrik Lindholm、 February 28、 2002
しかしながら、上記従来の技術では、鍵管理サーバが、本来の任務であるRe−keyプロトコルを実行する他に、レジストレーションプロトコルまで実行していたため鍵管理サーバの汎用性が失われていた(解決すべき課題1)。更に、上記従来の技術では、鍵管理サーバが、コンテンツ暗号化鍵を生成していたため、何らかの障害、例えば鍵管理サーバとビデオサーバ間での通信障害などの発生によってビデオサーバがコンテンツ暗号化鍵の取得が不可能になり、ビデオサーバの配信が停止してしまうことになった(解決すべき課題2)。ここで、Re−keyプロトコルとは、ユーザの視聴中/ビデオサーバの配信中に、鍵管理サーバと各ユーザ(Player)とが暗号化鍵の更新を行うために通信を行うことであり、レジストレーションプロトコルとは、ユーザの視聴要求/ビデオサーバの配信開始をシステム側が認証することである。
本発明は、マルチキャストストリーム配信を要求するストリーム受信装置を認証する認証サーバと、コンテンツを暗号化するコンテンツ暗号化鍵を生成・管理・運用し、コンテンツを暗号化してマルチキャストストリーム配信するビデオサーバの要求に基づいて、該当するコンテンツ暗号化鍵を返信すると共に、認証サーバが認証したストリーム受信装置の要求に基づいて、該当するコンテンツ暗号化鍵を返信する鍵管理サーバとを備え、認証サーバは、ストリーム受信装置を操作するユーザのユーザ情報を鍵管理サーバに送信し、鍵管理サーバは、ユーザ情報を受けると、当該ユーザからの配信要求を可能にすべく、ユーザ固有通信暗号化鍵と、ユーザを確認するための第1チケットと、ユーザ固有のMAC鍵とを設定し、これらを鍵管理サーバ確認情報として認証サーバに送信し、認証サーバは、鍵管理サーバ確認情報を受けると、該情報をストリーム受信装置に送信し、ストリーム受信装置は、鍵管理サーバ確認情報を受けると、自己のユーザIDと、視聴コンテンツの識別子と、第1チケットとを含む暗号化鍵要求情報を鍵管理サーバに送信し、鍵管理サーバは、暗号化鍵要求情報を受けると、該情報が改竄されているか否かを判定し、改竄されていない場合には、該暗号化鍵要求情報に含まれる第1チケットと、自己が有するメモリに格納されている設定した第1チケットとを照合して該当するユーザ情報を確認すると、ストリーム受信装置に対し当該ユーザが要求している視聴コンテンツに対応するコンテンツ暗号化鍵と、新たに新規設定した第2チケットとを送信し、ストリーム受信装置は、コンテンツ暗号化鍵と、第2チケットとが改竄されていないことを確認すると、該コンテンツ暗号化鍵を用いて視聴コンテンツを復号することを主要な特徴とする。
ユーザの登録、認証、コンテンツ情報の管理、というサービス毎に異なる部分を鍵管理サーバから切り離して、認証サーバに分担処理させることとしたので、鍵管理サーバがRe―keyプロトコルに専念できるようになる。その結果鍵管理サーバの汎用性が高まるという効果を得る。
ユーザの登録、認証、コンテンツ情報の管理等、サービス毎に異なる部分を鍵管理サーバから切り離して分担処理させるための認証サーバを配置し、鍵管理サーバに対してRe―keyプロトコルに専念させる。更に、ビデオサーバと鍵管理サーバとの間に何らかの通信障害が発生しても、ビデオサーバの配信が停止するのを排除するため、コンテンツ暗号化鍵の生成をビデオサーバが実行し、生成したコンテンツ暗号化鍵を鍵管理サーバへ送信することとする。
本実施例による暗号化システムは、上記、解決すべき課題1に対応すべく、ユーザの登録、認証、コンテンツ情報の管理、というサービス毎に異なる部分を鍵管理サーバから切り離して、認証サーバに分担処理させ、鍵管理サーバに対してRe―keyプロトコルに専念させる。かかる目的を達成するために本実施例は、以下のように構成される。
図1は、実施例1の暗号化システムのシステム構成図である。
図に示すように、実施例1の暗号化システム100は、鍵管理サーバ1と、認証サーバ2と、Player3と、ビデオサーバ4とを含む。
鍵管理サーバ1は、コンテンツ暗号化鍵生成部1−1を有し、各種コンテンツのコンテンツ暗号化鍵を生成し、自己が有するメモリに格納し、ビデオサーバ4からコンテンツ識別子を含めた、暗号化鍵の取得要求を受入れると、含まれているコンテンツに対応するコンテンツ暗号化鍵をビデオサーバ4へ送信するサーバである。又、認証サーバ2からPlayer3のユーザID(Player3を一意に特定する一定長の文字列)、コンテンツ識別子(そのユーザが視聴出来るコンテンツを一意に特定する一定長の文字列)、同コンテンツの視聴期限を含むユーザ情報を受入れると、そのユーザ情報を自己が有するメモリに格納し、Player3が直接、鍵管理サーバ1へコンテンツ暗号化鍵の取得要求を実施することを可能にするユーザ固有通信暗号化鍵、ユーザを確認するためのチケット、ユーザ固有MAC鍵等を含む鍵管理サーバ確認情報を、それぞれ設定して認証サーバ2へ送信するサーバでもある。
更に、Player3から鍵管理サーバ確認情報に基づいて構成された暗号化鍵要求を受入れると、該当するユーザ情報を確認し、確認出来ると、該当するコンテンツ暗号化鍵をPlayer3へ送出するサーバである。ここでチケットとは、ユーザを確認するための一定長の擬似乱数ビット列である。又、ユーザ固有MAC鍵とは、送信されたメッセージが改竄されていないことや、本人が送信したものであることを確認するために使うメッセージ・ダイジェストである。
認証サーバ2は、鍵管理サーバクライアントライブラリ2−1を有し、ユーザ情報(ユーザID、パスワード、視聴出来るコンテンツ、及びその視聴期間)を登録ユーザ情報として予め登録しておき、Player3を認証するサーバである。即ち、Player3からユーザのパスワード、ユーザが視聴出来るコンテンツ、等を含む視聴要求を受入れると、鍵管理サーバクライアントライブラリ2−1に予め登録されている登録ユーザ情報に基づいて認証処理を実行するサーバである。ここで、その視聴要求が正しいものと認証できたときには、視聴要求してきたPlayer3のユーザIDと、コンテンツ識別子と、同コンテンツの視聴期限を含めて、鍵管理サーバ1へPlayer3のユーザ情報(視聴要求)として送信するサーバである。又、鍵管理サーバ1からユーザ固有通信暗号化鍵と、チケットと、ユーザ固有MAC鍵とを、鍵管理サーバへのアクセス情報として受信すると、この鍵管理サーバへのアクセス情報とコンテンツ識別子とを、視聴要求してきたPlayer3へ転送するサーバでもある。ここでコンテンツ識別子とは、コンテンツを一意に特定する一定長の文字列である。
Player3は、ビデオサーバから暗号化されたコンテンツを受信する装置である。但し、図では説明の都合上1台のみ記載してあるが、実際には多数台配置されている。更に、認証サーバ2に対してユーザのパスワード、ユーザが視聴を希望するコンテンツ、等を含む視聴要求を実行し、認証サーバ2から受信したユーザ固有通信暗号化鍵を用いて鍵管理サーバ1に対してコンテンツ暗号化鍵を直接要求し、鍵管理サーバ1からコンテンツ暗号化鍵を取得し、そのコンテンツ暗号化鍵を用いて、ビデオサーバから受信した暗号化されたコンテンツを復号化する装置である。
ビデオサーバ4は、鍵管理サーバ1に対して、(自己が配信しようとしているコンテンツの)コンテンツ識別子を含めた、コンテンツ暗号化鍵の取得要求を送信し、鍵管理サーバ1から、(要求した)コンテンツ暗号化鍵を取得し、該当するコンテンツを暗号化して各Player3に対してマルチキャスト配信するサーバである。
図2は、実施例1の暗号化システムの動作説明図である。
この図は、上記図1を用いて説明した、Player3、認証サーバ2、ビデオサーバ4、鍵管理サーバ1を含むシステム全体の動作を、ステップS1−1からステップS1−11までのシーケンスに分割して説明するための説明図である。以下に、その動作シーケンスについてステップ順に説明する。
ステップS1−1
ビデオサーバ4は、コンテンツ配信前に鍵管理サーバ1に対して(自己が配信しようとしているコンテンツの)コンテンツ識別子を含めた、コンテンツ暗号化鍵の取得要求を送信する。
ステップS1−2
鍵管理サーバ1は、ビデオサーバ4からコンテンツ暗号化鍵の取得要求を受信すると、自己が有するメモリに格納されているコンテンツ情報を検索し、ビデオサーバ4が要求しているコンテンツを検索できたときには上記取得要求に対応するコンテンツ暗号化鍵をビデオサーバ4へ送信する。このときコンテンツ暗号化鍵に鍵の更新タイミングを含めて送信する。この鍵の更新タイミングは、鍵管理サーバ1の起動時に設定されている。尚、鍵管理サーバ1は、ビデオサーバ4が要求しているコンテンツを検索できなかったときにはビデオサーバ4へエラー通知を送信して再度取得要求させる。
ステップS1−3
ビデオサーバ4は、鍵管理サーバ1から取得したコンテンツ暗号化鍵を用いて暗号化マルチキャストストリームの配信を開始する。このときストリームの配信を行うRTPパケット毎に暗号化に用いたコンテンツ暗号化鍵の識別番号を付加する。これは、Player3が、受信するRTPパケット毎にどのコンテンツ暗号化鍵を用いて復号化すべきかを把握させるためである。又、ここでは、ビデオサーバ4が用いる方式(暗号化の単位は配信パケットの単位で暗号化するのか、MPEGの仕様に準拠して暗号化するのか等)、関数(共通鍵暗号を使うとして、AESを使うのか、DESを使うのか等)等については固定しない。即ち、システムに応じて異なる。
ステップS1−4
ユーザは、Player3を介して、視聴要求を認証サーバ2に対して行う。このとき認証サーバ2へ送信する情報の内容には、サービスの形態/ポリシーに依存して変化するが、一例として、ユーザID、パスワード、視聴を希望するコンテンツ、コンテンツの視聴期限などが含まれる。
ステップS1−5
認証サーバ2は、Player3から受入れた視聴要求と鍵管理サーバクライアントライブラリ2−1の内容とを照合し、その視聴要求が正しいものと認証できたときには、視聴要求してきたPlayer3のユーザIDと、コンテンツ識別子と、同コンテンツの視聴期限を含めて、鍵管理サーバ1へユーザ視聴要求しているPlayer3のユーザ情報として送信する(ユーザ情報キャッシュイン)。
ステップS1−6
鍵管理サーバ1は、認証サーバ2からユーザ情報を受入れると、そのユーザ情報を自己が有するメモリに格納する。更に、Player3が直接鍵管理サーバ1に対するコンテンツ暗号化鍵の取得要求を可能にするユーザ固有通信暗号化鍵、ユーザを確認するためのチケット、ユーザ固有MAC鍵等を設定し、自己が有するメモリに格納するとともに、鍵管理サーバ確認情報として認証サーバ2へ送信する。これらの鍵管理サーバ確認情報は各ユーザ毎に異なる。但し、既に、同一のユーザ情報が既に格納されている場合には、そのユーザ情報に上書きする。尚、ユーザ固有MAC鍵は、サービスのポリシーに応じて決定される。
ステップS1−7
認証サーバ2は、鍵管理サーバ1から鍵管理サーバ確認情報を受入れると、視聴要求したPlayer3へ転送する。
ステップS1−8
Player3は、鍵管理サーバ1から鍵管理サーバ確認情報を受入れると、自己のユーザIDと、視聴コンテンツの識別子と、受信した上記チケットとを含む、ユーザ固有MAC鍵に基づくメッセージを生成し、ユーザ固有通信暗号化鍵で暗号化した暗号化鍵要求として鍵管理サーバ1へ送信する。
ステップS1−9
鍵管理サーバ1は、Player3から暗号化鍵要求を受入れると、ユーザ固有通信暗号化鍵を用いて復号化してユーザ固有MAC鍵を用いて生成されたメッセージを取得し、自己の有するユーザ固有MAC鍵を用いてデータが改竄されていないことを確認する。又、データの改竄が認められない場合には、そのメッセージからチケットを取得し、取得したチケットと自己が有するメモリに格納されているチケットと照合し、該当するユーザ情報(視聴コンテンツの識別子を含む)を確認する。更に、コンテンツの視聴期限が有効か否かを判定する。ここで、チケット同士の照合不可、又はデータ改竄可能性がある場合、チケットと照合不可の場合、コンテンツの視聴期限が無効の場合には、エラー通知をPlayer3に送信し、暗号化鍵要求を拒否する。
ステップS1−10
鍵管理サーバ1は、該当するユーザ情報を確認できた場合には、自己が有するメモリに格納されている、そのときの鍵更新タイミングに合致した(ユーザが要求している視聴コンテンツの識別子に対応する)コンテンツ暗号化鍵を読み出す。又、更新チケットを新規設定し、自己のメモリに格納されているチケットを新規設定した更新チケットで上書きする。次回の暗号化鍵要求の安全性を維持するためである。更に、更新チケットと、コンテンツ暗号化鍵を含むユーザ固有MAC鍵を用いて生成したメッセージをユーザ固有通信暗号化鍵で暗号化した暗号化鍵をPlayer3へ送出する。
ステップS1−11
Player3は、鍵管理サーバ1から受信した暗号化された暗号化鍵を復号化し、ユーザ固有MAC鍵を用いて生成したメッセージを取得する。Player3は、自己の有するユーザ固有MAC鍵を用いて、鍵管理サーバ1から受信したメッセージが改竄されていないことを確認し、確認できたときはメッセージからコンテンツ暗号化鍵を取得し、このコンテンツ暗号化鍵に付加されている鍵更新タイミングの識別番号と、ビデオサーバからストリーム配信されてくるRTPパケットに付加されてくる鍵更新タイミングの識別番号との一致を確認し、取得したコンテンツ暗号化鍵を用いてビデオサーバから受信した暗号化されたコンテンツの復号化を開始する。又、コンテンツ暗号化鍵の鍵更新タイミングの識別番号と、RTPパケットに付加されてくる鍵更新タイミングの識別番号とが不一致になったときには、Player3は、ステップS1−8以降を繰り返し、更新されたコンテンツ暗号化鍵を取得してコンテンツの復号化を継続する。このときに上記新規設定されたチケットが用いられることになる。以後同様にPlayer3は、ステップS1−8以降を繰り返しながらコンテンツの復号化を継続することになる。
以上説明したようにユーザの登録、認証、コンテンツ情報の管理、というサービス毎に異なる部分を鍵管理サーバから切り離して認証サーバに分担処理させることとしたので、鍵管理サーバがRe―keyプロトコルに専念できるようになる。その結果鍵管理サーバの汎用性が高まるという効果を得る。
本実施例による暗号化システムは、上記、解決すべき課題2に対応すべく、コンテンツ暗号化鍵の生成をビデオサーバが実行し、生成したコンテンツ暗号化鍵を鍵管理サーバへ送信することとし、何らかの障害があっても、ビデオサーバの配信が停止するのを排除することを目的として本実施例は以下のように構成される。
図3は、実施例2の暗号化システムのシステム構成図である。
図に示すように、実施例2の暗号化システム200は、鍵管理サーバ21と、認証サーバ2と、Player3と、ビデオサーバ24とを含む。以下に実施例1との相違部分のみについて説明する。実施例1と同様の部分については実施例1と同一の符号を付して説明を省略する。
鍵管理サーバ21は、各種コンテンツのコンテンツ暗号化鍵をビデオサーバ24から受信し、自己が有するメモリに格納し、認証サーバ2からPlayer3のユーザID(Player3を一意に特定する一定長の文字列)、コンテンツ識別子(そのユーザが視聴出来るコンテンツを一意に特定する一定長の文字列)、同コンテンツの視聴期限を含むユーザ情報を受入れると、そのユーザ情報を自己が有するメモリに格納し、Player3が直接、鍵管理サーバ1へコンテンツ暗号化鍵の取得要求を実施することを可能にするユーザ固有通信暗号化鍵、ユーザを確認するためのチケット、ユーザ固有MAC鍵等を設定し、鍵管理サーバ確認情報として認証サーバ2へ送信するサーバでもある。
更に、Player3から鍵管理サーバ確認情報に基づいて構成された暗号化鍵要求を受入れると、該当するユーザ情報を確認し、確認出来ると該当するコンテンツ暗号化鍵をPlayer3へ送出するサーバである。ここでチケットとは、ユーザを確認するための一定長の擬似乱数ビット列である。又、ユーザ固有MAC鍵とは、送信されたメッセージが改竄されていないことや、本人が送信したものであることを確認するために使うメッセージ・ダイジェストである。実施例1との構成上の相違点は、実施例1の鍵管理サーバ1(図1)は、コンテンツ暗号化鍵生成部1−1(図1)を有していたが、本実施例では有していない点のみである。
ビデオサーバ24は、コンテンツ暗号化鍵生成部24−1を有し、各種コンテンツのコンテンツ暗号化鍵を生成し、自己が有するメモリに格納し、鍵管理サーバ21に対して、生成したコンテンツ暗号化鍵を送信するサーバである。又、自己が生成したコンテンツ暗号化鍵を用いて、該当するコンテンツを暗号化して各Player3に対してマルチキャスト配信するサーバである。実施例1との構成上の相違点は、実施例1のビデオサーバ4(図1)は、コンテンツ暗号化鍵生成部24−1(図3)を有していないが、本実施例では有している点のみである。
図4は、実施例2の暗号化システムの動作説明図である。
この図は、上記図3を用いて説明した、Player3、認証サーバ2、ビデオサーバ24、鍵管理サーバ21を含むシステム全体の動作を、ステップS2−1からステップS2−11までのシーケンスに分割して説明するための説明図である。以下に、その動作シーケンスについてステップ順に説明する。
ステップS2−1
ビデオサーバ24(図3)は、コンテンツ暗号化鍵を生成する。この鍵の更新タイミングは、ビデオサーバ24の起動時に設定される。
ステップS2−2
ビデオサーバ24(図3)は、コンテンツ識別子と、対応するコンテンツ暗号化鍵とを鍵管理サーバ21(図3)へ送信する。このときコンテンツ暗号化鍵に鍵の更新タイミングを含めて送信する。鍵管理サーバ21(図3)はコンテンツ暗号化鍵をコンテンツ識別子と対応付けて、自己が有するメモリに格納する。
ステップS2−3
ビデオサーバ24は、自己が生成したコンテンツ暗号化鍵を用いて暗号化マルチキャストストリームの配信を開始する。このときストリームの配信を行うRTPパケット毎に暗号化に用いたコンテンツ暗号化鍵の識別番号を付加する。これは、Player3が、受信するRTPパケット毎にどのコンテンツ暗号化鍵を用いて復号化すべきかを把握させるためである。又、ここでは、ビデオサーバ24が用いる方式(暗号化の単位は配信パケットの単位で暗号化するのか、MPEGの仕様に準拠して暗号化するのか等)、関数(共通鍵暗号を使うとして、AESを使うのか、DESを使うのか等)等については固定しない。即ち、システムに応じて異なる。
ステップS2−4
ユーザは、Player3を介して、視聴要求を認証サーバ2に対して行う。このとき認証サーバ2へ送信する情報の内容は、サービスの形態/ポリシーに依存して変化するが、一例として、ユーザID、パスワード、視聴を希望するコンテンツ、コンテンツの視聴期限などが含まれる。
ステップS2−5
認証サーバ2は、Player3から受入れた視聴要求と鍵管理サーバクライアントライブラリ2−1の内容とを照合し、その視聴要求が正しいものと認証できたときには、視聴要求してきたPlayer3のユーザIDと、コンテンツ識別子と、同コンテンツの視聴期限を含めて、鍵管理サーバ1へユーザ視聴要求しているPlayer3のユーザ情報として送信する(ユーザ情報キャッシュイン)。
ステップS2−6
鍵管理サーバ21は、認証サーバ2からユーザ情報を受入れると、そのユーザ情報を自己が有するメモリに格納する。更に、Player3が直接鍵管理サーバ21に対するコンテンツ暗号化鍵の取得要求を可能にするユーザ固有通信暗号化鍵、ユーザを確認するためのチケット、ユーザ固有MAC鍵、等を設定し、自己が有するメモリに格納するとともに、鍵管理サーバ確認情報として認証サーバ2へ送信する。これらの鍵管理サーバ確認情報は各ユーザ毎に異なる。但し、既に、同一のユーザ情報が既に格納されている場合には、そのユーザ情報に上書きする。尚、ユーザ固有MAC鍵は、サービスのポリシーに応じて決定される。
ステップS2−7
認証サーバ2は、鍵管理サーバ21から鍵管理サーバ確認情報を受入れると、視聴要求したPlayer3へ転送する。
ステップS2−8
Player3は、鍵管理サーバ1から鍵管理サーバ確認情報を受入れると、自己のユーザIDと、視聴コンテンツの識別子と、受信した上記チケットとを含む、ユーザ固有MAC鍵に基づくメッセージを生成し、ユーザ固有通信暗号化鍵で暗号化した暗号化鍵要求として鍵管理サーバ21へ送信する。
ステップS2−9
鍵管理サーバ21は、Player3から暗号化鍵要求を受入れると、ユーザ固有通信暗号化鍵を用いて復号化してユーザ固有MAC鍵を用いて生成されたメッセージを取得し、自己の有するユーザ固有MAC鍵を用いてデータが改竄されていないことを確認する。又、データの改竄が認められない場合には、そのメッセージからチケットを取得し、取得したチケットと自己が有するメモリに格納されているチケットと照合し、該当するユーザ情報(視聴コンテンツの識別子を含む)を確認する。更に、コンテンツの視聴期限が有効か否かを判定する。ここで、チケット同士の照合不可、又はデータ改竄可能性がある場合、チケットと照合不可の場合、コンテンツの視聴期限が無効の場合には、エラー通知をPlayer3に送信し、暗号化鍵要求を拒否する。
ステップS2−10
鍵管理サーバ21は、該当するユーザ情報を確認できた場合には、自己が有するメモリに格納されている、そのときの鍵更新タイミングに合致した(ユーザが要求している視聴コンテンツの識別子に対応する)コンテンツ暗号化鍵を読み出す。又、更新チケットを新規設定し、自己のメモリに格納されているチケットを新規設定した更新チケットで上書きする。次回の暗号化鍵要求の安全性を維持するためである。更に、更新チケットと、コンテンツ暗号化鍵を含む、ユーザ固有MAC鍵を用いて生成したメッセージをユーザ固有通信暗号化鍵で暗号化した暗号化鍵をPlayer3へ送出する。
ステップS2−11
Player3は、鍵管理サーバ1から受信した暗号化鍵を復号化し、ユーザ固有MAC鍵を用いて生成したメッセージを取得する。Player3は、自己の有するユーザ固有MAC鍵を用いて、鍵管理サーバ1から受信したメッセージが改竄されていないことを確認し、確認できたときはメッセージからコンテンツ暗号化鍵を取得し、このコンテンツ暗号化鍵に付加されている鍵更新タイミングの識別番号と、ビデオサーバからストリーム配信されてくるRTPパケットに付加されてくる鍵更新タイミングの識別番号との一致を確認し、取得したコンテンツ暗号化鍵を用いてビデオサーバから受信した暗号化されたコンテンツの復号化を開始する。又、コンテンツ暗号化鍵の鍵更新タイミングの識別番号と、RTPパケットに付加されてくる鍵更新タイミングの識別番号とが不一致になったときには、Player3は、ステップS2−8以降を繰り返し、更新されたコンテンツ暗号化鍵を取得してコンテンツの復号化を継続する。このときに上記新規設定されたチケットが用いられることになる。以後同様にPlayer3は、ステップS2−8以降を繰り返しながらコンテンツの復号化を継続することになる。
図5は、実施例2の暗号化システムの鍵管理サーバ停止時の動作説明図である。
この図は、上記図3を用いて説明した、Player3、認証サーバ2、ビデオサーバ24、鍵管理サーバ21を含むシステム全体の動作シーケンスであって、特に鍵管理サーバ21が何らかの理由によって停止した場合の動作をステップS2−11からステップS2−20までに分割して説明するための説明図である。以下に、その動作シーケンスについてステップ順に説明する。
ステップS2−11
ビデオサーバ24(図3)は、コンテンツ暗号化鍵を生成する。この鍵の更新タイミングは、ビデオサーバ24の起動時に設定されている。
ステップS2−12
ビデオサーバ24(図3)は、コンテンツ識別子と、対応するコンテンツ暗号化鍵とを鍵管理サーバ21(図3)へ送信する。鍵管理サーバ21(図3)はコンテンツ暗号化鍵をコンテンツ識別子と対応付けて、自己が有するメモリに格納する。
ステップS2−13
ビデオサーバ24は、自己が生成したコンテンツ暗号化鍵を用いて暗号化マルチキャストストリームの配信を開始する。このときストリームの配信を行うRTPパケット毎に暗号化に用いたコンテンツ暗号化鍵の識別番号を付加する。これは、Player3が、受信するRTPパケット毎にどのコンテンツ暗号化鍵を用いて復号化すべきかを把握させるためである。又、ここでは、ビデオサーバ24が用いる方式(暗号化の単位は配信パケットの単位で暗号化するのか、MPEGの仕様に準拠して暗号化するのか等)、関数(共通鍵暗号を使うとして、AESを使うのか、DESを使うのか等)等については固定しない。即ち、システムに応じて異なる。
ステップS2−14
鍵管理サーバ21が何らかの理由によって動作を停止する。
ステップS2−15
ビデオサーバ24は、コンテンツ暗号化鍵の生成を続ける。
ステップS2−16
ビデオサーバ24は、生成したコンテンツ暗号化鍵を鍵管理サーバ21へ送信するが、鍵管理サーバ21が動作を停止しているので送信に失敗する。
ステップS2−17
ビデオサーバ24は、暗号化マルチキャストストリーム配信を継続する。
ステップS2−18
鍵管理サーバ21の動作が復旧する。
ステップS2−19
ビデオサーバ24は、生成したコンテンツ暗号化鍵を鍵管理サーバ21へ送信すると、鍵管理サーバ21の動作が復旧しているので送信に成功する。以下、通常の動作(図4)を継続する。
以上説明したように、本実施例では、ビデオサーバ24が、自らコンテンツ暗号化鍵の生成を行うので、ビデオサーバ24と鍵管理サーバ21との間に何らかの障害、例え場通信切断が発生しても、ビデオサーバ24は、暗号化マルチキャストストリーム配信を継続することが出来るという効果を得る。
以上の説明では、Playerはビデオサーバとは共通鍵方式を用いることとして説明したが、本発明はこの例に限定されるものでは無い。即ち、共通鍵方式に限らず他の方式を用いることも可能である。
実施例1の暗号化システムのシステム構成図である。 実施例1の暗号化システムの動作説明図である。 実施例2の暗号化システムのシステム構成図である。 実施例2の暗号化システムの動作説明図である。 実施例2の暗号化システムの鍵管理サーバ停止時の動作説明図である。
符号の説明
1 鍵管理サーバ
1−1 コンテンツ暗号化鍵生成部
2 認証サーバ
2−1 鍵管理サーバクライアントライブラリ
3 Player
4 ビデオサーバ
100 暗号化システム

Claims (5)

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

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2006003823A JP4760385B2 (ja) 2006-01-11 2006-01-11 暗号化システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2006003823A JP4760385B2 (ja) 2006-01-11 2006-01-11 暗号化システム

Publications (2)

Publication Number Publication Date
JP2007189325A JP2007189325A (ja) 2007-07-26
JP4760385B2 true JP4760385B2 (ja) 2011-08-31

Family

ID=38344213

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006003823A Expired - Fee Related JP4760385B2 (ja) 2006-01-11 2006-01-11 暗号化システム

Country Status (1)

Country Link
JP (1) JP4760385B2 (ja)

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002252607A (ja) * 2000-12-22 2002-09-06 Nippon Telegr & Teleph Corp <Ntt> 情報配送方法及びその実施装置並びにその処理プログラムと記録媒体
US6993652B2 (en) * 2001-10-05 2006-01-31 General Instrument Corporation Method and system for providing client privacy when requesting content from a public server
JP2004078538A (ja) * 2002-08-16 2004-03-11 Phoenix Technologies Kk デジタルデータ保護システム
JP4080283B2 (ja) * 2002-09-13 2008-04-23 日本放送協会 コンテンツ配信システム
US7783044B2 (en) * 2003-02-20 2010-08-24 Proofpoint, Inc. System for on-line and off-line decryption
JP4377619B2 (ja) * 2003-06-27 2009-12-02 日本放送協会 コンテンツ配信サーバ及びそのプログラム、ライセンス発行サーバ及びそのプログラム、コンテンツ復号端末及びそのプログラム、並びに、コンテンツ配信方法及びコンテンツ復号方法
JP4076957B2 (ja) * 2004-01-26 2008-04-16 Kddi株式会社 コンテンツ配信システム及びコンテンツ配信方法
JP4587688B2 (ja) * 2004-03-26 2010-11-24 東芝Itサービス株式会社 暗号鍵管理サーバ、暗号鍵管理プログラム、暗号鍵取得端末、暗号鍵取得プログラム、暗号鍵管理システム及び暗号鍵管理方法
JP4543881B2 (ja) * 2004-10-28 2010-09-15 富士通株式会社 コンテンツ再生方法、再生プログラム、および再生装置

Also Published As

Publication number Publication date
JP2007189325A (ja) 2007-07-26

Similar Documents

Publication Publication Date Title
US6993652B2 (en) Method and system for providing client privacy when requesting content from a public server
CN1701561B (zh) 基于地址的验证系统及其装置和程序
CN100546244C (zh) 因特网上用于安全内容递送的密钥管理协议与认证系统
EP1486025B1 (en) System and method for providing key management protocol with client verification of authorization
JP4617763B2 (ja) 機器認証システム、機器認証サーバ、端末機器、機器認証方法、および機器認証プログラム
KR100664312B1 (ko) 홈 네트워크 환경에서 홈 디바이스 인증 방법 및 장치
US20030204716A1 (en) System and methods for digital content distribution
JP6471112B2 (ja) 通信システム、端末装置、通信方法、及びプログラム
KR100735221B1 (ko) 컨텐츠를 다수의 단말기에서 재생할 수 있도록 하는 컨텐츠재생 방법 및 이를 이용한 시스템과 단말 장치
US20080010207A1 (en) Information delivery system, node device, method to issue unrestricted data, and the like
US20060047960A1 (en) Session control server, communication system
KR101452708B1 (ko) Ce 장치 관리 서버, ce 장치 관리 서버를 이용한drm 키 발급 방법, 및 그 방법을 실행하기 위한프로그램 기록매체
KR100981568B1 (ko) 서비스 제공자와 다수의 단말기 간에 브로드캐스트 서비스를 지원하는 컨텐츠 보호 방법 및 장치
IL189131A (en) Distributed single sign-on service
EP2856729B1 (en) A scalable authentication system
JP3362780B2 (ja) 通信システムにおける認証方法、センタ装置、認証プログラムを記録した記録媒体
CN111080299B (zh) 一种交易信息的防抵赖方法及客户端、服务器
US20100299521A1 (en) Key management system, key management method, server apparatus and program
JP3914193B2 (ja) 認証を得て暗号通信を行う方法、認証システムおよび方法
JP4760385B2 (ja) 暗号化システム
CN102236753A (zh) 版权管理方法及系统
CN112035820B (zh) 一种用于Kerberos加密环境下的数据解析方法
JP2007074745A (ja) 認証を得て暗号通信を行う方法、認証システムおよび方法
JP2006129143A (ja) 秘密情報送受信システム及び方法、サーバー装置及びプログラム、並びに鍵情報保持装置
JP2009094592A (ja) 通信システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20081121

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110215

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110418

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20110510

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20110523

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140617

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

LAPS Cancellation because of no payment of annual fees