JP5400395B2 - データ配信システム、鍵管理装置および鍵管理方法 - Google Patents

データ配信システム、鍵管理装置および鍵管理方法 Download PDF

Info

Publication number
JP5400395B2
JP5400395B2 JP2009001589A JP2009001589A JP5400395B2 JP 5400395 B2 JP5400395 B2 JP 5400395B2 JP 2009001589 A JP2009001589 A JP 2009001589A JP 2009001589 A JP2009001589 A JP 2009001589A JP 5400395 B2 JP5400395 B2 JP 5400395B2
Authority
JP
Japan
Prior art keywords
key
subgroup
key management
receiving terminal
data
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
JP2009001589A
Other languages
English (en)
Other versions
JP2010161548A5 (ja
JP2010161548A (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.)
Hitachi Ltd
Original Assignee
Hitachi 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 Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2009001589A priority Critical patent/JP5400395B2/ja
Priority to US12/623,474 priority patent/US20100174899A1/en
Publication of JP2010161548A publication Critical patent/JP2010161548A/ja
Publication of JP2010161548A5 publication Critical patent/JP2010161548A5/ja
Application granted granted Critical
Publication of JP5400395B2 publication Critical patent/JP5400395B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/1854Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with non-centralised forwarding system, e.g. chaincast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/06Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/065Network architectures or network communication protocols for network security for supporting key management in a packet data network for group communications
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • H04L9/083Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP]
    • H04L9/0833Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) involving central third party, e.g. key distribution center [KDC] or trusted third party [TTP] involving conference or group key
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891Revocation or update of secret information, e.g. encryption key update or rekeying
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00Data switching networks
    • H04L12/02Details
    • H04L12/16Arrangements for providing special services to substations
    • H04L12/18Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H04L12/185Arrangements for providing special services to substations for broadcast or conference, e.g. multicast with management of multicast group membership
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/04Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104Grouping of entities

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、データ配信システム、鍵管理装置および鍵管理方法に係り、特に、マルチキャスト通信を効率的に実施するデータ配信システム、鍵管理装置および鍵管理方法に関する。
ネットワークに接続された端末間で同一の情報を共有する手段としてマルチキャストがある。マルチキャスト通信では情報を共有する端末がグループを構成し、グループ内では同報通信により同一の情報を共有することができる。マルチキャスト通信における情報をグループ外の端末に対して秘匿するためには情報を暗号化することが有効である。すなわち、マルチキャスト通信の送信者は、情報を暗号化鍵を用いて暗号化する。マルチキャスト通信の受信者は復号化鍵を用いて受け取った情報を復号化する。暗号化鍵・復号化鍵は、マルチキャストグループ内でのみ共有され、グループ外の端末からは秘匿されていなければならない。
このような暗号化マルチキャスト通信において、グループに属する端末がグループから離脱する場合、少なくとも復号化鍵は変更する必要がある。なぜならば、もし復号化鍵を変更しなかったならば、離脱した端末がひそかに情報を傍受していた場合、これを復号化できてしまう。すなわち、グループに属する端末だけが情報を共有するというマルチキャスト通信の属性を満たすことができなくなる。ここで、マルチキャストサーバが配下に存在する多数のマルチキャストクライアント端末に対してマルチキャスト通信を用いて有料の情報配信を行っている場合を考える。この場合、離脱した端末は、課金されることなく不当に情報を傍受できてしまう。
従来のマルチキャスト通信は、マルチキャストグループにいる受信端末に離脱があった場合、マルチキャストグループ内に残った受信端末全員にリキーしなければならなかった。ここで、リキーとは鍵を再発行することである。マルチキャストグループの規模の増大により、リキーのトラフィックが問題となる。
特許文献1に記載された鍵管理システムは、マルチキャストグループをいくつかのサブグループに分け、各サブグループに代表受信端末を設ける。代表受信端末は、マルチキャストサーバおよび自サブグループ内の受信端末との通信を行なう。復号化鍵の配送について、マルチキャストサーバは、代表受信端末にのみ行なう。さらに、各代表受信端末は、サブグループ内の受信端末に復号鍵を配送する。
特開2006−245663号公報
しかしながら特許文献1のマルチキャスト通信鍵管理システムでは、鍵更新のトラフィックが低減できるとはいえ、マルチキャストグループにある多数の受信端末から1台でも離脱があった場合、マルチキャストグループに残った受信端末全部に対してリキーしなければならない。しかも代表端末の配下に格納できる受信端末数には制限があった。
本発明は、代表端末を設けなくても自由にサブグループを作ることができ、かつ離脱があったサブグループのみに対してリキーすることを目的とする。
また本発明はマルチキャスト受信端末の位置に依存しない自由なサブグループの作り方を可能にする方法を提供する。
上述した課題は、データを配信する配信サーバと、この配信サーバからのデータを暗号化して複数の受信端末に送信するノードと、このノードに接続されてノードの暗号化鍵と複数の受信端末の復号化鍵とを管理する鍵管理装置とからなり、鍵管理装置は、受信端末を複数のサブグループのいずれかに割り付け、復号化鍵をサブグループ毎に割り当て、第1の受信端末からの離脱通知を受信したとき、暗号化鍵と第1の受信端末の所属する第1のサブグループの復号化鍵とを変更して、ノードと第1のサブグループの残りの受信端末に送信するデータ配信システムにより、達成できる。
また、データを配信する配信サーバと、この配信サーバからのデータを暗号化して複数の受信端末に送信するノードとに接続され、ノードの暗号化鍵と複数の受信端末の復号化鍵とを管理し、受信端末を複数のサブグループのいずれかに割り付け、復号化鍵をサブグループ毎に割り当て、第1の受信端末からの離脱通知を受信したとき、暗号化鍵と第1の受信端末の所属する第1のサブグループの復号化鍵とを変更して、ノードと第1のサブグループの残りの受信端末に送信する鍵管理装置により、達成できる。
さらに、受信端末を複数のサブグループのいずれかに割り付けるステップと、復号化鍵をサブグループ毎に割り当てるステップと、第1の受信端末からの離脱通知を受信したとき、暗号化鍵を変更するステップと、第1の受信端末の所属する第1のサブグループの復号化鍵とを変更するステップと、変更された暗号化鍵をノードに送信するステップと、からなる鍵管理方法により、達成できる。
暗号化鍵管理装置は、マルチキャストグループに属する受信端末を、サブグループに分けるサブグループ決定部と、グループ毎の暗号化鍵とグループ毎に対応するサブグループ用の復号化鍵を管理する鍵管理部と、復号化鍵の生成、更新および暗号化鍵の変更を行なう鍵生成部と、サブグループ決定方法によって決定されたグループ情報、鍵管理部の鍵情報を対応付けし管理するテーブル管理部と、メッセージの受信および鍵配布する情報送受信部からなる構成を有する。
暗号化鍵管理方法において、シードノードには、マルチキャストの配信データを暗号する暗号化部と、マルチキャストグループと暗号化鍵を対応付けして管理する暗号化鍵管理部と、暗号化した配信データの配布およびマルチキャストグループへの参加・離脱などのメッセージを受信する情報送受信部からなる構成を有する。
受信端末は、マルチキャストグループおよびマルチキャストグループ内のサブグループに分けられる。マルチキャストグループは、IPアドレスで識別・管理される。このIPアドレスが、マルチキャストアドレスである。239.0.0.1をあて先とするマルチキャストは、マルチキャストグループ239.0.0.1として扱われる。
暗号化方法において、暗号化するための暗号化鍵および暗号化したデータを復号化するための復号化鍵の生成、更新は鍵管理装置の鍵生成部によって行なう。サブグループの個数がn個ある場合で考える。マルチキャストサーバが配信しようとしているデータをMとおく。Mを数値とみたとき、これよりも大きい素数K1,K2,…,Knをとる。なおデータが大きい場合、これを適当な大きさに分割した上で、分割後のデータの一つを改めてMとして以下の処理を行ってもよい。暗号化鍵をA=K1*K2*…*Kn、サブグループ1の復号化鍵をK1、サブグループ2の復号化鍵をK2、‥サブグループnの復号化鍵Knとする。復号化鍵はサブグループの数だけある。
暗号化は、暗号化文をXとおくと、X=M+Aで行なう。
復号化は暗号化文Xを復号化鍵で割った余りによって得られる。サブグループ1に属する受信端末の場合、
X(mod K1)=M(mod K1)+A(mod K1)
=M(mod K1)
=M …(数1)
(数1)となって復号化できる。ここでmodは剰余を表す数学記号であり、mod K1はK1で割った剰余を表す。式の変形において、A=K1*…*Knなので、AをK1で割った剰余は0である。また、MはK1より小さいので、MをK1で割った剰余はM自身である。
サブグループ2のメンバが離脱した場合、サブグループ2の復号化鍵をK2’に変更し、暗号化鍵をA’=K1*K2’*…*Knとする。暗号化文X’は
X’=M+A’
となる。復号化鍵については、新しいK2’は使えるが、古いK2は使えない。実際
X’(mod K2’)=M(mod K2’)+A’(mod K2’)
=M(mod K2’)
=M …(数2)
また
X’(mod K2)=M(mod K2)+A’(mod K2)
=M+A’(mod K2) …(数3)
≠M
式の変形において、A’はK2では割り切れないので、復元できない。このようにして離脱した受信端末は古い復号化キーK2を用いて復号化することはできない。
しかも
X’(mod K1)=M(mod K1)+A’(mod K1)
=M(mod K1)
=M …(数4)
となって、暗号化鍵がAからA’に変わったにも関わらずサブグループ1はリキーの影響を受けない。
実用上はX=M+Aだけでは暗号としては弱いので、Aに関する定数項を持たない多項式(数5)を用いて、
f(A)=an・A^n+an−1・A^(n−1)+…+a1・A …(数5)
X=M+f(A)などするほうが暗号は強くなる。ここで係数ai(i=1,2,…,n−1,n)は乱数で生成する。また暗号を強めるために既存のDES(Data Encryption Standard,FIPS 46)またはAES(Advanced Encryption Standard,FIPS 197)と組み合わせてもよい。つまり、暗号化文XをさらにDESまたはAESで暗号化してから配信する。なお、「^」はべき乗を表す。A^nは、Aである。
本発明によれば、変更のあるサブグループのみに対して鍵を更新することによって、鍵更新処理に必要な転送量を低減することができる。また、暗号化された同報通信メッセージのマルチキャストが効率的に行なえる。
以下、本発明の実施の形態について、実施例を用い図面を参照しながら詳細に説明する。なお、実質同一部位には同じ参照番号を振り、説明は繰り返さない。
(実施例1)
図1ないし図10を参照して、実施例1を説明する。ここで、図1はマルチキャストネットワークのハードウェアブロック図である。図2はシードノードと暗号化鍵管理装置の機能ブロック図である。図3は暗号鍵管理テーブルを説明する図である。図4は暗号鍵/復号鍵管理テーブルを説明する図である。図5は受信端末とマルチキャストノードとシードノードと暗号化鍵管理装置とマルチキャストサーバとの間のサブグループ新規生成のシーケンス図である。図6は受信端末とマルチキャストノードとシードノードと暗号化鍵管理装置とマルチキャストサーバとの間の受信端末新規参加のシーケンス図である。図7は暗号化鍵管理装置の受信端末新規参加のフローチャートである。図8は受信端末とマルチキャストノードとシードノードと暗号化鍵管理装置とマルチキャストサーバとの間の受信端末離脱のシーケンス図である。図9は受信端末とマルチキャストノードとシードノードと暗号化鍵管理装置とマルチキャストサーバとの間のサブグループ新規消滅のシーケンス図である。図10は暗号化鍵管理装置の受信端末離脱のフローチャートである。
図1において、マルチキャストネットワーク1000は、マルチキャストサーバ400と、シードノード200と、暗号化鍵管理装置100と、4台のマルチキャストルータ300と、複数の受信端末10とから構成される。複数の受信端末10は、集合S_{1,X}510、集合S_{2,Y}520、…、集合S_{n,Z}5n0のいずれかに含まれ、全体としてマルチキャストグループG_{N}500を構成する。シードノード200と、暗号化鍵管理装置100と、4台のマルチキャストルータ300とは、IPネットワーク600で接続されている。
マルチキャストサーバ400は、受信端末10にマルチキャストでデータを配信する。シードノード200は、鍵管理装置100と連携して、マルチキャストグループを管理する。鍵管理装置100は、マルチキャストグループ内の暗号鍵/復号鍵を管理する。マルチキャストルータ300は、複数の受信端末10にマルチキャストでデータを配信する。
マルチキャストグループは、ツリーの幹をサブグループとするクラスタ、クラスタヘッドにグループ番号1からシーケンシャルに1ずつカウントアップした番号を、個々のクラスタメンバにメンバを特定できるように、メンバ番号1からシーケンシャルに1ずつカウントアップした番号を振り分ける。すなわち、マルチキャストグループG_{N}500は、サブグループS_{1,X}510,S_{2,Y}520,…,S_(n,Z)5n0によって、G_{N}=(S_{1,X},S_{2,Y},…,S_(n,Z))と分割される。
図2を参照して、鍵管理装置、シードノードの概略構成を説明する。図2において、鍵管理装置100は、シードノード200とIPネットワーク600により接続している。
鍵管理装置100は、鍵管理部110、鍵生成部120、サブグループ決定部130、テーブル管理部150、情報送受信部140から構成される。またシードノード200は、マルチキャストデータの暗号化部210、暗号化鍵管理部230、情報送受信部220から構成される。
鍵管理装置100において、鍵管理部110は、マルチキャストグループのテーブル管理部150のマルチキャストグループ毎の暗号化鍵、グループ毎にグループ内の各サブグループ用復号化鍵の登録、更新および削除を行なう。鍵生成部120は、鍵管理部110の鍵情報変更、生成および更新要求を受けた際、鍵情報の変更、生成および更新を行なう。サブグループ決定部130は、サブグループの決定方法および、情報送受信部140よりを通して受信端末からのIGMP(Internet Group Management Protocol)のjoinおよびIGMPのleave要求を受けた時、サブグループ決定方法よりサブグループの作成、更新、消滅を行なう。テーブル管理部150は、サブグループ決定部130のグループ情報、鍵管理部110の鍵情報を対応付けして登録、更新、削除を行なう。情報送受信部140は、メッセージの受信および鍵配布を行なう。
シードノード200において、暗号化部210は、情報送受信部220を介してマルチキャストサーバ400から受信した配信データを暗号化鍵管理部230が持つ暗号化鍵を用いて暗号化する。暗号化鍵管理部230は、鍵管理装置100から配布された暗号化鍵の登録、更新、削除を行なう。情報送受信部220は、受信端末10からのメッセージの受信および暗号部210が暗号化した暗号化文の送信を行なう。
図3を参照して、暗号化鍵管理部が保持する暗号鍵テーブルを説明する。図3において、暗号鍵テーブル240は、グループ241、暗号鍵242とから構成される。暗号化鍵テーブル240は、グループ241、暗号鍵242とを対応付けるテーブルである。
図4を参照して、テーブル管理部が保持する暗号鍵/復号鍵管理テーブルを説明する。図4において、暗号鍵/復号鍵管理テーブル160は、グループ161、暗号鍵162、サブグループ163、復号鍵164とから構成される。暗号鍵/復号鍵管理テーブル160は、グループ161と暗号鍵162、サブグループ163と復号鍵164を対応付けるテーブルである。
暗号化鍵の生成方法を、以下説明する。マルチキャストサーバ400が配信するデータをMとおく。なお、配信データのサイズが十分に大きい場合は、以下の処理を計算機上で処理できるだけの適当な大きさに区切ってもよい。
Mを数値と見做し、Mよりも大きい素数を取得する。取得する素数の数は、サブグループの数だけである。N個のサブグループがあったとき、それぞれ異なる素数K1,K2,…,Knを用意する。暗号化鍵Aは、A=K1*K2*…*Knとすると、素数K1,K2,…,Knは、復号化鍵である。暗号化鍵Aに関する定数項を持たない多項式(数6)を用いて、暗号化文Xを(数7)で作成する。
f(A)=an・A^n+an−1・A^(n−1)+…+a1・A …(数6)
X=M+f(A) …(数7)
ここで係数ai(i=1,2,…,n−1,n)は乱数で生成する。乱数生成は、情報送信のたびに行なってもよい。
受信端末10は、暗号情報を受信し、自分が属するサブグループの復号化鍵を用いて復号化する。復号化は、暗号化文Xを復号化鍵で割った余りによって得られる。サブグループ1に属する受信端末10で、復号化鍵K1の場合、(数8)を演算する。
X(mod K1)
=M(mod K1)+f(A)(mod K1)
=M(mod K1)+an・A^n(mod K1)+an−1・A^(n−1)(mod K1)+…+a1・A(mod K1)
=M(mod K1)
=M …(数8)
ここで、A=K1*K2*…*Knなので、f(A)をK1で割った余りは0である。K1はMよりも大きい素数なので、MをK1で割った余りはM自身となる。したがって、暗号化文Xから元のデータMを復号化できる。
図5を参照して、受信端末の新規参加によるサブグループの新規作成/暗号化文配信処理を、説明する。図5において、マルチキャストグループに新規参加したい受信端末10は、マルチキャストルータ300に対してIGMP join要求を送信する(S11)。マルチキャストルータ300は、そのメッセージを受けて鍵管理装置100に対して受信端末10のIGMP join要求通知を送信する(S12)。鍵管理装置100は、受信端末10が既存のサブグループに属するかどうかをチェックする。受信端末10がサブグループにも属さない場合、鍵管理装置100は、新規サブグループを生成する。鍵管理装置100は、生成したサブグループの復号化鍵を作成する(S13)。鍵管理装置100は、暗号化鍵を変更して、シードノード200に対して変更した暗号化鍵を配布する(S14)。鍵管理装置100は、新規生成したサブグループにいる受信端末に対して復号化鍵を配布する(S16)。
マルチキャストサーバ400は、シードノード200に対してデータを配信する(S17)。シードノード200は、変更した暗号化鍵を用いて、マルチキャストサーバ400から受け取った配信データを暗号化する(S18)。シードノード200は、マルチキャストグループにいる受信端末10に対して暗号化文を配信する(S19)。受信端末10は、ステップ16で配布された復号化鍵を用いて、暗号化文を復号化してデータを受け取る(S21)。
ステップ13において、n個のサブグループは、受信端末10の新規参加によりn+1個になる。n+1個目のサブグループの復号化鍵は、Mよりも大きい素数Kn+1を取る。ここでKn+1は、K1,K2,…,Knとは異なる素数とする。暗号化鍵Aは、A’=K1*K2*…*Kn*Kn+1に変更する。復号化鍵は、個々のサブグループについて素数K1,K2,…,Kn,Kn+1とする。A’に関する定数項を持たない多項式(数9)を用いて、暗号化文X’を(数10)より求める。
f(A’)=an+1・A’^(n+1)+an・A’^n+an−1・A’^(n−1)+…+a1・A’ …(数9)
X’=M+f(A’) …(数10)
ここで係数ai(i=1,2,…,n−1,n,n+1)は、乱数で生成する。
暗号文を復号化は、暗号化文X’を復号化鍵で割った余りによって得られる。新規参加した受信端末は、自分が属するサブグループの復号化鍵Kn+1を用いて、(数11)で復号化する。
X’(mod Kn+1)
=M(mod Kn+1)+f(A’)(mod Kn+1)
=M(mod Kn+1)+an+1・A’^(n+1)(mod Kn+1)+an・A’^n(mod Kn+1)+…+a1・A’(mod Kn+1)
=M(mod Kn+1)
=M …(数11)
既存のサブグループはそれぞれの復号化鍵K1、K2…Knを変更することなく、同じようにして暗号化文を復号化することができる。
なお、ステップ16において、シードノード200から受信端末10に対して、IKE(Internet Key Exchange protocol,RFC2409)を用いて鍵の配布を行なうことによりセキュリティを向上させることができる。
図6を参照して、受信端末の新規参加によるサブグループ新規生成がない場合の、暗号化鍵処理シーケンスを説明する。図6において、マルチキャストグループに新規参加したい受信端末10は、マルチキャストルータ300に対してIGMP join要求を送信する(S26)。マルチキャストルータ300は、そのメッセージを受けて鍵管理装置100に対して受信端末のIGMP join要求通知を送信する(S27)。鍵管理装置100は、受信端末のIGMP join要求通知を受信したとき、どれか既存のサブグループに属するかどうかをチェックする(S28)。既存のサブグループに属する場合、鍵管理装置100は、属するサブグループ用の復号化鍵を新規参加する受信端末10に対して配布する(S29)。
なお、ステップ31〜ステップ34は、図5のステップ17〜ステップ21と同じなので、説明を省く。
鍵管理装置100は、暗号化鍵、復号化鍵を変更することなく、新規参加する受信端末10がシードノードから受け取った暗号化文を復号化することができる。
図7を参照して、受信端末が新規参加する時の鍵管理装置の動作を説明する。図7において、鍵管理装置100は、新規参加する受信端末のIGMP join要求通知を受信する(S501)。鍵管理装置100は、新規参加する受信端末10が既存のグループに属するかどうかをチェックする(S502)。受信端末10がどの既存のサブグループにも属さない場合(S502:NO)、鍵管理装置100は、新規サブグループを作成する(S504)。鍵管理装置100は、新規サブグループ用の復号化鍵を生成し(S505)、鍵管理装置100は、暗号化鍵を変更する(S506)。鍵管理装置100は、シードノードに対して変更した暗号化鍵を配布する(S507)。鍵管理装置100は、新規参加する受信端末に対して生成した復号化鍵を配布して(S508)、終了する。
ステップ502で受信端末10がどれか既存のサブグループに属する場合(YES)、鍵管理装置100は、新規参加する受信端末に対して属するサブグループ用の復号化鍵を配布して(S503)、終了する。
図8を参照して、受信端末が離脱したサブグループに対する暗号化鍵処理を説明する。図8において、マルチキャストサーバ400は、シードノード200に対して配信データを送信する(S31)。シードノード200は、受信した配信データについて暗号鍵Aを用いて暗号化する(S32)。シードノード200は、暗号化文を受信端末10−2、受信端末10−1に送信する(S33、S34)。暗号化文を受信端末10−2、受信端末10−1は、それぞれ受信した暗号化文を復号鍵K1を用いて復号化し、配信データを受け取る(S36、S37)。
ここで、受信端末10−1がマルチキャストグループから離脱するとしよう。離脱する受信端末10−1は、マルチキャストルータ300に対してIGMP leave通知を送信する(S38)、マルチキャストルータ300は、そのメッセージを受けて鍵管理装置100に対して受信端末のIGMP leave通知を送信する(S39)。鍵管理装置100は、受信端末の離脱通知を受信し、離脱するサブグループ510に残りの受信端末あるかどうかをチェックする。ここでは離脱するサブグループ510に残りの受信端末があるので、離脱するサブグループのみに対して復号化鍵を更新し、暗号化鍵を変更する(S41)。鍵管理装置100は、シードノード200に対して、変更した暗号化鍵を配布する(S42)。鍵管理装置100は、離脱があったサブグループの残った受信端末10−2に対して、更新した復号化鍵を配布する(S43)。
マルチキャストサーバ400は、シードノード200に配信データを送信する(S46)。シードノード200は、変更された暗号化鍵(A”)を用いて、マルチキャストサーバ400から受け取った配信データを暗号化する(S47)。シードノード200は、暗号化した暗号化文をマルチキャストグループの受信端末10−2に対して暗号化文を配信する(S48)。ここでは、仮に離脱した受信端末10−1も配信データを受信したとする(S49)。受信端末10−2は、更新した復号化鍵を使って暗号化文を復号化する(S51)。しかし、離脱した受信端末10−1は、更新した復号化鍵を持ってないため、暗号化文を復号化できない(S52)。
n個のサブグループがあった場合、サブグループ1に属する受信端末10の離脱によって、鍵管理装置100がグループ1の復号化鍵K1について、K1,K2,…,Knとは異なる素数K1”に変更する。暗号化鍵は、A=K1*K2*…*KnからA”=K1”*K2*…*Knに変更する。復号化鍵は、個々のサブグループが取った素数K1”,K2,…,Knとする。A”に関する定数項を持たない多項式(数12)を用いて、暗号化文X”を(数13)より求める。
f(A”)=an・A”^n+…+a1・A” …(数12)
X”=M+f(A”) …(数13)
ここで係数ai(i=1,2…n−1,n)は、乱数で生成する。
暗号文の復号化は、暗号化文X”を復号化鍵で割った余りによって得られる。離脱があったサブグループ1に残った受信端末10−2は、復号化鍵K1”を用いて復号化すると、(数14)となる。
X”(mod K1”)
=M(mod K1”)+f(A”)(mod K1”)
=M(mod K1”)+an・A”^n(mod K1”)+…+a1・A”(mod K1”)
=M(mod K1”)
=M …(数14)
他の変更がないサブグループはそれぞれの復号化鍵K2…Knを変更することなく、同じようにして暗号化文を復号化することができる。
しかし、サブグループ1を離脱した受信端末10−1は、復号化鍵K1しか持ってないため、暗号化文を復号化しようとすると、(数15)となる。
X”(mod K1)
=M(mod K1)+f(A”)(mod K1)
=M(mod K1)+an・A”^n(mod K1)+…+a1・A”(mod K1)
=M+an・A”^n(mod K1)+an−1・A”^(n−1)(mod K1)+…+a1・A”(mod K1) …(数15)
≠M
ここで、A”=K1”*K2*…*Knなので、f(A”)をK1で割り切ることはできないため、(数15)は、Mとならず復号化できない。
図9を参照して、受信端末の離脱によるサブグループ消滅に対する暗号化鍵処理シーケンスを説明する。図9において、離脱する受信端末10は、マルチキャストルータ300に対してIGMP leave通知を送信する(S61)。マルチキャストルータ300は、そのメッセージを受けて鍵管理装置100に対して受信端末のIGMP leave通知を送信する(S62)。鍵管理装置100は、受信端末10の離脱通知を受信し、離脱したサブグループに残りの受信端末があるかどうかをチェックする。ここでは、残った受信端末がないので、鍵管理装置100は、該当サブグループを消滅し、暗号化鍵を変更する(S63)。鍵管理装置100は、シードノード200に対して変更した暗号化鍵を配布する(S64)。
n個のサブグループがあった場合、サブグループ1に属する受信端末の離脱によって、サブグループ1にいる受信端末がなくなったとき、サブグループの数はn−1個になる。サブグループ1の復号化鍵はK1であるとすると、暗号化鍵はA=K1*K2*…*KnはA'''=K2*…*Knに変更する。残ったn−1個のサブグループの復号化鍵は、それぞれ持っている復号化鍵K2、…、Knのままである。A'''に関する定数項を持たない多項式(数16)を用いて、暗号化文X'''を(数17)より求める。
f(A''')=an−1・A'''^(n−1)+…+a1・A''' …(数16)
X'''=M+f(A''') …(数17)
図10を参照して、受信端末が離脱するときの鍵管理装置の処理を説明する。図10において、鍵管理装置100は、受信端末からのIGMP leave通知を受信する(S801)。鍵管理装置100は、離脱したサブグループに残った受信端末があるかどうかをチェックする(S802)。離脱したサブグループに残った受信端末がある場合(YES)、鍵管理装置100は、離脱したサブグループ用の復号化鍵を更新する(S803)。鍵管理装置100は、暗号化鍵を変更する(S804)。鍵管理装置100は、シードノード200に対して変更した暗号化鍵を配布する(S805)。鍵管理装置100は、離脱したサブグループに残った受信端末に対して更新した復号化鍵を配布して(S806)、終了する。
ステップ802で離脱したサブグループに残った受信端末がない場合(NO)、鍵管理装置100は、離脱したサブグループを消滅させる(S807)。鍵管理装置100は、暗号化鍵を変更する(S808)。鍵管理装置100は、シードノード200に対して変更した暗号化鍵を配布して(S809)、終了する。
なお、本実施例においてシードノードの機能をマルチキャストサーバ内に組込むことが可能である。こうすればシードノードを設けなくても済む。同様に、鍵管理装置の機能もマルチキャストサーバ内に組込むことも可能である。
本実施例によれば、変更のあるサブグループのみに対して鍵を更新することによって、鍵更新処理に必要な転送量を低減することができる。さらに、暗号化された同報通信メッセージのマルチキャストが効率的に行なえる。
(実施例2)
実施例2について、図11を参照して説明する。ここで、図11はマルチキャストネットワークのハードウェアブロック図である。
図11において、マルチキャストネットワーク1000Aは、マルチキャストサーバ400、シードノード200、鍵管理装置100、マルチキャストルータ300、受信端末10で構成される。実施例2の構成は第1実施例と同じである。
実施例2はサブグループの決定手段に特徴がある。サブグループの決定方法として、マルチキャストグループをn個のサブグループに分割する場合、マルチキャストグループに参加する受信端末をランダム的にn個のサブグループに振り分ける方法と、順番的にn個のサブグループに振り分ける方法が可能である。また別の方法として、1個のサブグループに格納できる最大受信端末数を設定した場合、サブグループが最大受信端末数を超えた時、新たなサブグループを生成してマルチキャストグループに参加する受信端末を格納する方法が可能である。
図11は、マルチキャストグループ500に参加する受信端末10を順番的にn個のサブグループに振り分ける方法を示している。図11において、マルチキャストルータ300−1は、受信端末10−1−1と受信端末10−1−2とを収容する。マルチキャストルータ300−2は、受信端末10−2−1と受信端末10−2−2と受信端末10−2−3とを収容する。マルチキャストルータ300−3は、受信端末10−3−1と受信端末10−3−2と受信端末10−3−3とを収容する。
サブグループS_{1,X}510は、マルチキャストルータ300−1、300−3、300−4に最初に登録された受信端末10−1−1と、受信端末10−2−1と、受信端末10−n−1とで構成する。S_{2,Y}520は、マルチキャストルータ300−1、300−3、300−4に2番目に登録された受信端末10−1−2と、受信端末10−2−2と、受信端末10−n−2とで構成する。S_(n,Z)5n0は、マルチキャストルータ300−1、300−3、300−4にn番目に登録された受信端末10−2−nと、受信端末10−n−nとで構成する。
このとき暗号化鍵および復号化鍵は、鍵管理装置100が決定する。マルチキャストグループにおいて暗号化鍵1個に対して、復号化鍵はサブグループの数だけある。マルチキャストグループに新規参加する受信端末10があった場合、鍵管理装置100は、新規参加する受信端末が既存のサブグループに属するかどうかをチェックする。既存のサブグループに属さない場合、新規サブグループを作成し、新規サブグループ用の復号化鍵を生成して、暗号化鍵を変更する。鍵管理装置100は、シードノード200に対して変更した暗号化鍵を配布し、新規受信端末のみに対して生成した復号化鍵を配布する。つまり、変更があったのは暗号化鍵および新規サブグループ用の復号化鍵のみで、他既存のサブグループの復号化鍵は変更のないままである。また新規参加する受信端末が既存のサブグループに属する場合、鍵管理装置は属するサブグループ用の復号化鍵を新規参加する受信端末に対して配布する。つまり、暗号化鍵および復号化鍵は変更なしである。
マルチキャストグループに離脱する受信端末10があった場合、鍵管理装置100は、離脱があったサブグループに残った受信端末があるかどうかをチェックする。離脱があったサブグループに残った受信端末10があった場合、鍵管理装置100は、離脱があったサブグループの復号化鍵を更新し、暗号化鍵を変更する。鍵管理装置100は、シードノード200に対して変更した暗号化鍵を配布し、離脱があったサブグループに残った受信端末10に対して更新した復号化鍵を配布する。
つまり、変更があったのは暗号化鍵と、離脱があったサブグループ用の復号化鍵のみで、他のサブグループの復号化鍵は変更のないままである。また離脱があったサブグループに残った受信端末10がなくなった場合、鍵管理装置100は、離脱があったサブグループを消滅し、暗号化鍵を変更する。つまり、変更があったのは暗号化鍵のみで、他のサブグループは復号化鍵の変更なしである。また離脱によって消滅したサブグループは、マルチキャストルータよりデータが転送されないため、データを受信することができない。
本実施例に拠れば、マルチキャストグループの受信端末を自由にサブグループ分けすることができる。
(実施例3)
実施例3について、図12を参照して、説明する。ここで、図12はマルチキャストネットワークのシーケンス図である。マルチキャストグループのサブグループの個数がn個ある場合、マルチキャストサーバが配信しようとしているデータをMとおくと、Mを数値とみたとき、これよりも大きい素数K1,K2,…,Knをとる。なおデータが大きい場合、これを適当な大きさに分割した上で、分割後のデータの一つを改めてMとして以下の処理を行ってもよい。暗号化鍵AをA=K1*K2*…*Kn、サブグループ1の復号化鍵をK1、サブグループ2の復号化鍵をK2、…サブグループnの復号化鍵Knとする。復号化鍵はサブグループの数だけある。
暗号化は、暗号化文をXとおくと、(数18)で行なう。
X=M+A …(数18)
しかし、マルチキャストグループ以外からマルチキャストグループを守るためには、暗号化文X=M+Aの暗号化強度を強める必要がある。そこでX=M+AをさらにDESまたはAESで暗号化して暗号化文を配信する。ここで、DESまたAESで暗号化した暗号化文の復号化鍵はマルチキャストグループで共通とする。鍵管理装置が前記の復号化鍵を管理し、鍵の更新および配布を行なう。
図12を参照して、暗号化文X=M+AをさらにDESで暗号化して暗号化文を配信するシーケンスを説明する。図12において、マルチキャストグループに新規参加したい受信端末10は、マルチキャストルータ300にIGMP join要求を送信する(S71)。マルチキャストルータ300は、そのメッセージを受けて鍵管理装置100に対して受信端末のIGMP join要求を送信する(S72)。鍵管理装置100は、受信端末10に対してDESで暗号化した暗号化文を復号化するための復号化鍵を配布する(S73)。ここで復号化鍵は、Kとする。鍵管理装置100は、受信端末10が属するサブグループ用の復号化鍵を配布する(S74)。新規参加した受信端末10は、サブグループ1に属し、サブグループ1の復号化鍵K1を受け取る。
ここで暗号化鍵管理装置100は、IKEを用いて、復号化鍵を同時に配布する(S76)。マルチキャストサーバ400は、配信するデータMをシードノード200に対して送信する(S77)。シードノード200は、データMを受信し、暗号鍵Aを用いて配信データMを暗号化して暗号化文Xとする。さらにシードノード200は、暗号化文XをDESで暗号化して、暗号化文XをX’とする(S78)。シードノード200は、暗号化文X’をマルチキャストグループの受信端末10に対して送信する(S79)。受信端末10は、暗号化文X’を受信し、鍵管理装置100から配布された復号化鍵Kを用いて暗号化文X’を復号化する。暗号化文X’は、Xとなる。また受信端末10は、サブグループ1の復号化鍵K1を用いて、暗号化文Xを復号化して配信データMを受け取る(S81)。
(実施例4)
次に、実施例4について説明する。マルチキャストサーバ400が配信しようとするデータがM、データMの長さがLm=64bit、マルチキャストグループのサブグループ2個とする。データMよりも大きい素数を2つ取る場合、素数K1、K2の長さは、それぞれL1=64bit、L2=64bitとする。暗号化鍵Aは、A=K1*K2より、暗号化鍵Aの長さLaはLa=L1*L2=128ビットとなる。暗号化文Xは、X=M+Aより、Xの長さLxはLx=128bitとなる。実際の配信データMより64bitも長くなってしまい、さらにサブグループの数が増えると暗号化鍵も大きくなるので、通信の際に無駄が生じる。
実施例4は、復号化鍵がマルチキャスト配信データより大きい素数以外の整数を取った場合の暗号化方法について説明する。マルチキャストサーバが配信しようとしているデータをMとおく。Mを数値とみたとき、これよりも大きい素数以外の整数K1,K2,…,Knをとる。ただし、K1,K2,…,Knはお互い割り切ることができない整数である。なおデータが大きい場合、これを適当な大きさに分割した上で、分割後のデータの一つを改めてMとして以下の処理を行ってもよい。
暗号化鍵Aは、K1,K2,…,Knの最小公倍数である。最小公倍数を十分に大きく取り、K1,K2,…,Knは、因数分解が十分困難な程度に大きな素数からなるものとする。復号化鍵はサブグループ1の復号化鍵をK1、サブグループ2の復号化鍵をK2、…サブグループnの復号化鍵Knとする。復号化鍵はサブグループの数だけある。
暗号化は、暗号化文をXとおくと、(数19)で行なう。
X=M+A …(数19)
復号化、は暗号化文Xを復号化鍵で割った余りによって得られる。サブグループ1に属する受信端末の場合、(数20)で与えられる。
X(mod K1)=M(mod K1)+A(mod K1)
=M(mod K1)
=M …(数20)
ここで、Aは、K1,K2…Knの最小公倍数なので、AをK1で割った剰余は0である。また、Mは、K1より小さいので、MをK1で割った剰余はM自身である。
サブグループ2のメンバが離脱した場合、サブグループ2の復号化鍵をK2’に変更し、暗号化鍵A’はK1,K2’,…,Knの最小公倍数とする。暗号化文X’は、(数21)で生成する。
X’=M+A’ …(数21)
復号化鍵は、新しいK2’は使えるが、古いK2は使えない。実際、
X’(mod K2’)=M(mod K2’)+A’(mod K2’)
=M(mod K2’)
=M …(数22)
しかも
X’(mod K1)=M(mod K1)+A’(mod K1)
=M(mod K1)
=M …(数23)
となって、暗号化鍵が変わったにも関わらずサブグループ1はリキーの影響を受けない。
また
X’(mod K2)=M(mod K2)+A’(mod K2)
=M+A’(mod K2) …(数24)
≠M
このようにして離脱した受信端末は古い復号化キーK2を用いて復号化することはできない。
マルチキャストサーバが配信しようとするデータをM、データMの長さをLm=64bit、マルチキャストグループのサブグループ数を2個とする。データMよりも大きい素数を2つ取る場合、素数K1、K2の長さがそれぞれL1=64bit、L2=64bitとすると、暗号化鍵Aの長さLaはLa=L1*L2=128ビットである。暗号化文XはX=M+Aより、Xの長さLxはLx=128bitとなる。
しかし、データMよりも大きい素数以外の整数を2つ取る場合、お互い割り切れない2つの整数K1’、K2’の長さがそれぞれL1’=64bit、L2’=64bitとする。整数K1’、K2’の最大公約数が32bitであるとすると、暗号化鍵A’は整数K1’、K2’の最小公倍数なので、暗号化鍵A’の長さLa’は96bitである。暗号化文X’はX’=M’+A’より、X’の長さLx’はLx’=96bitとなる。よって実施例4による暗号化方法のほうが、暗号化文Xが小さくて済み、通信の効率向上に繋がる。
実用上はX=M+Aだけでは暗号化としては弱いので、実施例1のようにAに関する定数項を持たない多項式:
f(A)=an・A^n+an−1・A^(n−1)+…+a1・A
を用いてX=M+f(A)と暗号化する。ここで係数ai(i=1,2,…,n−1,n)は乱数で生成する。
また実施例3のように暗号化を強めるために暗号化文XをさらにDESまたはAESで暗号化してから配信する。
マルチキャストネットワークのハードウェアブロック図である。 シードノードと暗号化鍵管理装置の機能ブロック図である。 暗号鍵管理テーブルを説明する図である。 暗号鍵/復号鍵管理テーブルを説明する図である。 受信端末とマルチキャストノードとシードノードと暗号化鍵管理装置とマルチキャストサーバとの間のサブグループ新規生成のシーケンス図である。 受信端末とマルチキャストノードとシードノードと暗号化鍵管理装置とマルチキャストサーバとの間の受信端末新規参加のシーケンス図である。 暗号化鍵管理装置の受信端末新規参加のフローチャートである。 受信端末とマルチキャストノードとシードノードと暗号化鍵管理装置とマルチキャストサーバとの間の受信端末離脱のシーケンス図である。 受信端末とマルチキャストノードとシードノードと暗号化鍵管理装置とマルチキャストサーバとの間のサブグループ新規消滅のシーケンス図である。 暗号化鍵管理装置の受信端末離脱のフローチャートである。 マルチキャストネットワークのハードウェアブロック図である。 マルチキャストネットワークのシーケンス図である。
10…受信端末、100…鍵管理装置、110…鍵管理部、120…鍵生成部、130…サブグループ決定部、140…情報送受信部、150…テーブル管理部、200…シードノード、210…暗号化部、220…情報送受信部、230…暗号鍵管理部、300…マルチキャストルータ、400…マルチキャストサーバ、500…マルチキャストグループ、510…サブグループ、520…サブグループ、5n0…サブグループ、600…IPネットワーク、1000…マルチキャストネットワーク。

