JP2004015241A - 暗号通信システム、その端末装置及びサーバ並びに復号方法 - Google Patents

Abstract

【課題】一定の制限の下で暗号文の復号権限を委譲することの容易な暗号通信を実現する。
【解決手段】メッセージを暗号化して送信する送信者端末１０と、暗号化されたメッセージを受信して復号する受信者端末２０と、この受信者端末２０によるメッセージの復号を代行する代行者端末３０と、この代行者端末３０によるメッセージの復号を支援する変換サーバ４０とを備え、送信者端末１０は、受信者端末２０の公開鍵を用いてメッセージの暗号化を行う。受信者端末２０は、変換サーバ４０の公開鍵と所定の制約条件とメッセージを復号するための秘密鍵とを用いて、この制約条件の下でメッセージの復号が可能な委任鍵を生成して代行者端末３０に渡す。変換サーバ４０は、代行者端末３０から委任鍵に含まれる情報に基づいて代行者端末３０によるメッセージの復号権限を認証する。そして、代行者端末３０は、変換サーバ４０による認証を受けてメッセージの復号を行う。
【選択図】　　　　図１

Description

【０００１】
【発明の属する技術分野】
本発明は、暗号化されたメッセージの復号権限を委譲する暗号技術に関し、特に時間的制限などの制約条件を与えて復号権限を委譲する暗号技術に関する。
【０００２】
【従来の技術】
公開鍵暗号を用いた通信では、メッセージの送信者は、受信者の公開鍵を用いて当該メッセージを暗号化して送信する。そして、公開鍵に対応する秘密鍵を持つ受信者のみがこの暗号文を復号することができる（以後、「受信者」という語を暗号文に対応する秘密鍵（復号鍵）を保持するメンバを指して用いる）。
ここで、ネットワークに非接続状態にある場合など、受信者が秘密鍵を用いた復号処理を行使できない場面を考える。かかる場面において、複数のホストが関わる連続処理プロセスなどにおいて、特定の受信者が非接続状態にあるために処理が中断されることが望ましくない場面は、数多く存在する。このような場合に処理の中断を避けるために、受信者が、非接続状態になる前に自身が持つ復号権限を、受信者が指名した代行者に対して委譲できる手法が望まれる。
【０００３】
特定の受信者の復号処理を必要とし、かつその受信者が非接続状態にある場合には、予め指定された代行者に対して復号処理の代行を依頼することで、連続処理の中断を避けることが可能となる。
従来、権限の委譲に関しては、その実用面からの重要性を反映して多くの研究が存在する。しかし、その多くは権限証明書（Ｃｒｅｄｅｎｔｉａｌ）の委譲に関するものであり、復号権限の委譲に関する「代理復号（Ｐｒｏｘｙ　Ｃｒｙｐｔｏｓｙｓｔｅｍ）」と呼ばれる研究は非常に少ない。この種の従来技術としては、例えば、下記文献に記載された技術がある。
文献１：Ｍａｍｂｏ，　Ｍ．　ａｎｄ　Ｏｋａｍｏｔｏ，　Ｅ．，”Ｐｒｏｘｙ　Ｃｒｙｐｔｏｓｙｓｔｅｍｓ：　Ｄｅｌｅｇａｔｉｏｎ　ｏｆ　ｔｈｅ　Ｐｏｗｅｒ　ｔｏ　Ｄｅｃｒｙｐｔ　Ｃｉｐｈｅｒｔｅｘｔｓ，”　ＩＥＩＣＥ　Ｔｒａｎｓ．　Ｆｕｎｄ．　Ｅｌｅｃｔｒｏｎｉｃｓ　Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ　ａｎｄ　Ｃｏｍｐ．　Ｓｃｉ．　Ｅ８０−Ａ／１，　ｐｐ．５４−６３，　１９９７．
文献２：Ｂｌａｚｅ，　Ｍ．，　Ｂｌｅｕｍｅｒ，　Ｇ．　ａｎｄ　Ｓｔｒａｕｓｓ，　Ｍ．，”Ｄｉｖｅｒｔｉｂｌｅ　Ｐｒｏｔｏｃｏｌｓ　ａｎｄ　Ａｔｏｍｉｃ　Ｐｒｏｘｙ　Ｃｒｙｐｔｏｇｒａｐｈｙ，”　Ｐｒｏｃ．　ｏｆ　ＥＵＲＯＣＲＹＰＴ’９８，　ＬＮＣＳ，　１９９８．
文献３：Ｊａｋｏｂｓｓｏｎ，　Ｍ．，”Ｏｎ　Ｑｕｏｒｕｍ　Ｃｏｎｔｒｏｌｌｅｄ　Ａｓｙｍｍｅｔｒｉｃ　Ｐｒｏｘｙ　Ｒｅ−ｅｎｃｒｙｐｔｉｏｎ，”　Ｐｒｏｃ．　ｏｆ　ＰＫＣ’９９，　ＬＮＣＳ，　１９９９．
【０００４】
【発明が解決しようとする課題】
復号権限の委譲に関しての研究が少ない理由として、限定的に復号権限の委譲することが困難なことが挙げられる。復号権限を制限なく恒久的に委譲するのであれば、受信者の持つ秘密鍵の情報を代行者に与えれば十分である。だが、上記のような場面で要求される権限委譲は恒久的な権限の譲渡ではなく、その権限の行使できる条件を限定した形で行われる。例えば、ある開始時刻から復号権限を有効にし、ある終了時刻に復号権限を無効化するといった権限委譲である。このような権限委譲は、暗号学的に非常に困難な問題である。
上述した文献１〜３に記載された従来技術は、暗号文を代行者でも復号できるように変換する手法を提案しているが、いずれも時限的な復号権限の委譲に関しては全く取り扱っていない。
【０００５】
今後普及が予測されるＰｔｏＰ（ピア・ツー・ピア：Ｐｅｅｒ　ｔｏ　Ｐｅｅｒ）ネットワークでは、従来の静的に構成されたネットワークと異なり、ホスト（ピア）のネットワークからの離脱や（再）参加が頻繁に行われる。一方で、ＰｔｏＰネットワーク全体として一貫したセキュリティサービス（例えば、暗号化されたデータに対するアクセス）を提供するために、非接続状態にあるピアの復号鍵を必要とする場面が頻繁に起こり得る。そのため、復号鍵を行使する権限を、一定の制約条件の下で他のピアに委譲できれば、所定のピアが非接続状態となる際でも他のピアが復号処理を継続可能にできるので、極めて柔軟なセキュリティサービスの構築が可能となる。
【０００６】
そこで本発明は、一定の制限の下で暗号文の復号権限を委譲することの容易な暗号通信を実現することを目的とする。
また本発明は、上記の目的に加えて、かかる暗号通信を用いて柔軟なセキュリティサービスを実現した暗号通信システムを提供することを目的とする。
【０００７】
【課題を解決するための手段】
上記の目的を達成する本発明は、次のように構成された暗号通信システムとして実現される。すなわち、この暗号通信システムは、メッセージを暗号化して送信する送信者端末と、暗号化されたメッセージを受信して復号する受信者端末と、この受信者端末によるメッセージの復号を代行する代行者端末と、この代行者端末によるメッセージの復号を支援する変換サーバとを備えることを特徴とする。ここで、送信者端末は、受信者端末の公開鍵を用いてメッセージの暗号化を行う。受信者端末は、変換サーバの公開鍵と所定の制約条件とメッセージを復号するための秘密鍵とを用いて、この制約条件の下でメッセージの復号が可能な委任鍵を生成して代行者端末に渡す。また、変換サーバは、代行者端末から委任鍵の少なくとも一部を取得し、取得した情報に基づいて代行者端末によるメッセージの復号権限を認証する。そして、代行者端末は、変換サーバによる認証を受けてメッセージの復号を行う。
【０００８】
この制約条件としては、例えばメッセージの復号権限が有効となる開始時刻と終了時刻とを指定した時間的制限を設定することができる。また、委任鍵の生成には、一方向性ハッシュ関数を用いた計算が行われ、変換サーバにおいても、同一の一方向性ハッシュ関数の計算を介して代行者端末の委任鍵が前記制約条件を満足するかどうかの認証が行われる。
【０００９】
より詳細には、この受信者端末は、自身の公開鍵を用いて暗号化されたメッセージを復号するための秘密鍵を保持する秘密鍵保持手段と、所定の変換サーバの公開鍵と所定の制約条件と秘密鍵保持手段に保持されている秘密鍵とに基づいて、かかる制約条件の下でメッセージの復号が可能な委任鍵を生成する委任鍵生成手段とを備え、このメッセージの復号を代行する所定の代行者端末に委任鍵生成手段にて生成された委任鍵を渡す。これによりメッセージの復号権限が制約条件による制限付きで委譲される。
また、この代行者端末は、所定の変換サーバの公開鍵と所定の制約条件と暗号化されたメッセージを復号するための秘密鍵とに基づき、一方向性ハッシュ関数を用いて生成された、この制約条件の下でメッセージの復号が可能な委任鍵を保持する委任鍵保持手段と、委任鍵の少なくとも一部を変換サーバに送信し、変換サーバによる制約条件に応じた認証結果として得られるパラメータを変換サーバから受信する問い合わせ手段と、変換サーバから取得したパラメータと委任鍵とを用いてメッセージを復号する復号手段とを備える。
そして、この変換サーバは、所定の制約条件と第１の公開鍵で暗号化されたメッセージの一部と第２の公開鍵で暗号化された所定の情報とを、所定の端末装置から受信する受信手段と、取得した制約条件の適否を判定する判定手段と、第２の公開鍵に対応する秘密鍵で前記所定の情報を復号し、所定の情報と制約条件と第１の公開鍵で暗号化されたメッセージの一部とを用いて、メッセージを復号するためのパラメータを計算するパラメータ計算手段と、パラメータ計算手段にて計算されたパラメータを所定の端末装置に送信する送信手段とを備える。
かかる構成により、変換サーバの認証を経たことを条件として、代行者端末は、メッセージの復号を代行することが可能となる。
【００１０】
さらに、本発明は、これらの受信者端末、代行者端末、変換サーバを、コンピュータにて実現するためのプログラムとして実現することができる。このプログラムは、磁気ディスクや光ディスク、半導体メモリ、その他の記録媒体に格納して配布したり、ネットワークを介して配信したりすることにより提供することができる。
【００１１】
また、本発明による他の暗号通信システムは、メッセージを暗号化して送信する送信者端末と、暗号化されたメッセージを復号する秘密鍵を保持する受信者端末と、この受信者端末の秘密鍵に基づいてメッセージの復号を代行する代行者端末と、この代行者端末によるメッセージの復号処理に対する認証を行う変換サーバとを備え、閾値復号を用いて、受信者端末の秘密鍵の運用を代行者端末と変換サーバとで分散することにより、この変換サーバの認証を得た場合に、この代行者端末がメッセージの復号可能となることを特徴とする。
【００１２】
さらにまた、上記の目的を達成する他の本発明は、暗号化されたメッセージを復号する、次のような復号方法としても実現される。すなわち、この復号方法は、第１の公開鍵に対応する第１の秘密鍵と所定の制約条件と第２の公開鍵とに基づいて、制約条件の下で当該メッセージの復号が可能な委任鍵を生成するステップと、第２の公開鍵に対応する第２の秘密鍵を持つ外部機関に委任鍵の少なくとも一部を渡し、この委任鍵による復号処理がこの制約条件を満足するかどうかの判定結果をこの外部機関から取得するステップと、委任鍵及び外部機関の判定結果を用いて第１の公開鍵により暗号化されたメッセージを復号するステップとを含むことを特徴とする。
【００１３】
【発明の実施の形態】
以下、添付図面に示す実施の形態に基づいて、この発明を詳細に説明する。
図１は、本実施の形態による復号権の委譲方法を実現する暗号通信システムの概略構成を説明する図である。
図１を参照すると、本実施の形態の暗号通信システムは、送信者端末１０と、受信者端末２０と、代行者端末３０と、変換サーバ４０とで実現される。
送信者端末１０は、暗号通信にかかるメッセージの送信者が使用する端末装置であり、受信者の公開鍵でメッセージを暗号化して送信する。
受信者端末２０は、暗号化されたメッセージの受信者が使用する端末装置であり、公開鍵ｅ_Ａに対応する秘密鍵ｄ_Ａを持つ。
代行者端末３０は、復号処理の代行者が使用する端末装置である。
変換サーバ４０は、復号処理を行使しようとしている代行者が、予め定められた制約条件を満たすかをチェックするサーバであり、公開鍵ｅ_Ｔに対応する秘密鍵ｄ_Ｔを持つ。
【００１４】
本実施の形態による暗号通信システムを構成する各端末装置は、ワークステーションやパーソナルコンピュータ、ＰＤＡ（ｐｅｒｓｏｎａｌ　ｄｉｇｉｔａｌ　ａｓｓｉｓｔａｎｔｓ）その他のネットワーク機能を備えた情報処理装置にて実現される。また、変換サーバ４０は、ワークステーションやパーソナルコンピュータ、その他のネットワーク機能を備えたコンピュータ装置にて実現される。これらの装置は、図示しないネットワークを介してメッセージの交換を行う。ネットワークの通信回線は有線であると無線であるとを問わない。
なお図１においては、簡単のため各構成要素を１つずつ記載しているが、実際の運用においては、複数の送信者端末１０や受信者端末２０の間でメッセージの交換を行うことができる。さらに、後述のように変換サーバ４０を複数設けることもできる。また、送信者端末１０、受信者端末２０、代行者端末３０といった呼称は、所定のメッセージの通信における送信者、受信者といった立場に基づいている。したがって、通信の態様に応じて、同一の端末装置が送信者端末１０として機能したり、受信者端末２０として機能したり、代行者端末３０として機能したりする。
【００１５】
送信者端末１０として動作する端末装置は、プログラム制御されたＣＰＵがメッセージを暗号化する暗号化手段として機能し、メモリや磁気ディスク装置などの記憶装置が暗号化の対象であるメッセージを保持するメッセージ保持手段として機能する。
受信者端末２０として動作する端末装置は、プログラム制御されたＣＰＵが秘密鍵にてメッセージを復号する復号手段や後述する手順で委任鍵を生成する委任鍵生成手段として機能し、メモリや磁気ディスク装置などの記憶装置が暗号化されたメッセージを復号するための秘密鍵を保持する秘密鍵保持手段として機能する。
代行者端末３０として動作する端末装置は、プログラム制御されたＣＰＵが委任鍵にてメッセージを復号する復号手段や復号処理において変換サーバに問い合わせをして認証を受ける問い合わせ手段として機能し、メモリや磁気ディスク装置などの記憶装置が受信者端末２０から取得した委任鍵を保持する委任鍵保持手段として機能する。
また、変換サーバ４０として動作するコンピュータ装置は、プログラム制御されたＣＰＵが、委任鍵に伴う制約条件の適否の判定手段や代行者端末３０に返送するパラメータ（後述のｃ_Ｔ）を委任鍵の情報から計算するパラメータ計算手段として機能する。
さらに、これらの装置のネットワーク機能（ＣＰＵ及びネットワークインターフェイス）が、各装置間での通信をになう送受信手段として機能する。
【００１６】
次に、図１に示した４者によって実現される、本実施の形態による制約条件を伴う復号権限の委譲の方法について説明する。
以下の説明において、次に示す関数・アルゴリズムの記述を用いる。
・Ｅ（ｅｎｃ＿ｋｅｙ，　ｐｌａｉｎｔｅｘｔ）：公開鍵ｅｎｃ＿ｋｅｙ及び平文ｐｌａｉｎｔｅｘｔを入力とし、対応する暗号文を出力する既知の暗号化アルゴリズムである。
・Ｄ（ｄｅｃ＿ｋｅｙ，　ｃｉｐｈｅｒｔｅｘｔ）：暗号化アルゴリズムＥにより生成された暗号文ｃｉｐｈｅｒｔｅｘｔ及び秘密鍵ｄｅｃ＿ｋｅｙを入力として、対応する平文を出力する既知の復号アルゴリズムである。
・Ｇ（ｄｅｃ＿ｋｅｙ，　ｐｏｌｉｃｙ）：秘密鍵ｄｅｃ＿ｋｅｙ及び有効期間を含む制約条件ｐｏｌｉｃｙを入力として委任鍵ｄｅｌ＿ｋｅｙを出力する、本実施の形態による鍵生成アルゴリズムである。
・Φ（ｐｏｌｉｃｙ）：制約条件ｐｏｌｉｃｙが成立する場合に１を、不成立の場合に０を出力する既知の判定アルゴリズムであり、変換サーバ４０が秘密に保持する。
・Γ（ｄｅｌ＿ｋｅｙ，　ｐｏｌｉｃｙ，　ｃｉｐｈｅｒｔｅｘｔ）：委任鍵ｄｅｌ＿ｋｅｙ、制約条件ｐｏｌｉｃｙ、及び暗号文ｃｉｐｈｅｒｔｅｘｔを入力とし、対応する平文（Φ（ｐｏｌｉｃｙ）＝１）またはエラー（Φ（ｐｏｌｉｃｙ）＝０）を出力する、本実施の形態による代理復号アルゴリズムである。
・Ｈ（・）：衝突のない一方向性ハッシュ関数。
ここで、制約条件ｐｏｌｉｃｙは、有効期間を含む一般的なポリシー記述とする。例えば「時刻ｔ_１から時刻ｔ_２までの期間、Ｂに対して」を制約条件とした場合、判定アルゴリズムΦは「時刻ｔ_１とｔ_２の間であること」かつ「Ｂが代理復号を行っている」ことを判定する。
【００１７】
本実施の形態による復号権限の委譲は、図１を参照して、次のように定式化される。
（１）送信者端末１０は、受信者端末２０に対応する公開鍵ｅ_Ａにより暗号化された暗号文ｃ＝Ｅ（ｅ_Ａ，ｍ）を受信者端末２０に送信する。
（２）受信者端末２０は、復号権限を制約条件ρが成立する場合に限定して代行者端末３０に委譲するため、秘密鍵ｄ_Ａから委任鍵ｄｅｌ＿ｋｅｙ＝Ｇ（ｄ_Ａ，ρ）を生成し、ｄｅｌ＿ｋｅｙ，ρを代行者端末３０に秘密に送信する。
（３）代行者端末３０は、委任鍵ｄｅｌ＿ｋｅｙ，ρを用いてｍ＝Γ（ｄｅｌ＿ｋｅｙ，ρ，ｃ）によりメッセージを復号する。
本実施の形態では、公開鍵暗号化ＥがＥｌＧａｍａｌ型の暗号方式である場合に、次に挙げる７要件を満たす「復号権限の時限的委譲」の
（１）委任鍵生成アルゴリズムＧの構成法、
（２）代理復号アルゴリズムΓの構成法、
を示す。実現すべきプロトコルの概念図を図２、図３に示す。
【００１８】
図２、３を参照すると、本実施の形態にて実現される暗号通信のプロトコルでは、（１）まず、受信者端末２０にて委任鍵ｄｅｌ＿ｋｅｙを生成し、（２）当該委任鍵ｄｅｌ＿ｋｅｙを代行者端末３０に送信する。この後、送信者端末１０から受信者端末２０の公開鍵で暗号化されたメッセージ（暗号文）が受信者端末２０に送信されると、当該暗号文が受信者端末２０から代行者端末３０に転送される。
代行者端末３０は、受信した暗号文を復号するために、（３）変換サーバ４０へ委任鍵ｄｅｌ＿ｋｅｙに含まれる情報を送信し、暗号文の部分復号を依頼する。これに対し、変換サーバ４０は、（４）まず、委任鍵ｄｅｌ＿ｋｅｙの正当性（制約条件を満足するか否か）を判定する。委任鍵ｄｅｌ＿ｋｅｙが正当であるならば、（５）暗号文の部分復号を行って結果を代行者端末３０に返す。（６）代行者端末３０は、取得した部分復号の結果及び委任鍵ｄｅｌ＿ｋｅｙを用いて暗号文を復号する。
【００１９】
図２、３に示した本実施の形態による暗号通信のプロトコルは、次の７つの要件を満足することが要求される。
１．代理復号アルゴリズムΓの実行により、Φ（ρ）＝０である限り、代行者端末３０がメッセージｍを復号することはできない。
２．代理復号アルゴリズムΓは、代行者端末３０と変換サーバ４０の間における１ラウンドの通信により実現される。
３．送信者（送信者端末１０）は、暗号化をする際に、受信側で権限の委譲が行われているかを知る必要がない。
４．委任鍵生成アルゴリズムＧは、受信者端末２０が単独で実行でき、変換サーバ４０または代行者端末３０との通信を必要としない。
５．変換サーバ４０は、暗号文に関して、送信者（送信者端末１０）及び受信者（受信者端末２０）に依存する情報を保持する必要がない。
６．変換サーバ４０は、代理復号アルゴリズムΓの実行により、受信者端末２０の秘密鍵ｄ_Ａに関する情報を得ることができない。
７．代行者端末３０は、委任鍵ｄｅｌ＿ｋｅｙ及び代行復号アルゴリズムΓの実行により、受信者端末２０の秘密鍵ｄ_Ａに関する情報を得ることができない。
【００２０】
上の７つの要求項目は、復号権限を委譲する際の安全性及び効率性の向上のために必要とされる。具体的には次のようになる。
要件１は、制約条件に基づく復号権限の委譲を実現するための要件である。
要件２は、代理復号の効率を最適化するための要件である。変換サーバ４０で制約条件のチェックを行うことを考慮すると、変換サーバ４０と代行者端末３０との間の通信は、１ラウンドが最適である。
要件３は、送信者端末１０における暗号化処理の効率性のための要件である。受信側で復号権限の委譲が行われているかを送信者端末１０で知るには、受信者端末２０もしくは代行者端末３０との余分な通信を必要とするからである。
要件４は、受信者端末２０が容易に復号権限を委譲できるようにするための要件である。また、復号権限の委譲を受信者端末２０が単独で行えることは、変換サーバ４０や送信者端末１０に対して負荷をかけないために重要である。
要件５は、変換サーバ４０の負荷削減のための要件である。受信者端末２０毎、暗号文毎の情報を保持する必要がないことは、変換サーバ４０の記憶装置の容量削減や安全性向上に寄与する。
要件６は、変換サーバ４０が受信者端末２０の秘密鍵を知りえないようにすることで、変換サーバ４０が不正に受信者端末２０の秘密鍵ｄ_Ａを行使することを防ぐ。
要件７は、復号権限の委譲を行った結果、代行者端末３０が受信者端末２０の秘密鍵ｄ_Ａを知ることを防ぐ。代行者端末３０に秘密鍵ｄ_Ａが漏れると、受信者端末２０に対して送信された暗号文を恒久的に復号することが可能となってしまう。したがって、要件７は、セキュリティ上最も重要な要件である。
【００２１】
以下の説明において、次のパラメータを用いる。ｐ、ｑはｑ｜ｐ−１を満たす大きな素数であり、ｇは有限体Ｚ_ｐ上の位数ｑの元とする。ｐ、ｑのサイズは、ｇを生成元として構成される群ＧＦ（ｑ）上での離散対数問題が計算量的に困難であるように設定するものとする。またこれ以降、特に記述のない場合、演算は、全てｍｏｄｐ上で行われるものとする。
秘密鍵をｘ（∈Ｚ_ｑ）、公開鍵をｙ＝ｇ^ｘとすると、ＥｌＧａｍａｌ暗号は、次の通りである。
メッセージｍ∈Ｚ^＊ _ｐに対する暗号文（ｃ_１，ｃ_２）は、ランダムに選択したｒ∈Ｚ_ｑ及び公開鍵ｙを用いて、ｃ_１＝ｇ^ｒ、ｃ_２＝ｍｙ^ｒとして計算される。復号は、秘密鍵ｘを用いて、ｃ_２／ｃ_１ｘ＝ｍにより計算される。ＥｌＧａｍａｌ暗号の安全性は、ｇ、ｃ_１（＝ｇ_ｒ）、ｙ（＝ｇ_ｘ）の３つの値から、ｃ_１ ^ｘ＝ｙ^ｒ＝ｇ^ｘｒを求める問題（Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ問題）の計算量的な困難性に基づく。
【００２２】
なお、本実施の形態におけるＥｌＧａｍａｌ暗号化方式は、離散対数問題が計算量的に困難となるような任意の群ＧＦ（ｑ）上で定義される任意の暗号化方式（ＥｌＧａｍａｌ型の暗号化方式）に対して適用が可能である。このような群としては、位数ｐの素体の他にも以下のものが挙げられる。
・位数ｐの素体上での乗法演算を、任意の有限体上の楕円曲線などの曲線上の加法演算に対応させることにより構成される群。
・素数ｐに代えて素数ｐ’のべき乗数とし、素数ｐ’を法とする剰余演算に代えてＧＦ（ｐ’）の拡大体上での演算を行なうことにより構成される群。
【００２３】
以下、本実施の形態による復号権限の委譲方法について、変換サーバ４０が信頼機関であると仮定する基本方式と、変換サーバ４０を信頼機関としない２種類の拡張方式とに分けて説明する。信頼機関であるとは、知り得た情報を他者に漏らしたり、他者と結託して不正を行ったりするというような、定められた手順を逸脱した行為を行わないことが保証されたメンバを意味する。
また、基本方式、拡張方式共に、暗号通信の手順として、次のような前提を置くものとする。
送信者端末１０が受信者端末２０に向けてメッセージｍ∈Ｚ^＊ _ｐをＥｌＧａｍａｌ暗号化して送信する。より一般的には、メッセージＭを、鍵Ｋを用いて対称鍵暗号で暗号化し、その鍵ＫをＥｌＧａｍａｌ暗号化して送信する場面があるが、この場合、鍵Ｋを送信対象メッセージｍと見なすことで同一視することが可能となる。送信者端末１０は、ランダムに選択したｒ∈Ｚ_ｑ及び受信者端末２０の公開鍵ｅ_Ａ＝ｇ^ｄＡを用いて、ｃ_１＝ｇ^ｒ、ｃ_２＝ｍｅ_Ａ ^ｒを計算する。２つの値の組（ｃ_１，ｃ_２）を暗号文として受信者端末２０に対して送信される。受信者端末２０の復号権限を代行者端末３０に対して委譲し、ある制約条件の下で復号処理の代行を依頼するものとする。
【００２４】
〔基本方式〕
１．委任鍵生成アルゴリズムＧの構成
秘密鍵ｄ_Ａ（∈Ｚ_ｑ）を持つ受信者端末２０が、時限的な情報などの制約条件ρの下で、代行者端末３０に対して復号権限を委譲するための委任鍵ｄｅｌ＿ｋｅｙを生成するアルゴリズムを示す。
図４は、委任鍵生成アルゴリズムＧの概念を説明する図である。図４に示す例では、制約条件ρとして復号権限の有効期間（ｔ_１≦ｔ≦ｔ_２）を加味している。受信者端末２０は、乱数ｒ_Ａ∈Ｚ^＊ _ｐを選択し、変換サーバ４０の公開鍵ｅ_Ｔを用いてｕ_Ｔ、ｕ_Ｂを求め、制約条件ρ（図４の例では、開始時刻ｔ_１及び終了時刻が相当する）を併せて委任鍵ｄｅｌ＿ｋｅｙとする。
【数１】