Claims (5)

  1. データを1つのマルチキャストグループに属する複数の受信端末に配信する配信サーバと、この配信サーバからのデータを暗号化して複数の前記受信端末に送信するノードと、このノードに接続されて前記ノードの暗号化鍵と複数の前記受信端末の復号化鍵とを管理する鍵管理装置とからなるデータ配信システムにおいて、
    前記鍵管理装置は、
    前記1つのマルチキャストグループに属する複数の前記受信端末それぞれを、前記1つのマルチキャストグループを複数のサブグループに分けた当該サブグループのいずれかに割り付け、
    複数の前記サブグループ毎にそれぞれ異なる前記復号化鍵を割り当て、
    第1の前記サブグループに属する複数の受信端末の中の第1の受信端末から、前記マルチキャストグループからの離脱通知を受信したとき、前記暗号化鍵と前記第1のサブグループの復号化鍵とを変更して、当該変更した暗号化鍵を前記ノードに送信し、当該変更した前記第1のサブグループの復号化鍵を前記第1のサブグループの残りの受信端末に送信し、
    前記鍵管理装置は、
    前記データ量がMのとき、このMより大きい素数であるK1を前記第1のサブグループに、前記Mより大きく前記K1とは異なる素数であるK2を第2のサブグループに、それぞれ復号化鍵として割り当て、
    前記K1と前記K2との積を含む暗号化鍵を前記ノードに割り当てることを特徴とするデータ配信システム。
  2. データを1つのマルチキャストグループに属する複数の受信端末に配信する配信サーバと、この配信サーバからのデータを暗号化して複数の前記受信端末に送信するノードとに接続され、前記ノードの暗号化鍵と複数の前記受信端末の復号化鍵とを管理する鍵管理装置において、
    前記1つのマルチキャストグループを分けてなる複数のサブグループに、前記マルチキャストグループに属する前記受信端末をそれぞれ割り付けるサブグループ決定部と、
    複数の前記サブグループ毎にそれぞれ異なる前記復号化鍵を生成する鍵生成部と、を有し、
    第1の前記サブグループに属する複数の受信端末の中の第1の受信端末から、前記マルチキャストグループからの離脱通知を受信したとき、前記鍵生成部は、前記暗号化鍵と前記第1のサブグループの復号化鍵とを変更し、
    当該変更した前記暗号化鍵を前記ノードに送信し、当該変更した前記第1のサブグループの復号化鍵を前記第1のサブグループの残りの受信端末に送信し、
    前記データ量がMのとき、このMより大きい素数であるK1を前記第1のサブグループに、前記Mより大きく前記K1とは異なる素数であるK2を第2のサブグループに、それぞれ復号化鍵として割り当て、
    前記K1と前記K2との積を含む暗号化鍵を前記ノードに割り当てることを特徴とする鍵管理装置。
  3. 請求項2に記載の鍵管理装置であって、
    前記受信端末に、前記K1または前記K2を送信することを特徴とする鍵管理装置。
  4. データを1つのマルチキャストグループに属する複数の受信端末に配信する配信サーバと、この配信サーバからのデータを暗号化して複数の受信端末に送信するノードと、このノードに接続されて前記ノードの暗号化鍵と複数の前記受信端末の復号化鍵とを管理する鍵管理装置とからなるデータ配信システムの鍵管理方法において、
    前記鍵管理装置により、
    前記1つのマルチキャストグループに属する複数の前記受信端末それぞれを、前記1つのマルチキャストグループを複数のサブグループに分けたうちのいずれかの前記サブグループに割り付けるステップと、
    複数の前記サブグループ毎にそれぞれ異なる前記復号化鍵を割り当てるステップと、
    第1の前記サブグループに属する複数の受信端末の中の第1の受信端末から、前記マルチキャストグループからの離脱通知を受信したとき、前記暗号化鍵を変更するステップと、
    前記第1の受信端末の所属する前記第1のサブグループの復号化鍵を変更するステップと、
    変更された暗号化鍵を前記ノードに送信するステップと、
    前記鍵管理装置により、
    前記データ量がMのとき、このMより大きい素数であるK1を前記第1のサブグループに、前記Mより大きく前記K1とは異なる素数であるK2を第2のサブグループに、それぞれ復号化鍵として割り当てるステップと、
    前記K1と前記K2との積を含む暗号化鍵を前記ノードに割り当てるステップと、を含むことを特徴とする鍵管理方法。
  5. 請求項4に記載の鍵管理方法であって、
    さらに、変更された復号化鍵を前記第1のサブグループの残りの受信端末に送信するステップを含む鍵管理方法。