生成された委任鍵ｄｅｌ＿ｋｅｙは、受信者端末２０から代行者端末３０へ送信される。代行者端末３０では、この委任鍵ｄｅｌ＿ｋｅｙに含まれる制約条件ρを満足する場合にのみ、この委任鍵ｄｅｌ＿ｋｅｙを用いて、受信者端末２０の公開鍵ｅ_Ａで暗号化されたメッセージを復号することが可能となる。
【００２５】
２．代理復号アルゴリズムΓの構成
代行者端末３０が委任鍵ｄｅｌ＿ｋｅｙ及び制約条件ρを用いて受信者端末２０に対する暗号文（ｃ_１，ｃ_２）を復号するためには、次の処理（（ａ）〜（ｃ））を行う。
図５は、代理復号アルゴリズムΓの概念を説明する図である。図４と同様に、制約条件ρとして復号権限の有効期間（ｔ_１≦ｔ≦ｔ_２）を加味している。
（ａ）代行者端末３０は、復号しようとするメッセージ（暗号文）に対応する委任鍵ｄｅｌ＿ｋｅｙに含まれるｕ_Ｔ、制約条件ρ、及び暗号文の一部ｃ_１を変換サーバ４０に対して送信する。
（ｂ）変換サーバ４０は、判定アルゴリズムΦによりΦ（ρ）＝１であることを確認する。これが満たされない場合は、エラーを返す。すなわちこの場合、代行者端末３０は、メッセージの代理復号を行うことができない。Φ（ρ）＝１であることを満たす場合には、ｗ_Ｔ、ｃ_Ｔを、次の数２式のように計算し、ｃ_Ｔを代行者端末３０に対して送信する。
【数２】

（ｃ）代行者端末３０は、ｃ_１、ｃ_２、ｃ_Ｔを用いてメッセージｍの復号を行う。
【数３】

【００２６】
この基本方式は、先に述べた７つの要件全てを満たす。
まず、代理復号アルゴリズムΓにおいて、代行者端末３０は変換サーバ４０から送信されるｃ_Ｔの情報なしにメッセージを復号できないこと、（ｂ）の段階で変換サーバにより制約条件ρの正当性をチェックされていること、（ａ）の段階で送られる制約条件ρを偽った場合、（ｂ）において復号を可能にするｃ_Ｔを得ることができないことにより、要件１が満たされる。また要件２〜５は、上記手順から明らかに満たされている。
次に、代理復号Γの実行中に変換サーバ４０が受信者端末２０の秘密鍵ｄ_Ａに関して知るのは、高々ｄ_Ａ−ｕ_Ｂのみである。ここで、ｕ_Ｂは変換サーバ４０に明かされないため、変換サーバ４０が受信者端末２０の秘密鍵ｄ_Ａに関する情報を得ることはできず、要件６も満たされる。
最後に、要件７を満たすことを示す。代行者端末３０が得ることのできる全ての情報は、ρ、ｃ_１、ｃ_２、ｃ_Ｔ、ｕ_Ｂ、ｅ_Ａ、ｅ_Ｔである。秘密鍵ｄ_Ａに関してｄ_Ａ＝ｕ_Ｂ＋ｗ_Ｔ（ｍｏｄｑ）が成立すること、及びｗ_Ｔ＝Ｈ（ρ，Ｄ（ｄ_Ｔ，ｕ_Ｔ））はｄ_Ｔを持つ変換サーバ４０のみが知りえることから、秘密鍵ｄ_Ａは、ｕ_Ｂを持つ代行者端末３０とｗ_Ｔを持つ変換サーバ４０との間で秘密分散されていると見なすことができる。すると、ｃ_Ｔは変換サーバ４０による暗号文ｃ_１、ｃ_２に対する（２，２）閾値復号の部分復号結果である。したがって、閾値復号の安全性の議論より、代行者端末３０が単独で秘密鍵ｄ_Ａに関する情報を得ることはできないので、要件７も満たされることがわかる。
【００２７】
〔拡張方式１〕
上記の基本方式は、変換サーバが信頼機関であると仮定する。変換サーバ４０が不正にｗ_Ｔを代行者端末３０へ知らせた場合、代行者端末３０は、ｄ_Ａ＝ｕ_Ｂ＋ｗ_Ｔ（ｍｏｄｑ）により受信者端末２０の秘密鍵ｄ_Ａを復号できるため、安全性は変換サーバ４０の信頼性に大きく依存する。そこで、複数の変換サーバを利用して基本方式に示した変換サーバ４０の機能を秘密分散することにより、単一の変換サーバによる不正を防止する方式（拡張方式１）を提案する。
図６は、拡張方式１にて実現されるプロトコルの概念を説明する図である。
拡張方式１は、代理復号Γの実行に複数の変換サーバ４０ｉ（１≦ｉ≦ｎ）のチェックを必要とし、変換サーバ４０ｉのうちの１つでも正確に動作する限り、変換サーバ４０ｉ及び代行者端末３０はメッセージを不正に復号したり、秘密鍵ｄ_Ａを取得したりすることはできない。以下の説明において、変換サーバ４０ｉの公開鍵をｅ_ｉ、復号鍵をｄ_ｉ、ＩＤをｉとする。
【００２８】
１．委任鍵生成アルゴリズムＧの構成
秘密鍵ｄ_Ａ（∈Ｚ_ｑ）を持つ受信者端末２０が、ある制約条件の下で代行者端末３０に対して復号権限を委譲するための委任鍵ｄｅｌ＿ｋｅｙを生成するアルゴリズムを示す。
まず、受信者端末２０は、代理復号に必要な変換サーバ４０ｉの集合を選択する。ここで、選択された変換サーバ４０ｉのＩＤの集合（リスト）をＴ＝｛１，・・・，ｎ｝とする。（ｎ＝｜Ｔ｜は選択した変換サーバの数）。また、変換サーバ４０ｉに検証を依頼したい制約条件をρとする。
【００２９】
次に、受信者端末２０は、ｎ個の乱数ｒ_１、・・・、ｒ_ｎ∈Ｚ_ｐを選択し、変換サーバ４０ｉの公開鍵ｅ_ｉを用いて、次の数４式により、ｕ_１、・・・、ｕ_ｎを求める。
【数４】