JP2009001589A 2009-01-07 2009-01-07 データ配信システム、鍵管理装置および鍵管理方法 Expired - Fee Related JP5400395B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2009001589A JP5400395B2 (ja) 2009-01-07 2009-01-07 データ配信システム、鍵管理装置および鍵管理方法
US12/623,474 US20100174899A1 (en) 2009-01-07 2009-11-23 Data distribution system, key management device, and key management method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2009001589A JP5400395B2 (ja) 2009-01-07 2009-01-07 データ配信システム、鍵管理装置および鍵管理方法

Publications (3)

Publication Number Publication Date
JP2010161548A JP2010161548A (ja) 2010-07-22
JP2010161548A5 JP2010161548A5 (ja) 2011-09-22
JP5400395B2 true JP5400395B2 (ja) 2014-01-29

Family

ID=42312465

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2009001589A Expired - Fee Related JP5400395B2 (ja) 2009-01-07 2009-01-07 データ配信システム、鍵管理装置および鍵管理方法

Country Status (2)

Country Link
US (1) US20100174899A1 (ja)
JP (1) JP5400395B2 (ja)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5676331B2 (ja) * 2011-03-24 2015-02-25 株式会社東芝 ルートノード及びプログラム
KR101874043B1 (ko) * 2011-07-08 2018-07-06 삼성전자주식회사 무선 통신 시스템에서 그룹키 갱신 방법 및 장치
US8914635B2 (en) * 2011-07-25 2014-12-16 Grey Heron Technologies, Llc Method and system for establishing secure communications using composite key cryptography
JP5949444B2 (ja) * 2012-10-25 2016-07-06 富士通株式会社 ネットワーク管理装置及び方法
US9825759B2 (en) * 2013-07-08 2017-11-21 Alcatel Lucent Secure service management in a communication network
US9788076B2 (en) * 2014-02-28 2017-10-10 Alcatel Lucent Internet protocol television via public Wi-Fi network
EP3116196A1 (en) * 2015-07-06 2017-01-11 Tridonic GmbH & Co KG Secure group communication

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5748736A (en) * 1996-06-14 1998-05-05 Mittra; Suvo System and method for secure group communications via multicast or broadcast
US6195751B1 (en) * 1998-01-20 2001-02-27 Sun Microsystems, Inc. Efficient, secure multicasting with minimal knowledge
JP2000057695A (ja) * 1998-08-13 2000-02-25 Sony Corp 情報記録再生装置および方法、並びに提供媒体
US6584566B1 (en) * 1998-08-27 2003-06-24 Nortel Networks Limited Distributed group key management for multicast security
JP2003069547A (ja) * 2001-08-29 2003-03-07 Fujitsu Ltd マルチキャスト通信システム
CN1918914A (zh) * 2004-02-12 2007-02-21 皇家飞利浦电子股份有限公司 用于选择性数据传输的系统
US7664810B2 (en) * 2004-05-14 2010-02-16 Via Technologies, Inc. Microprocessor apparatus and method for modular exponentiation
EP1793525B1 (de) * 2005-12-01 2008-10-15 BRAVIS GmbH Verfahren zum Ändern eines Gruppenschlüssels in einer Gruppe von Netzelementen in einem Netz
JP4685659B2 (ja) * 2006-02-23 2011-05-18 三菱電機株式会社 局側装置、加入者側装置およびponシステム