また、ｕ_Ｂを次の数５式により計算する。
【数５】

そして、以上の結果から委任鍵ｄｅｌ＿ｋｅｙを生成する。
ｄｅｌ＿ｋｅｙ＝＜ｕ_Ｂ，ｕ_１，・・・，ｕ_ｎ，Ｔ＞
【００３０】
２．代理復号アルゴリズムΓの構成
代行者端末３０が制約条件ρ、委任鍵ｄｅｌ＿ｋｅｙを用いて受信者端末２０に対する暗号文（ｃ_１，ｃ_２）を復号するためには、次の処理（（ａ）〜（ｃ））を行う。
（ａ）代行者端末３０は、復号しようとするメッセージ（暗号文）に対応する委任鍵ｄｅｌ＿ｋｅｙを特定し、全てのｉ∈Ｔについて、当該委任鍵ｄｅｌ＿ｋｅｙに含まれるρ、ｕ_ｉ及び暗号文の一部ｃ_１を変換サーバ４０ｉに対して送信する。
（ｂ）変換サーバ４０ｉは、Φ（ρ）＝１となることを確認する。これが満たさない場合はエラーを返す。この場合、代行者端末３０は、メッセージ（暗号文）の代理復号を行うことができない。Φ（ρ）＝１となることを満たす場合には、ｗ_ｉ，ｃ_Ｔｉを次の数６式のように計算し、得られたｃ_Ｔｉを代行者端末３０に対して送信する。
【数６】