Also Published As

Publication number Publication date
US20100174899A1 (en) 2010-07-08
JP2010161548A (ja) 2010-07-22

Similar Documents

Publication Publication Date Title
US6584566B1 (en) Distributed group key management for multicast security
CN1157021C (zh) 多节点加密与密钥传送
US6049878A (en) Efficient, secure multicasting with global knowledge
JP5400395B2 (ja) データ配信システム、鍵管理装置および鍵管理方法
Snoeyink et al. A lower bound for multicast key distribution
KR100495540B1 (ko) 다수-대-다수 보안 통신용의 분배 그룹 키 관리 구조
US8160246B2 (en) Apparatus and method for generating a key for broadcast encryption
US6785809B1 (en) Server group key for distributed group key management
JP2007538454A (ja) 大規模及び中規模シナリオ及び少ないユーザ側要求のためのマルチキャストキー発行スキーム
JP2007525126A (ja) 選択的データ伝送のためのシステム
KR20060079491A (ko) 조합에 기반한 브로드캐스트 암호화 방법
Kumar et al. A secure and robust group key distribution and authentication protocol with efficient rekey mechanism for dynamic access control in secure group communications
JP4606885B2 (ja) 鍵配信システムおよび鍵管理サーバならびに鍵配信方法
JPH10107832A (ja) 暗号同報メールシステム
JP2001211154A (ja) 秘密鍵生成方法,暗号化方法及び暗号通信方法
JP2009010745A (ja) 暗号鍵更新方法、暗号鍵更新装置、及び暗号鍵更新プログラム
Iqbal et al. DM-GKM: A key management scheme for dynamic group based applications
JP2007235946A (ja) ドメインに含まれたグループのキーを構成する方法および装置
Du et al. Towards solving multicast key management problem
US8594334B2 (en) Key management method
Yung A secure and useful “keyless cryptosystem”
Lee et al. Scalable and lightweight key distribution for secure group communications
JP5279824B2 (ja) 情報処理装置及びプログラム
JP2008124884A (ja) 暗号鍵管理方法、そのシステム及びそのプログラム
Zhu Cryptanalysis of two group key management protocols for secure multicast

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110808

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20110808

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20121130

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20121211

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130205

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130521

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130718

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20131001

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20131025

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