（ｃ）代行者端末３０は、ｃ_１、ｃ_２、ｃ_Ｔ１、・・・、ｃ_Ｔｎを用いてメッセージｍの復号を行う。
【数７】

【００３１】
この拡張方式１が先に述べた７つの要件全てを満たすことを示す。
秘密鍵ｄ_Ａに関してｄ_Ａ＝ｕ_Ｂ＋ｗ_１＋・・・＋ｗ_ｎ（ｍｏｄｑ）が成立すること、およびｗ_ｉ＝Ｈ（ρ，Ｄ（ｄ_ｉ，ｕ_ｉ））は秘密鍵ｄ_ｉを持つ変換サーバ４０ｉのみが知り得ることから、秘密鍵ｄ_Ａは、ｕ_Ｂを持つ代行者端末３０及びそれぞれｗ_ｉを持つｎ個の変換サーバ４０１、・・・、４０ｎの間で秘密分散されていると見なすことができる。また、ｃ_Ｔ１、・・・、ｃ_Ｔｎは、変換サーバ４０１、・・・、４０ｎによる暗号文ｃ_１、ｃ_２に対する（ｎ＋１，ｎ＋１）閾値復号の部分復号結果であると見なすことができる。したがって、代理復号アルゴリズムΓにおいて代行者端末３０は、ｎ個全ての変換サーバから送信されるｃ_Ｔ１、・・・、ｃ_Ｔｎの情報なしにメッセージを復号できないこと、（ｂ）の段階で全ての変換サーバ４０１、・・・、４０ｎにより復号時刻の正当性をチェックされていること、（ａ）の段階で代行者端末３０が変換サーバ４０ｉに送る制約条件ρを偽った場合、（ｂ）において復号に必要なｃ_Ｔｉを得ることができないことにより、要件１は満たされる。
要件２−５は、基本方式と同様に、上記手順から明らかに満たされている。また、閾値復号の安全性から要件６、７も満たされる。
【００３２】
拡張方式１は、代理復号アルゴリズムΓの実行に、受信者端末２０により指定された全ての変換サーバ４０１、・・・、４０ｎのチェックを通過することを必要とするので、変換サーバ４０ｉの１つでも正確に動作すれば安全性が保証される。したがって、単一のサーバに対する信頼に依存しない点で基本方式より優れる。一方、委任鍵ｄｅｌ＿ｋｅｙのメッセージ長及び代理復号に必要となる通信量は、変換サーバ４０ｉの数ｎに比例してしまう。だが、ｎは受信者自身が復号権限の委譲にどの程度の安全性を求めるかによって自由に選択することができるパラメータであり、高度な安全性を求める場合にはより多くのコストを必要とする点で現実のモデルと適合している。また、ｎの変化は、送信者端末１０における暗号化や変換サーバ４０の記憶領域サイズに影響を及ぼさず、受信者端末２０と代行者端末３０の間にだけ影響を及ぼす点も、システムの拡張性に大きく寄与する。
【００３３】
〔拡張方式２〕
図７は、拡張方式２にて実現されるプロトコルの概念を説明する図である。
拡張方式１では、メッセージ（暗号文）復号のために、ｎ個の変換サーバ４０ｉ全ての検証を通過する必要があった。拡張方式２では、ｎ個の変換サーバ４１ｉ（１≦ｉ≦ｎ）のうち、ｔ個の変換サーバ４１ｉの検証を通過することで復号できるように変更する。以下の説明において、変換サーバ４１ｉの公開鍵をｅ_ｉ、復号鍵をｄ_ｉ、ＩＤをｉとする。
１．委任鍵生成アルゴリズムＧの構成
秘密鍵ｄ_Ａ（∈Ｚ_ｑ）を持つ受信者端末２０が、ある制約条件の下で代行者端末３０に対して復号権限を委譲するための委任鍵ｄｅｌ＿ｋｅｙを生成するアルゴリズムを示す。
まず、受信者端末２０は代理復号に必要な変換サーバ集合４１ｉの集合を選択する。ここで、選択された変換サーバ４１ｉのＩＤの集合（リスト）をＴ＝｛１、・・・、ｎ｝とする。（ｎ＝｜Ｔ｜は選択した変換サーバの数）。また、変換サーバ４１ｉに検証を依頼したい制約条件をρとする。
【００３４】
次に、受信者端末２０はｎ個の乱数ｒ_１、・・・、ｒ_ｎ∈Ｚ_ｐを選択し、変換サーバ４１ｉの公開鍵ｅ_ｉを用いて、次の数８式により、ｕ_１、・・・、ｕ_ｎを求める。
【数８】

また、次の数９式のようにｎ−１次多項式ｆ（ｘ）を定義する。
【数９】

そして、ｕ_Ｂを次の数１０式で計算する
【数１０】

また、Ｚ_ｑ＼Ｔからｎ−ｋ個の整数の集合Γ＝｛ｉ_１、・・・、ｉ_ｎ−ｋ｝を選び、τ_ｊ（ｊ＝１、・・・、ｎ−ｋ）∈Γ
を、
τ_ｊ＝ｆ（ｉ_ｊ）
として計算する。このとき、委任鍵ｄｅｌ＿ｋｅｙは、次のように生成される。
ｄｅｌ＿ｋｅｙ＝＜τ_１，・・・，τ_ｎ−ｋ，ｕ_Ｂ，ｕ_１，・・・，ｕ_ｎ，Ｔ＞
【００３５】
２．代理復号アルゴリズムΓの構成
代行者端末３０が制約条件ρ、委任鍵ｄｅｌ＿ｋｅｙを用いて受信者端末２０に対する暗号文（ｃ_１，ｃ_２）を復号するためには、次の処理（（ａ）〜（ｃ））を行う。
（ａ）代行者端末３０は、復号しようとするメッセージ（暗号文）に対応する委任鍵ｄｅｌ＿ｋｅｙを特定し、Ｔの部分集合Ｔ’を選ぶ（Ｔ’⊂Ｔ∧｜Ｔ’｜＝ｋ）。全てのｉ∈Ｔ’について、当該委任鍵ｄｅｌ＿ｋｅｙに含まれるρ、ｕ_ｉ及び暗号文の一部ｃ_１を変換サーバ４１ｉに対して送信する。
（ｂ）変換サーバ４１ｉは、Φ（ρ）＝１となることを確認する。これが満たさない場合はエラーを返す。この場合、代行者端末３０は、メッセージ（暗号文）の代理復号を行うことができない。Φ（ρ）＝１となることを満たす場合には、ｗ_ｉ，ｃ_Ｔｉを次の数１１式のように計算し、得られたｃ_Ｔｉを代行者端末３０に対して送信する。
【数１１】

（ｃ）代行者端末３０は、ｃ_１、ｃ_２、ｃ_Ｔ１、・・・、ｃ_Ｔｋを用いてメッセージｍの復号を行う。
【数１２】

【００３６】
この拡張方式２は、拡張方式１と同様に、先に述べた７つの要件全てを満足する。
拡張方式２では、代理復号アルゴリズムΓの実行に、受信者端末２０により指定されたｎ個の変換サーバ４１１、・・・、４１ｎのうちｔ個のチェックを通過することを必要とする。したがって、ｔ個の変換サーバ４１ｉの１つでも正確に動作すれば安全性が保証されることは拡張方式１と同様である。
【００３７】
以上のように、本実施の形態（基本方式、拡張方式１、２を含む）では、変換サーバ４０、４０ｉ、４１ｉという中立な第３者機関を利用することで、暗号文の受信者端末２０が、有効期間などの制約条件が成立する場合に限り、復号処理の代行を代行者端末３０に対して依頼できるような暗号通信システムが実現される。制約条件としては、他に、例えば代行者端末３０が受信者端末２０から認証を受けること、課金により制約条件を満たす情報を取得していることなどを設定することができる。
この暗号通信システムの特徴をまとめると、次のようになる。
・閾値復号の技術を応用することで、受信者端末２０の秘密鍵の運用を、変換サーバ４０と代行者端末３０との間で分散する。これにより、代行者端末３０が変換サーバ４０のチェックを通過した場合にのみ、暗号文の復号処理を行うことが可能となる。また、復号処理を通じて、変換サーバ４０、代行者端末３０のいずれも受信者の秘密鍵を知ることはできない。
・一方向性ハッシュ関数を利用し、復号処理に制約条件のチェック機能を含める。これにより、代行者端末３０は、変換サーバ４０が行う制約条件が成立するかのチェックを通過しない限り復号ができず、また、満たすべき制約条件を偽って変換サーバ４０に報告しても復号処理を継続することができない。
・変換サーバ４０の公開鍵を利用することで、受信者端末２０が単独で委任鍵を生成し代行者端末３０に与えるだけで復号権限の委譲を完了することを可能にする。これにより、復号権限の委譲が容易に行える。
なお、本実施の形態は、暗号化方式に変更を加えないため、既存の多くの暗号化サービスに適用できる。
【００３８】
次に、種々のネットワークシステムに対する本実施の形態の適用例について説明する。
〔代理復号サービスプロバイダ〕
複数のホストコンピュータ（以下、ホストと略す）を含み、暗号通信を行うネットワークシステムに対し、変換サーバ４０として動作する代理復号サービスプロバイダを提供することにより、かかるネットワークシステムに本実施の形態による暗号通信システムを実現することができる。
図８は、この代理復号サービスプロバイダの提供により、本実施の形態の暗号通信システムを実現するネットワーク構成を説明する図である。
所定の暗号通信におけるメッセージ（暗号文）を受信して復号する動作するホストＡ（受信者端末２０に相当する）が、ネットワークの通信トラフィックの増大や一時的な故障などにより暗号文の復号処理を行えなくなった場合、当該メッセージの複合機能を持つホストＢ（代行者端末３０に相当する）に一時的に復号処理を委託する必要が生ずる。この場合、さらに、ホストＡの機能が復旧した後は、ホストＢから復号権限を取り戻したいというケースが考えられる。このような代理復号をサポートするために、本実施の形態にて説明した変換サーバ４０の役割を担うサービスプロバイダ８０１をネットワーク上で提供する。
このサービスプロバイダ８０１は、本実施の形態に基づいて、閾値復号の技術を用いた分散により、ホストＢの復号処理のサポートを行う。また、当該復号処理に関して、本実施の形態による制約条件を満足するために、復号時刻のチェックを行ったり、復号回数に応じた課金を行ったりする。
【００３９】
図８を参照して、サービスプロバイダ８０１を含むネットワークシステムでの暗号通信の処理の流れを説明する。
まず、ホストＡにおいて委任鍵ｄｅｌ＿ｋｅｙが生成され、ホストＢに渡される（処理１）。これに伴い、ホストＡは、受信した暗号文をホストＢへ転送（フォワード）するように設定する。
そして、ホストＡがネットワークから自分宛で送信された暗号文を受け取ると、当該暗号文がホストＢへ転送される（処理２）。これに応じて、ホストＢは到着した暗号文を復号するため、サービスプロバイダ８０１へ問い合わせを行う（処理３）。サービスプロバイダ８０１は、復号時刻をチェックし、復号処理のサポートを行う。場合によっては、復号回数に応じてホストＡへ課金を行う（処理４）。
課金を伴うシステムでは、権限委譲自体には課金が発生せず、復号処理に対して課金されるため、使用回数に応じた料金のみを支払えば良いという長所がある。また課金を伴わないシステムであっても、サービスプロバイダ８０１を含む暗号通信システムを構築することで、ネットワーク上での安全な復号権限の時限委譲を実現するサービスを提供できる。
【００４０】
〔耐性・秘匿性のあるＰｔｏＰデータベース〕
ＰｔｏＰ（ピア・ツー・ピア）技術を用いたデータベースシステム（ＰｔｏＰデータベース）は、各ホスト（ピア）の持つデータを他のピアから検索・ダウンロードできるようにすることで巨大なデータベースを構成しようとするものである。また、各ピアの持つ余剰ストレージを他のピアから利用できるようにすることで、余剰資源の有効活用も可能となる。
ＰｔｏＰデータベースでは、ネットワーク全体を一つの巨大なストレージと見なすので、ピアの持つデータに対するアクセスを制限するために暗号化技術が用いられる。ところが、従来の中央サーバで管理されるデータベースと異なり、ＰｔｏＰネットワークにおいてはピアのネットワークからの離脱（非接続状態になること）が頻繁に起こりうる。すなわち、所定のピアがＰｔｏＰデータベース上に暗号化された状態で保管されているデータに対するアクセスを必要とした時、復号に必要となる鍵を保持するピアがネットワークに接続状態にない可能性があることとなる。
したがって、ピアが非接続状態になっている間、接続状態にあって信頼できる他のピアに復号権限を委譲できれば、暗号化されたデータに対するアクセシビリティが大きく広がり、秘匿性と耐性を兼ね備えたＰｔｏＰデータベースを構築することが可能になる。
【００４１】
図９は、本実施の形態を適用したＰｔｏＰデータベースの構成を示す図である。
図９において、ＰｔｏＰでネットワーク接続されている６台のピアのうち、ピアＤがネットワークから離脱したものとする。このとき、ピアＤの復号権限を時間的制限を与えてピアＣに与える（すなわち、時間的制約条件を持った委任鍵ｄｅｌ＿ｋｅｙをピアＣに渡す）。
この状態で、所定のピアＡからピアＤの持つ復号鍵（秘密鍵）にて復号されるデータへのアクセス要求が発行されたものとする。かかるデータを保有するピアＢは、ピアＤから委任鍵ｄｅｌ＿ｋｅｙを渡されているピアＣにデータの復号を依頼する。これに応じて、ピアＣは、委任鍵ｄｅｌ＿ｋｅｙに含まれる制約条件の下で、変換サーバ４０のサポートを経て当該データの代理復号を行う。
【００４２】
〔ＰｔｏＰマルチキャストのためのグループ鍵生成〕
図１０に示すようなＰｔｏＰネットワークにおいて、所定の送信者１００１が所定のグループ１０１０に対してメッセージを配信する際に、一定数以上のグループメンバ１０１１の承認があった場合のみメッセージを復号可能にしたいというケースがある。例としては、合意事項の議題の伝達や暗号化されたコンテンツの配信などが挙げられる。かかるケースにおいて、所定のグループメンバが、承認する意思はあるものの、ピアがネットワークに対して非接続状態にあるために承認プロトコルに参加できず、グループ全体としてメッセージを復号できない場合がある。
このような場合、当該ＰｔｏＰネットワークに本実施の形態を適用し、委任鍵ｄｅｌ＿ｋｅｙを他のグループメンバのピアに渡すことにより、復号権限の時限的な委譲を行うことができる。すなわち、当該委任鍵ｄｅｌ＿ｋｅｙに含まれる時間的制約の下で、メッセージの復号に対する承認を他のグループメンバに委任することができる。
【００４３】
〔暗号化データのアクセス制御−暗号文の送信者と受信者が同一の場合〕
本実施の形態による暗号システムにおいて、暗号文の送信者と受信者は別のエンティティである必要はない。受信者自身が暗号文の送信者となることも可能である。
図１１は、受信者自身が暗号文の送信者であるようなシステムの構成を示す図である。
図１１に示すように、受信者かつ送信者である端末装置１１０１は、予め自分の秘密鍵でのみ復号できる暗号文を生成し、公開されたデータベース１１１０に格納しておく。そして、委任鍵ｄｅｌ＿ｋｅｙを生成すると共に、当該暗号文の代理復号を代行者端末３０に依頼する。本実施の形態による暗号システムを用いることにより、代行者端末３０の代理復号権の行使に対して一定の条件を課すことが可能となる。
【００４４】
〔携帯端末を用いたパスワード管理〕
本実施の形態による暗号システムを用いて、携帯端末による情報管理を行うことができる。
図１２は、かかる管理システムの構成を示す図である。
図１２を参照すると、この管理システムは、送信者端末１０及び受信者端末２０に相当するホストコンピュータ１２０１と、代行者端末３０に相当する携帯端末１２０２を備える。ホストコンピュータ１２０１に格納された情報（例えばパスワード）を暗号化しておき、これを復号するための委任鍵ｄｅｌ＿ｋｅｙを携帯端末１２０２に渡しておけば、ホストコンピュータ１２０１を操作できない場合（例えばユーザが離れた場所にいる場合）であっても、携帯端末１２０２から変換サーバ４０へ通信を行って復号処理のサポートを受けることで、暗号文を安全に復号することができる。ホストコンピュータ１２０１から携帯端末１２０２への委任鍵ｄｅｌ＿ｋｅｙの送信は、電子メールなどの手段を用いて行うことができる。また、携帯端末１２０２として携帯電話などを用いる場合でも、株式会社ＮＴＴドコモが提供するｉモードなどのデータ通信サービスを利用することにより、変換サーバ４０との通信を行って復号処理を行うことが可能である。
かかる管理システムにおいて、携帯端末１２０２での代理復号が可能になるための制約条件（時間的条件や携帯端末１２０２の持ち主のみが知り得るパスワードなど）を予め記述しておくことで、携帯端末１２０２を紛失した場合に、他人に暗号文を復号されてしまう危険性を回避できる。
【００４５】
〔所定期間内での契約文書の調印を条件とする契約文書の交換〕
所定の期間内に契約を完了する電子署名を入手した場合に限り、暗号文を復号し中身を読むことが許されるアプリケーションが存在する。例えば、暗号化された有料デジタルコンテンツを利用する場合、期限内に振込みが行われたことを示す電子署名を持つ端末装置においてのみ、コンテンツの復号が許可される。このようなケースにおいても、本実施の形態の暗号システムを利用して暗号文の送信システムを構築できる。
図１３は、このようなアプリケーションにおける暗号文提供方法を説明する図である。
図１３において、暗号文（デジタルコンテンツ）を提供するコンテンツ提供サーバ１３０１を送信者端末１０及び受信者端末２０に相当すると考え、当該暗号文の利用者の端末装置１３０２を代行者端末３０と考え、当該暗号文と共にまたは別途に、当該電子署名の情報を制約条件として設定した委任鍵ｄｅｌ＿ｋｅｙを端末装置１３０２に渡しておく。これにより、上記のように電子署名を持つ端末装置１３０２においてのみ、変換サーバ４０のサポートを受けて暗号文を復号することができることとなる。
【００４６】
【発明の効果】
以上説明したように、本発明によれば、一定の制限の下で暗号文の復号権限を委譲することの容易な暗号通信を実現することができる。
また本発明によれば、かかる暗号通信を用いて柔軟なセキュリティサービスを実現した暗号通信システムを提供することができる。
【図面の簡単な説明】
【図１】本実施の形態による復号権の委譲方法を実現する暗号通信システムの概略構成を説明する図である。
【図２】本実施の形態の基本方式にて実現されるプロトコルにおいて、委任鍵ｄｅｌ＿ｋｅｙの生成及び代理復号権の委譲を説明する図である。
【図３】本実施の形態の基本方式にて実現されるプロトコルにおいて、代行者端末による代理復号を説明する図である。
【図４】本実施の形態における委任鍵生成アルゴリズムＧの概念を説明する図である。
【図５】本実施の形態における代理復号アルゴリズムΓの概念を説明する図である。
【図６】本実施の形態の拡張方式１にて実現されるプロトコルの概念を説明する図である。
【図７】本実施の形態の拡張方式２にて実現されるプロトコルの概念を説明する図である。
【図８】代理復号サービスプロバイダの提供により、本実施の形態の暗号通信システムを実現するネットワーク構成を説明する図である。
【図９】本実施の形態を適用したＰｔｏＰデータベースの構成を示す図である。
【図１０】本実施の形態を適用したＰｔｏＰネットワークにおいて実現されるマルチキャストを説明する図である。
【図１１】本実施の形態を適用した暗号システムにおいて、受信者自身が暗号文の送信者であるようなシステムの構成を示す図である。
【図１２】本実施の形態を適用した暗号システムにおいて、携帯端末による情報管理方法を説明する図である。
【図１３】本実施の形態を適用した暗号システムにおいて、電子署名を持つ端末装置においてのみ暗号文を復号することが可能となる暗号文提供システムの構成を示す図である。
【符号の説明】
１０…送信者端末、２０…受信者端末、３０…代行者端末、４０、４０ｉ、４１ｉ…変換サーバ

Claims (19)

1. メッセージを暗号化して送信する送信者端末と、
   暗号化された前記メッセージを受信して復号する受信者端末と、
   前記受信者端末による前記メッセージの復号を代行する代行者端末と、
   前記代行者端末による前記メッセージの復号を支援する変換サーバとを備え、
   前記送信者端末は、前記受信者端末の公開鍵を用いて前記メッセージの暗号化を行い、
   前記受信者端末は、前記変換サーバの公開鍵と所定の制約条件と前記メッセージを復号するための秘密鍵とを用いて、当該制約条件の下で前記メッセージの復号が可能な委任鍵を生成して前記代行者端末に渡し、
   前記変換サーバは、前記代行者端末から前記委任鍵の少なくとも一部を取得し、取得した情報に基づいて当該代行者端末による前記メッセージの復号権限を認証し、
   前記代行者端末は、前記変換サーバによる認証を受けて前記メッセージの復号を行うことを特徴とする暗号通信システム。
2. 前記受信者端末は、制約条件として時間的制限を設定して前記委任鍵を生成することを特徴とする請求項１に記載の暗号通信システム。
3. 前記受信者端末は、一方向性ハッシュ関数を用いて前記委任鍵を生成し、
   前記変換サーバは、前記一方向性ハッシュ関数を用いて、前記代行者端末の委任鍵が前記制約条件を満足するかどうかを認証することを特徴とする請求項１に記載の暗号通信システム。
4. 前記変換サーバは複数設けられ、前記代行者端末による前記メッセージの復号権限の認証を、当該複数の変換サーバによる秘密分散にて行うことを特徴とする請求項１に記載の暗号通信システム。
5. メッセージを暗号化して送信する送信者端末と、
   暗号化された前記メッセージを復号する秘密鍵を保持する受信者端末と、
   前記受信者端末の秘密鍵に基づいて前記メッセージの復号を代行する代行者端末と、
   前記代行者端末による前記メッセージの復号処理に対する認証を行う変換サーバとを備え、
   閾値復号を用いて、前記受信者端末の秘密鍵の運用を前記代行者端末と前記変換サーバとで分散することにより、当該変換サーバの認証を得た場合に、当該代行者端末が前記メッセージの復号可能となることを特徴とする暗号通信システム。
6. 前記受信者端末は、前記代行者端末による前記メッセージの復号を代行する権限に所定の制約条件を設定し、
   前記変換サーバは、前記代行端末による前記メッセージの復号処理が前記制約条件を満足しているか否かを認証することを特徴とする請求項５に記載の暗号通信システム。
7. 前記受信者端末は、制約条件として時間的制限を設定することを特徴とする請求項６に記載の暗号通信システム。
8. 前記変換サーバは複数設けられ、当該複数の変換サーバによる秘密分散にて前記認証を行うことを特徴とする請求項５に記載の暗号通信システム。
9. 暗号化されたメッセージを受信して復号する端末装置であって、
   自身の公開鍵を用いて暗号化されたメッセージを復号するための秘密鍵を保持する秘密鍵保持手段と、
   所定の変換サーバの公開鍵と所定の制約条件と前記秘密鍵とに基づいて、当該制約条件の下で当該メッセージの復号が可能な委任鍵を生成する委任鍵生成手段とを備え、
   前記メッセージの復号を代行する所定の代行者端末に前記委任鍵生成手段にて生成された委任鍵を渡すことを特徴とする端末装置。
10. 前記委任鍵生成手段は、一方向性ハッシュ関数を用いた計算により前記委任鍵を生成することを特徴とする請求項９に記載の端末装置。
11. 前記委任鍵生成手段は、制約条件として時間的制限を設定することを特徴とする請求項９に記載の端末装置。
12. 所定の変換サーバの公開鍵と所定の制約条件と暗号化されたメッセージを復号するための秘密鍵とに基づき、一方向性ハッシュ関数を用いて生成された、当該制約条件の下で当該メッセージの復号が可能な委任鍵を保持する委任鍵保持手段と、
    前記委任鍵の少なくとも一部を前記変換サーバに送信し、当該変換サーバによる前記制約条件に応じた認証結果として得られるパラメータを当該変換サーバから受信する問い合わせ手段と、
    前記変換サーバから取得した前記パラメータと前記委任鍵とを用いて前記メッセージを復号する復号手段と
    を備えることを特徴とする端末装置。
13. 前記委任鍵保持手段に保持されている前記委任鍵は、複数の変換サーバの公開鍵に基づいて生成されており、
    前記問い合わせ手段は、前記公開鍵に対応する複数の前記変換サーバに対して情報の送受信を行うことを特徴とする請求項１２に記載の端末装置。
14. 所定の制約条件と第１の公開鍵で暗号化されたメッセージの一部と第２の公開鍵で暗号化された所定の情報とを、所定の端末装置から受信する受信手段と、
    取得した前記制約条件の適否を判定する判定手段と、
    前記第２の公開鍵に対応する秘密鍵で前記所定の情報を復号し、当該所定の情報と前記制約条件と前記第１の公開鍵で暗号化されたメッセージの一部とを用いて、前記メッセージを復号するためのパラメータを計算するパラメータ計算手段と、
    前記パラメータ計算手段にて計算された前記パラメータを前記所定の端末装置に送信する送信手段と
    を備えることを特徴とするサーバ。
15. 前記パラメータ計算手段は、一方向性ハッシュ関数を用いて前記パラメータを計算することを特徴とする請求項１４に記載のサーバ。
16. コンピュータを制御して、暗号化されたメッセージを復号するプログラムであって、
    自身の公開鍵を用いて暗号化されたメッセージを復号するための秘密鍵を所定の記憶装置に保持する機能と、
    所定の変換サーバの公開鍵と所定の制約条件と前記秘密鍵とに基づき、一方向性ハッシュ関数を用いて、当該制約条件の下で当該メッセージの復号が可能な委任鍵を生成する機能と、
    前記メッセージの復号を代行する所定の代行者端末に前記委任鍵を送信する機能と
    を前記コンピュータに実現させることを特徴とするプログラム。
17. コンピュータを制御して、暗号化されたメッセージを復号するプログラムであって、
    所定の変換サーバの公開鍵と所定の制約条件と暗号化されたメッセージを復号するための秘密鍵とに基づき、一方向性ハッシュ関数を用いて生成された、当該制約条件の下で当該メッセージの復号が可能な委任鍵を所定の記憶装置に保持する機能と、
    前記委任鍵の少なくとも一部を前記変換サーバに送信し、当該変換サーバによる前記制約条件に応じた認証結果として得られるパラメータを当該変換サーバから受信する機能と、
    前記変換サーバから取得した前記パラメータと前記委任鍵とを用いて前記メッセージを復号する機能と
    を前記コンピュータに実現させることを特徴とするプログラム。
18. コンピュータを制御して、暗号化されたメッセージを復号するプログラムであって、
    所定の制約条件と第１の公開鍵で暗号化されたメッセージの一部と第２の公開鍵で暗号化された所定の情報とを、所定の端末装置から受信する機能と、
    取得した前記制約条件の適否を判定する機能と、
    前記第２の公開鍵に対応する秘密鍵で前記所定の情報を復号し、当該所定の情報と前記制約条件と前記第１の公開鍵で暗号化されたメッセージの一部とを用いて、前記メッセージを復号するためのパラメータを計算する機能と、
    前記パラメータを前記所定の端末装置に返送する機能と
    を前記コンピュータに実現させることを特徴とするプログラム。
19. 第１の公開鍵に対応する第１の秘密鍵と所定の制約条件と第２の公開鍵とに基づいて、当該制約条件の下で当該メッセージの復号が可能な委任鍵を生成するステップと、
    前記第２の公開鍵に対応する第２の秘密鍵を持つ外部機関に前記委任鍵の少なくとも一部を渡し、当該委任鍵による復号処理が前記制約条件を満足するかどうかの判定結果を当該外部機関から取得するステップと、
    前記委任鍵及び前記外部機関の判定結果を用いて前記第１の公開鍵により暗号化されたメッセージを復号するステップと
    を含むことを特徴とする復号方法。

Images